Multi-tile object randomisation

[michael blunck]

I think it´s not possible to achieve consistent multi-tile object randomisation, simply because "random bits are unique to each tile in the object, and are not shared across the whole object"?

I.e., what I´d like to achieve is to randomise the tiles of an object in a consistent way, say for a two-tile object I want to get randomised sprites A-A, or B-B, C-C, ..., but not A-B, C-B, etc.

Is that possible in some way?

regards
Michael

[zero.eight]

var61 + var40 will get the random bits of some specific tile in the object, so for each tile in a multi-tile object you could make decisions based on the random bits of the northernmost tile, which should be consistent.

[frosch]

There is even an example in the specs for exactly that: http://newgrf-specs.tt-wiki.net/wiki/Va ... andom_bits

[michael blunck]

var61 (objinfo_randombits) + var40 (position) will get the random bits of some specific tile in the object, so for each tile in a multi-tile object you could make decisions based on the random bits of the northernmost tile, which should be consistent.

Thanks for your reply. Yes, I know that this is the usual approach, and I´ve already used it this way, and hence there seems to be no better method I´ve now implemented it again.


However, I still don´t understand why the same result can´t be achieved by a simple use of a randomaction (the code would be very much simpler: 1 line versus n+1 lines). The fact that a simple randomaction does not work for features composed from multiple tiles is nowhere mentioned in the docs. Moreover, how a randomaction works in general is nowhere explained in the docs as well. Please note, question is not about "*re*-randomising" (which is indeed (sparingly) explained) here, since objects have no triggers.

This reminds me of that problem with re-randomisation in callback chains, which was likewise nowhere explained, but uncovered the existence of an undocumented "callback 1" to the audience.

@frosch
Thanks, I know about this example (it´s even implemented as a pre-defined function in m4nfo).

regards
Michael

[Eddi]

so what you're proposing is something like random action type 84 also for <whatever>Tiles, not only for trains?

[michael blunck]

so what you're proposing is something like random action type 84 also for <whatever>Tiles, not only for trains?

Well, current behaviour seems to exist because of "historical reasons" (trains were first, multi-tile features were introduced much later).

(the code would be very much simpler: 1 line versus n+1 lines)

Even more, since you´ll have to check for that northern tile explicitly, both for x- and y direction.

regards
Michael

[Lakie]

From my understanding there are two possible solutions (proposed):

1. Store 'whole object' random bits which are accessed through 83. *
2. Implement 84 for objects taking offset (as a byte) from the north tile and fetch its random bits. **

I haven't looked to see how feasible either solution would be, but both solutions hold their merits.

~ Lakie

* If I remember correctly, defined object layouts do not require the north tile, meaning just fetching those bits is undefined in some (rare) cases.
** Objects can have a maximum dimension of 15x15 making negatives infeasible with just a single byte.

[michael blunck]

From my understanding there are two possible solutions (proposed):

1. Store 'whole object' random bits which are accessed through 83. *
2. Implement 84 for objects taking offset (as a byte) from the north tile and fetch its random bits. **

I haven't looked to see how feasible either solution would be, but both solutions hold their merits [...]

IMO, supplying random bits for an object as a whole would be the more "conservative" approach, since stations and industry tiles work the same way. Whereas type "84" seems to be especially useful for trains (plus taking into account the limitations you pointed out).

feature bits

vehicles 8
stations 16+4
houses 0/8+8*
ind tile 16+8
objects 0+8

*depending on trigger set for periodic tile processing loop

regards
Michael

[Eddi]

the difference is that industries have completely separate "industry" (global) and "industry tile" (local) representations ingame, where objects only have the "object tile" representation. there is no "object pool" storing global data about each object. (there's also no reason for that to exist, since objects have no relevant gameplay effect that would require this storage, so introducing it just for the sake of random bits sounds a bit overkill)

[Lakie]

Actually, both TTDPatch and OpenTTD keep certain information about the object separate in a small data structure shared by all the tiles of the object, (see objects.inc and object_base.h).

~ Lakie

[michael blunck]

Well, yes. W/r to industry tiles you´re right, but for stations, there are indeed 16 bits for the station as a whole, not for its "related" feature (town).

So, there´s no fixed "scheme" for random bit allocation in existence, defining a clear distinction between bits for feature tiles and bits for its related feature (sorry, there´s really a clash between "object" and object in our terminology).

Hence, I don´t see any fundamental contradiction in adding random bits for an object as a whole. Since"new" objects are built up from more than one tile most of the time, such a feature would come indeed quite handy, and it would outweigh any theoretical concerns.

IMO, it´d be much more straightforward than implementing type "84" for objects.

regards
Michael

[michael blunck]

@Lakie
So, what´s this

26 #define OA_WHOLEOBJECT 0x4 // Every 250? ticks (whole object)
27
28 #define OA_FORALLTILES 0x5 // Used to detect which triggers are for the whole object

In addition, there´s a periodic tileloop trigger?

regards
Michael

[Lakie]

Those are just the bit definitions for property 13, the last is a mask for any of the animation bits triggering the whole object to be updated.

~ Lakie

[michael blunck]

@Lakie

Aha. "OA" means "object animation", so it has nothing to do with randomisation which we´re talking about here.

regards
Michael

[Lakie]

Yes, apparently object layouts was planned but never implemented. Thus the solution of redirecting type 83 random to use the random bits from the north-tile is currently viable. (Although possibly not future safe).

~ Lakie

[michael blunck]

Speaking about missing features in objects, there´s also that old proposal to allow for shared bits for animation triggers.

regards
Michael

[Lakie]

Well, we're going a little off topic here. At present there are two suggestions for multi-tile object randomization, either shared object random bits or another tile's (in the same object) random bits.
The former could only really be implemented as type 83, whilst the latter could be either type 83 or 84 depending on how flexible the solution should be. Also, a combination of the two might be preferable.

[edit] I've attached my test object source code (NFO) for a comparison of the the NewGRF (NFO) code. I wasn't sure how it was presently done so I took best guess (last object).

~ Lakie

[frosch]

For shared random bits within an object I am strongly in favour of using type 83. If there would be triggers at some point, it could work similar to industry tiles.

I see no point in using type 84. Triggers will never work to rerandomize bits of other tiles, and it does not work for vehicles either (actually for vehicles type 83 already fails). Reading of random bits can already be done with the existing variables (object var 61 and vehicle var 61), so actually type 84 is on my list of crap to remove from specs in some unknown future.

[Eddi]

unless you completely remove randomaction2, i don't see how that would work...

(Off-Topic Alert)