Vehicles longer than default - glitches and solutions

[Eddi]

When playing with "realistic" NewGRFs, i frequently come to the conclusion that wagons, especially passenger wagons, are too short (compared to their width). as vehicle length is a fairly fundamental part of the game, it cannot easily be changed, so i have prepared a testing grf to discuss some problems and solutions involved.

0) before we begin, some fundamental terminology. in (Open)TTD, a tile is not the smallest unit, in fact, a tile is divided into a 16x16 grid of position, from here forward i will call the distance between those grid positions "length unit" (lu). translated to screen pixels, 1 lu in / (X) or \ (Y) direction is 2px left/right and 1px up/down, in | direction it is 2px up/down and in - direction it is 4px left/right. this length unit is relevant for both vehicle movement and vehicle sizes. a default vehicle is 8lu (1/2 tile) long, but newgrfs can shorten the vehicles in steps of 1lu. TTDPatch may have problems with vehicles shorter than 3lu, but these are not my concern here.

in my example, i will try to construct a 16lu wagon.

1) the first apparent problem for making a vehicle longer than 8lu is that the newgrf specs don't allow this, and the game engine will probably not be changed to allow this. the first obvious solution to that is to make a 2-part articulated vehicle, and give each part its own half of the vehicle graphics. an example of this approach can be seen in the DBSetXL 0.82 for the BR 194 (E 94) "German Crocodile".

2) while this is done fairly quickly, it has an immediate flaw: the vehicle "bends" in curves, because for the game, the vehicle is split in half. to solve this, we can use a larger sprite for one vehicle, and give an invisible (all transparent) sprite to the other vehicle. to ensure the "turning point" of the vehicle in curves is the center of the vehicle, the articulated setup can be changed from 8lu - 8lu to 4lu - 8lu - 4lu. the middle vehicle will be the visible one.

3) making the first part of the vehicle invisible has a nasty side-effect in the depot, where the sprite of the wagon is picked up as mouse cursor while dragging, so an exception must be done for vehicles in depots. dragging around articulated vehicles in the depot has other shortcommings, but they are not at immediate concern for now.

4) while the vehicle does not bend in curves anymore, it now sticks out very far out of the rails. the solution for that is to introduce more vehicle views than the default 4 (or 8 for asymmetric). i tried 8 (22.5° steps) and 12 (15° steps), and decided to go with 12, because for 8 the aligning is more tricky. to show the correct vehicle view, curvature info is used.

5) there is an internal problem that the bounding box of a vehicle is not shortened, when the vehicle is shortened, this leads to some unrelated bugs (see fs#3569), but the problem here is that the curvature info gives weird results in some occasions, since short vehicles don't rotate around their center, resulting in wagons moving "sideways" for short times. the workaround here until this is fixed is to change the length setup from 4-8-4 to 4-4-8.

6) now that we use curvature info to change the sprites, there is a problem with the GUI, because in vehicle details and vehicle lists, the curvature info is evaluated as well, showing weird wagons. a proposed solution here is to expand the specs with "extra callback info" when the sprite is resolved for the GUI. currently there is no implementation for this. this can also help with oversized ships like sailing ships, so the grf can provide reduced size sprites for the GUI.

7) and this is probably the most complicated. the vehicle glitches in tunnels, under bridges and near foundations. the idea here is to split up the sprites again to the individual vehicles, and assembling them in a way that they seem one large sprite. this, however needs more information than currently is available through curvature info. i have previously posted an unfinished patch providing 60+ variables to access vehicle positions and direction more than 1 vehicle ahead/behind as a followup to fs#2521, which can be used for this. another problem is that this requires lots of duplicated sprites with modified xrel/yrel values, since it is not possible to dynamically adjust these.

i have currently a testing GRF implementing up to step 5 (skipping 3)

[DJ Nekkid]

I once did have an idea to make a 'long trains' trainset with 'double length' both engines and wagons, but what you did with the wagons in the curves were quite nice

Wanna share some code?

[Eddi]

i could provide an nml template when i have the time to clean it up a little.

[Hyronymus]

About your point 7: it sounds like a lot of work to me to create workarounds to the current sprite drawing mechanism in OpenTTD. And I do think it's even more work to focus on adapting the sprite drawing mechanism to "new demands". But wouldn't that be far more promissing too?

[Eddi]

the problem is that this may very well result in a really huge code change, including adjustments to the newgrf spec, if dynamic xrel/yrel adjustments were to be implemented. it could also be a very big performance hit, if the (very frequent) sprite resolving mechanism gets overloaded with complicated newgrf callbacks.

the advantage of my method is that (aside from providing some more varaction2 variables) very little to no code change is required, and all the necessary calculations will be encapsulated in an nml template. you can then reuse this template for as many real vehicles as you wish, without worrying about the underlying complexity. it's a very little invasive, "do the complex task once, and then reuse it often" concept.

[DJ Nekkid]

That is the way we (or ATLEAST I) love it Altho i prefer 'real' nfo