GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion

[zoinkity]

https://mega.nz/file/IqgigCSL#7HgleKyR03vxohTHHnZWlMU6D74djV4RY00HmhpbJq4

With the beta release late April came a neat feature to add and remove the label tables in setup files. In "Edit Setup > Edit Presets/Pads" are two new options, (currently named) "Extra Pointer 8 Data" and "Extra Pointer 9 Data" (setup +20 & +24, respectively). They're optional fields only two stages included, and they were filled with unused string labels for development stuff.

Useless, in other words.

The patches linked above give a use to the second table in a completely backward compatible way. It allows you to embed a sky table, just like the built-in ones, that overrides the original settings (if any exist). This way you can provide skies for a stage without editing the "game settings" page.
New skies are tested first, then old ones. Both the "long" and "short" (fogless) type can be used. This patch also allows multiplayers to use the short type and automatically falls back to the solo stage's sky if no MP-only ones are present.

The format is identical to the built-in tables. An example is provided. PAL skies use a different label, so you can provide NTSC & PAL sky tables in the same setup file.

The readme explains this, but...
First it assembles a list of sky IDs to check.

• If a cutscene, checks stageID + 900 first.
  
• If a multiplayer, checks stageID + (#players * 100).
  
• Checks for original stageID.
  
• Checks for default (-1).

Next it assembles a list of all the tables it will check.

• If it exists, it searches the second table for data that starts with a "E1SK" or "P1SK" label. If found, the table is added to the list. Up to six tables of the same type can be present (not that you need that).
  
• The built-in table for "long" skies is checked after that.
  
• If it exists, the second table is checked again for a "E2SK" label. That's added to the list.
  
• The built-in "short" skies are checked after that.
  

The general idea is that the second table will be used for weird global stuff like this (maybe a future music patch?), and the first table can be reserved for user stuff. This gives an editor-safe place to embed things in a way you can find them again. For instance, you could embed ASM using an entry, then execute it with a specialized action block type. (Since it's user-only, you can make the presumption the user won't give a bad index...though you could also assume they know the table already exist and strike that branch. Anyway...)
The code portion of that action would be rather simple:

Code:

(NGEE only, obviously) if (p := @80065D20+0):   call @p+(cmd[1] << 2)() LUI   AT,8006 LW   V0,5D20 (AT) BEQ   V0,R0,+6 LBU   AT,0001 (S0) SLL   AT,AT,0x2 ADDU   V0,V0,AT LW   AT,0000 (V0) JALR   RA,AT NOP

Doesn't have to be code though. Anything stage-specific you want to embed can use these "label" banks.

[Wreck]

I've tested the setup file skies for the Tournament Edition multiplayer mod, and it works great. As I have about 70 different level IDs currently in use (59 + 11 mirrored variants), it means I will run out of sky entries at some point. This removed that concern completely. It also means that you could potentially rely on this method almost entirely, perhaps only keeping default skies inside the 21990 file (and a terminator entry, that might now be just 0x4 of zeroes), which would give the user nearly 0x1000 space to repurpose for other things. Nice chunk.