Talk:Presence flag

MDL0 -low

@Atlas wrote: These objects load the MDL0 from the BRRES files that are tagged with "-low" at the end of their name.

Can you please explain it for me. What is These objects? Bit set or bit cleared? Have you an example for me?

Btw, I plan also a section about the *_d.szs files after some more tests.

-- Wiimm (talk) 21:25, 24 October 2016 (UTC)

And is it "-low" or "-lod"? Both strings appear in the game files as "%s-low" (once) and "%s-lod" (twice). -- Leseratte (talk) 03:07, 25 October 2016 (UTC)

I changed it to "-low" because all MDL0s that uses lower polygon models or smaller textures have object name + -low as their MDL0 name, and I think that is what Atlas refers to. "These objects" should be all the general objects that have a MDL0.
--Wexos (Talk | Contribs) 06:10, 25 October 2016 (UTC)

"-lod" is kind of a mistake from me, since it's only used for CPU models (when they're far away, the characters turn into their low-poly, unanimated Level of Detail version, model-lod). The tag "_LOD" is found into TruckWagon.brres, and instead of those models tagged with "-low", this one loads in 1 Player mode too and it does the same as the CPU models, the model is changed to the Level of Detail version when the trucks are far away from the player. —Atlas (talk) 10:01, 25 October 2016 (UTC)

I believe, that "-lod" has nothing to do with the presence flag. If the related bit is not set, the object is hidden. And this is true for TruckWagon/offline too.

-- Wiimm (talk) 17:53, 25 October 2016 (UTC)

Yeah, it hasn't. I've tested again, and it seems like -low models are loaded on a track from *_d.szs in splitscreen. In the race intro, the object loads the normal MDL0 instead. So, where is used the -low from the normal course .szs and not the *_d? My guesses are they're used for online 2 players splitscreen. But I can't test that. —Atlas (talk) 19:32, 25 October 2016 (UTC)

LE-CODE Extension: First ideas

File:Lecode-ver-36x160.png

I have tested 8124 tracks of my archive and only 1 track has a bit set outside from 0x3f (by accident; I'll update it in the next days). So the usage of bits 6-15 by LE-CODE is not problematic.

The basic idea is:

• Use 2 bits to define a general extension MODE.
• Use the remaining 8 bits as PARAMETERS depending on MODE.
• Allow future extensions.

Here is a first definiton. Discuss it!

Bit Groups and usage

Bits	Mask	Description
0–5	0x003f	Standard bits used by Nintendo. Fallback for non LE-CODE.
6–7	0x00c0	MODES 0 to 3: Define the meaning of the next block (PARAMETERS).
8–15	0xff00	PARAMETERS, meaning depends on MODE.

LE-CODE interprets the presence flags only, if at least one bit of MODE or PARAMETER is set.

Modes

Mode	Parameter	Description
0	0	Standard settings → LE-CODE does nothing special.
0	>0	Reserved! The idea is, that PARAMETER is an index (1–255) into a LEX table with advanced settings (triggers, counters, conditions, …).
1	*	Enable or disable object on combination of race/battle, offline/online, versus/time trial, number of players. For details, see tables below.
2	*	Reserved for future extensions!
3	*	Reserved for future extensions!

Mode 1 (Variant A)

Depending on a condition, 1 bit of the PARAMETER is used to decide, if the object is available. LE-CODE will set the presence flags either to 0x00 (disabled) or to 0x3f (enabled) after loading the track. If disabled, the object id is set to 0 too.

PARAMETERS: 2*8 different conditions

Bit	Mask	Condition for racing tracks	Condition for battle arenas
0	0x01	Offline, Versus, 1 human player.	Offline, Ballon Battle, 1, 3 or 4 human players (or 1 player).
1	0x02	Offline, Versus, 2 human players.	Offline, Ballon Battle, 2 human players (or 2–4 players).
2	0x04	Offline, Versus, 3 or 4 human players.	Offline, Coin Runners, 1, 3 or 4 human players (or 1 player).
3	0x08	Offline, Time trial	Offline, Coin Runners, 2 human players (or 2–4 players)..
4	0x10	Online, Versus, 2–5 players.	Online, Ballon Battle, 2–8 players.
5	0x20	Online, Versus, 6–8 players.	Online, Ballon Battle, 9–12 players.
6	0x40	Online, Versus, 9–10 players.	Online, Coin Runners, 2–8 players
7	0x80	Online, Versus, 11–12 players.	Online, Coin Runners, 9–12 players.

The number of players is only a proposal. The idea is, that tracks that are tend to be laggy can disable object if more players are active.

For battles we distinguish between Ballon Battle and Coin Runners as well as between few and many players. An alternative for 1,3,4 and 2 players is to distinguish between 1 and 2,3,4 players.

Mode 1 (Variant B)

An alternative for Variant A:

PARAMETERS: 2*8 different conditions

Bit	Mask	Condition for racing tracks	Condition for battle arenas
0	0x01	Offline, Versus, 1 human player.	Offline, Ballon Battle, 1 player.
1	0x02	Offline, Versus, 2 human players.	Offline, Ballon Battle, 2–4 human players.
2	0x04	Offline, Versus, 3 or 4 human players.	Offline, Coin Runners, 1 player.
3	0x08	Offline, Time trial	Offline, Coin Runners, 2–4 human players.
4	0x10	Online, Versus, 2–8 players online, single player at Wii.	Online, Ballon Battle, single player at Wii.
5	0x20	Online, Versus, 2–8 players online, 2 players at Wii.	Online, Ballon Battle, 2 players at Wii.
6	0x40	Online, Versus, 9–12 players online, single player at Wii.	Online, Coin Runners, single player at Wii.
7	0x80	Online, Versus, 9–12 players online, 2 players at Wii.	Online, Coin Runners, 2 players at Wii.

Using the padding at offset 0x02

There are maybe 16 more bits available: The padding at offset 0x02 in each GOBJ record. Nearly all tracks (all in Nintendo tracks and arenas) use value 0. It can be used for additional conditions by LE-CODE.

The idea here: If the MODE part of presence flags is set to a well defined value, than the padding is used for conditions. After analysis it will set it to 0 to avoid any possible side affects.

So it is enough space for additional settings like use low poly model.

-- Wiimm (talk) 2–4 January 2020 (UTC)

Discussion

Would it be an option to allow loading of -lod MDL0 files depending on the presence flag? I can imagine that in many cases it is not an option to remove an effect, and loading a simplified model could solve that problem.
--kHacker35000vr (talk) 18:59, 2 January 2020 (UTC)

Is this a decision for every single object? I think, it is more a global setting:

• On CONDITION load simplified models if available.

-- Wiimm (talk) 20:39, 2 January 2020 (UTC)

Yes, it's a possible flag for all objects. If set, the low poly model is loaded (if it exists) if it would otherwise not be loaded. Not all objects of a certain type are absolutely necessary for the track to function in some cases after all.

--kHacker35000vr (talk) 09:07, 3 January 2020 (UTC)

Then it is a decision/setting outside of presence flags. I put it to our LE-CODE to-do list. -- Wiimm (talk) 10:25, 3 January 2020 (UTC)

I think you misunerstood what kHacker said. It's a possible flag for all objects, that doesn't mean it would be a flag just once for the whole track. That suggestion would fit right into the "presence flag" discussion and there should be, as he said, a single bit in the presence flags that forces the game to load the low-poly version. -- Leseratte (talk) 10:34, 3 January 2020 (UTC)

Again my question and some more:

• Does it make sense to define low-poly-model-loading by a single bit for each GOBJ-element?
• What should a set bit mean? (Why not modifying the brres file?)
• What happen, if a bit is set for one object, but not for a other object of the same type? Then we have 2 different loading statements.

So my idea is, to define a tuples of kind (object_id,condition) into a lex file. If condition is true, all objects of that type use the low poly model. Another point is, that 1 bit reduces the condition list to half size.

-- Wiimm (talk) 13:30, 3 January 2020 (UTC)

• Since most objects have to be visible at all times, most of them can't use any other value than 0x3F to not affect gameplay. Changing the presence flag to also support low-poly model loading will allow for further reduction in CPU/GPU cycles.
• That's indeed a flaw I did not think about when I proposed this idea. However, if I remember correctly, the model to load is stored in memory per object, rather than by object type. It should then be trivial to have different versions of the object loaded at the same time. This is also the advantage this approach has over modifying the brres file.

It will indeed cost a bit, but in exchange this functionality can be used for more objects and authors will have to worry less about complexity of their objects. Using a lex file for this behaviour is also a solution, but since the presence flag still has 8 unused bits, personally I don't think it's a necessity.

--kHacker35000vr (talk) 19:57, 3 January 2020 (UTC)

"the model to load is stored in memory per object, rather than by object type." Is it really true? If I remember right, you can't use choropu and choropu2 in the same track. I speculate the reason is, that the brees is only loaded once and internally prepared for choropu or for choropu2. -- Wiimm (talk) 00:14, 4 January 2020 (UTC)

LE-CODE Extension: Second idea

File:Lecode-ver-36x160.png

After some discussion of the first idea, a second idea was developed. Herefor 3 different variables of KMP/GOBJ are used:

• The OBJECT_ID (16 bit, values between 0x0001–0x02f3 ⇒ mask 0x03ff) is used to identify the object. Other bits (mask 0xfc00) can be used to hide and disable an object. MKWii will simply ignore unknown objects. Value 0 is a special case for it. LE-CODE uses bit 12 (mask 0x1000) to enable objects on CONDITIONS, that are otherwise disabled.
• The padding at offset 2 (16 bits) is ignores by MKWii. LE-CODE will use it for the definition of CONDITIONS.
• PRESENCE_FLAGS is a 16 bit value, but Nintendo has only defined bits 0–5 and MKWii uses only bits 0–2. So bits 6–15 (mask 0xffc0) can be used for custom/LE-CODE. The idea is, that bits 12-15 (highest hex digit, mask 0xf000) are used to select one of 16 general MODES. MODE=0 is the classic mode and MODE=1 is used first this LE-CODE extension. Bits 6-11 can be used for other settings like "loading low poly model". Wiimm tested 8124 tracks of his archive, and all objects are in MODE=0.

Further tests to confirm all assumptions are ongoing.

LE-CODE behavior

LE-CODE analyses MODE and CONDITIONS:

• If MODE is unknown or not supported, LE-CODE does nothing.
• If the object is active, bit 12 of OBJECT_ID is cleared and the PRESENCE_FLAGS is set to values 0x3f. CONDITIONS is set to 0.
• If the object is inactive, OBJECT_ID, CONDITIONS and PRESENCE_FLAGS are set to value 0.

Standard code behavior

Standard code ignores …

• … the complete object, if its OBJECT_ID is unknown (e.g. if bit 12 is set).
• … the CONDITIONS (16 bit padding).
• … bits 3-15 of PRESENCE_FLAGS.

Presence Flags

The Bits of the Presence Flags can be devided into 4 groups:

Bit Groups and usage

Bits	Mask	Description
0–2	0x0007	Standard bits defined by Nintendo and used by MKWii. Ignored by LE-CODE and fallback for non LE-CODE.
3–5	0x0038	Standard bits defined by Nintendo, but not used by MKWii. Ignored by LE-CODE.
6–11	0x0fc0	PARAMETERS (7 bits), ignored by MKWii, custom meaning depends on MODE.
12–15	0xf000	MODE: Define the meaning of PARAMETERS and CONDITIONS, ignored by MKWii. MODE=0: Standard mode, no special processing by LE-CODE or other extensions. MODE=1: LE-CODE mode ⇒ process OBJECT_ID, CONDITIONS and PRESENCE_FLAGS. MODE=2-3: Reserved for a future LEX extension. MODE=4–15: Reserved.

CONDITIONS on MODE=1

This section describes, how LE-CODE will interpret the CONDITIONS (16 bits at offset 2) on MODE=1. Because of 16 bits, we can define 16 conditions for racing tracks and 16 conditions for battle arenas. Each set of conditions covers all possible combinations of the related states.

All conditions are proposals and discussable. This is especially true for the numbers of online players. One point: Is the fine tuning for 5 different classes "players online" really useful?

Racing tracks:

• Time trial.
• Offline versus, 1 human player.
• Offline versus, 2 human players.
• Offline versus, 3+4 human players.
• Online versus, 1 player at Wii, 2–7 players online.
• Online versus, 1 player at Wii, 8–12 players online.
• Online versus, 1 player at Wii, 13+ players online (for CTGP).
• Online versus, 2 players at Wii, 2–7 players online.
• Online versus, 2 players at Wii, 8–12 players online.
• Online versus, 2 players at Wii, 13+ players online (for CTGP).
• Online item rain, 1 player at Wii, 2–7 players online.
• Online item rain, 1 player at Wii, 8–12 players online.
• Online item rain, 1 player at Wii, 13+ players online (for CTGP).
• Online item rain, 2 players at Wii, 2–7 players online.
• Online item rain, 2 players at Wii, 8–12 players online.
• Online item rain, 2 players at Wii, 13+ players online (for CTGP).

Battle arenas:

• Ballon battle, offline, 1 human player
• Ballon battle, offline, 2 human players
• Ballon battle, offline, 3+4 human players
• Ballon battle, online, 1 player at Wii, 2–7 players online.
• Ballon battle, online, 1 player at Wii, 8–12 players online.
• Ballon battle, online, 2 players at Wii, 2–7 players online.
• Ballon battle, online, 2 players at Wii, 8–12 players online.
• Ballon battle, online, 1 or 2 players at Wii, 13+ players online.
• Coin runners, offline, 1 human player
• Coin runners, offline, 2 human players
• Coin runners, offline, 3+4 human players
• Coin runners, online, 1 player at Wii, 2–7 players online.
• Coin runners, online, 1 player at Wii, 8–12 players online.
• Coin runners, online, 2 players at Wii, 2–7 players online.
• Coin runners, online, 2 players at Wii, 8–12 players online.
• Coin runners, online, 1 or 2 players at Wii, 13+ players online.

Discussion

Please add your notes here.

Using custom object IDs for settings

Another suggestion: The variant that Wiimm suggested above is pretty complicated with all the bitpacking, and would leave basically no space for expansion, so I'd like to suggest a different variant. Each object has the 16 bits unused padding right after the object ID. My idea would be that you can put an unique, custom ID into that field (for example, 20000), and then you add yet another object with the object ID 20000 and padding 0. As we know the game ignores unused object IDs, the game wouldn't load that ID 20000 object - but we could use all the 8 object settings (16 bytes) to define conditions for the object that has its padding set to 20000.

That way we have way more space, the data is more readable (less bitpacking), and it would still be compatible with all tools. -- Leseratte (talk) 15:59, 5 January 2020 (UTC)