OTTD - extending control over smoke / visual effects

[andythenorth]

OTTD r21240 added support for visual effects (smoke etc) for RVs and ships, which is awesome

For ships, the current method of specifying a z offset for one effect vehicle is insufficient. Ships may have:
- n funnels (n<6 in a sane world)
- funnels offset laterally (at sides of ships)
- end of funnel may be somewhat higher than default z index for smoke (currently 10)
- ships should be able to produce diesel smoke constantly, not just when accelerating

I discussed somewhat with frosch who proposed a solution.

http://bugs.openttd.org/task/4263

[michael blunck]

OTTD r21240 added support for visual effects (smoke etc) for RVs and ships, which is awesome [...]

Aha. So this is a "side effect" of that new feature?

regards
Michael

[Hirundo]

OTTD r21240 added support for visual effects (smoke etc) for RVs and ships, which is awesome [...]

Aha. So this is a "side effect" of that new feature?

regards
Michael

"Bug reports" like these are extremely helpful.... as you should know.

I assume there's nothing that needs to be changed/fixed in any way?

[michael blunck]

[...]

"Bug reports" like these are extremely helpful.... as you should know.

I assume there's nothing that needs to be changed/fixed in any way?

That post was not a bug report. I´ve just seen it somewhere else and was already wondering ...

As you might know, I´m using http://bugs.openttd.org/ for bug reports.

regards
Michael

[ChillCore]

"Bug reports" like these are extremely helpful.... as you should know.

I assume there's nothing that needs to be changed/fixed in any way?

http://www.tt-forums.net/viewtopic.php? ... &start=722

I have not yet tested the earlier revisions of OpenTTD to see when exactly this bad behaviour was introduced.
If someone would be so kind ... if nobody finds time I will report later.

[michael blunck]

http://www.tt-forums.net/viewtopic.php? ... &start=722

I have not yet tested the earlier revisions of OpenTTD to see when exactly this bad behaviour was introduced.
If someone would be so kind ... if nobody finds time I will report later.

Yeah, http://www.tt-forums.net/viewtopic.php?p=914741#p914741

That´s exactly the same train (BR420 EMU from DBXL v0.82; I think my pic was from the German tt-forums). Seems to be a bug indeed.

regards
Michael

[Hirundo]

I have run some debugging tests with a recent trunk version + DBSetXL. It turns out that the problem is caused by returning 0 as callback result for CB 10 for the third (and sixth, etc) wagon in the consist.

Unlike previous versions of OpenTTD (and I presume, TTDPatch), recent OpenTTD nightlies actually exhibit the documented behaviour, which is to show the default visual effect 8 units ahead of the vehicle. The default visual effect is determined by prop 19, which has a (documented) default value of 00 i.e. steam. Therefore, steam puffs are shown ahead of the vehicle, so they appear to be coming from the second unit in the chain which has a pantograph. This vehicle still shows sparks, though, albeit these are hardly visible amidst the smoke.

So the observed behaviour in OpenTTD's nightlies seems correct to me. If there's a bug, I'd say it's in the NewGRF.

[michael blunck]

[...] If there's a bug, I'd say it's in the NewGRF.

LOL

regards
Michael

[Hirundo]

[...] If there's a bug, I'd say it's in the NewGRF.

LOL

Care to explain what's funny here?

If you want to imply that I'm wrong, please provide actual arguments.

[Lakie]

So in the OpenTTD nightlies (whilst keeping compatibility with TTDPatch) what value should we return, if any, for the callback to have no effect generated, (just out of curiosity)?

~ Lakie

[Hirundo]

So in the OpenTTD nightlies (whilst keeping compatibility with TTDPatch) what value should we return, if any, for the callback to have no effect generated, (just out of curiosity)?

~ Lakie

Returning 0x40 disables any visual effect.

[michael blunck]

Care to explain what's funny here?

If you want to imply that I'm wrong, please provide actual arguments.

The BR420 in DBXL v0.82 is a bit special. Unlike in v0.9, it´s not an articulated EMU, but has to be composed by the player by adding 2 passenger coaches to it.

Furthermore, in v0.82, the BR420 (veh-ID 67h) uses all three visual effects:

- 0x00
- 0x34
- 0x40

Prop19 for the BR420 itself is set to "30" (i.e. "electric"), thus:

"00..0F Use the default effect type from property 19, but reposition it"
http://wiki.ttdpatch.net/tiki-index.php ... n_power_22_

Default effect type for "electric" is "sparks".

Now, when adding the local passenger coach (veh-ID 1B), things might go wrong, because for this ID, prop19 is not being set at all. OTOH, ID 1B sets prop22 to "40". So ...


This had been worked for more than 5 years, and it still works in OTTD r21243. I really wonder what has been changed since then and whether it´s in compliance with the specs.


[edit]
Aha!

Powered wagon callback (10)

This callback is used to determine whether a wagon is powered (adding power and weight to the train) and what visual effect to use for the wagon. It only applies if the wagon would by default be powered (i.e. property 1B is set), and is only called when loading a game, when the train reverses, or when rearranging the train in a depot. If the callback fails for any reason (e.g. not defined, action 2 does not return callback result etc.), the value of property 22 is used instead. For possible return values, refer to train property 22.

http://wiki.ttdpatch.net/tiki-pagehisto ... allback_10_

Now, a certain "Hirundo" steps in ("Update information about CB10"):

Visual effect and wagon power (10)

This callback is used to determine the visual effect to use for a vehicle and whether a train wagon is powered (adding power and weight to the train). In TTDPatch, it only applies for train wagons that would by default be powered (i.e. property 1B is set), and is only called when loading a game, when the train reverses, or when rearranging the train in a depot. In OpenTTD it is called for all trains and (since r21238) for road vehicles and ships as well. If the callback fails for any reason (e.g. not defined, action 2 does not return callback result etc.), the value of the corresponding action 0 property ( train property 22, road vehicle property 21, ship property 1C ) is used instead. For possible return values, refer to these properties as well.
http://wiki.ttdpatch.net/tiki-index.php ... n_power_10_

(emph. by mb)


Conclusion: The BR420 in DBXL 0.82 is in accordance with the specs (before "Hirundo" did modify them). The attached passenger coaches might lack prop19, but they don´t need to include it, simply because they have not set prop1B. And, in this way, CB10 may not manipulate any visual effects, or add them like in this case.
[/edit]

regards
Michael

[Hirundo]

The change I documented there has been in trunk since r5061, which is more than four years ago. I merely documented the already existing behaviour of OpenTTD.

Now, when adding the local passenger coach (veh-ID 1B), things might go wrong, because for this ID, prop19 is not being set at all. OTOH, ID 1B sets prop22 to "40". So ...

Since prop19 is not set, the 'steam' engine class is taken as default (as is documented). A CB10 value of 00 means the following:

00..0F Use the default effect type from property 19, but reposition it

Which is exactly what recent versions of OpenTTD do. Previous versions showed nothing for values of 00..0F for wagons and for 00 altogether. I think that the recent changes (resulting in a 'better' implementation of the specs at this point) caused OpenTTD's existing undocumented behaviour w.r.t. CB10 to break DBSetXL.

[michael blunck]

I think that the recent changes (resulting in a 'better' implementation of the specs at this point) caused OpenTTD's existing undocumented behaviour w.r.t. CB10 to break DBSetXL.

In different words: you´ve been introducing that bug, not Peter, back in 2006 (somehow he managed to escape incompatibility).

This callback is used to determine whether a wagon is powered (adding power and weight to the train) and what visual effect to use for the wagon. It only applies if the wagon would by default be powered (i.e. property 1B is set) [...]

This is the spec DBXL 0.82 has been developed for in 2005.

This callback is used to determine the visual effect to use for a vehicle and whether a train wagon is powered (adding power and weight to the train). In TTDPatch, it only applies for train wagons that would by default be powered (i.e. property 1B is set), and is only called when loading a game, when the train reverses, or when rearranging the train in a depot. In OpenTTD it is called for all trains [...]

Not this one, which has been added by you on Thu 18 of Nov, 2010.

regards
Michael

[ChillCore]

I have run some debugging tests with a recent trunk version + DBSetXL. It turns out that the problem is caused by returning 0 as callback result for CB 10 for the third (and sixth, etc) wagon in the consist.

Unlike previous versions of OpenTTD (and I presume, TTDPatch), recent OpenTTD nightlies actually exhibit the documented behaviour, which is to show the default visual effect 8 units ahead of the vehicle. The default visual effect is determined by prop 19, which has a (documented) default value of 00 i.e. steam. Therefore, steam puffs are shown ahead of the vehicle, so they appear to be coming from the second unit in the chain which has a pantograph. This vehicle still shows sparks, though, albeit these are hardly visible amidst the smoke.

So the observed behaviour in OpenTTD's nightlies seems correct to me. If there's a bug, I'd say it's in the NewGRF.

Thank you for further testing Hirundo, much appreciated.

ps:
I am not familiar with all those bits and callbacks but I somehow feel that this topic should be split as recent discussion does not seem related to OP.
Sorry andythenorth for YAOP -> (Yet Another Offtopic Post.)

[andythenorth]

I would prefer if some of this somewhat bad tempered discussion went somewhere else. It's in some ways irrelevant to my original post.

thanks,

Andy

[PikkaBird]

It's somewhat on topic imo. Play nicely, gentlemen. Also; woo, smoky ships and rvs!

[Hirundo]

How do you (andy / frosch) suggest to activate the new behaviour of CB 10? Is there some sort of flag a grf needs to set, or do you simply call CB10 anyways?
Could performance be affected adversely, if a grf decides to output a lot of smoke clouds each tick? Should this be limited, and to what amount?

I think that the recent changes (resulting in a 'better' implementation of the specs at this point) caused OpenTTD's existing undocumented behaviour w.r.t. CB10 to break DBSetXL.

In different words: you´ve been introducing that bug, not Peter, back in 2006 (somehow he managed to escape incompatibility).

The specs state this:

00..0F Use the default effect type from property 19, but reposition it

There is nothing here that states that this should not apply to wagons (powered or not). Therefore, it is logical to assume that this applies to all vehicles.

Yet, TTDPatch (multihd.asm:1234), contains this clarifying comment:

// for wagons, 00..0F counts as 40 (no effect) here

How is this included in the NewGRF spec, either now or in 2005?

As of recently, OpenTTD has adopted the behaviour as specified by the specs, which differs from the behaviour in TTDPatch. Does that make OpenTTD wrong?

Personally, I'm fine with changing the default effect for wagons (back) to 'no effect'. How to handle powered wagons remains a question. Should they use their own prop19, the prop19 of their associated front engine, or 'no effect' as default? All of this should of course be documented in the specs.

[michael blunck]

I think that the recent changes (resulting in a 'better' implementation of the specs at this point) caused OpenTTD's existing undocumented behaviour w.r.t. CB10 to break DBSetXL.

In different words: you´ve been introducing that bug, not Peter, back in 2006 (somehow he managed to escape incompatibility).

Your citations are incorrect.

The specs state this:

00..0F Use the default effect type from property 19, but reposition it

There is nothing here that states that this should not apply to wagons (powered or not). Therefore, it is logical to assume that this applies to all vehicles.

You didn´t read the spec correctly.

According to the spec, prop19 only sets the visual effect if no prop22 specified. As a result, the coach in question is not set to effect "steam".

Only CB10 can override prop22, but if a vehicle does not set prop1B, CB10 is not applied. It´s all in the spec.

As of recently, OpenTTD has adopted the behaviour as specified by the specs, which differs from the behaviour in TTDPatch. Does that make OpenTTD wrong?

IMO, Peter´s modification back in 2006 (r5061) has not been adherent to the spec, but something else prevented it to show up as that particular bug. Only as of r21249 this bug had set free.

Chillcore had reported about the effect of simply reverting r5061 in a recent post, but obviously, this needs some more testing because of possible side effects (?).

Personally, I'm fine with changing the default effect for wagons (back) to 'no effect'. How to handle powered wagons remains a question. Should they use their own prop19, the prop19 of their associated front engine, or 'no effect' as default? All of this should of course be documented in the specs.

Maybe I don´t see the point here, but what´s unclear in the specs?

A "powered wagon" uses its own props 19, 22 and 1E. In addition, it has set prop0B to a non-zero value.


On-topic: w/r to ships, I don´t see much use in the current generalisation w/o the possibility to specify custom effect graphics.

regards
Michael

[Andrew350]

Sorry to dig up an old topic, but I was wondering what came of this? Having only one axis to adjust the visual effect is almost useless, and it would be nice for ships to be able to have multiple smoke plumes (one for each stack). Also, everything else andy said . I don't see any clear conclusion in the discussion, so maybe something behind-the-scenes was reached? Or maybe I'm just not looking in the right places?

Anyway, maybe someone can enlighten me, I'd like to know

Also, this.