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

[Morrigan Aensland-Hill]

I would like to request a feature for DKR that when you load one of the ROMs with custom text, they show up instantly on the text editor instead of trying to save one modified text file and importing it. What's more, there is a bug in the DKR Setup Editor where if you expand or shrink the Visual Editor window, the applied custom textures will revert back into the vanilla ones. This occurred to me while I was tinkering around with one of the custom GE-themed courses in the Visual Editor.
_________________
My beauty can overcome brains and brawn!

...Also, my husband sells propane and propane accessories.

[SubDrag]

I'm guessing something crashed/reloaded - I don't see the texture problem on resize here. Guessing that won't happen if you try again. I added it to auto-load text bank so when you open text editor it'll use whatever last thing you opened in Game Configuration.

[HackBond]

SubDrag wrote:

It's fixed. I guess Visual Studio 2026 decided that for this: int val = f() | f() | f(); It's now right to left instead of left to right. Hopefully I didn't make this mistake any other places of assuming L to R, but at least, this spot it's fixed.

I think this problem has extended to the sounds as well. Any sound I play or others play through Game Configuration is also slowed down and the exported sound is the same way. I haven't tested importing sounds.
_________________
Also known as Spyster or Nyxem
[Youtube]

[Decoy] Antenna | Control | Silo | Escape

[Morrigan Aensland-Hill]

Thanks for the info, Sub. But there is an error with the BSP generation when trying to import levels from the Visual Editor such as Ancient Lake.

Also I would be delighted to request adding new textures to the end of the DKR ROM.
_________________
My beauty can overcome brains and brawn!

...Also, my husband sells propane and propane accessories.

[SubDrag]

I never was able to figure out the bsp import perfectly. So you can only really so basic cuboid levels.

Adding textures is not something anyone figured out all the spots. Doubt will be added.

[Morrigan Aensland-Hill]

Oh, well um... It appears that deleting objects in the DKR Visual Editor causes it to crash and close the Setup Editor. But I do have one more request; an option to toggle a selected object between primary and secondary. I was planning to polish up the preview cam placements for existing custom courses.
_________________
My beauty can overcome brains and brawn!

...Also, my husband sells propane and propane accessories.

[SubDrag]

HackBond wrote:

SubDrag wrote: It's fixed. I guess Visual Studio 2026 decided that for this: int val = f() | f() | f(); It's now right to left instead of left to right. Hopefully I didn't make this mistake any other places of assuming L to R, but at least, this spot it's fixed. I think this problem has extended to the sounds as well. Any sound I play or others play through Game Configuration is also slowed down and the exported sound is the same way. I haven't tested importing sounds.

GE sounds normal to me in GoldenEye? Not noticing anything. Can you post a copy of the rocket launcher sound. Or what game?

Deleting works fine DKR for me too. Quick added the toggle between primary/secondary though.

[Morrigan Aensland-Hill]

Thanks for the update, but frankly, the Visual Editor still crashes on me whenever I delete something. I'm not rather sure if it's my computer or an outdated redistributable.
_________________
My beauty can overcome brains and brawn!

...Also, my husband sells propane and propane accessories.

[HackBond]

SubDrag wrote:

HackBond wrote: SubDrag wrote: It's fixed. I guess Visual Studio 2026 decided that for this: int val = f() | f() | f(); It's now right to left instead of left to right. Hopefully I didn't make this mistake any other places of assuming L to R, but at least, this spot it's fixed. I think this problem has extended to the sounds as well. Any sound I play or others play through Game Configuration is also slowed down and the exported sound is the same way. I haven't tested importing sounds. GE sounds normal to me in GoldenEye? Not noticing anything. Can you post a copy of the rocket launcher sound. Or what game?

Ah sorry, I forgot to mention the game. I tested this on Perfect Dark's editor.
This is the Rocket Launcher sound as extracted https://files.catbox.moe/lfxxm2.wav
_________________
Also known as Spyster or Nyxem
[Youtube]

[Decoy] Antenna | Control | Silo | Escape

[SubDrag]

That's not new, been there for many years - but I got rid of the keybase adjust for sounds.

[StupidMarioBros1Fan]

I'd like to ask about the last file found at the end of the table (ob/ob_end.seg) and whether or not it's safe to have it get overwritten with another file since it is an empty file.

I found an old discussion from 2020 regarding extending the number of files up to 2E0 (which included that one) which was implemented into the Editor a while back. What I couldn't find was a straightforward answer on whether or not it's confirmed to be safe to have a normal file at the end, only that you can't go past 2E0 and the Editor gives a popup whenever attempting to go past it.

The confusing part was that Wreck accidentally had a corrupted file which messed with the testing as well as changing the topic to be about possibly moving stuff to a different spot to allow for more files. While it's implied that everything works correctly, especially since the Editor still allows up to 2E0 after all these years, I'd like explicit confirmation on if it is infact safe to replace "ob/ob_end.seg" with something else because that would be a free extra file if yes.

Here's the old conversation as a refresher and to make it easier to check things (any other notes would obviously have to be dug up):

Wreck wrote:

Question regarding the main file table. Normally, the last entry is 02D6, with 02D7 being set @ 800482D4 [27544 in 21990]. The Editor seems to let you add one more in, making the ID/tally at that spot 02D8. Why can we not go up to 02DF being the very last file, with that final ID/tally at the end of table being 02E0? There is room for it, and you can shorten file names down so new file names will fit, as well. Does anything get written in that space during gameplay to prevent this from being done right now?

SubDrag wrote:

Also as for the # files to 2DF, I believe you have to do something special to go higher. I can't remember the details but Zoinkity provided something I think to let us go past the 2D8 # in GF64. It's using 27546 in editor (16-bits) to know how many files. You can try bumping that to 2DF, but I remember there being a problem with doing something. Can't remember what though. You could try it I guess. Something about the Spectrum games.

SubDrag wrote:

OK I found the notes: Change 0xF17A3 to C4 And then editor will let you go up to 2E0 files. Hopefully there wasn't more needed. I made the editor automatically do that if you exceed now. I probably was skittish because it's somewhat untested and I'm still not sure if that is all that is needed. But I can't find any other notes about anything more to do.

Wreck wrote:

Hmmm, I can sort of see what is going on. At 800888B0 in RAM, it is storing the data for each file, with a 0x14 sized block per entry. It has file sizes (compressed and decompressed), and something else, perhaps if it is currently loaded someplace? There is enough space, it appears, to reach 02DF being your final file... However, the last entry (which by default is a 0x0 sized file [ob/ob_end.seg]) is giving a different value. With 0x2DF being my last file shown in Editor, it reads "FF70XXXX". And other tests with 0x2DE being the last file, it is giving "00000848" or "00000840". This should be zeroes, as the file is so? My final used file (not the end empty file) is now "LtraE". However, Train is crashing immediately when going to load the text at the folders. I'm not sure why. Well, it seems to be happening even in early slots, too... [EDIT: Turns out I somehow had either a corrupted LtraE file, or it could have been even the Japanese version, and that was causing the crash! The text file in later slot is loading fine.] Also, I just loaded up the GF64 ROM I have, and it looks like the last file is still 02D6? Maybe something went bad with it, and you had to reduce it back down? But the change you mentioned is present (changing address pointer at F17A3 from 88B0 to 88C4). Anyway, it appears to work, but I am confused with the final entry, which should be zeroes, but is giving out different values. Not tried console. I just tried switching that 88C4 updated address back to 88B0 (at F17A3), and it still seems to work alright. In fact, I'm not even getting the weird final file size value like I was previously. I'm a bit confused on why that change was made to begin with?...

SubDrag wrote:

Not certain but I believe Zoinkity believe that fix was needed. I didn't investigate further. I think Gf64 just had more heads planned but never made it, so I had reserved some files that never got used and deleted unused ones.

Wreck wrote:

I noticed there are many references to 800888B0 and 800888C4 in that area of ROM. 88B0 would be the start of the file list in RAM, for file 000. Or, I imagine it would be. 88C4 is file 001, anyway. From my limited testing so far, changing that address didn't seem to make any real difference. In fact, the only thing I found different, was the game appeared to somehow think the final empty file had size (or was writing something at that spot) when updating the address. It might need to have it, I really don't know. Everything seemed to play fine remaining at 88B0.

_________________
Stupid Mario Brothers is a YouTube series, get asked about my username a lot.

[zoinkity]

No, extending the table past 0x2DF requires some hefty changes.

I've been meaning to write the "long answer" in the debug stuff thread for some time and eventually will get to it, but the oversimplifed version is this:

(Set aside PAL for a moment.)
That particular table is part of a set. GE is designed to dynamically load files externally, not as a debug feature but part of normal operation. The functional part is a table at a higher address that tracks filesizes, whether a file is loaded, where the data is located, etc. The three word filetable basically prebuilds entries in the info table. As it builds this table it also fills a filename->entry table on the side. When you load a file by its name it checks this generated table and matches it to the loader entry. If found it checks if the file's already loaded and if not loads it. If the string isn't found it loads it externally and creates a filename + info entry. (This is how the speccy emu was first tested, btw)

There's more moving parts than that but should give an idea how file management works.


Anyway, file 0 isn't real and there's a "max #entries" value that enforces 0x2E0 as the limit. If you simply changed that you'd roll over the ends of those tables and either corrupt something or read garbage. If not fatal, would still be grumpy.

Obviously it can be (painfully) relocated but because that tie between multiple tables, the entry=index nature of the code, and the fact the strings need a home too there's no practical way to make it fully dynamic without trashing the loader and rewriting it or some hefty realloc/copy scheme that would be a pain to garbage collect. It would also leave some oddly-sized holes in other parts of memory with no simple way to recover the space. Assume there's always going to be a cap.


The future would be either loading everything from a flashcart's filesystem or stripping the table down and drawing from a ROM-side filetable on-demand. Either route would supply a few hundred unique objects to any given stage without limiting any other stage.

[StupidMarioBros1Fan]

I apologize if I worded things improperly or if the quotes I used led you down the wrong path but you misunderstood what I was asking.
I'm not asking to increase the count past 2E0 (0-2DF), the quotes were so the whole conversation could be read in case there was something I missed.

I'm asking about replacing the "ob/ob_end.seg" file specifically because if that file is safe to change, then it would allow for one more file in terms of modding, not increasing the number of files by one.

Sure it'd be nice to have more but I understood that it becomes a complicated process to achieve thanks to coding & RAM shenanigans, I can work with the current limit. Just needed to know if the last file (normally ob/ob_end.seg) needs to be an empty file like how certain chunks need "0000" as a termination command, or if it's simply an existing slot that is normally empty but could be used for an additional background or setup file for levels.
_________________
Stupid Mario Brothers is a YouTube series, get asked about my username a lot.

[Wreck]

For my Tournament Edition mod, I have needed to get creative with how many files you can have. Since it is multi only, I could reuse mission specific stuff (like briefings), cut out all (but one) level text files (making all levels share one between them), delete nearly all items / gadgets beyond the bomb case, but...

The safer solution if missions do exist, would be reusing unused and/or placeholder props. There are a lot. I think I counted nearly a hundred way back years ago. You can delete the file, and inject a new one. You do need to add a text string within 21990 that matches your new filename, and direct the entry to that place in RAM. It is pretty easy, but depending what kind of file it is, there could be more involved in getting it to function properly. But if I can get close to 100 unique level IDs to fully function, I am sure you can figure some nice things out. Feel free to message me if you need any specific info.

[StupidMarioBros1Fan]

Here's some pics to make it more clearer for what I'm asking about, sorry I didn't do that the first time.

"ob/ob_end.seg" at the end:


Added "Ump_setupsiloZ" right before it as an example:


Reloaded the rom after saving:


While the "ob/ob_end.seg" file can't be edited directly, if you add enough to push it to be file 02E0, then it'll disappear after reloading the new rom. So far the initial testing shows the new file work correcting (MP Silo in this example) but because the Editor says the "Size" is now 00000000 and doesn't allow you to use any of the button to Save/Inject/Delete/Rename it, I want to understand what's going on with slot 02DF and if it's actually safe to use it for normal files. The MP Silo file can be edited through the Visual Editor like usual and played correctly on Emulator so the file itself is fine and presumably any other kind of file pushed to slot 02DF will work as expected outside of those specific features in the Game Configuration window, but that was enough to make me wonder if it's safe to do this or if it should remain as "ob/ob_end.seg" at slot 02DF and instead look into replacing other unused files instead.
_________________
Stupid Mario Brothers is a YouTube series, get asked about my username a lot.