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

[Jonaeru]

The opening is not displayed and remains a black screen. (Project64 3.0.1)
I uploaded xdelta just in case. Sorry if my steps are wrong.
xdelta: https://drive.google.com/file/d/1Sjx3CxXtkNCUZypPqzyWtEC_E0Neu9Su/view?usp=sharing

Steps:
1. Choose the original Japanese ROM in Game Configuration
MD5: 1880DA358F875C0740D4A6731E110109 (GoldenEye 007 (J) [!] .z64)
2. Push "Delete Debug Data (and J text)"
3. Write ROM
_________________
YouTube: https://www.youtube.com/user/jonaeru
NicoNico: https://www.nicovideo.jp/user/2033487
Twitter: https://twitter.com/jonaeru

[SubDrag]

Are you on latest beta? I just did those steps and it's fine.

[Jonaeru]

It's latest. (Build Apr 21 2023)

I used Simple64 and it started. Maybe there is a problem with my Project64 settings. Sorry for the trouble.
Thank you.
_________________
YouTube: https://www.youtube.com/user/jonaeru
NicoNico: https://www.nicovideo.jp/user/2033487
Twitter: https://twitter.com/jonaeru

[SubDrag]

Didn't get to try console, but it loads in Cen64 so yeah probably just something wrong on emulator as you mentioned (maybe not detecting 8 meg or ROM settings are off in PJ64).

[Jonaeru]

Sorry, I had set the save type to "16-kbit EEPROM".
I changed it to "4-kbit EEPROM" or "Use first-used save type" and ROM started!
Thanks.
_________________
YouTube: https://www.youtube.com/user/jonaeru
NicoNico: https://www.nicovideo.jp/user/2033487
Twitter: https://twitter.com/jonaeru

[HackBond]

Thanks to Coockie for telling me this

The obj format in the current version of Blender (3.5 as of writing) has support for Vertex Colours

Vertex colours are appended to the v commands in R G B order normalized from 0 to 1.

example line

Code:

v 1.000000 1.000000 -1.000000 1.0000 0.0941 0.1451

Having support for this could be nice as it's getting more annoying to add FBX support with the SDK being hosted on archive.org, which itself is going through some legal troubles. It could also help speed mod development up as we wouldn't need to convert FBX files on output from the Editor.
_________________
Also known as Spyster or Nyxem
[Youtube]

[Decoy] Antenna | Control | Silo | Escape

[SubDrag]

I think Trevor had mentioned this to me, and I had added support to obj2an8, so it could convert to the normal output format even obj -> obj with the checkbox of ".Obj output vertex colors in v command" (uncheck to output as editor expects in #fvcolor. But it wasn't really the right approach for editor since that shared vertices, with different colors being part of the draws, not the vertices. I think my spec was better...So you don't need to use FBX, but you would still have to manually convert in obj2an8 first to work in editor.

[HackBond]

SubDrag wrote:

I think Trevor had mentioned this to me, and I had added support to obj2an8, so it could convert to the normal output format even obj -> obj with the checkbox of ".Obj output vertex colors in v command" (uncheck to output as editor expects in #fvcolor. But it wasn't really the right approach for editor since that shared vertices, with different colors being part of the draws, not the vertices. I think my spec was better...So you don't need to use FBX, but you would still have to manually convert in obj2an8 first to work in editor.

Awesome so there is support, just gotta go through obj2an8 first. Thanks.
_________________
Also known as Spyster or Nyxem
[Youtube]

[Decoy] Antenna | Control | Silo | Escape

[HackBond]

I feel like I've mentioned something about this in the thread before but I have new information anyway.

When entering comments into the Action Block Editor, if the Object Editor is open at the same time, the Object Editor refreshes with the Action Block editor. This creates a noticable delay when typing in characters for the comment. Is there any chance that this delay can be improved?
_________________
Also known as Spyster or Nyxem
[Youtube]

[Decoy] Antenna | Control | Silo | Escape

[SubDrag]

HackBond wrote:

I feel like I've mentioned something about this in the thread before but I have new information anyway. When entering comments into the Action Block Editor, if the Object Editor is open at the same time, the Object Editor refreshes with the Action Block editor. This creates a noticable delay when typing in characters for the comment. Is there any chance that this delay can be improved?

It updates that window in case you delete/add/update actions, since paths use the action values. It's to always get you the latest. I think comboboxes are just slow...there may be some possibilities to improve the speed by ignoring when it doesn't change. I'll think about it when get a moment.

[HackBond]

SubDrag wrote:

HackBond wrote: I feel like I've mentioned something about this in the thread before but I have new information anyway. When entering comments into the Action Block Editor, if the Object Editor is open at the same time, the Object Editor refreshes with the Action Block editor. This creates a noticable delay when typing in characters for the comment. Is there any chance that this delay can be improved? It updates that window in case you delete/add/update actions, since paths use the action values. It's to always get you the latest. I think comboboxes are just slow...there may be some possibilities to improve the speed by ignoring when it doesn't change. I'll think about it when get a moment.

I figured this might be the case but I thought I should ask anyway if there was a possibility of improving that somehow.
_________________
Also known as Spyster or Nyxem
[Youtube]

[Decoy] Antenna | Control | Silo | Escape

[Trevor]

you couold update on window focus only
that way its not trying to update all the windows at the same time every frame.

Trev
_________________

[RyanDwyer]

Wreck and I believe that the editor is able to write outside the bounds of a jump table relating to which weapons show up on the threat detector.

This is the switch statement from decomp, annotated with the weapon numbers:

Code:

switch (weapon->weaponnum) {     case WEAPON_GRENADE:       // 0x1e     case WEAPON_NBOMB:         // 0x1f     case WEAPON_TIMEDMINE:     // 0x20     case WEAPON_PROXIMITYMINE: // 0x21     case WEAPON_REMOTEMINE:    // 0x22         pass = true;         break;     case WEAPON_DRAGON:        // 0x0f         if (weapon->gunfunc == (u32)FUNC_SECONDARY) {             pass = true;         }         break;     }

The game subtracts 0x0f from the weapon number to find the jump table index. Therefore the permitted weapon numbers are 0x0f through 0x22. The jump table exists in memory from 7f1b7800 ending at 7f1b7850 (20 entries). The editor should make sure it only writes to the jump table if it's within those ranges.

If you want to check the switch statement itself, it's near 7f168c44.

I hope this isn't an issue for most other jump tables in the game...

[Wreck]

Yeah, it ends up overwriting into the next section, which just so happens to be float points that affects mission AI stats. Whatever a recent GE-X build did, had guard accuracy at perfection on Special Agent and higher.

[SubDrag]

Are you sure? This seems to match unless I'm missing something. Can you help show me steps to recreate on vanilla PD in editor. It doesn't even show up past 0x22 in editor?

Read



Write

[/img]