More flexible vehicle lengths

[jamespetts]

The recent addition of the ability to put decimal places in vehicle weight was most worthwhile. I wonder whether we could do the same with the length of vehicles? Currently, it is often the case that railway carriages will either have too large a gap between them with one length setting or too small a gap between them with the immediate next length setting. Being able to set, for example, "length=7.5" would greatly assist the look of the game.

[Ters]

Technically, there isn't any decimal places i weight. The basic unit of weight was "simply" changed from tons to kilograms, but makeobj still reads the value in terms of tons and converts it to kilograms. Similarly, Simutrans converts from tons to kilograms when reading old paks.

To get what you want, one has to change the basic unit of length in Simutrans. I actually think one can do that already, either in simuconf.tab or some constant in the code, though there might be drawbacks. Or I might remember incorrectly. The length of the vehicle should then be given as 15, 75 or something like that.

[jamespetts]

Hmm, interesting. Does anyone remember what the drawbacks are, apart from having to change the length of all vehicles in a pakset?

[Ters]

Hmm, interesting. Does anyone remember what the drawbacks are, apart from having to change the length of all vehicles in a pakset?

Having to rewrite all the formulas that depend on the value having it's current value, for the most part the ones using shift instead of division, and those that would overflow with a higher value. Higher values also means that some data types may need to be lengthened, which might ruin structure packing and cache line alignments. This is likely more problematic with positions than it was for weights, as everything has a position, but not everything has a weight (in the simulation).

So it's not as easy to just change the #defines like it might first appear. That it's #defines also means that it's a global, not a per pak set, setting.

[jamespetts]

Hmm - we really ought to be using division instead of shift in any event. Don't modern compilers automatically optimise to the equivalent speed of bit shift where possible in any event?

[Ters]

Hmm - we really ought to be using division instead of shift in any event. Don't modern compilers automatically optimise to the equivalent speed of bit shift where possible in any event?

Modern compiler probably will, but a problem Simutrans has a history of encountering is a platform without a modern compiler. I don't know if that has changed.

[prissi]

The current system has intervals of four pixels in pak128 size. Given the very distorted scales of teh game (i.e. length distances and vehcile dimensions), I would rather tweak the vehiles a little, should there be a gap a pixel too large. But in the end the change could be done on pak load time, i.e. multiplying of versions with 16, to have the same 256 steps per tile. (This might even save some operations in vorfahren and the like).

[jamespetts]

Interesting idea. Alternatively, one could specify the spacing in units of single pixels rather than four, and have old paksets just multiply the number by four on loading?