Adding New Characters

[Tcll]

btw, as far as the goal of this thread, I have to input that may not be possible for a while...
(as far as I know anyways, not sure who else is looking into the stuff I'm looking into)
I had a heck of a time designing the pathfinder to read just about any HAL_DAT formatted file... heh

I still have to figure out the order of the data applied to the relocation table.
(building the relocation table is easy, just gather all of the (valid) pointers in order from the data section of the file)
but as far as building the data section, everything needs to be specific as it's indexed from elsewhere in the game, in particular by animations and such.

 

[CeLL]

Do you know if the data for a character's model is just somewhere inside Pl*.dat or if it's in a different file like Pl*Nr.dat?

If I'm digging around in animation data(Which is slow going, but still progressing. I think I may have found two scripts the game calls for animation files, but I'm not entirely sure what their parameters are) I might as well dig around in the model data while I'm at it.

The 3D models are different per color

 

[Ampers]

would knowing the way brawl handles animation help? We clearly understand that pretty well if you just look at BrawlBox. I don't know how similarly the two work.

 

[Doq]

would knowing the way brawl handles animation help? We clearly understand that pretty well if you just look at BrawlBox. I don't know how similarly the two work.

For all intents and purposes, we assume that the two are vastly incompatible due to the different engines: Melee uses it's own engine, while Brawl uses Intel's Havoc engine.

 

[Tcll]

Brawl uses Intel's Havoc engine.

well heck, didn't know Intel played a part in this.

yea Melee used HAL's own engine (same engine used in Kirby Air Ride), which is why I add HAL_DAT to the format.

btw, I personally love the structure of HAL's format, and am considering using it in my own games.
the MDL0 structure sucks and is so inefficient compaired to Melee's.

HAL's structure is actually infinitely expandable, though it's not as easily moddable.
(you can literally define your own structures and link them in HAL's format)
^ I could make the format support fur if I wanted to

the only solid part is where the structures are defined.

my pathfinder works using a bunch of pre-defined ambiguous structures and categorizes them based on their size.
so it doesn't actually know what structure is what, it just simply calls the function associated with that structure (if everything is valid)

how the pathfinder works is it makes sure the testable path is 100% valid.
it validates the file's unknown structures match the expected structure definitions.

 

[Doq]

well heck, didn't know Intel played a part in this.

They didn't, Intel just acquired Havok, Inc. in 2004 (so before Brawl was released).

 

[MagicScrumpy]

Tcll, what exactly needs to be accomplished in reading and working with the HAL structure for models before we're able to do cool stuff with it? What else---besides figuring out the format of the relocation table---needs to be done before importing or significantly modifying (more than just some vertex edits) models?

Is there anything that anybody can do to help out with that? Like, would Tater's help or any minor research (which I would be happy to try to do) benefit you in any way? I'm not necessarily (but still in some regard) referring to the development of UMC (though that tool will also be very useful for this sort of modification when we are able to use it to convert models into that crucial HAL format) in saying this.

 

[Tcll]

I think you mean to say writing and exporting... but bleh

for models alone in total known data, I've only really gotten as far as the joint root node (documented on the HAL DAT format page), everything else is still pretty unknown, including stages.

I'm not sure what others have figured out with the game logic and animations and such, but I do know there's still alot to be covered, which will eventually be found out

the only thing that would really help is if I could get more people together on my UMC skype group to talk about the format... heh
not to mention me sharing my repo with them to fill in the blanks with their knowledge.
(I can't do every last little thing in a short amount of time... I'm already doing everything)

I'm not necessarily (but still in some regard) referring to the development of UMC (though that tool will also be very useful for this sort of modification when we are able to use it to convert models into that crucial HAL format) in saying this.

well, I still have yet to look into exporting the format as I can't even currently get bones to import properly.
(I currently can't transform UT data because of the LRS to MTX calculations returning non-invertable matrices)
^ brbx src btw.

but once I can import the format properly, exporting Pichu is my first task
(if I can export Pichu as a DAT and have the main data (including added extras) be equal to PlPcNr then I'll have the format roughly moddable)

moddable file structure: (in theory)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # header
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # data
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # modded data
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # relocation entries
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # modded relocation entries
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # root nodes
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # modded root nodes
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # strings

the offset of the relocation table doesn't seem to matter to the outside references if I'm not mistaken.
(I havn't really looked into this, so don't quote me if I'm wrong)

 

[Tater]

I think you mean to say writing and exporting... but bleh

for models alone in total known data, I've only really gotten as far as the joint root node (documented on the HAL DAT format page), everything else is still pretty unknown, including stages.

I'm not sure what others have figured out with the game logic and animations and such, but I do know there's still alot to be covered, which will eventually be found out

the only thing that would really help is if I could get more people together on my UMC skype group to talk about the format... heh
not to mention me sharing my repo with them to fill in the blanks with their knowledge.
(I can't do every last little thing in a short amount of time... I'm already doing everything)


well, I still have yet to look into exporting the format as I can't even currently get bones to import properly.
(I currently can't transform UT data because of the LRS to MTX calculations returning non-invertable matrices)
^ brbx src btw.

but once I can import the format properly, exporting Pichu is my first task
(if I can export Pichu as a DAT and have the main data (including added extras) be equal to PlPcNr then I'll have the format roughly moddable)

moddable file structure: (in theory)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # header
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # data
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # modded data
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # relocation entries
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # modded relocation entries
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # root nodes
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # modded root nodes
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # strings

the offset of the relocation table doesn't seem to matter to the outside references if I'm not mistaken.
(I havn't really looked into this, so don't quote me if I'm wrong)

I've been interested in the model format for a while, and I think the model format may play a part in the animation format. I'd like to be a part of that UMC skype group if that's cool with you; I'm not well-versed in Python but I'd love to learn more about what you know and see if I can contribute at all.

 

[Tcll]

sure, in fact at anyone else too:

Skype: Tcll5850 (DarkPikachu)

just send me a request saying you'd like to join my UMC skype group and I'll add you right off
(I'll know you aren't a bot trying to add me if you mention UMC)

 

[PK Illuminati]

Even if it were found out on how to add a new "character" whether that be a PAL and NTSC or an entirely new one, the UMC (Universal Model Converter) is very, very far from being done. Tcll who is working on UMC has nearly come to a stand still with his knowledge. He needs help with something 3D related which he doesn't have enough knowledge on yet. If you wish to check out his progress visit his thread here.

It's not that far.
With help from revel8n, Tcll's been getting very far on most characters, and even other games with the same .dat structure like Kirby's Air Ride!
tcll is my favorite person

 

[Tcll]

OMG! how did I not knotice your post before @Veggies =o

big thank you! (incuding @PK-illuminati)

I've got a few other sources who havn't responded yet
- Ian Mallet
- sicdf
- mike_2000_17 (from Daniweb)

not sure if I asked on BlenderArtists or the OpenGL forums >.>

and I could also ask ImaginaryZ, but I walk on a thin line with him blowing up at my personality... heh
plus he doesn't like my idea of UMC, he wants me to use what's available, which is too complex for me (OpenGL's FFP is simpler than Blender26 scripting)
one of the reasons I'm writing UMC is kindof out of wanting to get back at Blender for getting more complex (you need to know python classes now),
where I want to provide something where using it is as simple as possible (you hardly need to know how to write functions).

not only that, but in 3.0 (not 3.0a) I'm working towards what I call automation,
where you pretty much don't need to define variables when reading a file.
(the only problem I'm having with that is the logic itself)

automation is basically nothing but recursed function calls:

format_func(
....data_func(options)(
........data_func()
....)
)

anyways... sorry for going OT...
I'm trying to work on UMC, but I can't do anything until I get some info...
meanwhile though I'm working on minor improvements and/or side-programs such as UMC_SIDE.

speaking of SIDE, one of those "minor improvements" I'm working on is somewhat of a dummy API structure for 3.0a which will allow SIDE to work with it's sloppy backend and integrate 3.0a's functions.
(3.0a is scrap, but I'm working on it because 3.0 will take much longer to develop, especially with the GLSL backend interface)

 

[tatatat0]

Not sure if this is relevant but I found something interesting in the start.dol starting at 003BCD40, it seems that it assigns the characters data tables there, perhaps inserting another character with it pointing to a custom .dat could be used to create another character??

along with some text starting at 003D8480 that lists the characters debug names

 

[Doq]

Last I checked that's exactly how Alternate Costumes work in 20XX, is by injecting an arbitrary filename to load instead of the vanilla costume.

 

[NewChallenger]

I think the problem here is that we can't load two versions of one character's dat. That's why you can't play PAL vs NTSC dittos. If you "added" a character right now, you couldn't play them with the character they were based from.

This has been fixed with m-ex tool, by cloning someone, you create a new slot, so you can do it

You can't change a pen1s to a vag1na without model hacking...
Texture hacks are not changing shapes.

Apparently we need to go to Thailand to find out how to add new Melee characters

I just asked @ Tcll (huge shoutouts to him btw); here's what he has to say about it:

So model data are stored in files such as PlFxNr.dat.

This is interesting, because when I make Wario, the main Nr file changes, but alt colors can still be Mario.

WarioNrDat doesn't fit into any of Mario's PlMrBuDat etc, for example.

So the main PlMrNrDat or whatever characterNr.Dat seems to be more special than the others