Interface Editing
-
The goal here isn’t to do just a reskin. This is merely the first step.
-
yes, imo, too, it is very, very important, to make it with sense. the FL interface is designed for the purpose it serves. there is nothing too much but still enough to look of everything to look good. a balanced interface sometimes really influences the gameplay and attracts more people than it might detract.
-
Mini_Me wrote:
Just curious, did you actually slog through all those half-3dbs / half-cmps and piece them together by hand? If so, my hat’s off to you, that was way more work than I was prepared to endure.the 3db’s are pretty much only used for displaying the textures for buttons, they pretty much only reference a single square mesh.
The CMP’s are the core of the interface, and yeah… I lack the ability to do a mass convert of the cmp’s to make them editable in milkshape lol, So yeah… I think it took almost two days to convert over a period of a week
and im not even done converting them all lol, started working on what Ive already converted. -
Gisteron wrote:
would you offer us editable versions of the vanilla interface cmp’s one day? would be another step on our way to ensure the game’s survival for some more years.Of course
Thats what I plan to do -
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…
