Interface Editing
-
well, its not because of the mesh data. actually, the mesh data is just the same as in regular cmp’s. but you need to apply a different file structure for the milkshape importer to read them. and that structure changes are exactly what cheeseontoast is working on.
-
yes, it is. though, no, it is no new importer. to freelancer, it makes no difference, whether a cmp (which is, as we know a UTF file), has a structure typical for spaceships and stations, or a structure typical for interface items. but the importer only supports ship/station-like cmp structures. so, CoT does rebuild the interface cmp’s to have the structure of shiplike cmp’s but containing the mesh data from the original interface cmp’s. just open up one of each, a station and a button with the UTF editor and you see the difference in the trees.
-
-
Cheesy, are you individually importing each 3db into a merged file with the whole VmeshLibrary, or chopping up the interface.generic.vms and merging that into smaller files?
Either way it’s monumental task O.O
Kudos again for having the fortitude.The one thing I do notice though, is the lack of a Cmpnd node anywhere, which is why I speculated it is a 3DB rather than CMP.
Not that there’s much difference aside from that.
I do know the Indexing order can affect a model’s appearance; whether it is higher or lower -unfortunately it’s been a while so I forget specifics.
But perhaps interface’s Cmpnd is replaced with ini entries? I don’t know how FL represents these objects internally so, could be.Just a quick visualization to show what we’re talking about here:
Edit: Ah I see the CMPs you’re referring to, like inv_biginforcard.cmp
-
Mini_Me wrote:
Cheesy, are you individually importing each 3db into a merged file with the whole VmeshLibrary, or chopping up the interface.generic.vms and merging that into smaller files?
Either way it’s monumental task O.O
Kudos again for having the fortitude.Well, the interface is made up primarily of the cmp files… every 3db file is, essentially, just a square with a texture on it. And im taking every CMP file, and extracting the data needed from the interface.generic.vms file, 99% of the cmp’s mesh data is in the interface.generic-102.vms with the occasional cmp file looking in the interface.generic-2.vms.
As for the monumental task… Yeah lol
I’m not going to lie, doing it was pretty long, I think I had 4 maybe 6, 7- 9 hour sessions on doing it, because I cant code to make something do it automatically but as it stands, I have done every CMP file now, it is now a case of going through them to see if they import into milkshape, the strange thing is, you dont even need to do an import to make new shapes for the HUD, I figured it out after a while, all you need to do is make sure the scale is the correct size, the mesh ordering goes from background to foreground with anything using material animations to the bottom of the list.With the Cmpnd node, from what ive seen the hud doesnt need it… I would have to go back and test but, when I first started doing it, the first few conversions I did were just implanting the VMeshData into a VMeshLibrary node, essentially… Nothing else was added, only exsisting stuff was modified.
As I said earlier, I will be releasing the CMP’s and the XML’s so you can go through them and see for yourselves what was done
-
From my own work interface_generic.vms only contains mesh data, nothing else. All of the textures are store in other files. It is the most simplest mesh format you will find in FL, nothing else in there uses something that simple IIRC…
-
front_button.cmp theres 3 instances of it in the interface folders. CHANGE THEM ALL. Or don’t…
