More diesel_smoke patch

[petert]

Could you please update the first post SirkoZ?

[SirkoZ]

You mean with the latest version?

I guess I could... Always thought it's good enough if I have the link to the latest version in my sig...

[petert]

Well, most Patchmakers update the latest version in the first post, since thats what the thread is about.

[SirkoZ]

Done.

[petert]

Thanks, this helps me A LOT.

[Anon]

Crash when the train tries to reverse on a waypoint.

[SirkoZ]

Thank you for the heads-up. It is already fixed, but I haven't posted the new patch yet because I'm fiddling with some other aspects of it.
I'll have it posted shortly.

[SirkoZ]

Here it is - version 3.1 - now finally working as it should.
Trains no longer smoke also when given the turn-around-order and smoking or lack of it is as it should be on stations, no matter which _end setting (far_end/middle/near_end).
I've been fiddlin' around with non-excessive smoking on bridges, but even as it is there are a lot of checks and computations - besides - it's not bothersome at all.

Anyhow - trunk_patches for r20225 and 1-0-2_rel.

[ChillCore]

Hello SirkoZ,

I have added the new version to my patchpack (testfolder) and all seems to work again.
Thank you for the fixed update.
It is a very nice feature to have.

Have you had some feedback of this getting to trunk at some point in time or have you not yet asked?

[Timmaexx]

You don't ask dev's, the devs ask you!

[SirkoZ]

Hello SirkoZ,

I have added the new version to my patchpack (testfolder) and all seems to work again.
Thank you for the fixed update.
It is a very nice feature to have.

Have you had some feedback of this getting to trunk at some point in time or have you not yet asked?

Thank you for the kind words. I appreciate you including the patch in your patch pack - only this way more people that perhaps don't know how to apply it to trunk are able enjoy it.
As for developers - good one Timmaexx - they think it's a cosmetic addon which it is and at some point in trunk history their line used to be - this patch increases the number of overall sprites (smoke sprites) on the map too much and so is not feasible for inclusion. From what I know and I never experienced any difficulties with using it - max. sprite number now has been increased (long ago).
I don't know what is developers' du jour rationalisation for non-inclusion; the patch still is cosmetic - that says in my first post, they just may be too busy with various bug-reports and other features that involve more drastic changes, but I can't speak in their name.

[Eddi]

their line used to be - this patch increases the number of overall sprites (smoke sprites) on the map too much and so is not feasible for inclusion. From what I know and I never experienced any difficulties with using it - max. sprite number now has been increased (long ago).

actually, i think they meant vehicles, not sprites. for sprites it is relevant how many different are loaded from grfs, not how many are displayed. but each smoke puff is a vehicle that takes a slot in the pool, and must be processed when moving etc.

[SirkoZ]

their line used to be - this patch increases the number of overall sprites (smoke sprites) on the map too much and so is not feasible for inclusion. From what I know and I never experienced any difficulties with using it - max. sprite number now has been increased (long ago).

actually, i think they meant vehicles, not sprites. for sprites it is relevant how many different are loaded from grfs, not how many are displayed. but each smoke puff is a vehicle that takes a slot in the pool, and must be processed when moving etc.

I'm sorry - yes - you're right, Eddi - smoke puffs are vehicles. Well - still the number of them has since been increased; I could be wrong though.

[Rubidium]

Yes, we definitely meant vehicles. The problem will show especially when you're near the pool's limit (which has not been increased since r1783; more than 5 years ago) and it seems to me that more people are hitting that limit lately than before. So effectively lowering the limit by replacing "useful" vehicles by eye candy vehicles is going to make their savegames unplayable as the extra smoke fills the pool completely and that effectively halts autorenew and autoreplace.

If/when the size of the vehicle pool has been increased considerably the extra "smoke" vehicles would not matter that much anymore as the pool limit would be very very far away.

It might be an idea to "counter" the more smoke, thus the extra "slowdown" of due to more smoke vehicles, patch by another patch adding a setting for disabling those effects all together to make this the set of patches beneficial for those that want a game with as many vehicles as possible, those that don't have a very fast computer and those that want somewhat more realistic smoke/effects [I have not tested that, so it's an assumption I make].

[SirkoZ]

Thank you for the clarifications, Rubidium.
Is there any good way (no drastic mods needed) to not treat smoke/eye-candy as vehicles?

For what it's worth - I used to include a smoke reduction switch in there....could put it in again...

[ChillCore]

You don't ask dev's, the devs ask you!

I thought that was when you have the desire to become a Dev ...

Sprites?

Umm, vehicles ...

Yes, vehicles.
Maybe add a setting to disable smoke effects and related.

For what it's worth - I used to include a smoke reduction switch in there....could put it in again...

Please do.
As Rubidium suggested make it a two stage inclusion.
First a patch that enables disables the vehicle effects. Setting in advanced settings -> enable disable/original behaviour.
Then a patch that lets you select a third option -> Pseudo-realistic aka more_diesel_smoke.
(Or maybe easier and more fun to do, write the second one first and then derive the first one for lubricating the trunk inclusion of the second. )

My games are unlikely to hit the vehicle pool limit any time soon but I would love to see a coopgame with triple the amount of vehicles. (Or seeing one of their current big games run at full speed.)
If they can disable the vehicle effects this would be possible without increasing the vehicle pool limit for the moment?

Is there any good way (no drastic mods needed) to not treat smoke/eye-candy as vehicles?

I think you would need to make an entire new class for that to happen. The only thing that can make smoke move the way it does is vehicles for the moment. That is, if I am not mistaking -> shadows and rotors are vehicles too. I think vehicles is fine if the intent is to increase the pool limit later on.
Another question that pops up is: Could this be a clients side settings and could it cause deyncs if the number of vehicles/other class thingies is not the same for all clients?

[Yexo]

My games are unlikely to hit the vehicle pool limit any time soon but I would love to see a coopgame with triple the amount of vehicles. (Or seeing one of their current big games run at full speed.)
If they can disable the vehicle effects this would be possible without increasing the vehicle pool limit for the moment?

As far as I know most openttdcoop games don't come even near the vehicle limit, so there is no problem there.

Another question that pops up is: Could this be a clients side settings and could it cause deyncs if the number of vehicles/other class thingies is not the same for all clients?

It'll cause desync as long as smoke is a vehicle, if smoke would be moved to a different class then it could work. It is however possible to introduce a client setting that hides (as in doesn't draw) the smoke.

[SirkoZ]

...

For what it's worth - I used to include a smoke reduction switch in there....could put it in again...

Please do.
As Rubidium suggested make it a two stage inclusion.
First a patch that enables disables the vehicle effects. Setting in advanced settings -> enable disable/original behaviour.
Then a patch that lets you select a third option -> Pseudo-realistic aka more_diesel_smoke.
(Or maybe easier and more fun to do, write the second one first and then derive the first one for lubricating the trunk inclusion of the second. )

My games are unlikely to hit the vehicle pool limit any time soon but I would love to see a coopgame with triple the amount of vehicles. (Or seeing one of their current big games run at full speed.)
If they can disable the vehicle effects this would be possible without increasing the vehicle pool limit for the moment?

Well that's nice - I shall make it so.
...

My games are unlikely to hit the vehicle pool limit any time soon but I would love to see a coopgame with triple the amount of vehicles. (Or seeing one of their current big games run at full speed.)
If they can disable the vehicle effects this would be possible without increasing the vehicle pool limit for the moment?

As far as I know most openttdcoop games don't come even near the vehicle limit, so there is no problem there.

This is encouraging.

[SirkoZ]

Replying myself - couldn't resist.

Anyhow - I've finally put it together - v3.2 with regulation back (last diesel_smoke patch that had regulation was back in r15xxx and 2.0b ).
It has 3 regulating states 0 = no smoke is emitted from any train, 1 = small amount of smoke and 2 = diesel_smokin' - the realistic/previous patched amount of puffs/smoke/sparks.

I didn't make it as two patches though because it is so small and settings touch the very workings of it. Besides - with setting 0 = no smoke, puffs/smoke/sparks calculations are even considered, so it really saves that many effect_vehicles and also CPU cycles. As for the latter - even when enabled, bit-shifting is used as often as possible (as I like to do) because it's free on X86 processors (if I recall correctly).

By the way - I'll also post it to FlySpray...

Enjoy!

[Eddi]

bit-shifting is used as often as possible (as I like to do) because it's free on X86 processors (if I recall correctly).

that can be a serious pitfall.

firstly, nothing is "free", every action takes some time.

secondly, the compiler can optimise certain actions way better than you can. but for this to work, you must give the description what you really want to do as clear as possible.

for example, a compiler may catch a static multiplication by 2: a*2, and replace it with the fastest alternative possible. that may be a shift: a<<1, or an addition: a+a, or something entirely different, depending on which platform the code will run. in that case, the multiplication is the most portable and most clear piece of code. if you try to "optimise" things by hand, you might obfuscate it enough that the compiler cannot detect these special cases anymore, so the code might even get slower, but at least less maintainable.