Jump to content
  • 0

I also propose a challenge.


Conker
 Share

Question

Recommended Posts

  • 0

We need to get a list going of other forums for modding other games. Like these for example:

 

Goldeneye/Perfect Dark modding community

http://www.shootersforever.com/forums_message_boards/

 

SMW - SM64 hacking community

http://www.smwcentral.net/?p=viewforum&f=64

 

I also second what Conker is saying, I would love to have a new SSB64 rom with new levels and characters.

  • Like 1
Link to comment
Share on other sites

  • 0

Not much time right now, but I did work on SF64 a few years ago. See... my YT channel, z64 and OZMAV SVN, I think.

Speaking of which, if you're ever interested, it would be interesting if you could somehow make a rewrite that excels to or near the level of SceneNavi is at with OoT. A larger variety of games need to be modded.

Link to comment
Share on other sites

  • 0

Haha, this is nostalgic, reminds me of when I first messed around with the game:

 

 

Posted Image

 

Meteo's boss in all its untextured (code copy-pasted, hacked up and partially commented out from SceneNavi) glory. Got a very dumb Ucode interpreter and renderer going, just so that I can try and render stuff. Next I'll try to figure out more about the enigmatic table at 0xCE158 0xC5BFC in the code file, which should help figuring out level to file linkage... and speaking of which, here's what I currently know about that, in (messy...) copy-pasta form from my local wiki setup:

 

 

Level to File Linkage

 

...oh man, I wish I knew how this worked! There is a pointer table inside code at 0xCE158, which points to the level headers inside each level's main data file. It's in the same order as the level IDs used in the Level Select GameShark code, so ex. the training mode stage is ID 0x0A. The table's format is simply one address for each level, so I'm not gonna make a wikitable for it. One address in there is all zero, that for level 0x0F, so this might've been a now-removed level?

Now, how the game knows which level uses which file(s)... I am not sure. There is a table of some kind at 0xC5BFC inside code, but... changing anything in there seems to break the game. I suppose I'm just not changing the right things, or change them to the right things, so this'll be the next lead to follow.

 

Presumed Format of Table 0xC5BFC

 

The table appears to consist of 33 entries, each containing 19 address pairs (RAM and ROM). Red descriptions denote uncertain information.

 

Location - Description

 

0x0000 - Code overlay

0x0008 - RAM location 1

0x0010 - RAM location 2

0x0018 - RAM location 3

0x0020 - File for RAM segment 0x01 (*)

0x0028 - File for RAM segment 0x02

0x0030 - File for RAM segment 0x03

0x0038 - File for RAM segment 0x04

0x0040 - File for RAM segment 0x05

0x0048 - File for RAM segment 0x06; main level file

0x0050 - File for RAM segment 0x07

0x0058 - File for RAM segment 0x08

0x0060 - File for RAM segment 0x09

0x0068 - File for RAM segment 0x0A

0x0070 - File for RAM segment 0x0B

0x0078 - File for RAM segment 0x0C

0x0080 - File for RAM segment 0x0D

0x0088 - File for RAM segment 0x0E

0x0090 - File for RAM segment 0x0F

 

↑ An address pair of all zero, for any of the segments, means the segment is not associated to a file.

 

 

Edited by xdaniel
  • Like 5
Link to comment
Share on other sites

  • 0

This is horrible...

 

...and yes, it really is, because this is almost as hacky as the old SF64 Toolkit's level viewer was... or, it's hacky in different ways. It does use the enigmatic table 0xC5BFC to populate the RAM segments (which might actually start several entries before that), but the address of Corneria's entry in said table, which is 0xC5BFC, is currently and temporarily hard-coded in and the program throws an exception if you try to load any non-Corneria entry...

 

I think I remember why I had stopped hacking this game. I didn't get anywhere without hard-coding all kinds of stuff and I couldn't even find half the data you'll need for an editor (or even a good viewer) -.-

 

 

Posted Image

 

Link to comment
Share on other sites

  • 0

This is horrible...

 

...and yes, it really is, because this is almost as hacky as the old SF64 Toolkit's level viewer was... or, it's hacky in different ways. It does use the enigmatic table 0xC5BFC to populate the RAM segments (which might actually start several entries before that), but the address of Corneria's entry in said table, which is 0xC5BFC, is currently and temporarily hard-coded in and the program throws an exception if you try to load any non-Corneria entry...

 

I think I remember why I had stopped hacking this game. I didn't get anywhere without hard-coding all kinds of stuff and I couldn't even find half the data you'll need for an editor (or even a good viewer) -.-

 

 

 

 

 

yeah, I tried modding SSB64 once and ran into the same problem. it's because a lot of the developers were retards and used virtual addresses with the RSP instead of using the segment table like the manual tells them to do.

Link to comment
Share on other sites

  • 0

There appears to be a table for Object type/IDs 0x3E8 and up in the main level file. The starting offset for this table is hard-coded so you're going to have to go through the asm to find it for each level. Corneria's (0x0095D2F0 Virtual Start Address) begins at 0x0003D9E8. I have no idea how it works from here on but it looks like each entry ends with FE000000. Or maybe not. I'm not sure.

  • Like 2
Link to comment
Share on other sites

  • 0

Dumping some notes here while messing around...

 

Training stage (virtual start 0x00DD7620), at 0x9748 is the ground-based turret thingy (ID 0x0410 I think). Begins with "D00A0008"; 08 might be index into another table, probably 0xCB1FC in code?, that actually determines what model is used, as changing to 03 (from next entry at 0x977C, ID 0x0411 then?) changes the model to that of the rotating, round, floating enemies. Changing to 09 gives it the model of those winged enemies, complete with flapping animation.

 

EDIT: 66 are the moving doors from the training stage; while not moving, they have their usual collision model, etc. meaning you can fly right into them & get damaged, can't shoot nor target them, etc.

 

EDIT 2: Something else in there, besides the D00A00xx "command", determines ex. if the enemy shoots at you. Nulling the remaining data until FE000000 makes them not shoot at you (still targetable, destroyable).

EDIT 3: There's C0050087 00000064, where the 64 seems to be the amount of time from spawning until they shoot. Setting that to 00 makes them shoot right when they come into view.

 

EDIT 4: E00000xx 000000yy seem to be shot properties or something; changing xx appears to change the angle of the shot, yy appears to be another delay. This enemy has this command twice, E0000002 00000006, E0000002 00000001. Changing 06 in the first to 01 reduces the delay between the two considerably. (EDIT 7; 06, not 0A)

 

EDIT 5: Oh man, wtf? Changed the second E0###### shot thingy to "185A0384 02140008" from the moving doors; enemy shot at me once, then turned and ran off to my left!

EDIT 6: "16B40384 FC040014", bwahaha, they shoot, then turn around like "Hmpf!", as if they're mad they missed XD

Edited by xdaniel
  • Like 1
Link to comment
Share on other sites

  • 0

I think I figured out the F0 command. It's used for messages.

 

F0xxyyyy

 

xx = Character name/portrait

00 = Fox

0A = Falco

14 = Slippy

1E = Peppy

28 = Katt (Glitchy Portrait?)

5A = ROB64

yy = Message ID

 

The message table is at 0xCCAC in file 0x00DE1360 (Virtual Start Address)

 

xxxxxxxx yyyyyyyy

 

xx = Message ID

yy = Offset of text in RAM

 

EDIT: D20000xx will turn the enemy into a teammate.

 

00 = Fox/James?01 = Falco02 = Slippy03 = Peppy04 = Katt*05 = Bill**Portrait will be glitchy if used on levels other than the ones they're supposed to appear in.

 

The 00 command modifies movement speed and can also act as a delay timer.

 

00xxyyyyxx = Movement speed (0x7F max?)yy = Delay

 

EDIT 2: Forgot the D0 command

 

D0xxyyyy

xx = Health

yy = Model

 

002B is the Arwing.

 

EDIT 3: C0 has something to do with the way an enemy attacks.

 

C0xxyyyy

 

xx = Attack/Action

09 - fire laser twice, spin, fly up 0A - fire laser once, spin, fly up 0B - fire laser twice, fly up 0C - fire laser once, fly up 19 - fire laser ball when really close, fly left 1A - fire 2 laser balls, fly left 1B - fire laser ball, fly left 2E - changes into a different enemy?

yy = unknown

Edited by fkualol
  • Like 2
Link to comment
Share on other sites

  • 0

I'm starting to think that hard-coding stuff isn't the worst option... or, maybe not "hard-coding" in the sense of putting a bunch of ex. offsets into the actual code, but having external files that contain all of those offsets, file numbers, what have you. Not unlike SayakaGL and its ZeldaVer.xml, with the scene, object and actor table offsets, etc... That would mean manually looking for ex. our newly found scripting commands in every level file, but all that seems more feasible (for me) than tearing apart the game's code, or interpreting it in the editor. Hell, it might be possible to find some of this stuff automatically by making the program recognize patterns in the data, which would be not unlike SceneNavi...

  • Like 2
Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.