[patch] Realistic Train Shunting

[supermop]

Use case for dividing orders is entering terminus station in reversed state (the loco pushing wagons) and then the loco can go somewhere else. It's meant for small cargo terminus stations. Or it can be used for some kind of shunting yard.

Currently it works pretty well for this, and I've been having fun with mainline locomotives leaving wagons in a siding, for a shunter to push into station. I love how this patch gives life to engines you wouldn't normally have cause to use.

The patch also makes the real-world advantages of multiple units manifest in game, as eventually I tire of making a headshunt at every end of line. I've been top-and-tailing some trains, but I hope the patch will encourage NewGRF authors to provide some cab cars / driving trailers for push-pull service.

There was suggestion to make it in a faster "hack" way with "contitional jump", but I personaly dislike those hacks in gui, it's annoying for gameplay and usually brings unwanted special cases. Basically what should solve all this is implementation of independent orders list, which I call global order list, that could store future orders of both train parts. But it will take a while to implement.

I agree that a special conditional order could work around this, but would likely not make it worth it. If nothing else, it would probably make it nearly impossible to schedule trains.

[SkullKrixzz]

so, i have given the patch a try, i like it, tho its quite confusing to me right now, is the steam whistle sound that happens during each decouple intended? i would assume so, that later on will probably be changed to a more fitting sound i guess to... im sure i can figure it out the more i play around with it, just looking forward to when its added to JGR pack.

[Snail]

version 0.10.3:
Fixed bugs from Snail's 1st and 2nd save game.
Added 0(auto) for number of wagons to decouple

Thanks, Karn! Those two bugs are now corrected.

Unfortunately, though, it looks like your implementation is interfering with my newGRF's way of choosing a train's livery when building it in the depot.
I'm writing a PM to you with some details on how to recreate this in a game (I don't want to bore everyone with such details here).

Another issue I'm seeing is in the vehicle details GUI. When a train reverses, it looks like the offsets there change, changing my sprites' positions (see picture)... This also happens in a depot: if a train reaches a depot when reversing, the in-depot graphics will all have different offsets. (Please note that, in my set, I specifically separate sprites for "viewport" from all other sprites, i.e. depot, vehicle GUI, purchase list...)

If I could suggest a way to solve this, perhaps your patch should change graphics in "viewport" only, and not in other views, if possible?

[Karn]

Another issue I'm seeing is in the vehicle details GUI. When a train reverses, it looks like the offsets there change, changing my sprites' positions (see picture)... This also happens in a depot: if a train reaches a depot when reversing, the in-depot graphics will all have different offsets. (Please note that, in my set, I specifically separate sprites for "viewport" from all other sprites, i.e. depot, vehicle GUI, purchase list...)

If I could suggest a way to solve this, perhaps your patch should change graphics in "viewport" only, and not in other views, if possible?

Defining custom graphics for gui is in my opinion problematic. There is problem with alignment of short vehicles in trunk. When you try your set in official branch of OpenTTD and set your language to right-to-left (for example arabic) and you try different combination of locos and wagons, you will see alignment glitches there too. I was trying to fix alignment problem in this patch (it's essential for NewGRFs that don't use custom gui sprites), which results in what you see because alignment is changed. Also I made a PR for trunk, but I'm holding back with it for a while, because it's going to affect GRFs that use this feature and I'm not sure about all the consequences yet. Ignoring custom gui graphic in this patch should be possible and easy if you are fine with it.

[Snail]

Defining custom graphics for gui is in my opinion problematic. There is problem with alignment of short vehicles in trunk. When you try your set in official branch of OpenTTD and set your language to right-to-left (for example arabic) and you try different combination of locos and wagons, you will see alignment glitches there too. I was trying to fix alignment problem in this patch (it's essential for NewGRFs that don't use custom gui sprites), which results in what you see because alignment is changed. Also I made a PR for trunk, but I'm holding back with it for a while, because it's going to affect GRFs that use this feature and I'm not sure about all the consequences yet. Ignoring custom gui graphic in this patch should be possible and easy if you are fine with it.

Unfortunately, there are some cases when we have no choice: vehicles longer than 8/8, for instance, need to use custom non-viewport graphics, since they're defined as 3 graphically separate parts in viewport (to avoid glitches), while they have a single sprite in depots, purchase list, vehicle GUI etc. So I'm afraid this patch will have to take this into account.
Additionally, all my horizontal sprites in viewport include a line of dark grey pixels underneath them, to draw a shade on the rails they travel on (otherwise you'd see shiny rails under a vehicle!). That shade shouldn't be there in views other than viewport, hence the need of custom sprites.

Alternatively, I would have to add one extra set of non-viewport sprites with different offsets and have a parameter to switch to them, if this patch doesn't explicitly support different sprites.

As for your other question (through PM), yours was a good catch: I do switch across liveries using the "getubyte" function, like this for example:

Code: Select all

// What's this engine's livery?
def(30) getubyte(
	engine(
		ref(24) if(1)	// Corsica
		ref(29) else	// Brittany
	)
)

This is the final part of the code for the engine in my example, where refs (24) and (29) are the final callbacks for each locomotive livery. I use a very similar code to choose the liveries of the wagons as well.

[Karn]

0.10.4: only change is to support liveries through user_data byte (getubyte).

It seems the current version is pretty stable now and reported bugs are not game breaking, so I'll work on something bigger from known issues list without minor updates. Hopefully it will end up in 0.11

[TrueSatan]

Option Forbid 90 degrees turn breaks shunting is missing on the list of someday to do

[Snail]

0.10.4: only change is to support liveries through user_data byte (getubyte).

This did the trick! Thanks Karn.

[Karn]

Option Forbid 90 degrees turn breaks shunting is missing on the list of someday to do

Known issues in the first post contain whole area that is bugged. Very specific bugs such as 90° would be annoying to maintain there. It's on my personal list and in the forum posts, which I think is sufficient for one man development.

0.10.4: only change is to support liveries through user_data byte (getubyte).

This did the trick! Thanks Karn.

I'm glad to hear that and there are no complains about anything else being broken by this change

[markyisri]

Hi,

Just a minor aesthetic issue I discovered while playing with NARS 2.51 and this patch starting in (virtual) year 2013. If you make the following kind of train:

1. EMD F59PHI (it seems to happen with any locomotive though)
2. Highspeed passenger cars (at least 3)
3. Any locomotive flipped around or the Cabbage Car

When realistic reversing happens, the fins on the leading and trailing passenger cars are flipped. I can attach a screenshot if you'd like.

I had a look in the code but couldn't find anything to suggest that wagons are flipped during reversing. Maybe I missed something?

[Mackensen]

I'm enjoying this patch a good deal; well done! Suggested feature: "couple any full load" in addition to "couple full", to match the any full load order. Ideally this would be paired with the cargo type, so you can effectively tell the locomotive "couple iff load type X is full."

[Jim Starluck]

Started poking around with OTTD stuff again recently. Haven't yet played with this patch, but I love that someone is finally making this sort of stuff work!

Question; is there an up-to-date daylength patch that this one plays nice with? If so, I may need to finally figure out how to apply patches myself instead of just depending on others for patchpacks...

[kamnet]

Started poking around with OTTD stuff again recently. Haven't yet played with this patch, but I love that someone is finally making this sort of stuff work!

Question; is there an up-to-date daylength patch that this one plays nice with? If so, I may need to finally figure out how to apply patches myself instead of just depending on others for patchpacks...

Pretty much the only updated daylength patch is maintained by JGR for use in his patchpack. Its probably not going to be suitable for patching vanilla OpenTTD.

[Jim Starluck]

Started poking around with OTTD stuff again recently. Haven't yet played with this patch, but I love that someone is finally making this sort of stuff work!

Question; is there an up-to-date daylength patch that this one plays nice with? If so, I may need to finally figure out how to apply patches myself instead of just depending on others for patchpacks...

Pretty much the only updated daylength patch is maintained by JGR for use in his patchpack. Its probably not going to be suitable for patching vanilla OpenTTD.

...well, nuts.

[kamnet]

Started poking around with OTTD stuff again recently. Haven't yet played with this patch, but I love that someone is finally making this sort of stuff work!

Question; is there an up-to-date daylength patch that this one plays nice with? If so, I may need to finally figure out how to apply patches myself instead of just depending on others for patchpacks...

Pretty much the only updated daylength patch is maintained by JGR for use in his patchpack. Its probably not going to be suitable for patching vanilla OpenTTD.

...well, nuts.

If you have an understanding of C++ and patching code in general, then the other patches probably won't take much work to make them work with the current master code. The main issue is going to be how well it works. The outstanding issues with all of the daylength patches still exists, and nobody has a way that seems to be completely satisfactory. So for that reason most work on this has come to a halt. JGR keeps his going because it suits his interests for his patchpack.

[Wahazar]

Are there compatible windows binary and corresponding source code? I would like to test this patch in multiplayer mode, but have no windows compiler.

[Karn]

Are there compatible windows binary and corresponding source code? I would like to test this patch in multiplayer mode, but have no windows compiler.

The source code is same on github and first post binaries, I always update them at the same time. I'm not sure about version string, there could be something special depending on how you download source code.

[Wahazar]

I tried to make locomotives from my set compatible with this patch (not flipping after reversal),
it was easy for single asymetric locomotives (shunters etc), but nightmare with multi-part locomotives, because it is not possible to switch articulated part length when outside depot - thus after reversal locomotive and its tender length doesn't match. I tried to add third invisible part, but it still doesn't look good and nml code is complicated.

[Leanden]

I tried to make locomotives from my set compatible with this patch (not flipping after reversal),
it was easy for single asymetric locomotives (shunters etc), but nightmare with multi-part locomotives, because it is not possible to switch articulated part length when outside depot - thus after reversal locomotive and its tender length doesn't match. I tried to add third invisible part, but it still doesn't look good and nml code is complicated.

Following.

[morzenmebs]

I just started using the patch and i cant figure out how to give a loco an order to reverse at a waypoint