B Info Module System The Nature of Slots 1.153

[Zsar]

A slot handles in essence like the member variable of an object in OoP (Object-oriented Programming). It is defined, though, as just a number. There are at least two ways to implement a slot like this, that immediately spring to mind: as an array index - so that each object holds an array of <greatest slot number> length; or as a mapping key-to-value.

Now, I wonder:
1) How much fits into a slot? How many bits are available? Or does it just save a reference (which would be of fixed width, no matter the content).
2) While there is a slot defined as <n>, does this mean all numbers in [0, n[ constitute valid slots? In other terms: Does the game allocate unnecessary space for gaps between the slot numbers (which would be the case for an array-based implementation)?
3) Are there other slot definitions possible than natural numbers? Is there a size restriction for slot definitions?

... Unfortunately, seeking for "slot" yields only information about its usage, of which I am already fairly aware.

I seem to have bad luck (Or karma?) regarding questions I would like to see answered, so I do not really bet on it, but then: Who knows.
As a meaningless boon I offer in exchange the insight that slot_agent_target_entry_point is defined twice, as a value of 11, not as a value of 0.
Oh yes, and with multiplayer components ripped out the native module is ~8 MB smaller. There does not happen to be someone who has done that without altering anything else?

 

[Mad Vader]

The slots are apparently implemented as dynamic (signed) integer arrays.
If you set a higher numbered slot of some entity to some value, all lower-numbered slots that are not already allocated would be allocated (and initialized to 0), for all the entities of the same type. If you just read some slot that's out of range, you'll just get 0 and no array reallocation.
The point is, don't use slot numbers that are too high and skip over a lot of unused lower slots, you are wasting memory and making savegames large. That's all there is to it.

 

[Zsar]

Is there then a more efficient way to store a value for some troops but not all, some parties?

One might reuse slots, of course, if disjunct sets of entities with similar numbers of different values can be found...
If the exact size of a slot were known, one could accumulate many values into one bitmask...

 

[Mad Vader]

You shouldn't bother that much. If your slot is used by several parties, that's enough of a justification. The integers are 64-bit I think, and anyway you can use bit masks that use the lower bits only, but don't bother with that, and freely use slots to store 0s and 1s. It's not worth the slightly more complicated code.
There is always a way to store information more efficiently. Declare fake troops and use them as proprietary arrays to store any information in any way you want.

 

[cmpxchg8b]

2) While there is a slot defined as <n>, does this mean all numbers in [0, n[ constitute valid slots? In other terms: Does the game allocate unnecessary space for gaps between the slot numbers (which would be the case for an array-based implementation)?

Yes, it's array based (std::vector to be precise).

If you set a higher numbered slot of some entity to some value, all lower-numbered slots that are not already allocated would be allocated (and initialized to 0), for all the entities of the same type.

This is not true, every entity (troop, party, site, item kind...) has individual slots. If you set slot 100000 on a troop, it will allocate 100000 slots only on that troop.

 

[Mad Vader]

If you set a higher numbered slot of some entity to some value, all lower-numbered slots that are not already allocated would be allocated (and initialized to 0), for all the entities of the same type.

This is not true, every entity (troop, party, site, item kind...) has individual slots. If you set slot 100000 on a troop, it will allocate 100000 slots only on that troop.

Thanks for clarifying that, this may be old info.
I was once (before Warband?) experimenting with setting very high-numbered slots to some values and watched the savegame size, that's where it comes from.

 

[cmpxchg8b]

If you set a higher numbered slot of some entity to some value, all lower-numbered slots that are not already allocated would be allocated (and initialized to 0), for all the entities of the same type.

This is not true, every entity (troop, party, site, item kind...) has individual slots. If you set slot 100000 on a troop, it will allocate 100000 slots only on that troop.

Thanks for clarifying that, this may be old info.
I was once (before Warband?) experimenting with setting very high-numbered slots to some values and watched the savegame size, that's where it comes from.

Could be that it was different back in that day.
Also, if the requested allocation size is between 16 and 65536 the game will round up to the nearest power of 2 (for example if you set slot 37000 it will still allocate 65536).

 

[Zsar]

Most valuable information, most valuable. Thank you, oh Unpronounciable One, and thank you too, Rider-of-deliberately-degenerate-Cats.
Two-and-a-half out of three, it must be my lucky day.