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

[MultiplayerX]

Okay so for THREE days I've been putting off finishing this mod because of Depot's stupid loading issues. Apparently the geometry conflicts with weapon placements because if you try and place more than one set of weapons it freezes on loading. Either that or it could be a clipping issue HOWEVER I tried moving the things around and SAME thing. Hmmmmmm well I'm moving on to TRAIN for now and the only thing left I can figure is my setup is either corrupted OR the setups themselves have some coding issues SINCE every level in the FIRST MOD worked perfectly in ANY level.

INCLUDED A FILE SUBBIE IF YOU THINK YOU CAN TROUBLESHOOT THIS. Multi X I'm moving on to Train for now lol

DEPOT WTF FILE LOL: http://www.kalleload.net/uploads/haujfgyuqauo.zip
_________________

[SubDrag]

You probably ran out of memory allocation, depot is very high.

[MultiplayerX]

Aaaahhhh The thought did occur to me that maybe the million scaled DOORS are the main issue of the memory allocation Think I may just redo the setups using ARCHIVES. Will this effect anything or does multi setup level size matter?

ONE MORE QUESTION.... If you overwrite a setup and then try to use it for a different setup does it mess up the tables? I was thinking I did overwrite some setup files into the main folder for several levels. Complex was used in Facility in the FIRST mod and stuff This same file may be conflicting from a facility overwrite? I refreshed and just overwrote ALL setups from the BACKUP folder just in case MOD PART ONE is conflicting with PART TWO That would explain Streets crashing from pasting things.
_________________

[bmw]

To answer your second question - yes, overwriting in that way will cause all kinds of problems - only one level per BG/clipping/setup will work.

As to the depot specifically - this is probably the roughest map to attempt to convert to multiplayer. The only suggestions I have (and this will give you minor improvement at best) are as follows:

-the 3 door garage (the one with 3 doors on the same wall) - either lock 2 of the doors or link all 3 together so they all open and close together and then change the door bitflags for all 3 doors to DOOR NOT VISIBLE and uncheck the DOOR VISIBLE flag. This will cause this garage to only load into memory when a door is open. The reason they're all set to visible is that if a room has multiple doors, opening 2 doors and then closing one of them will cause the portal in the still-open door to go black. But if you make it impossible for this situation to arise (either locking all but one or linking their movement together) you can get away with changing those bitflags.

-the train doors - uncheck the DOOR VISIBLE flag and check the DOOR NOT VISIBLE flag - I can find no reason why it should not be this way, otherwise the train interior is loaded into memory when the door is closed and that is unnecessary since it has no windows.

-the backzone warehouse (with 3 doors and connected building) - I can't recall what works here and what doesn't but you may be able to change some door flags here, though I know for sure you have to either link the 2 on the same wall together or lock one of them.

Finally, any room that doesn't have a railing, you can delete its secondary indice file (mainly garage interiors) - you do this by exporting the rooms to a room positions file and then changing the final entry of the line for that particular room to a NULL.bin, then re-exporting the room using that new edited file and write the new bg file to rom. Doing this will cause you to lose some detail (ie, any textures painted on over walls) but it may alleviate your problems.

[Dragonsbrethren]

I'm not sure if removing them will really help, but there are also five silos outside the playable area (forget the exact room numbers) that you can delete entirely since they have no portals/vis data and are never displayed in-game.

[bmw]

Zoinkity would probably know more about whether removing those silos would do anything or not - I've wondered that myself whether or not a room that is never visible has its textures still loaded and counted against texture memory.

Also another small suggestion - if you're leaving the safe in the game but locked, I would delete the blueprints object that's stored inside.

[SubDrag]

All textures for the level are loaded on start of level, so it's to your advantage to remove all instances of a texture if removing. The props/guards load textures on view though. The editor has a live -mt calculator from PJ64 where you can prove it to yourself (in room positions mode)

[MultiplayerX]

Wow thanks for all the advice guys! This is some really fascinating information. I have redone Depots setups using ARCHIVES instead of COMPLEX since my first release of the mod it seems to load EVERY level perfectly with no issues and has the most objects etc to hold up a Solo setup. I think I'll change ALL the door flags in the garages too since there are no windows in them as well. Hmmmmmm maybe that's why the level blacks out so much especially with the SILOS?

OH....speaking of silos do i save the removal as the background file right? Then overwrite it in setup? There is no ROOM injection button in the editor so I just wanted to be sure I understand this is a part of the background file?

MAN... i'm just ready to get moving again so I can get this thing knocked out. Any advice for Jungle or Egyptian I should be aware of? Especially JUNGLE since it has 200 something objects????
_________________

[bmw]

To delete rooms, there are several ways to do this but the easiest way is to simply delete their entries from a room positions file and then re-export. A more detailed procedure would be as follows:

1) Create an empty folder somewhere on your computer.

2) Set visual editor to ROOM POSITIONS mode, right-click on any room, and choose EXPORT ROOM POSITIONS TO TEXT FILE AND RE-EXPORT ROOMS.

3) A pop-up box will come up with a save-as .txt file dialog. Save this file to your empty folder.

4) Click on each of the rooms you want to delete (from within the visual editor) and make note of its room number.

5) Open the text file you created with notepad and delete the the line-entries for the rooms you want to delete. To figure which lines these are, don't count the very top line (with all zeros and Nulls), start counting with the second line. Each line counts as a number - 1,2,3,4,5,6,7,8,9,A,B,C,D,E,F,10,11,12, etc - remember its hex so count carefully.

6) Once you have those entries deleted, save your changes, then go back into the visual editor, right-click, and EXPORT FULL BACKGROUND FILE. It will ask for your room positions text file - use your modified file.

7) The second pop-up box will be for saving your actual background file. Save it to your now not-empty folder.

8 ) Go to TOOLS -> CONVERT ROM.

9) Use the very bottom drop-down box to write your new background file to the rom. You will be using the very top set of options (all end with FULL FILE) - look for the appropriate background file to overwrite (if you're pointing your setup to a different level, that will be the level's bg data you want to modify) and then click the very bottom button. You will have 3 boxes to choose stuff - choose your exported bg file, then a normal GE rom, then choose a name for your modified rom.

[zoinkity]

The whole point of ROM hacking is that none of the shuffling (as in using base setups from other stages) is necessary. But that's not that important.

The only impact the silos in Depot have is causing their textures to preload and taking up space in the BG file. Otherwise, they aren't loaded. Only rooms that are visible are loaded, and even then they're shuffled out depending on priority (your room has highest, special vis. unless set otherwise, attached next, attached to that, etc.) and since they're never visible and nothing makes them visible they won't be loaded.

The three big problems you'll face are having enough room allocated for all your objects, having enough memory allocated to run seamlessly, and not clogging the pipeline with so much stuff frameskipping renders things unplayable.

Jungle, Aztec, Silo, and Depot are all the worst offenders. Silo, Depot, and Aztec are hardest on point 1, and Jungle is worst with the final two points. For Jungle, I'd suggest keeping all the sky 'far' values relatively close. Low visibility may be bad for sniping but very good for framerates. The more vertices that need to be rendered at a given time--especially these complex plants--the more time the RDP needs to do it. This is compounded 2-4 times for each additional player. Reducing render distance reduces how much the coprocessor needs to work.

Texture allocations for stages basically don't need to increase unless you have issues with character or weapon image corruption. Even then, you're only increasing by 1-2 blocks (each about a kb).

MP requires increasing a solo stage's vertex buffer anywhere from 1 1/3 to 2 times it's original value for each additional player. After all, you're displaying 2-4 times as much stuff, so you need to have 2-4 times as many room models as usual at any given time to avoid blackouts.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[MultiplayerX]

zoinkity wrote:

The whole point of ROM hacking is that none of the shuffling (as in using base setups from other stages) is necessary. But that's not that important. The only impact the silos in Depot have is causing their textures to preload and taking up space in the BG file. Otherwise, they aren't loaded. Only rooms that are visible are loaded, and even then they're shuffled out depending on priority (your room has highest, special vis. unless set otherwise, attached next, attached to that, etc.) and since they're never visible and nothing makes them visible they won't be loaded. The three big problems you'll face are having enough room allocated for all your objects, having enough memory allocated to run seamlessly, and not clogging the pipeline with so much stuff frameskipping renders things unplayable. Jungle, Aztec, Silo, and Depot are all the worst offenders. Silo, Depot, and Aztec are hardest on point 1, and Jungle is worst with the final two points. For Jungle, I'd suggest keeping all the sky 'far' values relatively close. Low visibility may be bad for sniping but very good for framerates. The more vertices that need to be rendered at a given time--especially these complex plants--the more time the RDP needs to do it. This is compounded 2-4 times for each additional player. Reducing render distance reduces how much the coprocessor needs to work. Texture allocations for stages basically don't need to increase unless you have issues with character or weapon image corruption. Even then, you're only increasing by 1-2 blocks (each about a kb). MP requires increasing a solo stage's vertex buffer anywhere from 1 1/3 to 2 times it's original value for each additional player. After all, you're displaying 2-4 times as much stuff, so you need to have 2-4 times as many room models as usual at any given time to avoid blackouts.

ZOINK are you saying you could just use a SOLO setups, clear the level, then use respawn MULTI STARTS and the level will work the same way? ??????????
_________________

[zoinkity]

You don't even need to replace an existing stage setup. You could add an entirely new one.

Well, actually you can only add, what, 8 of them before you hit the physical end of the list. (However many Speccy games there were, -1. It was a slight issue.)

It does file lookup based on name patterns. If you have a file with the proper stage setup name then yes, it just works.

Technically, if you rewrite the dev device filename lookup in the event of a miss you can upload them from a GS into an unused portion of memory as well. Really, you just need to redirect the table to someplace useful and give it valid entries. That works for anything by the way--anything that it tries to look up in the main table at least. You're sort of screwed when it comes to images unless they're embedded, and that's a whole other kettle of kittens.

So yes, you aren't limited to just recycling existing MP setups. That's crazy talk.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[MultiplayerX]

zoinkity wrote:

You don't even need to replace an existing stage setup. You could add an entirely new one. Well, actually you can only add, what, 8 of them before you hit the physical end of the list. (However many Speccy games there were, -1. It was a slight issue.) It does file lookup based on name patterns. If you have a file with the proper stage setup name then yes, it just works. Technically, if you rewrite the dev device filename lookup in the event of a miss you can upload them from a GS into an unused portion of memory as well. Really, you just need to redirect the table to someplace useful and give it valid entries. That works for anything by the way--anything that it tries to look up in the main table at least. You're sort of screwed when it comes to images unless they're embedded, and that's a whole other kettle of kittens. So yes, you aren't limited to just recycling existing MP setups. That's crazy talk.

Oh wow that's cool. SO you can just empty a SOLO setup and throw in your MULTI start points and walah!???? That gives me a ton of ideas for some custom stages Might be a while as I have to go back to preparing a film for this year's film festival AFTER I finish GoldenEye Legend

NOTE: BTW ....Here's a curious question... Ever wonder why they made the train track in TRAIN so long. It seems long enough for a guard layout



ALSO ZOINK uuuuummmmm kettle of kittens??????? I know they eat chow dogs in China like chicken. Is this some sort of delicacy we should be aware of?
_________________

[zoinkity]

You'll need to get rid of all the actions, guards, briefing, and objective stuff, but yes you could start from a solo stage much easier.

The track is so long so it can extend into the distance realistically. If it ended in an image it would obviously be a flat surface (Mission: Impossible is an example) or faded too early it would appear that the train simply ran out of track. Distance adds realism.

"Kettle of kittens' is alliteration, which makes for slightly better narrative than "**** of @#$%"--no intended offense to Q-Bert.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!

[MultiplayerX]

zoinkity wrote:

You'll need to get rid of all the actions, guards, briefing, and objective stuff, but yes you could start from a solo stage much easier. The track is so long so it can extend into the distance realistically. If it ended in an image it would obviously be a flat surface (Mission: Impossible is an example) or faded too early it would appear that the train simply ran out of track. Distance adds realism. "Kettle of kittens' is alliteration, which makes for slightly better narrative than "**** of @#$%"--no intended offense to Q-Bert.

Oh I see Well, Train is almost done. Weapon placements then on into the Jungle Getting excited about finishing this hopefully NEXT WEEK now thanks to Streets and Depot slowing things down. I will be busy this holiday weekend. DEPOT runs great now. Couldn't get rid of all the blackout issues BUT everything is in there as well. NO object sacrifice needed using ARCHIVES setup. I can't believe it took 4 days to get past this bloody level. Lol It's maximized for multiplayer now with all SOLO objects
_________________