If my program is displaying that message, then it can't find CSSRoster.dat in the "/BrawlEx/" folder. It could be in the wrong place, have a spelling error or something, but thats what that error message means.
You probably know this, but ADPM parameters are very similar to STPM parameters. (Normal Brawl stages use STPM for pause-camera and shadow direction among other things.)
:0 oh wow..i feel kinda stupid now lol. I had the data right in front of me, i knew what ADPM stood for (Adventure stage parameters) and yet somehow it didin't click xD.
ADPM = Adventure Stage Parameters. STPM = Stage Parameters. Well, that makes things a whole lot easier. Hopefully some really interesting things are in here! Thanks for pointing that out mate!
In other news, i've found these new "ID's" everywhere now..it's strange o.O i wonder what they do. I also wonder if it's really GET1 that defines them. Maybe GET1 was just the easiest for me to see the ID's in, however there is nothing more besides these ID's in the GET1 besides a few float values...leading me to believe it ISN'T what i originally hoped it would be..i knew it was too good to be true.
However, they still seem to be ID's for referencing other files. It's likely that buttons and GMSJ (Explicit stepjumps which can be triggered without a door) still use these ID's for referencing triggerable events
I need help, it always says CSSRoster not found! Make sure to edit the CSS Code!
I don't know what to do.
You need to be using the CSS expansion to use the CSSRoster.dat method. If your not, you'll need to edit the CSS code to add the clones to it. This can also be caused from selecting the wrong directory with the tool. Make sure your selecting the 'pf' folder
Yes, when you enter a match and activate a CPU it will show as level o. This equates to 16... somehow. It's just a visual indicator really. But navigating away from the o, by attempting to change the level will remove the o as an option and give you the standard 1-9 option. To get it to come back I believe you have to leave the CSS.
The difference is definitely there... but I went through the entire roster and beat them with my main without losing once and I wouldn't consider myself a master Brawl player, so I don't know how much more tough they ACTUALLY are...
It's actually half an infinity symbol, from the infinite time image in rules. Dunno why brawl chooses to use that but it does.
ANYWHO, im thinkin about uploading a video tutorial today..anybody wanna tell me what the most useful one would be? I got some free time today
If you specific a memory offset, add something like "vBrawl P1 training mode" to let people know how you got them. Those should be the pretty constant.
For now i've just been adding the memory range for p1 vBrawl training mode. I'll probably specify specific memory offsets at a later date, im much more interested in discovering what they do right now then getting specific memory offsets
In any case, i updated the OP with info for GBLK (breakable blocks) and will probably start up on either buttons or the "punch sliders" as Brawl calls them. The uh..slidey things in SSE that you hit and then they move along the track and break stuff. Or maybe canons...or the cart tracks..idk which i will do first..
Oh also, for anyone interested, I've begun implenting almost all of these files into BBox. (not editable, just viewable and exportable). You can find the latest source for BBox here if people wanna export and view these things in hex editors
EDIT: Oh ho ho, i believe i found something like...event ID's in the files.. Seems GET1 files dictate events that call other files. For example, GNDV causes the clouds collapsing animation to play and all that jazz in skyworld, however removing GET1 causes the GNDV files to never activate, and the forced camera scroll doesn't activate either.
Upon further research, i noticed there are these ID's in GET1 that seem to match up with the GNDV Unknown values.
This has HUGE implications. It explains how buttons work, it explains how step activated events occur, and it explains how when certain item blocks are hit, events occur. SWEET. This is definitely a good find
BX_Fighter.rel basically is BrawlEx. It coupled with the generic modules is what makes the engine work. The config files specify the details for the fighter such as flags, functions, IC constants etc etc.
The kirby copy fix is the module that fixes kirby copying ex characters.
Here's what it says, "Microsoft .NET Framework, Unhandled exception has occurred in your application. If you click Continue. the, the application will ignore this error and attempt to continue. If you click Quit, the Application will close immediately.
Object reference not set to an instance of an object." Apparently the problem is with both my sc_selcharacter and common5 both. But I don't know why the sc_selcharacter is one that had already been prepared with slots for the clones.
Wait, why are you using both sc_selcharacter and common5? one overides the other. Did you check the compression on the sc_selcharacter of the one your using?
okay...well im going to need a little more information to try and fix it..try posting the crash log from when the program crashes..
Also, make sure your sc_selcharacter in either common5 or pf/menu2/ is either compressed to lz77 or none.
If they are indeed, try temporarily removing those files from the setup and see if it loads up. If it does, it means there is something wrong with your sc_selcharacter or common5
I'd use the current clone tool but it won't load the clones up from the old tool
By clone tool do you mean the config utility that PW made that edits fighter.dat and CSSRoster.dat files? or my clone tool? (speaking of which, now that i'm programming BBox adding support to my clone tool for adding new cosmetic slots should be a breeze.)
You should keep notes on file/memory offsets for all this stuff!
Indeed! i've been updating the wiki with the info i've found and keeping a local record of things i've found. (i think my account is called '3x' there idk)
When i add them to the wiki i've been specifying file offsets in both absolute to the beginning of the module, and relative offsets starting at section[4]'s offset inside the particular file.
The only reason i didn't record memory offsets is that depending on what mode your in, the offset changes of course. In training mode the memory offset is completely different then that of in normal brawl mode. In any case, i suppose i can add memory offsets as it would make it easier for others to test and contribute.
Fox's is really really small, but here is what i have for the people in this thread.
==Fox== 0x00 - 10 0x04 - 1 0x08 - 0 Weird stuff, see earlier video 0x0C - 20 0x10 - -1 0x14 - 0 0x18 - 1 - Aerial fox illusion power multiplier. 3 = insta-death 0x1C - 0
but it seems that other then articles, some characters have *general power* multipliers or something that multiplies the knockback, hitlag, damage etc of almost all hitboxes the character possesses. (wario is an example of this multiplier dealio).
In regards to that strange effect i achieved in that video, it seems that the values in section[4] at 0x00-0x0C are (almost)always the same between modules, and the third value is the one that causes those strange shenanigans
Hey Ernie, idk if your aware but rebuilding any changes made to STDT entries writes all 0's out of the unsafe Buffer instead of the correct data. At least the current Source on github does, just thought i would let ya know
I noticed when i was trying to get some of the BLOC entries rebuildable. I'll likely setup the files first so that BBox at least displays them correctly with various info before i implement editing them. Exporting individual entries (GDOR, GEG1 etc) is done though, replacing on the other hand is not.
When Kirby copies a character, the character's Fighter Id is sent to a function located in ft_kirby.rel at roughly m60[1] 0xD420. At this particular point, the code checks if the id is either Kirby's id (which he can't copy), the alloys' ids (which he can't copy either), or an ExCharacter's id (added by BrawlEx). If the id is valid, it sets it into one of Kirby's soWorkManageModule variables (i.e. one of the PSA variables). From there, only if the previous check was valid, another code located around m60[1] +0x1D618 will read that id and use it to lookup into a table of ft<Character>Transactor objects located in BSS memory at m60[6] +0xD20. These objects are declared inside sora_melee and seem to be responsible for creating the copied articles that Kirby uses. When Kirby copies one of the Forbidden 7, the ft<Character>Transactor entry inside the table is null - which is what causes the game to crash.
oh ho ho? well, looks like i have something to toy around with i sure hope i find something awesome!
As for why I keep coming back to this game in particular, that's mainly because I like hacking it. That, and it has one of the best hacking communities for a console game with many talented modders and active hackers like myself.
So don't worry too much about me getting burnt out. I do this because this is how I like to spend my spare time.
Thats good to hear. It's the same for me lol, there's just something in me that doesn't want to stop hacking this game and figuring out new things until it's completely done, and then some, though im nowhere near as knowledgable yet, i must learn moar
Show Posts
i sure hope i find something awesome!