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

[zoinkity]

The super-messy, fast solution you'd absolutely regret would be keeping a table with the actual order, maybe just a table of object instances or however that's implemented. Rebuild by calling each in order, but otherwise it wouldn't really affect anything else.
...Come to think of it, that's probably not that easy in C++.

Haha, so much we didn't know when the editor was first made. Didn't even have proper deflate()!

[SubDrag]

I had thought about it, but it gets trickier with new items, plus still need to force the orders of weapons, monitors, etc. I mean could have an "overall" index, that is tweakable. I was just going to leave for now unless there was an earnest need that can't be worked around.

[Manurocker95]

Hey! glad to see this forum is still active! I'm making a Pokémon Snap fangame for (New) Nintendo 3DS with Unity Engine. As I need the animated models from Snap, some time ago I started making a custom importer from rom assets with a mips interpreter that mostly works for static actors but dynamic actors got me into tons of troubles when reconstructing the skinned mesh data + bones. I saw this tool works with Snap dynamic actors and it mostly works with most of them but there are some mons missing and some of them are parsed not correctly. E.g:



In addition, scenario + static actors can't be exported. any clue?

[Manurocker95]

Btw, is Pokémon Stadium (and 2) considered for future builds? as they use F3DEX2 (NoN iirc) as well. Would be dope to have support for those.

I guess not as it is closed source but is the source available to take a look somewhere? To check the Snap parser.

[SubDrag]

This site is more accurate and open source than what I did ages ago.
https://github.com/magcius/noclip.website/tree/main/src/PokemonSnap

[Manurocker95]

SubDrag wrote:

This site is more accurate and open source than what I did ages ago. https://github.com/magcius/noclip.website/tree/main/src/PokemonSnap

As part of the feedback, fixing the snap editor or supporting stadium would be awesome <3

[SubDrag]

I highly doubt will ever even think about supporting Pokemon Stadium 2. But Charmander looks fine to me in editor, so maybe you're just not on latest, or try again?. Also, that other guy is using "hi polygon" Pokemon. Or at least he told me there is a second set of Pokemon stored that are used for the photographs that are higher polygon, which I never quite found. Also the textures are all movement type so don't look right. I think you'd have to write your own tools or modify noclip's to get solid exports.

[zoinkity]

There's basically nothing shared between Snap and the Stadium games.

Stadium's models (both 'mon and 3D text) are assembled and animated via a sort of scripting. The details vary slightly between the three~ish iterations, but that's pretty unique to just the Stadiums.

[Morrigan Aensland-Hill]

A crash has occurred on the PD Setup Editor when I choose 0151 PkeypadlockZ and then click Edit on the Model Editor. Is this a bug or is there not a model assigned to it?

What's more, the Visual Editor for TWINE doesn't display any proper models for characters. Instead, all we can see in place of characters are placeholder models shaped like wedges.
_________________
My beauty can overcome brains and brawn!

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

[SubDrag]

I fixed the key pad lock crashing on edit. The TWINE thing is expected - they are Object Triggers, not guards (though they can trigger guards, but have flags, etc). I had considering replacing them with visualizing guards if matched that, but kept it as is for now, at least.

[Atari-Dude1]

Not the highest priority thing, but today I decided to get back into working on Combat Simulator setups for a map after a couple months break, and spent an hour or so laying pads/pathing for sims. Then right at the end when I was ready to test, I accidentally clicked Edit Multi Level in Visual instead of Import Multi Setup from Visual. I know I should be able to restore from backup, but in this case I already deleted the backup (it's basically instinct for me to due to my OCD not wanting them to build up lol)

My request would be a dialogue pop-up if you click Edit Multi Level in Visual while Visual is already open, asking to confirm you may lose any progress if you continue. Just a small quality of life thing for silly folks like me who don't really have experience utilizing backups (or in my case, foolishly impulsively deleting them )

Another request which is even less priority but would be nice: theoretical support for viewing textures in the 0x1000 ID range. For normal ROMs this isn't important (since no N64 mod would realistically need or support textures 0x1000 or higher), but it would be convenient for me as someone who handles the textures for the All In One PC port mod. Currently, I believe 0x1000 just rolls over back to 0x0000 in Visual.

Additionally, would it be possible to allow for non-contiguous/sparse texture IDs? For example, skipping a block of IDs and manually defining an arbitrary ID, even if just temporarily for loading within Visual. While I am unsure how N64 hacks handle non-sequential indexing, the PC port handles skipped IDs perfectly. Right now, I maintain a dummy romhack featuring all the AIO textures just to keep track of the texture IDs used, but I haven't included anything above 0x0FFF because the Editor cannot display them in Visual and I'm unsure of any other potential adverse side effects from including IDs that high.

[SubDrag]

Is there a sample xdelta patch and setup over 1000? Not even sure game supports this. Non contiguous I don't really understand but it doesn't make sense for how editor edits and works.

[Atari-Dude1]

https://drive.google.com/file/d/1tVADztk6vcaIyXf4lSHVkn-k3nDXBU-2/view?usp=sharing

I just added the latest AIO textures (through 0x1050). Not sure if a patched ROM would have any adverse effects in-game, but that's not a concern for my purposes.

Main issue as far as PD Editor goes, appears to involve interpreting models that include texture IDs in the 0x1000 range, such as the test Cheaddark_frockZ file I injected and is additionally bundled via that Google Drive link (that file works correctly on the PC port but I'm guessing it wouldn't display correctly in-game via a patched ROM since the original game, iirc, at least partially bugs out over this range.

But in PGE-- that sample model's UVs don't render correctly as the textures fall back to 0x0000 and 0x0001 in Visual.

My hope would be that PGE can be updated so that it correctly reads/loads/displays models like that, so that I can tweak models utilizing high ID textures without having to manually swap the textures to a lower ID via hex edit so that the files can be edited in PGE, and then afterwards restore the correct 0x1000 range IDs for the PC port each time I want to test an edit. That's a very tedious workflow, heh.

[SubDrag]

Is there some indicator that it's a special ROM that can handle over 1000? Because if this fails in Vanilla PD I don't want to enable this, unless a certain byte indicates it is valid.

[Atari-Dude1]

Having the functionality to correctly display and load files with high ID textures in PGE is overwhelmingly a positive thing imo. Assuming it's reasonably easy enough to implement a fix, of course. I believe the pros outweigh the cons in any case, as I'll get to.

I tested it briefly yesterday and the game still appears to load via patched ROM, just some textures (not all) appear to load with wrong UVs or something for textures in the 0x1000 range.

There's nothing actually special about this patch other than it includes more textures than normal, to assist with easily testing file edits for AIO, so the tex IDs go into a range above what has historically been useful or needed for N64 romhacks. It's a specific use-case unique to PD modding in 2026.

I can understand if there's a concern that supporting the proper loading of high tex IDs in PGE would erroneously suggest to traditional romhack creators that the N64 could flawlessly render files utilizing those textures.

If so, perhaps there can be a popup warning any time specifically texture 0x1000 is detected being added to End of Rom-- notifying the user that textures beyond this point may display incorrectly in romhacks, but can be supported on the PC port. Or if a file is injected which loads ID 0x1000 or higher, that warning can show up?

Personally, I think that's overkill, but it's better than excluding the visual support for loading these textures properly in PGE.