Texture Files for the bases?

adoxa

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.

Moonhead

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)

Moonhead

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 $:\$

Moonhead

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!

Moonhead

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

Updated the post and attachment.

Moonhead

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.

Moonhead

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?

TheDvDMan

Don’t forget who deserves a special credit here eh?
coughadoxacough

adoxa

Moonhead wrote:
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?

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)

You’d add (or is it subtract? not sure where the flipping occurs) 0.25 to the V coordinate, which is the only other one (although some models have two textures, so they have U1/V1, U2/V2).

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

Sorry, I have none, I think I just used MilkShape’s help. I’m a number cruncher, not a modeller.

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)

space_police02.cmp.xml, lines 101-121 (with the rotation option).

      <door3_a_lod1110102204010.3db><vmeshwire include="space_police02_cmp\door3_a_lod1.vwd.xml"><multilevel><level0><vmeshpart><vmeshref type="VMeshRef">60,
                      data.solar.dockable.space_police02.lod0-112.vms,
                      82,
                      36,
                      84,
                      36,
                      6,
                      2,
                        19.965044,     0.098823674,  1.0047495,
                                            -19.965048,   -19.730618,    -1.0047466,
                      -215.96416e-6,  -9.8181152,   -0.099950612,
                      22.319862</vmeshref></vmeshpart></level0></multilevel></vmeshwire></door3_a_lod1110102204010.3db>

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?

space_police02_cmp\lod0-112.vms.xml, lines 13 & 14 (you need to extract include files [and texture files, to convert it back]) and 786 to 797. Generating the strings helps, too.

              0,    23,   24, 0xcc, STADTLS2_128G
             24,    35,   12, 0xcc, STANUMS_256

              19.9639570000,    -19.7306140000,     -1.0047431000;  65.680609e-09, -42.084316e-09,  -1.0000000000;     0.5167020600,     0.8692129900
             -19.9650480000,      0.0988180560,     -1.0047466000;  65.680609e-09, -42.084316e-09,  -1.0000000000;     0.7582513100,     1.0110909000
              19.9650440000,      0.0988037140,     -1.0047439000;  65.680609e-09, -42.084316e-09,  -1.0000000000;     0.5165944700,     1.0110912000
             -19.9646340000,    -19.7305970000,     -1.0047457000;  65.680609e-09, -42.084316e-09,  -1.0000000000;     0.7579515600,     0.8689792200
              19.9639570000,    -19.7306140000,     -1.0047431000;  65.680609e-09, -42.084316e-09,  -1.0000000000;     0.5167020600,     0.8692129900
             -19.9650480000,      0.0988180560,     -1.0047466000;  65.680609e-09, -42.084316e-09,  -1.0000000000;     0.7582513100,     1.0110909000
             -19.9646360000,    -19.7305980000,      1.0043066000; -247.79504e-09,  42.082515e-09,   1.0000000000;     0.5167020600,     0.8692129900
              19.9650440000,      0.0988061430,      1.0043156000; -247.79504e-09,  42.082515e-09,   1.0000000000;     0.7582513100,     1.0110909000
             -19.9650480000,      0.0988236740,      1.0043057000; -247.79504e-09,  42.082515e-09,   1.0000000000;     0.5165944700,     1.0110912000
              19.9650440000,      0.0988061430,      1.0043156000; -247.79504e-09,  42.082515e-09,   1.0000000000;     0.7582513100,     1.0110909000
              19.9639550000,    -19.7306180000,      1.0043164000; -247.79504e-09,  42.082515e-09,   1.0000000000;     0.7579515600,     0.8689792200
             -19.9646360000,    -19.7305980000,      1.0043066000; -247.79504e-09,  42.082515e-09,   1.0000000000;     0.5167020600,     0.8692129900

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.

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

For this particular file, no, just changing the number was sufficient, since the other instances of door3/4 have different stamps (I checked to see if it was necessary, but decided to do it anyway). However, the root file name would remain the same if the stamp isn’t changed. This means if you wanted police01 & police02 to have different loadouts, whichever one got loaded first would be used for both, since the file name is the same, so it just reuses the existing one. This is what you discovered with the numbers.

Moonhead

Thanks man, I’m gonna let this sink in!

Why485

I’m digging this back up because I’m having a similar issue. I want to clone weapon turrets (and other equipment) so I can reuse them with a different texture and scale. I’ve downloaded the FL Model Cloner from Starport but no matter what settings I use, the resultant model does not appear in HardCMP.

I see nothing in HardCMP, and the hardpoints are all completely gone as well. Looking at the newly generated cmp in UTF Editor, it all looks intact and correct, but something apparently went wrong if nothing shows up in HardCMP.

Is the best way to do this the manual way?

[Edit 1]
I tried doing this the manual way with the XML Project conversion method. For whatever reason I can’t get the XML to UTF tool to work correctly. It says 4 XML examined, 0 UTF created.

[Edit 2]
Although definitely not the way I’d like to do it, I’ve found a working solution in importing the cmp into milkshape, renaming the groups and materials, then re-exporting the model.

[Edit 3]
I really, really don’t want to have to do this through Milkshape. It’s a huge pain in the ass to have to go through that whole process.

[Edit 4]
Re-exporting the models loses some information, like the wireframes and hardpoints. I already have to redo a lot of stuff when re-exporting with milkshape. Please tell me there is a working alternative…

adoxa

Why485 wrote:
I’ve downloaded the FL Model Cloner from Starport but no matter what settings I use, the resultant model does not appear in HardCMP.

The Cloner does not update the length when it writes the new File name in the Cmpnd. Attached a new version, but now the help commands don’t work (a mismatch between our compiler versions).

I tried doing this the manual way with the XML Project conversion method. For whatever reason I can’t get the XML to UTF tool to work correctly. It says 4 XML examined, 0 UTF created.

Look at the log - %temp%\XMLUTF.log.

Why485

Thanks a lot for looking into this adoxa. I haven’t had a chance to test this though because I’ve been pretty busy. I’ll let you know what happens.

But if what you say is true, doesn’t that mean there is a huge oversight or bug in the program? I would think a fixed version should be big news.