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

[Carnivorous]

2B name now has a random space at the start when loading with a footsteps based ROM - it works fine when loading the retail NTSC ROM. I think now that there is footsteps ROM detection, the dynamic descriptions for 2B should be disabled for non footsteps patch ROMs

Footsteps
https://files.catbox.moe/r6kjj4.png
Retail
https://files.catbox.moe/7h8cx8.png

FB is incorrectly named, should be [Fade Fog]. EC should be [Bond Disable Damage And Pickups Toggle] instead of [Bond Disables Damage And Pickups Toggle]. E9's name is good, please keep that.

Last edited by Carnivorous on Thu Jun 18, 2020 10:29 pm; edited 2 times in total

[MRKane]

I've a request, for the "there's a room that has zero verticies" message could you please add a note as to which room[s] it is. I think I'm tracking a funny export bug but as usual a little more information never hurt

EDIT: Another quick suggestion for the right click portal menu: "Flip portal". While I'll usually get the room numbers right, I frequently get them around the wrong way and this would be seriously handy also!
_________________
No Mr. Bond, I expect you to be re-coded!

[Wreck]

While on the subject of portals...

In GE, if there are two portals sharing the exact same points, did Rare make it so they share one entry? That is what the Editor does. Now, I'm not 100% sure, but an area of Grid (ported) does have four sets of portals that overlap (added myself to correct blackout issues), and if felt as though the framerate was affected when they reused the same coordinate entries. After updating the portals so the extra four were all -1 elevation at the ground, it seemed to perform better when they had their own entries. Again, I did not confirm in anyway. It was just a feeling while running in that area.

[SubDrag]

I did some cleanup to hopefully make action names match what was said a little beter.

Added room number of zero vertices.

You can already invert portals, just right click and say Invert Portal Normal.

The portals shouldn't automatically merge. How did you import the portals for Grid level? If importing from obj, you need to make the groups have unique names, so they are not merged.

[Carnivorous]

Works perfectly, thank you.

[Trevor]

SubDrag wrote:

Yeah it runs in Cen64, bounces around, but not sure if that's a PAL vs NTSC issue or what. Menus are always off on 480I. That was on base GoldenEye ROM PAL 480i. Not sure if what was tried was a mod or base ROM. I am not sure I ever actually tested 480i PAL but Trevor may have. But try the new PAL option, that was absolutely tested by Trevor and others and it did work GF64 too.

I will test again, but yes, PAL worked great before. As for the Hi-Res PAL Im not sure - Ill check now (though of course, the caveat for both NTSC and PAL is the menu which I think the original bugreport failed to realise was a known issue of Hi-Res)

Trev
_________________

[SubDrag]

https://youtu.be/mwSDRplmcZ0
It looks like Graslu is the one who tested PAL 640 480i but it seems to have worked.

[Wreck]

GE Grid is the same one you had done years ago for multi, which was reused by Dragonsbrethren in his mission. All I did, was clone a portal, then edit the room IDs (new ones use other rooms) and fix the coordinates to match the originals (as clones are offset slightly when first added). When you export the background, it ends up having both the original, as well as the other one that shares the same coordinates, link to the same portal position data.

Two portals sharing the same portal data felt laggier than both using unique entries.

[SubDrag]

Wreck wrote:

GE Grid is the same one you had done years ago for multi, which was reused by Dragonsbrethren in his mission. All I did, was clone a portal, then edit the room IDs (new ones use other rooms) and fix the coordinates to match the originals (as clones are offset slightly when first added). When you export the background, it ends up having both the original, as well as the other one that shares the same coordinates, link to the same portal position data. Two portals sharing the same portal data felt laggier than both using unique entries.

It's pretty easy to disable that optimization in editor, but are we sure this is actually an issue?

[Trevor]

Just to let everyone know PAL (Hi res and lo res) woks perfectly.

It registers as PAL on TV and has the correct timings.

Wreck, did you confirm the "lag" via MCM?
If not then I can test, but the MCM is really easy to use and will give you a straight answer.

Trev
_________________

[CrashOveride]

My tester also confirms that it works perfect, thanks subdrag
_________________
Playing old, low poly games since 2003

[Uufje]

I am having trouble injecting PD intro cameras into a ROM... the first time I tried injecting four cameras; trying to access the fourth camera crashed the editor. The subsequent times I tired to inject them again, but the second and the third camera somehow didn't get saved, all that was left is an empty camera slot. I've included the four in the zip. I injected them into the C5, C7, C9 and CB slots (Defection intro cameras), with a vanilla PD ROM.

https://drive.google.com/file/d/15vZSPjQu5Ws-MMDpbr3l28Qq6TTCQ0D3/view?usp=sharing
_________________
Oofjay

[SubDrag]

Something's definitely wrong, and it seems related to Carnivorous's Animation extension. I might need his help. Write ROM seems ok. I'll look more when I get some time though.

[Carnivorous]

From what I remember, Ryan pointed me towards an area after the animation block that contained a bunch of unused TLB code, which can be removed safely and merged [function ShiftAnimation()]. I remember testing this with camera and animations, and the most I was able to fit was one unique animation without having to delete skedar animations.

[RyanDwyer]

To clarify:

* The game zips segment ends at 0x157810.
* From 0x157810 to 0x1a15c0 is garbage data.
* The animation segment is at 0x1a15c0.

So the animation segment can be moved earlier, anywhere back to 0x157810, as long as the game zips segment doesn't grow. It may grow due to compression differences if you make edits to it, so moving the animation table to somewhere like 0x157900 should be pretty safe.