The module editor is a bit of a work in progress right now. I originally intended to have a new control or form for the object/method editing. However with the planned release date nearing, i figured i would put that back in for now. Even then, a few of my changes were (unfortunately) unable to be committed and released, since my internet decided to die Christmas eve.
As for the problem with windows 8 interaction, i can't really help there. I don't have any machine running windows 8 at the moment. I can however look into it if you post a screenshot of the problem
So I went to start using .74 for animating, and when I went to view an animation... Well, I'll let the pictures tell what happened.
When it originally was like this In .71. Any ideas?
Unfortunately, most things related to the model previewer or animations are out of the range of my abilities, as BJ rewrote a whole lot of the model related code in both Brawllib and Brawlbox in this update. That all said, this is the perfect example of why the automatic updates will be helpful
Your seeing that, because the latest release's version number is different from the one in the development build. That's a given, since we haven't released the new version yet. This won't happen to people who get the released version, since they're version number won't be ahead of the latest release
Visual Studio is the easy way to compile it without these errors. Although it can detect errors when compiling if any code like that exists.
Please, i request that you do not post development builds in this thread.
We're nearing release now anyways, so please let others wait the short amount of time left. If people get the dev build now, it will be unfinished, and many will likely not come get the completed version afterwards. I would like for people to get the most complete, most functional build of our work rather than an early development build that will likely be broken, all over a matter of time as short as this.
That being said, you can compile the code yourself if you'd like. Just please, don't post it here. If anybody wants the dev build, compile it yourself or PM Brandon here. The less confusion around this release the better.
Well i've currently finished re-writing all core functions, and finished adding some new ones. The tool is back to (close to) 100% functionality in regards to where it last left off, however i have more plans for the tool before i officially release it.
I apologize, but currently your better off waiting until i finish the new version of that tool. If you really want to try the old one, an updated link is in my signature.
I briefly looked into the conversion process as well, though at the time it was too much of a hassle to do without adequate documentation. Now that you have it, best of luck to you mate.
You don't require visual studio professional to compile it. You can use the free version by Microsoft, visual studio express. Personally, i prefer compiling code myself when it comes to open source projects anyways. It's pretty easy. just go the github repo on the first page of this thread, and on the right there is a button to download the source in a .zip. Just unzip it and double click the .sln file. Then in the menu bar up top click build->rebuild solution.
Your compiled version will be in brawltools/brawlbox/bin/debug or brawltools/brawlbox/bin/release depending on if you compiled a debug build or release build.
Aww yiss, this is great. I've been meaning to add the object parser back.
One thing though - I've been hesitant to add it back because I don't know if ALL rels used in any game follow this same "null, code, constructors, destructors, constants, objects, BSS, null" kind of format. I know that some brawl rels only use 5 sections instead of 6, which would mean that parsing the 5th section as objects would be incorrect. Another thing is that tree nodes are a bit cumbersome to dynamically manage using code. I was thinking there should be an intuitive object editor that you could optionally open and would be incorporated into the section editor window. It would only find objects if there were strings in the section so it would have no negative effect if used on non-object sections.
Yea i had the same thought. Not all rel's follow the pattern, and i don't like the idea of statically hard-coding in the section to be parsed based on index either. It's really only a placeholder I had a similar idea to make a new control + form for the method editor, that way it'd be easier to edit them and at the same time it would be easier to add / delete methods without coding the functionality into the section editor.
Wait wait wait lol. I actually already did this. I haven't committed in a while because I'm kind of doing a pretty large rewrite of... things... and I guess I forgot to commit my REL changes. I'll do that so your code is up to speed with mine first.
Well...whoops haha xP Alrighty, well I'll be looking forward to the changes. I wish i had internet right now then i woulda seen this before i actually committed it xD I'll be on the lookout.
forgot to ask more of this. will you be able to press on a Method and see what it leads to hex and possible able to change it directly on it instead for going into section[5]? o: let say I want to change Method[0][0] in your pic from external to inside module directly by pressing on it without looking for it in section5? will you also make it possible to add Method in a section this way? also, keep it red! that way its easy to tell if its used in that module or not!
Well, i intended to allow you to open the relocation's offset in section[5] as well, but i figured i would wait until i finished the actual method editor (or something to the same effect?) before doing that. But don't worry i got ya
Been a while since something was posted here, just wanted to let people know that development hasn't stopped
Anywhozits, here's some pictures! Methods! Under section 5 will be the methods. Im still working on a few kinks here and there, but for the most part they are completely functional. You can right click->open memory viewer to open directly to the method's target section and offset. Using the section editor of course, so it will disassemble and show the method. This also means you can see linked commands and open relocations, since it's using the section editor. (which is AWESOME for following exactly what a method is doing.) speaking of which...i'm also working on making it so you can double click on any branch or branch link command, click "Open Branch" to jump to where the code would jump to, without doing the math yourself Just more convenience for following the methods flow
(Don't mind the red colored nodes, that was just to temporarily show me that external method nodes were working right...though it could stay if people would like?)
Awesome! i had/have no idea what those things are honestly, always wanted to know though..
oh uh...to go in conjunction with your module editor stuffs, i'll be randomly adding more PPC opcodes as i find them while digging around in the fighter modules.
I was paid to get Brawlbox's module editor all fixed and working (apparently it still doesn't work right?) so if you guys could research what the heck reads the moveset file data after that thing is working, that would help out a lot. I will do what I can.
Indeed. This is one of the main reasons im excited about it. If i and pikazz or anyone else who's willing can find where the modules actually load up and read the data from the moveset file, it would make it possible to have ikarus optionally load the module file as well and enable the article editing/previewing to be more dynamic, as well as many other things (liking porting articles) ...but yea. Totally the first thing imma be looking into when it's finished I already have a few ideas of what methods to start researching to find it..
Ok, soyou added th features to the progeam already, or not? Also, they will be uploaded as a new version of BB/Ikarus or they will be an update of V0.73?
They will be included in the next official release, based on the repo that me, Liberty, and BJ are all committing to. (as well as anyone else who contributes to the source).
I would love to try making a PSA command for spawning an enemy if you figure this out Sammi
Interestingly enough, this may be easier than i previously thought. It could probably piggyback off of the item routines considering they're all contained within sora_melee, and is the way the enemies in stages are spawned in non adventure stages. It could even be made to load enemy files off of a new folder on the SD specifically for enemies. Though i still need to do quite a bit more module work before i can make it work.
All i really have to do is RE the rest of the ASM routines in sora_melee and then add new ID's to the item system. Luckily that's the gist of it since the game automatically gets the file path from section[5] and passes in the Item ID. Then it uses the ID as an index for a list of item names, adding that to the path. Once that is tested and working, i can possibly move the system to it's own module similar to how PW did for BrawlEx. Of course i still need to learn just how PW's sora_melee hook works first..
You should remove anything CSS related from the GCT. However, if your having the CSSRoster.dat read by the game and it's still a vBrawl layout, it's likely that the CSS expansion isn't correctly installed. Remember you need to have all the core files from it. (including common3.pac, replacing ours.) If all that is done, than im sorry but there isn't much i can do to help :/
Show Posts
Under section 5 will be the methods. Im still working on a few kinks here and there, but for the most part they are completely functional. You can right click->open memory viewer to open directly to the method's target section and offset. Using the section editor of course, so it will disassemble and show the method. This also means you can see linked commands and open relocations, since it's using the section editor. (which is AWESOME for following exactly what a method is doing.) speaking of which...i'm also working on making it so you can double click on any branch or branch link command, click "Open Branch" to jump to where the code would jump to, without doing the math yourself 
