Texture Files for the bases?

I’m looking at the military_icebase1 now (using the files generated by the UTFXML generator) and I’m wondering where the references to the texture material are?

I know there are two material_library lines in SolarArch.ini, but these are general references… I’d expected to find some texture filenames or references in the .cmp files…

Can someone point me in the right direction?

(What I want to do, is create an alternative of the rock/ice bases, with a normal looking door instead of the one with the skull. So I’d hoped for a line referencing door03.dds in asteroid_dock.mat)

<sarcasm>Great, CRC!!!</sarcasm>

Why did Digital Anvil / Microsoft use this CRC anyway? Was it some form of content protection? Or does it make the game faster than using readable stuff instead?

And why not everywhere. It’s not used in e.g. planet files, NPC skins etc.

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

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

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.000000

And 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,

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

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!