Stage Hacking: NEW Research + Documentation

[Ohsm]

I currently work on a balanced version of DL64 with lower blastlines and lower platforms to resemble battlefield a bit more.

Here are my notes so far:

GrOp.dat (Dreamland 64)

12660 - collision begins

c2 75 92 54 41 f1 23 05 c1 fd cd 9f 41 f1 23 05 <- left platform
41 fd a0 f9 41 f1 f0 a4 42 7c 4c 4a 41 f1 f0 a4 <- right platform
c1 98 25 12 42 4d b3 82 41 98 23 05 42 4d b3 82 <- top platform

12770 - collision ends

10b08 - 10b90 -> platform position data

13300 - 13327 magnifier data

13328 somewhere around here the timer data begins, not sure how long the string is.
I just put "7F FF FF FF" in the next couple of rows to disable the windblow and the dedede/kirby spawn in the background

135ac - 1367f -> camera boundaries + blastzones
note: the data string doesn't begin with the usual "3F 80 00 00 3F 80 00 00 3F 80 00 00"
instead it uses "43 DB EC 87 43 DB EC 87 43 DB EC 87"

Some position date:

021e8 -> treetop
02228 -> little tree 1
02268 -> little tree 2
022a8 -> Whispy
024a8 - 025ff -> 6 little stars in the treetop
Order: yellow, red, red, purple, purple, yellow
03428 -> Whispy's face
random note: removing the face causes some graphical glitching, but only on console (Dios Mios Lite), dolphin works fine for some reason. I recommend just moving the face oob instead of fully removing it if you don't like it.
035e8 -> busch 1
03628 -> busch 2
10c48 -> bigger pond
10c88 -> smaller pond

 

[zankyou]

By the way, for those of you who've seen my Mushroom Kingdom tutorial, I did a dump of the models for Kirby 64 in Blender:

https://www.mediafire.com/?vkbv7sv0v6yrfy7

When you're done working with the models, you need to select ONE of the two that are in the scene and go export > obj.
When in the export window, be sure to have "selection only" and "keep vert order" selected.

Then, after exporting go to the .obj file, open it in notepad, and remove all rows of text that don't begin with data in the format of:

v 1.4390 3221.34 392.324234

You can then use my terrible program to convert them back into Hex:

https://www.mediafire.com/?z1a89nxgvofowhd

Finally, open the file the program spits out and copy all the Hex text. In your .dat, paste it in one of the following:

If you edited the part of the model which has the tree in it (the back half of the stage) paste it here: 0000480
If you edited the part of the model which was twice as large (the front half of the stage) paste it here: 0000E920

How do I get into model hacking. I barely understand how meshes work. Can your program turn any mesh into an .obj. If so how would I go about that. I think tcll's program allows you to import and export meshes as well but doesnt touch uvs or display list.

 

[Anutim]

By the way, for those of you who've seen my Mushroom Kingdom tutorial, I did a dump of the models for Kirby 64 in Blender:

https://www.mediafire.com/?vkbv7sv0v6yrfy7

When you're done working with the models, you need to select ONE of the two that are in the scene and go export > obj.
When in the export window, be sure to have "selection only" and "keep vert order" selected.

Then, after exporting go to the .obj file, open it in notepad, and remove all rows of text that don't begin with data in the format of:

v 1.4390 3221.34 392.324234

You can then use my terrible program to convert them back into Hex:

https://www.mediafire.com/?z1a89nxgvofowhd

Finally, open the file the program spits out and copy all the Hex text. In your .dat, paste it in one of the following:

If you edited the part of the model which has the tree in it (the back half of the stage) paste it here: 0000480
If you edited the part of the model which was twice as large (the front half of the stage) paste it here: 0000E920

Oh my god, this is amazing! Would this also work to edit other models? I'm guessing you're only able to change positions of vertices currently so no skin modifier would get messed up because of this, right?

How do I get into model hacking. I barely understand how meshes work. Can your program turn any mesh into an .obj. If so how would I go about that. I think tcll's program allows you to import and export meshes as well but doesnt touch uvs or display list.

A mesh is built of several tiny points called vertices, together they draw lines between one another which forms polygons who shape the model.

Obj is a file format for 3D models, so yes you can. But as far as I know you can't save skin data/bones in it. (Bones are "invisible" parts that you build up inside the model so you can animate it and the skin are "weights" assigned to different vertices to follow certain bones.)

Since I've explained this I might as well explains UVWs, they basically use the polygons that the combined vertices draw up to create a 2D map that you can export as an image to draw textures on.

I hope I helped out a bit.

 

[zankyou]

Oh my god, this is amazing! Would this also work to edit other models? I'm guessing you're only able to change positions of vertices currently so no skin modifier would get messed up because of this, right?


A mesh is built of several tiny points called vertices, together they draw lines between one another which forms polygons who shape the model.

Obj is a file format for 3D models, so yes you can. But as far as I know you can't save skin data/bones in it. (Bones are "invisible" parts that you build up inside the model so you can animate it and the skin are "weights" assigned to different vertices to follow certain bones.)

Since I've explained this I might as well explains UVWs, they basically use the polygons that the combined vertices draw up to create a 2D map that you can export as an image to draw textures on.

I hope I helped out a bit.

Well I know that its possible to export them, it was more of whether this program can do it. And the lack of understand is more so about the display list which tells the game where to place the image on the mesh.

 

[Milun]

Zankyou, I'm going to have to disappoint you there. All my program does is converts a .txt of Hex data into vertices (aka, "dots") connecting those dots is what Tcll looked into, but I myself have only dabbled in that to get inconsistent results (I could export Yoshi's trophy perfectly, but stuff like Mushroom Kingdom 1 glitches horribly).
Bottom line, yeah, the program can flawlessly convert... the vertices to .obj format. Connecting the dots is something that must be done manually (and I did that myself for Kirby 64... took a while too).

 

[zankyou]

Zankyou, I'm going to have to disappoint you there. All my program does is converts a .txt of Hex data into vertices (aka, "dots") connecting those dots is what Tcll looked into, but I myself have only dabbled in that to get inconsistent results (I could export Yoshi's trophy perfectly, but stuff like Mushroom Kingdom 1 glitches horribly).
Bottom line, yeah, the program can flawlessly convert... the vertices to .obj format. Connecting the dots is something that must be done manually (and I did that myself for Kirby 64... took a while too).

Even that sounds really powerful. I imagine you get a vertex cloud. Could you move the vertices around keeping the same connections. Being able to at least edit the shapes of meshes would give me a lot of freedom to hack stages.

 

[Milun]

Yeah you can move them and re import them. It's how I've been doing things so far. I'd still recommend trying to get in contact with Tcll though. He made waaaaaay more progress than I did on this subject.

 

[zankyou]

Yeah you can move them and re import them. It's how I've been doing things so far. I'd still recommend trying to get in contact with Tcll though. He made waaaaaay more progress than I did on this subject.

He has a pretty legit character model exporter going. But I dont think it works for stages. Ill give moving them a try though. Im pretty sure you can import meshes from other stages so that would open up so many options.

 

[Achilles1515]

I currently work on a balanced version of DL64 with lower blastlines and lower platforms to resemble battlefield a bit more.

Here are my notes so far:

0x12660 - collision begins

c2 75 92 54 41 f1 23 05 c1 fd cd 9f 41 f1 23 05 <- left platform
41 fd a0 f9 41 f1 f0 a4 42 7c 4c 4a 41 f1 f0 a4 <- right platform
c1 98 25 12 42 4d b3 82 41 98 23 05 42 4d b3 82 <- top platform

0x12770 - collision ends

0x10b08 - 0x10b90 -> platform position data

0x13300 - 0x13327 magnifier data

0x13328 somewhere around here the timer data begins, not sure how long the string is.
I just put "7F FF FF FF" in the next couple of rows to disable the windblow and the dedede/kirby spawn in the background

0x135ac - 0x1367f -> camera boundaries + blastzones
note: the data string doesn't begin with the usual "3F 80 00 00 3F 80 00 00 3F 80 00 00"
instead it uses "43 DB EC 87 43 DB EC 87 43 DB EC 87"

Some position date:

0x021e8 -> treetop
0x02228 -> little tree 1
0x02268 -> little tree 2
0x022a8 -> Whispy
0x024a8 - 0x025ff -> 6 little stars in the treetop
Order: yellow, red, red, purple, purple, yellow
0x 3428 -> Whispy's face
random note: removing the face causes some graphical glitching, but only on console (Dios Mios Lite), dolphin works fine for some reason. I recommend just moving the face oob instead of fully removing it if you don't like it.
0x035e8 -> busch 1
0x03628 -> busch 2
0x10c48 -> bigger pond
0x10c88 -> smaller pond

Dude! Awesome notes. Great to see others getting involved. I might use these.

 

[Ohsm]

Anyone know how to change the size of stage objects (not the collision data)?
the left platform of DL64 is a little bit shorter than the right one, that really bugs me.

 

[Achilles1515]

Anyone know how to change the size of stage objects (not the collision data)?
the left platform of DL64 is a little bit shorter than the right one, that really bugs me.

That's what the "3f800000 3f800000 3f800000" is for each object before the x,y,z location. (Most have these values...some are already modified)

Size multipliers in the x,y,and z direction in that order.

And before those, there are, usually, three sets of "00000000". These are the rotation of the object around the x,y, and z axes.

 

[Ohsm]

That's what the "3f800000 3f800000 3f800000" is for each object before the x,y,z location. (Most have these values...some are already modified)

Size multipliers in the x,y,and z direction in that order.

And before those, there are, usually, three sets of "00000000". These are the rotation of the object around the x,y, and z axes.

I feel so stupid right now :D
Thank you very much!

Edit:

Just finished my DL64 hack:

I wanted to create a balanced and simple stage without any jank cause our 6 competitive stages all have some kind of (minor) annoyance (battlefield ledges, Whispy's wind, rendall etc).

So I tried this as my first stage hack

Changes from vanilla DL:

- Changed the blastzones to the size of battlefield (around 1-2 % off)
- Removed the windblow and the background dedede/kirby spawn
- Removed the background trees
- Removed the 2 stupid looking ponds in the fourground
- Fixed the platforms to be more symethrical, the vanilla platforms all had slightly different sizes (position and collision data)

Shoutout to Milun for the awesome bottom-texture, the stage now looks like a piece of nature ripped from the earth and thrown in the sky, or something like that.

http://www.mediafire.com/download/ond88d6udo0fkfb/GrOp.dat


Zankyou how exactly did you upscale the background and put it back in the file?
I read that you just pasted the data on the end of the file but how does the game use the offset at the end instead of the regual on?
I'm still looking for a better background for the hack and your upscaling would help a ton.

 

[Milun]

At offset 9FBC0 is the value which refers to the offset of the background (I think).

It'll say: 00 01 AA A0
Which is 20 less than the real offset (when I say 20, I mean HEX 20. Aka D0 becomes B0).

I tried setting the offset to the new texture - 20 and it didn't work for me though (the game just crashed when I loaded K64). I'm assuming either I did something wrong or I made the texture too large (I doubled its size).

 

[Achilles1515]

At offset 9FBC0 is the value which refers to the offset of the background (I think).

It'll say: 00 01 AA A0
Which is 20 less than the real offset (when I say 20, I mean HEX 20. Aka D0 becomes B0).

I tried setting the offset to the new texture - 20 and it didn't work for me though (the game just crashed when I loaded K64). I'm assuming either I did something wrong or I made the texture too large (I doubled its size).

Did you change the file size value to the new larger size? The very first line in the .dat file.

 

[zankyou]

Did you change the file size value to the new larger size? The very first line in the .dat file.

Completely forgot to include that part. You have to change the filesize in the header as well.
Theres some real potential with some of the stages for multiple variations. With Shamrock's method could you add like 3 versions of a stage.

 

[Milun]

Hm... ok well it doesn't crash anymore.

I noticed something though. First off, the offset I gave for the texture was wrong. There was actually one other occurrence of 00 01 AA A0 which, when changed, gave results... unfortunately:

(I don't know why the snapshot is in those weird colours, but you get the idea).
It also seems to be showing the old, low res texture on half of the stripes.

Did I just make the texture too large or something? Also, wouldn't it want the texture dimensions to be specified (I have no idea how these newfangled texture doodads work).

Also worth noting: there's a large list of offsets at the end of the file (which include texture offsets). However, changing them seems to have no visible impact?

EDIT: There's also some use to be gained from finding the references to the texture offsets. It's an easy way to narrow down where certain objects are located. For instance, thanks to you guys, I found where the model for the background and the bushes is declared!

 

[zankyou]

Thats my current method. Taking steelia image offsets and tracing them to objects. Also every pointer in the file is listed in the relocation table. Its how the game knows whats a pointer and whats not. Rootnodes are pointers to things. Changing the relocation table values allows you to skip things. But if you dont know what youre doing you'll break the game. I believe the texture offset is immediately the image header. You should see things like 3f800000 and 00000001 00000001 0101 and stuff like that. Its documented somehere. If I were by my computer Id tell you where. Change the 00000001 to 00000000. Also add like 4 lines of 00's after the string table. That should fix your background problem.
Currently running through my ROUGH notes. Ill have some type of documentation for what I know soon.

I also find it extremely helpful to use the maphead. That way I can deactivate things like targets and what not. And also things I normally cant find like reflections although if the maphead is messy I just search for 3f800000. Took me forever to think of that.

Oh and Milun, I don't know if youve read Yak's excel sheet but its really well documented and explains somethings you might not know.

 

[Milun]

................. O_O?

....................................................................look mommie I did a thing:

Faces are annoying. And unfortunately, they tend to be stored inconsistently.

 

[zankyou]

................. O_O?

....................................................................look mommie I did a thing:

Faces are annoying. And unfortunately, they tend to be stored inconsistently.

What... did you do and how can I do it.
Have you read about what revel and tcll documented on display list. You may be able to decipher it a lot faster than I can.

 

[Milun]

I haven't actually. Could you link me to it please (I'll read through it a bit later)?

As for what I did, I just copied the Doshin trophies vertice data and pasted it over Goomba's in Trophy Tussle. The mess is a result of the Goomba model's faces connecting the vertices in the order that the Goomba uses.

 

[zankyou]

Thats how I import meshes. But you have to copy the displaylist as well which are different sizes and creates a few problems. Pretty sure I have a working method but I havent tested it more.

 

[Milun]

http://www.emutalk.net/threads/50312-Melee-Arcive-Viewer-(MAV)-in-development-project/page15

^ Display list link. IIIInteresting... I'll have to give the Goomba another crack later (though, there seem to be issues caused by the animating background, causing the face values to need incrementing I think.

 

[zankyou]

http://www.emutalk.net/threads/50312-Melee-Arcive-Viewer-(MAV)-in-development-project/page15

^ Display list link. IIIInteresting... I'll have to give the Goomba another crack later (though, there seem to be issues caused by the animating background, causing the face values to need incrementing I think.

Display list tell the game how to draw vertices. So far all Ive been doing is breaking things as a quick way to alter meshes with no idea what im doing. I planned on understanding it because I believe that between that and borrowing values in the relocation table we'd virtually be able to create any stage we want from scratch barring animations. I chose to look into gecko codes temporarily but if someone else is willing to further decipher stages with me ill put that off.

 

[Milun]

Yeah this stuff is a bit too complex for me too I'll be honest. I think I might dabble with creating a pyramid from scratch at the end of the Mushroom Kingdom stage and then just work from there.

 

[zankyou]

Yeah this stuff is a bit too complex for me too I'll be honest. I think I might dabble with creating a pyramid from scratch at the end of the Mushroom Kingdom stage and then just work from there.

I feel the same way. Would take forever to understand with my current knowledge. Maybe if we beg TCLL he'll help us out. Its probably the fastest way since he could probably do it in no time flat.

 

[Milun]

Haha, yeah. I have his email, I'll give him a call.

 

[zankyou]

I was planning on making some crappy program in python to edit stages more effectively like shifting offsets around to save space. using revels template I found. It literally color codes pointers and nodes. Its amazing. If we could use tcll's model editor is some way we'd be one step closer to a melee box.

 

[Tcll]

holy heck Milun =O
I thought you'd kicked the bucket in our last email

dude, this is some freakin amazing work =D

I'll definately get in on this and hopefully improve my article =3
http://wiki.tockdom.com/wiki/HAL_DAT_(File_Format)

anyone here, please help me improve this as well

EDIT:
jsyk, I'm reworking UMC's GUI, but for some progress on models, I've gotten a near flawless pathfinder up and running

any game that uses this format can be tested with the script

excuse the off topic

 

[zankyou]

holy heck Milun =O
I thought you'd kicked the bucket in our last email

dude, this is some freakin amazing work =D

I'll definately get in on this and hopefully improve my article =3
http://wiki.tockdom.com/wiki/HAL_DAT_(File_Format)

anyone here, please help me improve this as well

Im starting to join on Achilles hype train. You guys are like legends in the hacking community. Ive basically memorized that page. Thanks for creating it. Really the only thing your'e missing that's documented somewhere are a few flags from the dat thread.

 

[Milun]

holy heck Milun =O
I thought you'd kicked the bucket in our last email

Nah, I just overdid it. Don't get too excited, I'm kind of pseudo back to the scene at this point due to other responsibilities. I just wanna make a few stages here and there for a friend while sharing whatever knowledge I have and helping from the sidelines.

(i.e. please don't get too excited. My methods and knowledge is 2 years behind. All this file format stuff is flying over my head).

 

[Tcll]

Ni.e. please don't get too excited

crap man, I miss working with ya and can help wherever you need

that goes for anyone else too
feel free to ask, and I'll offer whatever knowledge I have

heck, I'm still working to get the NBT vector data actually working in a future release of UMC 3.0a


yea, 3.0a may be trash, but that doesn't mean I can't get the most out of it.
(not joking, I can't wait to scrap 3.0a to actually continue working on the muuuch improved 3.0)
^ there's quite alot 3.0a just can't support w/o alot of rework, such as GLSL shaders (where 3.0 is built for them)

the problem with 3.0 and why I'm working on 3.0a...
don't expect to see 3.0 any time soon... newer systems take quite alot of knowledge and pain to actually make them work properly.
and for something like UMC, heck, I can't even begin to describe just how overwhelmed I am... heh

but I can note I'm working on 3.0a to give everyone something to start with
any scripts that work with 3.0a will work with the 3.0 update when it's available
I can't say the same for libraries however... you'll need to port those if you work on any.

sorry milun... don't mean to hijack your thread
I hope to get UMC to support stages, but I need help with what you know, when I can catch up to working on the HAL_DAT script again... heh

one major problem, even for the pathfinder is root-node image data, found in melee stages.
right now I don't have any way of testing those structures...

 

[Tcll]

................. O_O?

....................................................................look mommie I did a thing:

Faces are annoying. And unfortunately, they tend to be stored inconsistently.

hey milun, rmbr what I stated about GCN/Wii facepoint data??
the mesh attribute structures will tell you how the facepoints in the display list aree composed:
http://wiki.tockdom.com/wiki/HAL_DAT_(File_Format)

I'll admit, I really need to work on the display list data structures

it's really not hard to figure out once you understand the CP register

here's my script for a little more info (actively updated/synced)
https://copy.com/GhS6PAbuBH7MedUI

and yes, the GCN is the same as the Wii.
the Wii is a copy of the GCN with more RAM and a few extra instructions, as well as a slightly faster clock.

EDIT:

Im starting to join on Achilles hype train. You guys are like legends in the hacking community. Ive basically memorized that page. Thanks for creating it. Really the only thing your'e missing that's documented somewhere are a few flags from the dat thread.

no problem, always glad to lend knowledge! =3

yea, there's alot I need to restate better and clarify on... heh
I've also updated that page btw with my current pathfinder code for the HAL_DAT script
(you know it works because you can see the VcStarSlick.dat import from Kirby Air-Ride)
feel free to copy from that, just be sure mention that page in that part of your code. ;D


EDIT2:
just a little fun...
in UMC 3.0, here's something you'll be able to do:
line 105 in my HAL_DAT script:

bind,invbind = matrices[bones.index(MO+32)]

for a more direct approach, you can define a bone struct and call:
b = deref( bone, MO+32 )

b.bind
b.invbind

that's right, 3.0 already has a working pointer system ^_^
(this actually CAN'T be ported to 3.0a unfortunately)

 

[Milun]

Hey by all means, hijack away man! I don't know how I got this reputation but what you've done is actually amazing (I struggle to understand all this terminology).

I'll just post tidbits which I think are worth noting whenever I find them. That's all I really wanted to do anyway. Leave the hacks to the professionals (which for the last time, I am not! I just brute force trial and error based on patterns I recognize).

 

[Tcll]

haha, you think I'm a pro. XD
dude, I havn't done much but fill in small blanks when it comes to hacking... heh
what I've posted there was basically small fixes to Revel8n's info, he gets the credit for that.
but what I've learned was through the help of Kryal and BlackJax and looking at the src for BrawlBox.
I've also gotten help understanding OpenGL from Ian Mallet aka Geometrian, ImaginaryZ (the legendary FSYS hacker), and various sources.
as far as I'm concerned, I'm still quite a noob when it comes to alot of this stuff... heh

Revel8n understands far more of this than I do
but heck, that ain't stopping me from doing something cool.

I'm not gonna push you though as in your last email, I understand what you're going through.
if you need a break, that's all ultimately your decision.

You understand far more than the average person, and as such, you should be proud to be an honored member of the smash community.
You deserve what you've rightfully earned.


just take a step up when you're ready dude, I'll help you understand what you need


EDIT:
wanna know what's even worse...
those "experts" I mentioned, Ian and IZ, they have no faith in UMC and think it's rather a disgrace to 3D programming and is too complex to pull off.
(one reason being my focus is for the noobs, and IZ hates that... he hates that I'm using a single level function system with an automated interruptable state engine, and would rather I use classes for the frontend scripting system)
Ian at least is rather just uninterested, but doesn't hate the project, though he still thinks it's dumb to even try, especially for being written in python.

what's even funnier is even they don't consider themselves to be experts in OpenGL... heh

so yea, I'm rather pushing through quite hard on this project with no help.
(BrawlNub just got with me just a few minutes ago and is helping me work on an updates system for 3.0a)
^ the idea will be forwarded to 3.0, but 3.0a won't be able to directly update to 3.0.


EDIT2:
also, I never said thanks...

> but what you've done is actually amazing
thanks, because yea, it wasn't easy to pull off.

 

[zankyou]

@ Tcll heres a question. How feasible do you think it would be to change uvs/faces. Or basically editing the display list.

 

[Tcll]

shouldn't be much different from vertex editing an MDL0 in BrawlBox...

all we really have to make up for is the resize, which is something UMC really needs pointer support for in order to export a HAL_DAT model.
(now that I've built the pathfinder, I roughly understand how to export)

the resize would render all pointers above the resized data as invalid, and would have to be ajusted as necessary.
(the relocation table can help here)
after that, for the sake of Melee, it's probably best to keep the number of pointers the same...
of course though this is something that has yet to be played with, so I'm not sure if adding weights won't break the game... heh

EDIT:
just to show a little something:

the blue structures are weights
the green structures are pointers (marked from the relocation table)
the pink structure is a display list
the yellow structures are the attributes for reading the display list

EDIT2:
also to note, the current HAL_DAT template for HexEdit uses an outdated method of entry into the file...
I have yet to port the pathfinder from my UMC-script... heh

you can get the actively updated template here:
https://copy.com/AjtjUrwVlrKPwveF

again though, expect it to break with most files... heh
(particularly anything other than Pl or Ty)

EDIT3:
btw, you can get HexEdit from the HAL_DAT format page ( http://wiki.tockdom.com/wiki/HAL_DAT_(File_Format) ), but you can't get my crack for it...
here's the crack/patch (please don't redistribute or spread the link): http://www.4shared.com/file/gmsRpsxGce/HexEditPro.html?
this crack/patch is only to help the community for those who can't afford it.
(if you can afford HexEdit, please pay for the program instead of using my crack)

I've posted the link publicly yes... I want it to spread as I spread it because I try to encourage downloaders to pay for the program.
(Andrew needs help, and alot of it... his site http://hexeditpro.com went down a while back.)

 

[zankyou]

shouldn't be much different from vertex editing an MDL0 in BrawlBox...

all we really have to make up for is the resize, which is something UMC really needs pointer support for in order to export a HAL_DAT model.
(now that I've built the pathfinder, I roughly understand how to export)

the resize would render all pointers above the resized data as invalid, and would have to be ajusted as necessary.
(the relocation table can help here)
after that, for the sake of Melee, it's probably best to keep the number of pointers the same...
of course though this is something that has yet to be played with, so I'm not sure if adding weights won't break the game... heh

Changing the number of pointers in the relocation table breaks the game in my experience. However as far as resizing the file, I realized that you can add stuff to the end of the file. Its how I test it before inserting it in the middle and adjusting the pointers. The filesize doesnt have to remain the same, just the relocation table/pointer table and probably the rootnode table. I havent tested this yet with models because I have no idea what Im doing. All Ive done is import meshes from other files because I could just copy the display list and mesh over. I just found out both you and milun have a program for editing meshes.
Edit: Now that I understand the basic layouts of dat files, looking at your program now, it has everything there.

 

[Tcll]

actually, UMC can't edit models... heh
it can only import and export currently...

the final project for UMC is an editor, which renames UMC to UGE (take note of the prefix in most of UMC 3.0's functions)
by then it should be able to actually edit meshes

but yea, my assumptions were right, you'd have to edit the game logic and any 3rd-party files that link the file to be able to change the amount of pointers in the file.

 

[zankyou]

actually, UMC can't edit models... heh
it can only import and export currently...

the final project for UMC is an editor, which renames UMC to UGE (take note of the prefix in most of UMC 3.0's functions)
by then it should be able to actually edit meshes

but yea, my assumptions were right, you'd have to edit the game logic and any 3rd-party files that link the file to be able to change the amount of pointers in the file.

I was referring http://www.emutalk.net/threads/5031...opment-project?p=436127&viewfull=1#post436127

 

[Tcll]

oh hello, there's a resource I'd forgotten about... haha

yea, that stuff needs improvment