Plantlike: Fix visual_scale being applied squared

[paramat]

Visual_scale was applied twice to plantlike by accident sometime between
2011 and 2013, squaring the requested scale value. Visual_scale is
correctly applied once in it's other uses in signlike and torchlike.

Two lines of code are removed, they also had no effect for the vast
majority of nodes with the default visual_scale of 1.0.
The texture continues to have it's base at ground level.
/////////////////////////////////////////////////////

New PR replacing #5070

Below, papyrus with 'visual_scale = 2.0'

^ Currently

^ This commit

See discussion in issue #5069

When added by celeron55 visual_scale was applied once eed727c here

minetest/src/content_mapblock.cpp

Line 825 in eed727c

vertices[i].Pos *= f.visual_scale;

Since then it was accidently applied a second time in S3DVertex.
Looks like it was broken during the many changes meant to keep the texture base at ground level, and no-one noticed the double application.

If approved i will make a post in the forum news section detailing the necessary adjustment to visual_scale, we are early in a release cycle so plenty of time for modders to make the quick edit.

If you are concerned about the mod breakage consider this: overall this will actually save modders time and frustration.
Currently a modder will want a texture, for example, 1.5 times larger, they use 1.5 and get something much bigger. Because they don't know the engine code responsible they won't know it has been squared, so they have to spend a few minutes using trial-and-error to get the texture exactly 1.5 nodes high, with associated small amounts of confusion and frustration.

This experience has happened to me more than once.
This benefit more than compensates for having to update a mod.

This will also make it easier to add new plantlike meshoptions in future, as the second application of visual_scale makes things complex. For example when i experimented with a plantlike meshoption that is fixed to ceilings and expands downwards with visual_scale it was difficult to get it to scale properly, i had to add code to undo the second application of visual_scale.

It was suggested that this transition could be done by introducing a new, correct, API with an alternative name like "visualscale" and deprecating the old one. This is a method sometimes done to avoid mod breakage, but in this case i consider this too messy and disruptive to be worth doing. It would need another node property added for nodes, extra code for handling old and new versions, and the new name would not match with the 'visual_scale' used for other drawtypes.

So, a little bit of pain but we can get this cleanly and simply sorted out.

[sofar]

👍

early enough in the release cycle so I think we should do this now.

[rubenwardy]

This breaks compatibility with old clients and mods. You should at least send the scale squared to old clients so they still work after mods are updated. It may be worth adding a flag to features

[kaeza]

It may be worth adding a flag to features.

Doing so is useless, as the mesh is created client-side and the server has no way to know what the client will do with the scale.

[rubenwardy]

server has no way to know what the client will do with the scale.

False, with my suggestions the client version doesn't matter, only the server version. Either way the client receives the scale the mod intends

[paramat]

Ah poo didn't think of old clients. I don't know how to write the compatibility code for old clients.

[paramat]

News post made in the forum with details of how to update mods.

[rubenwardy]

where it sends the visual scale to the client (nodedef serializer?) add a check for the clients protocol, and square it if lower than the current (29? I forget). Clients using a version in the last few days will be broken, but any before the last protocol bump will work on new servers. Don't forget to document in the network protocol version log. (all this is afaik)

[paramat]

Thanks.

[paramat]

#5138 merged.