Texture Files for the bases?
-
unless you want to reprogram or hack the game in this aspect and re-export any cmp your mod will be using anywhere with a re-creation of the cmp exporter that’d not calculate the crc, just get used to it
to the question of why: probably the crc is taking less bytes due to that it is not a direct reference and multiple strings can have the same crc. any string would contain essentially more information then a crc of it. -
Gisteron wrote:
unless you want to reprogram or hack the game in this aspect and re-export any cmp your mod will be using anywhere with a re-creation of the cmp exporter that’d not calculate the crc, just get used to it
:-x :lol:So, how should I approach making an alternatively skinned base (without losing the original)? Can I use the clone tool that works for ships? IIRC right, that proggy then creates new names / references to texture files…
-
Gisteron wrote:
got it
that model cloner is exactly what you need. or ofc, you wait for someone to answer on which offset and how many bytes can be the crc reference, calculate the ones for your new materials and save the changes in a new file.:lol: The Clone Tool it is, then.
Thanks
-
A crc is usually much faster than referencing it by a string. Its 32 bits and the processor can get it in a single read. A string of the same size would require 4 reads (its 4 bytes).
The material hash codes are stored in the VMeshData section of the cmp. As posted above use the model cloner. You can try out Adoxa’s XML converter, iirc it can reencode the file one you have changed the numbers…
-
-
adoxa wrote:
This might help - it shows how to clone the Eagle’s wing textures, which sounds similar to what you want.Thanks, the overal process is dawning on me after looking at it. (I’d wish the ships and bases were as simply as planets and NPCs though)
Btw doesn’t the Clone Tool automate this proces? The advantage is that one need not bother with what part references to what texture file: just clone everything and replace whatever texture files one wants. The disadvantage is, that the entire texture library must be cloned, including the textures that remain looking the same.
The advantage of using the XML project seems to me that it provides more insight, and eventually (when one gets into it) more direct control. And smaller, tailor-made additions to the texture libraries. Am I right?
Anyway, I can’t delve into this stuff more atm - I lack the opportunity for the necessary isolation. So Í’m confined to the simpler modding that I can do in a living room with other people in it
-
adoxa wrote:
This might help - it shows how to clone the Eagle’s wing textures, which sounds similar to what you want.Ahh…. Clone texture… You know, I found ouut a MUCH SIMPLER way for a model to have more then 1 MAT: Just make another texture file with MS3D or any UTF editor of its kind, and save it in a separated directory! Works like a miracle, as long as you put every MAT for same model in a separated directory.
I was gonna make a thread, but then this one poped in the Latest Posts, so I posted it here.
-
To revive this thread: I’m about to tryout DVD-Man’s approach.
I want to have an alternative Space_Police01 archetype to use doors with 3 and 4 on it, rather than 1 and 2.
All these door textures are in STANUMS_256_ALT.dds:
and it still seems a bit weird to me that I have to either clone the entire archetype, and/or create a whole nes texture file, while all the necessary data is in the game files already!
Isn’t there really a simple way to just copy the space_police01 archetype and make it use other already existing texture files than the 1 and 2 doors??
NB using adoxa’s XML project, I fail to see any references to texture/material at all when I look at the space_police01 files, not in even in CRC… But that can probably be traced to my inexperience in this.
Btw, I assume that, when one uses Milkshape to create custom bases, one can use the approach that’s normally used for texturing ships. Is that correct?
-
I even failed in having DVD-Man’s approach work :evil:
I use this entry in SolarArch:
[Solar]
nickname = space_police02
ids_name = 60215
ids_info = 60216
type = STATION
DA_archetype = solar\dockable\space_police01.cmp
material_library = solar_ALT\Solar_mat_dockable03.matmaterial_library = fx\envmapbasic.mat
envmap_material = envmapbasic
LODranges = 0, 2000, 15000
mass = 10000.000000
open_sound = depot_open_sound
close_sound = depot_close_sound
docking_sphere = berth, HpDockMountA, 4.500000, Sc_open dock1
docking_sphere = berth, HpDockMountB, 4.500000, Sc_open dock2
docking_sphere = moor_medium, HpDockMountC, 5.000000
docking_sphere = moor_large, HpDockMountD, 5.000000
docking_camera = 0
solar_radius = 600
shape_name = NAV_depot
hit_pts = 999999961690316250000000000000000000.000000And of course, use a slightly modified texture in the solar_ALT\Solar_mat_dockable03.mat file, where the 1 and 2 doors are exchanged with the 3 and 4 ones:
So, DVD-man, at what point did I screw it up?
EDIT I even made a solar\dockable\space_police02.cmp archetype (and accompanying .sur). Of course, the contents of the file are exactly the same as of the space_poice01.cmp, as it is totally unclear to me what I would change – which is the essence of this entire thread.
Btw I’ve decided to stop bothering in this matter, so any feedback will be for future generations,
-
Don’t do it DvDMans way. I mean no disrespect to him, but it is sloppy modding and if you by chance put both variants of the bases in the same system, you will have texture swapping between the two. Back when I was a noob at modding, I done the same thing and had texture swapping.
Use FLModelCloner, you can have a duplicate fully working base in a matter of minutes.
-
Here’s the raw method, but you’re better off using the cloner.
What we want to do is add 0.5 to the texture’s U coordinate, thus shifting from 1 & 2 across to 3 & 4. The coordinates are part of the VMeshData, so we’re basically going to have to duplicate the entire cmp (although I guess you need to do that for a new texture, anyway). I did this from the XML, copying space_police01.cmp.xml to space_police02.cmp.xml, creating directory space_police02_cmp and copying space_police01_cmp* into it. Then I opened all the new 02 XML files in my editor and globally replaced space_police01 with space_police02. To change all the U’s, we need the VMeshRefs from the cmp to provide the vertices in the vms, but we also need the meshes in the vms to know which VMeshRef to use. So, in lod0-112.vms.xml we see materials 3, 5, 7 & 9 use STANUMS_256. In door1a’s Level0 VMeshRef, we see start mesh is 6 and it uses 2 meshes, so that’s 7 (the top part of 1). That starts at vertex 82, so back to the lod to notice the numbers start at 24 and there are 12 of them, so that means we want to add 0.5 to the U coordinates of vertices 106 to 117. Repeat for all the other door parts, and for lod1. Attached is the result (tested in MilkShape, but not ingame).
Edit: Ah yes, part names can remain the same, but the file names have to be different. Renamed door1 to door3, door2 to door4 and what the heck, changed all the timestamps, too (guess that explains why they’re there). Still didn’t test it ingame, though, but it really should work this time.
-
Forsaken wrote:
Don’t do it DvDMans way. I mean no disrespect to him, but it is sloppy modding and if you by chance put both variants of the bases in the same system, you will have texture swapping between the two. Back when I was a noob at modding, I done the same thing and had texture swapping.Use FLModelCloner, you can have a duplicate fully working base in a matter of minutes.
Thx for the kind words; I’ll proba bly do that after a few more attempts.
But that still doesn’t satisfy me completely
I know I could probably have it working that way - but I wanna find out how the game itself do it!You know, in the Space_shipping archetype, there are four docks in a row, each resembling the Space_Police01 archetype. Each of these docks uses different numbers - so in the game files there must be some directions: “use this door (texture)”. I had hoped to just copy the appropriate “door section” from Space_Shipping into my Space_Police02 - assuming there might be four pairs of doors instead of one pair - but it’s not that easy (Btw I’m doing all this using the XML Projects tools, mainly using WordPad to do all the changes)
-
adoxa wrote:
Here’s the raw method, but you’re better off using the cloner.What we want to do is add 0.5 to the texture’s U coordinate, thus shifting from 1 & 2 across to 3 & 4. The coordinates are part of the VMeshData, so we’re basically going to have to duplicate the entire cmp (although I guess you need to do that for a new texture, anyway). I did this from the XML, copying space_police01.cmp.xml to space_police02.cmp.xml, creating directory space_police02_cmp and copying space_police01_cmp* into it. Then I opened all the new 02 XML files in my editor and globally replaced space_police01 with space_police02. To change all the U’s, we need the VMeshRefs from the cmp to provide the vertices in the vms, but we also need the meshes in the vms to know which VMeshRef to use. So, in lod0-112.vms.xml we see materials 3, 5, 7 & 9 use STANUMS_256. In door1a’s Level0 VMeshRef, we see start mesh is 6 and it uses 2 meshes, so that’s 7 (the top part of 1). That starts at vertex 82, so back to the lod to notice the numbers start at 24 and there are 12 of them, so that means we want to add 0.5 to the U coordinates of vertices 106 to 117. Repeat for all the other door parts, and for lod1. Attached is the result (tested in MilkShape, but not ingame).
Right!! This indeed sounds like the methode I was after (I indeed did do the first part - making a Space_Police02) although I could never have figured out all the number stuff! That’s all abracadabra to me!
And you also included the file!!
Thanks!!!Eager to look at it, of course, and to try if I can make a Space_police03 (using yet another set of numbers) with this method, but the kids just came home so I need to socialize
![😕](https://the-starport.com/forums/assets/plugins/nodebb-plugin-emoji/emoji/android/1f615.png?v=mhmq9j4qrjg ":\")
-
Strange, Adoxa’s .cmp looks perfect in HardCMP, with the 3 and 4 on the doors. Yet, in-game, I still see the 1 and 2 doors…
Already checked my ini’s to see if I screwed up - but they seem fine.
Ofcourse, I used a renamed .sur from Space_Police01, but I don’t think the problem lies there (.SURs don’t reference textures, right?)
But -like I said, now time atm.
Thanks anyway!!! Now it’s just a matter of bug-hunting!
-
Just found that replacing all the Space_Police01 archetypes in the Star System with Space_Police02 types, eliminates the problem: I can now indeed see the 3 and 4 on the bay doors.
So, apparently there is still some sort of cross reference, leading the Space_Police02 archetype to the Space_Police01 usage of the texture. Weird…
-
adoxa wrote:
Edit: Ah yes, part names can remain the same, but the file names have to be different. Renamed door1 to door3, door2 to door4 and what the heck, changed all the timestamps, too (guess that explains why they’re there). Still didn’t test it ingame, though, but it really should work this time.
It does indeed work this time
Thanks!!Also saved your post as a tutorial.
