Station tile trigger re-randomisation and CB14

[michael blunck]

Am I right in presuming that station tile trigger re-randomisation does not work in a CB14 chain?

Most of the large station sets are using CB14 in a varAction2 chain to define the sprites to draw for a particular tile, depending on decisions done inside a varAction2 chain. But I´ve never seen a proper re-randomisation by station triggers like "new cargo waiting", "train arrives", etc.

In any case, this does not work for NewStations, and so I checked CanStations set (which uses trigger "no more cargo") and ISR (which doesn´t use re-randomisation at all).

In a next step I´ve been searching the forums and only found a very old posting of Josef Drexler about that problem.

Is this still valid, for OpenTTD? What´s the status quo?

regards
Michael

[Yexo]

Randomization triggers are very badly documented as you've probably found out the hard way by now. Every time a trigger is hit by the OpenTTD code it runs "CB 1", which is a special callback used only to determine if re-randomisation should happen. Since CB1 is so badly documented (I haven't seen a project which implemented it directly) it always goes to the "default" graphics chain. Only re-randomisations part of the CB1 chain will actually happen.

[michael blunck]

Hm. Never heard any details about CB1, only its name, by rumour.

So, two questions.

- I´ve never used CB1 explicitly, but yet all re-randomisations (e.g. for trains) have been run "implicitly"? Except now in connection wiith CB14, neither in TTDPatch nor in OpenTTD?

- would it be possible to use both CBs (1 + 14) to achieve the desired result?

Another remark about "bad documentation": It´s nowhere documented that you can´t use certain features in a varAction2 chain. I even did never see Josef´s post from 2005 until today ...

regards
Michael

[peter1138]

Station randomisation triggers aren't implemented in OpenTTD, No reason, it just hasn't been done. I think I actually intended to do it when I was implementing station animation triggers, but never got around to it.

As dbsetxl uses randomisation triggers, I suspect you know how they are implemented. CB 1 is not documented, but that variable 10 is indeed set to 1 for the trigger, in both OpenTTD and TTDPatch. However this may be an internal implementation detail of TTDPatch that got copied in OpenTTD, as it isn't necessary to test for CB 1 as having RandomAction2s in the chain when is sufficient. When not processing a trigger, the same RandomAction2s are used to select the appropriate branch by the randomised data (it's stored persistently, obvious, otherwise there'd be no point in it), so testing for CB 1 is would probably be the wrong thing to do anyway.

The "big problem" that Josef talked about was just an implementation detail in TTDPatch, and relates to how the random data is stored. This isn't an issue in OpenTTD and I doubt it is in TTDPatch either any more.

[Michi_cc]

However this may be an internal implementation detail of TTDPatch that got copied in OpenTTD, as it isn't necessary to test for CB 1 as having RandomAction2s in the chain when is sufficient.

I do think it can be necessary, for example if you want a RandomAction inside the CB36 chain (as recently seen for the nice NUTS desync). At least in OTTD re-randomization always happens as CB1 and will not touch the CB36 chain unless you extend the CB-decision VarAct2 to "CB == 36 || CB == 01". No idea how to apply that to multiple RandActs in different CB chains, as you can only enter one chain (except maybe for some trickery with procedure calls).

-- Michael Lutz

[michael blunck]

Station randomisation triggers aren't implemented in OpenTTD [...]

So, this is not for real?

Stations have 16+4 random bits. Bits 0 to 15 are a property of the station as a whole, and bits 16 to 19 are different for each tile. To get tile-based randomness, therefore use randbit=10 and nrand of no more than 16 (since only 4 random bits are available per tile).

http://newgrf-specs.tt-wiki.net/wiki/Ra ... 2#Stations

The "big problem" that Josef talked about was just an implementation detail in TTDPatch, and relates to how the random data is stored. This isn't an issue in OpenTTD and I doubt it is in TTDPatch either any more.

I totally don´t understand this sentence:

The big problem is that this callback is used for so many different things, vehicles, track type and stations so far [...]

Because CB14 is ONLY being used for stations! Except, he´s talking about that mysterious CB1 ...

Now, anyway.

In stations, CB14 can/is only used for graphical variations, it is not, and cannot be, used for changing properties. And from a layman´s perspective, I can´t understand why there should be a difference between a graphics reference and a callback result (which, in this very case is just a pointer into a sprite layout structure). In addition, there has never and nowhere been mentioning this limitation in the documentation, neither for varAction2 nor for randomAction2. So IMO, this is kind of weird.


This is how "re-randomisation" has been used in NewStations since years (for those "passengers" on station platforms), which in hindsight, did never work as intended (i.e., no re-randomisation taking place):

Code: Select all

// single track

// platform loads
2359 * 0 02 04 01 08 01  00 80 00 80 08 80 10 80 18 80 20 80 28 80 30 80  38 80 
2360 * 0 02 04 02 08 01  00 80 08 80 10 80 18 80 20 80 28 80 30 80 38 80  40 80 
2361 * 0 02 04 03 08 01  00 80 10 80 18 80 20 80 28 80 30 80 38 80 40 80  40 80 

// re-randomise on train arrive
2362 * 0 02 04 04 80 04 10 04  01 00  02 00  02 00  03 00 

[...]

// single platform?
2380 * 0 02 04 0a 81 40 14 0F 01
	04 00 01 01   // single track
	09 00 
 
// callback
2381 * 0 02 04 20 85 0C 00 FF FF 01
	0a 00 14 00  14 00   
	00 00 

//------------------------------------------------------------------
// ID=04 (roofs)
//------------------------------------------------------------------

2383 * 0 03 04 01 04 03
	ff  21 00  		// menu
	00 20 00
	fe 20 00  
	20 00

I would really appreciate an eventual implementation of re-randomisation triggers for stations as documented in the specs.

regards
Michael

[peter1138]

It's for real, the RandomAction2s still select the appropriate targets and the random bits are stored persistently, just the triggers aren't implemented so the random bits never change after first build.

[michael blunck]

Well, OK.

So the old code will automatically start to work as intended, if ever stations triggers will be implemented.

[edit]
Backtracking this issue further is quite amusing.

In fact, station trigger re-randomisation in TTDPatch seems to be implemented, but indeed not when in a CB14 chain. This is even more astonishing, because back in 2005, Josef and me were discussing the way station random triggers should be implemented on a nearly day-to-day basis, and also CB14 had been implemented just before, because I needed something like this for the first implementation of NewStations. It´s a mystery to me why he didn´t mention that all those thoughts would be totally useless with this set in mind, w/o the possibility to also use re-randomisation when in a CB14 chain.

Another funny thing is that missing re-randomisation went unnoticed in NewStations for so many years, and also in the CanStations Set whose code includes station trigger re-randomisation as well.
[/edit]

regards
Michae

[Eddi]

i'm not entirely sure whether i understand the problem correctly, but besides the triggers not being implemented in OpenTTD, the issue seems to be that rerandomisation calls CB1, and whichever triggers it comes across during processing the chain, will get rerandomised, right?

so in order to traverse both the default chain and the CB14 chain, you thus need at the end of the default chain a switch "if current_callback == 1: goto cb14_chain, else goto action2"

[michael blunck]

i'm not entirely sure whether i understand the problem correctly, but besides the triggers not being implemented in OpenTTD, the issue seems to be that rerandomisation calls CB1, and whichever triggers it comes across during processing the chain, will get rerandomised, right?

so in order to traverse both the default chain and the CB14 chain, you thus need at the end of the default chain a switch "if current_callback == 1: goto cb14_chain, else goto action2"

I have no idea what this "callback 1" is or what it should do in this particular case, since its completely undocumented, aka "non-existant".

regards
Michael

[frosch]

i'm not entirely sure whether i understand the problem correctly, but besides the triggers not being implemented in OpenTTD, the issue seems to be that rerandomisation calls CB1, and whichever triggers it comes across during processing the chain, will get rerandomised, right?

so in order to traverse both the default chain and the CB14 chain, you thus need at the end of the default chain a switch "if current_callback == 1: goto cb14_chain, else goto action2"

Yes, and afaik NML even does such stuff.

[peter1138]

i'm not entirely sure whether i understand the problem correctly, but besides the triggers not being implemented in OpenTTD, the issue seems to be that rerandomisation calls CB1, and whichever triggers it comes across during processing the chain, will get rerandomised, right?

Wrong way around. A trigger happens as a defined event (e.g. train enters a platform) which then follows the Act 3-2-1 chain for each appropriate station tile. If a RandomAction2 is encountered, the bits to reseed are updated and the chain continues. Once the chain is completed, if a result is returned (and as far as I remember it must be as the there's no way to not have a result), rerandomisation happens based on the bits to reseed.

If the RandomAction2s are before the CB14 chain is selected, then they will work correctly. If the RandomAction2s are hidden after a CB14 chain, then they won't be seen by the trigger because it won't be following the code for the CB14. During callbacks, RandomAction2s are valid to select the appropriate value from the random data, but the random data will never change.

so in order to traverse both the default chain and the CB14 chain, you thus need at the end of the default chain a switch "if current_callback == 1: goto cb14_chain, else goto action2"

But as previously stated, "CB1" doesn't actually exist. The correct way, I believe, is to have the RA2s in the chain before the CB selector, and then include them again after the CB14 selector so that you the chain can decide based on the random data.

Michael, I have implemented station triggers (as a patch so far) and they do appear to operate with newstats (i.e. the RandomAction2s are being seen when the trigger follows the Act 3-2-1 chain), although I don't know if it's operating correctly.

[Michi_cc]

But as previously stated, "CB1" doesn't actually exist. The correct way, I believe, is to have the RA2s in the chain before the CB selector, and then include them again after the CB14 selector so that you the chain can decide based on the random data.

I have no idea what TTDPatch does, but OpenTTD sets variable 0C ("current callback ID (feature-specific)") to 0x01 when doing re-randomization for vehicles. It might not be an official CB, but to me it looks like any other CB.

-- Michael Lutz

[michael blunck]

If the RandomAction2s are hidden after a CB14 chain, then they won't be seen by the trigger because it won't be following the code for the CB14

This is the key sentence, and we´re back to the discussion woith Josef in 2005.

IMO, this makes no sense (besides the fact that this limitation has never been part of the spec, at least not explicitly). Using a random action inside a chain should be "transparent" to the user, both for graphics or callback results, no fancy extra code should be involved.

Michael, I have implemented station triggers (as a patch so far) and they do appear to operate with newstats (i.e. the RandomAction2s are being seen when the trigger follows the Act 3-2-1 chain), although I don't know if it's operating correctly.

In NewStats only the passenger graphics on some of its station tiles should be re-randomised. So, just observe one certain tile on a platform until all passenger graphics have been removed (by a train). Now, the old behaviour was that the very same cycle would be re-iterated when passengers pile up again. This should have been changed with introducing random triggers.

regards
Michael

[peter1138]

But as previously stated, "CB1" doesn't actually exist. The correct way, I believe, is to have the RA2s in the chain before the CB selector, and then include them again after the CB14 selector so that you the chain can decide based on the random data.

I have no idea what TTDPatch does, but OpenTTD sets variable 0C ("current callback ID (feature-specific)") to 0x01 when doing re-randomization for vehicles. It might not be an official CB, but to me it looks like any other CB.

TTDPatch also sets the current callback ID to 0x01, which is most likely why OpenTTD does. One probable reason is that TTDPatch will ignore a callback result if it is not expecting one, and it tests the current callback to do this. This means triggers will still work where ever the RA2 leads.

IMO, this makes no sense (besides the fact that this limitation has never been part of the spec, at least not explicitly). Using a random action inside a chain should be "transparent" to the user, both for graphics or callback results, no fancy extra code should be involved.

Do RandomAction2s predate callbacks perhaps, in which case this may not have been considered? As far as I can tell there is no way to make it transparent like you suggest because triggers and callbacks are separate events executed at different times. The chain that is followed is up to the NewGRF to decide.

[michael blunck]

IMO, this makes no sense (besides the fact that this limitation has never been part of the spec, at least not explicitly). Using a random action inside a chain should be "transparent" to the user, both for graphics or callback results, no fancy extra code should be involved.

Do RandomAction2s predate callbacks perhaps, in which case this may not have been considered? As far as I can tell there is no way to make it transparent like you suggest because triggers and callbacks are separate events executed at different times. The chain that is followed is up to the NewGRF to decide.

What I read from the specs, a random action2 can both handle graphics and callbacks. Even a normal action2 can handle callbacks (like I do in NewStations). Would be a pity if triggers for such random action2s would be impossible. IMO, this would look like a conceptual flaw.

regards
Michael

[peter1138]

Here's a test, along with the NewGRF sources. Not much in the way of complex chains though...

[michael blunck]

[...] Not much in the way of complex chains though...

As already pointed out before, I´d like to re-randomise not the graphics sprites but CB14 results (see code in post above).

As I understand that there´s no re-randomisation taking place inside a CB chain, could this be achieved by splitting re-randomisation the triggers from doing the random choice? I.e., putting a random action in the "graphics chain" (for trigger re-randomisation) and another random action (probably the same) in the CB14 chain?

O/c, this would look quite silly, but would it work? Other than this, I can´t see how your work would be of any use for me and other station newGRF coders, simply because coding large station sets needs to be based on CB14.

regards
Michael

[peter1138]

You'll need to duplicate the random action, once in the graphics chain to do the actual randomisation, and the other (in the CB14 chain) would effectively be used only to select the bits you need.

[michael blunck]

[random action duplication]

If this will work, I´d give them different names in m4nfo then, to avoid utter sillyness at first sight.

Would be interesting if this will work in TTDPatch as well, as the random triggers should be there.

regards
Michael