More diesel_smoke patch

[SirkoZ]

I see.
I must mention here, that I tried to play some of the OpenTTD COOP save games with around 1000 diesel/steam trains running at any time and it ran fine. How many vehicles does my patch "steal" from the array?

one for each steam/diesel cloud anywhere on the map.

Oh my.

Is there any way to make the patch client-side?

Yes, but you will not like this. You will need to split eyecandy effects from vehicles, that affects the game. Overloading the eyecandy one will not affect the game while overloading the vehicle will.

Say we got close to the limit of vehicles in a game. One player (A) got really intense smoke from his steam trains, so he takes up say 20 vehicle space for each locomotive. Another guy (B) only use 8 vehicle slots for each steam locomotive. Eventually B will build a new vehicle and the game will allow him to do so because it can find free vehicle slots. The same goes for the server, so they both build the new vehicle. A already used all his slots for steam and the game will fail to build the vehicle and now we got a game, where all clients will not have the same amount of vehicles in the game -> desync.

I really can't see any easy way out of this one and splitting the vehicles and the "eyecandy vehicles" is a massive job.

Oh boy - now how would I - a simple (open)TTD fan - a lousy programmer go about and do that (and I mean that)?
No really - was any such task as decoupling of eyecandy vehicles (e.g. shadows,...) and vehicles planned by the OpenTTD developers? Because it sounds to me, that the whole graphics engine would have to be altered.

Now - I would suggest for the time being - let's try and test the worst possible scenario - how many steam/diesel engines could there be on one map that would not affect the buying/selling the same or other vehicles?
I know it's not the best sollution, but what I remember from the internet Mini_IN/Integrated_build games, there were never any problems with buying vehicles...
What say you?

[DaleStan]

Is there any way to make the patch client-side?

Yes, but you will not like this. You will need to split eyecandy effects from vehicles, that affects the game. Overloading the eyecandy one will not affect the game while overloading the vehicle will.

Say we got close to the limit of vehicles in a game. One player (A) got really intense smoke from his steam trains, so he takes up say 20 vehicle space for each locomotive. Another guy (B) only use 8 vehicle slots for each steam locomotive. Eventually B will build a new vehicle and the game will allow him to do so because it can find free vehicle slots. The same goes for the server, so they both build the new vehicle. A already used all his slots for steam and the game will fail to build the vehicle

1) Since when was there a reachable limit on the total number of vehicles in the game? And if that's a soft limit, whoever thought it was a good idea to make special vehicles count toward this limit?
2) What's keeping you from kicking out a steam puff or two?

Or better yet, revert whatever change it was that changed the vehicle array from a split (690+160) array to a common pool. It's not like special effects need all ~100 bytes of vehicle data.

was any such task as decoupling of eyecandy vehicles (e.g. shadows,...)

Shadows aren't eyecandy. They're honest vehicles, and under normal circumstances are the mail compartment.

[SirkoZ]

was any such task as decoupling of eyecandy vehicles (e.g. shadows,...)

Shadows aren't eyecandy. They're honest vehicles, and under normal circumstances are the mail compartment.

I see. Thanks for the correction.

[peter1138]

To clarify:

There are actually 1024 reserved vehicle IDs just for special effects. These start from 0, and hence all real vehicles (including aircraft shadows) have IDs greater than 1024.

If there are too many special effects, then no more are created (until some are deleted). So they can't interfere with real vehicles, but could conceivably cause desyncs if clients have different settings, as some of the special effect handlers involve randomness.

[SirkoZ]

To clarify:

There are actually 1024 reserved vehicle IDs just for special effects. These start from 0, and hence all real vehicles (including aircraft shadows) have IDs greater than 1024.

If there are too many special effects, then no more are created (until some are deleted). So they can't interfere with real vehicles, but could conceivably cause desyncs if clients have different settings, as some of the special effect handlers involve randomness.

Very nice! So I see no problem.

The patch is server-side - so it's settled.

[SirkoZ]

Again - an update of the 2.0b (diesel) smoke patch - this time for source r10348+ - the one with thoroughly fixed (finally) smooth_economy.

[SirkoZ]

Another update to revision r10715 of the nightly source:

[White Rabbit]

What about this?

Why not have even more options for longer steam trails and more frequent puffs, like TTDP? While there's a difference between steam/smoke generated by this patch and default OTTD, I still think there's not nearly enough of it, and the patch doesn't compare with the Patch, if you know what I mean...

You 'duelly noted' it, but then forgot.

[SirkoZ]

Because I think the patch is good enough for now.
I mean - let's face it - it's still not in the main build although great many players have been really happy with it through the years of the integrated builds and also separate releases...
Not to mention there's no "bug" with it - like OpenTTD developers themselves said - if there's too many smoke phantom vehicles, OpenTTD will simply not draw them...but enough 'bout that.

[SirkoZ]

Here's the simpler version for the latest trunk with more either type of smoke emitted only at train's start 0-64 or some more km/h (decreases with speed for all 3 locomotive types).

[Bilbo]

To clarify:

There are actually 1024 reserved vehicle IDs just for special effects. These start from 0, and hence all real vehicles (including aircraft shadows) have IDs greater than 1024.

If there are too many special effects, then no more are created (until some are deleted). So they can't interfere with real vehicles, but could conceivably cause desyncs if clients have different settings, as some of the special effect handlers involve randomness.

There are two "random" generators - one that is used for simulating the game and is synchronized between client and server.
Second is "interactive" random, which is not synchronized, used for random events not communicated over network.

If those handlers would be rewritten to use the "interactive" random, it won't affect network game (ok, each of the clients would have slightly diferent eye candy, or even completely different if he desires and set it so. This could allow also perhaps some further optimizations (do not create eye-candy effects for vehicles not visible in current viewport, or create them with less detail)

[peter1138]

The 1024 reserved special vehicles no longer applies. That was removed quite some time ago.

[SirkoZ]

The 1024 reserved special vehicles no longer applies. That was removed quite some time ago.

Oh and you didn't tell me that, peter1138?

That's just great!

BTW - with ALL integrated builds, where we extensively played over the net (NOT lan) - there were NO desyncs - at least no because of any of my patches!



Bilbo - I can have those rewritten in a Jamie, but that's besides the point. The point is apparently my vehicle stuff just don't fit into Peter1138's little agenda.

[Bilbo]

Bilbo - I can have those rewritten in a Jamie, but that's besides the point. The point is apparently my vehicle stuff just don't fit into Peter1138's little agenda.

Its not the only patch devs don't want (now) in trunk ... some of my patches were either rejected (FS#924, FS#1060) or I received no response to them for long time (FS#1059, no response for last 2.5 months, had to resync with updates in trunk several times).

Although 10 of them ended up as accepted, though these were rather minor corrections ....

[SirkoZ]

Well - so are my - quite tiny, but very useful indeed and what is of the most value - well tested.

One can't help but feel frustrated...

[Ben_K]

Well, don't stress Sirkoz, just keep up the good work.

[SirkoZ]

Thank you Ben_K.

[SirkoZ]

New version - let's call it v3, shall we?

It's for trunk r15513 and it has been rewritten to be as simple as possible with amplified smoke effects for all locomotives (as usually).

File (patch):

[Benny]

Why isn't this in trunk? Does it have any bugs?
I love the patch by the way!

[Daniel Schuhmann]

Very nice patch - I like it!