Texture Files for the bases?

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!

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.

Like Pink Floyd’s Eugene, I’m gonna cut this into little pieces.
space_pilot01

adoxa wrote:

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.

Sofar, I get most of this. Two Qs:

1) I assume your 0.5 means “half of the texture”. So, if we’d wanted to use the new .cmp to use the <2> and <3> textures, we’d be taking 0.25. Is this correct?

2) You mention the U coordinate, which apparently stands for horizontal. What other coordinate(s) is/are there? If I would wanna make another .cmp that should use door <5> and <6>, I’d move the focus vertically instead of horizontally (the 5 and 6 are below the 1 and 2)

(NB No need to spell this out - you can also just give a URL which explains this basical stuff - if there is any)

Now it is getting more abstract. I can follow the overall proces, but I’m at a loss for most of the details in the following:

adoxa wrote:

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

3) Makes sense, sort of, but in what file is this?? Might make more sense when I can look at it, but can’t seem to find it (probably also be because I’m lost within all these numbers)

adoxa wrote:

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.

4) And I’m even more at a loss where all this is taking place! Could you please elaborate a bit on this? You’re a very fast thinker, and to you all of this is an open book - but for me it’s more like a telephone book in a faraway country where I don’t know anyone!

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.

This makes sense. Except maybe for the timestamps - do these actually matter?