• Welcome to SC4 Devotion Forum Archives.

Conflicting Props Issue

Started by thingfishs, May 30, 2017, 11:07:06 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

thingfishs

Hi,
I wasn't sure quite where this should go...
I've gotten back into batting after a 6 or so year hiatus, and a problem has started to occur which I would like to better understand so that I can completely avoid it's recurrence. Plus I especially don't want this issue to spread beyond my HD with something I release.

What's happening is sometimes, having created a new prop model & desc file (using the latest Bat4Max and SC4PIM), and brought it into the LE, it is appearing as another model I had made a couple of weeks earlier:

 

You can see in the photo that a small section of fence is showing up as a bin I had made earlier - though on the right hand side you can see the LOD shape of the fence...

Why is this happening? I understand there's a conflicting number issue, but WHY??
I know I can change the numbers and get them working but surely there's an easier way...? (I'm making a lot of props and to have to deal with this on a regular basis is highly undesirable)

Thanks for looking  :thumbsup:

Simcoug

I know IDS had a similar problem with exporting models, and I believe we came to the conclusion that it had something to do with his computer clock.  I think TGI numbers are randomly generate based on the internal computer clock, so if there is an issue with your computer clock it may keep generating the same numbers.   ()what()

thingfishs

Thanks (again) simcoug  :thumbsup:
My experiences exactly replicate those of IDS2's. It's such a relief to have a bit of understanding of what's going on.  :bnn:

I quote from that link:

Will anything bad happen/is it possible to manually change part (specifically the third string, immediately before the .SC4Model suffix) of a building ID (ex. buildingname-0x5ad0e817_0x9edef4d8_0x10000.SC4Model) using the reader?

To be honest I'm a bit fuzzy about how the IDs are even generated. How is it that different content creators are able to avoid having conflicting IDs between their models? Is there a "fingerprint" in that ID sequence that is unique to my copy of the program or something?


I second these questions. Basically, if this is what's going on, how do I best deal with it.? (I haven't got an alternative computer to render from).

mgb204

Honestly the computer clock issue is a very unlikely hypothesis. Mainly because when your computer is on, the time changes, even if there is some issue like a failing battery causing the clock to reset when it's off. Windows also updates your system time with the internet if you are connected. Given that this is done to the second, there is a far more likely cause...

When you make a LOD or a model in SC4BAT, the ID is linked to the file. Reopen the file and re-export and the ID remains the same, because, you probably don't want the IDs constantly changing. So if you are re-using a file every time you make something, the IDs will remain the same.

If you are sure you are using new files every time, the first question I have to ask is if you are using just SC4 BAT or are you working with 3DS Max or another modelling application at all? What scripts (if any) are you using that might modify the default setup? Are you using Windows 10?, if so, where did you install gMax?

thingfishs

Thanks mgb :thumbsup:

Quote from: mgb204 on May 30, 2017, 12:00:53 PM
When you make a LOD or a model in SC4BAT, the ID is linked to the file. Reopen the file and re-export and the ID remains the same, because, you probably don't want the IDs constantly changing. So if you are re-using a file every time you make something, the IDs will remain the same.

I'm not sure I follow you here. I've just exported two identical, other than name, copies of the same model and the filenames are:



It seems it's the sequentially increasing third number that causes the issue. I sometimes use a scene as a starting off point, for example I've made a sand model with some 11,000 polygons and want a few different shades. My process then is to apply a new texture to it, save with a new name, and export. You're not suggesting that I remodel it every time? 

Quote from: mgb204 on May 30, 2017, 12:00:53 PM
If you are sure you are using new files every time, the first question I have to ask is if you are using just SC4 BAT or are you working with 3DS Max or another modelling application at all? What scripts (if any) are you using that might modify the default setup? Are you using Windows 10?, if so, where did you install gMax?

To answer your questions:

1: Bat4Max Version 5 with 3DS Max.
2: The only script I've used was the one that came with the Bat4Max installer.
3: Windows 8.
4: The gmax folder is in my C: drive root folder

Simmer2

Here is the solution. (Attached at the bottom of this post)

Simply copy/paste it over the old script found in \gmax\gamepacks\BAT\scripts.

Cheers

Nick

________________________________________________________________________________

thingfishs

#6
Brilliant, thanks a lot Nick :thumbsup: :thumbsup: It's good to know you're not alone...

As a test I ran two more exports of the same prop:



and can see that now the instance number is staying the same despite different exports (as mgb said it should). Two questions though:

1: If I'm wanting to make different colour variations of the same model, how do I do it now (so that I have a new IID)?

2: Doesn't my instance number there (0x30000), look a little generic? (you know, its not 0x4571efc7 or something more random? That smells suss to me)

3: Actually three: I noticed the second number (group?) is now changing whereas before it looks like it was staying the same. What could all of this mean for all the props that I've already created? Will I have to redo them?  :'(

Thanks to everyone for prompt support with this.  :)

Ryan

Simmer2

Quote from: thingfishs on May 30, 2017, 01:34:21 PM
Brilliant, thanks a lot Nick :thumbsup: :thumbsup: It's good to know you're not alone...

As a test I ran two more exports of the same prop:



and can see that now the instance number is staying the same despite different exports (as mgb said it should). Two questions though:

1: If I'm wanting to make different colour variations of the same model, how do I do it now (so that I have a new IID)?

2: Doesn't my instance number there (0x30000), look a little generic? (you know, its not 0x4571efc7 or something more random? That smells suss to me)

3: Actually three: I noticed the second number (group?) is now changing whereas before it looks like it was staying the same. What could all of this mean for all the props that I've already created? Will I have to redo them?  :'(

Thanks to everyone for prompt support with this.  :)

Ryan

1) Every time you export a model you will get a different IID on the second group. The first IID and the third IID stays the same. Eight HEX digit group (second IID) will give you something like 11 billion possible combinations. Rather unlikely you are going to get the same combination. Also, if you are rendering the same model but with different textures and/or orientation, you should always change something in the name to mark the chances so that you can see it at a glance in either LE or PIMx.

2) Take a look at any model you already have in your plugin made by other than you. They all end with 0x30000. LE and PIMx chops the first 3 zeros. If memory serves me right, in reality it is 0x00030000 Do not be concerned by it.

3) Unfortunately you will have to re-render all of the models you have made prior the usage of the script I gave you.

Have fun  ;)

Nick
________________________________________________________________________________

thingfishs

Thanks again Nick, though that is some disheartening news about having to re-render everything - at least now everything's working and there won't be potentially even bigger stuff ups further down the line (it's particularly good having caught it prior to releasing any of it). :)

(and again, thanks to everyone that helped; I came a long way in a short space of time :thumbsup:)

Cheers, Ryan.

Simcoug

Quote from: Simmer2 on May 30, 2017, 01:06:12 PM
Here is the solution. (Attached at the bottom of this post)

Simply copy/paste it over the old script found in \gmax\gamepacks\BAT\scripts.

Cheers

Nick

Thanks for the solution Nick... I'll let IDS know about this.  Thanks.

mgb204

#10
First off the point I was making before concerns the file in 3DS Max or SC4BAT. The ID is generated when you make the LODs with SC4BAT. But if you use the same file or scene there, it will keep the same ID. If you are using 3DS Max/BAT4Max and always use a brand new scene (or file) in SC4BAT, then you don't need to worry about it. Probably the missing patch was the issue there.

Quote from: thingfishs on May 30, 2017, 02:08:36 PM
Thanks again Nick, though that is some disheartening news about having to re-render everything - at least now everything's working and there won't be potentially even bigger stuff ups further down the line (it's particularly good having caught it prior to releasing any of it). :)

(and again, thanks to everyone that helped; I came a long way in a short space of time :thumbsup:)

Cheers, Ryan.

No need to re-render a thing. You can manually give a model a new ID very easily, I do it all the time. But you must first understand how IDs work and the inner workings of SC4Model files, which are key to doing this successfully.

First off, "typically" only the group ID will change when rendering models. But, sometimes for reasons I don't understand and have never personally experienced, it will give you a unique instance ID instead of a group ID. You need to be very careful with such models, since the usual rules for them will not apply. If you look at your screenshot with the four exports, you will see the top two have 0x140000 and 0x150000 as the instance ID. So long as the instance ID is 0x30000, then the following rules apply to IDs:

An SC4 Model contains 20 S3D (Model/LOD exports). These represent the 5 zoom and 4 rotations used by SC4, each needs it's own LOD (models don't really exist once rendered, the LOD becomes the model). The IDs of the Instance ID are then linked as follows:

0003NXYZ

Where N = 0 for day textures and 8 for night textures
Where X = the Zoom Level from 0 (zoom 1) to 4 (zoom 5/6). Note zoom 6 does not have it's own model.
Where Y = the rotation where 0=South, 1=West, 2=North and 3=East.
Where Z (textures only) = the unique texture increment. Textures can be a maximum of 256x256px in size, so if a particular Zoom/Rotation works out larger, it's cut into multiple textures. The first texture uses 0, which is then incremented all the way to F (16 in Hex). Which also means you are limited to no more than 16 textures for any model. Requiring very large/tall models to be split into multiple segments.

Using this system, it's easy to work with model files and IDs.


  • Open the model file in the reader and copy one of the objects inside it. My recommendation is the XML file, since there is only one, it's easier to keep track of.
  • Highlight this new file, right click and select "Generate new Group and Instance".
    Note how the two IDs have been given a random new ID. This is very important, if you start manually editing them, regardless of the system, it may cause problems. Using random numbers is the only safe way to proceed.
  • Now, go back to the original XML file, the one that isn't a duplicate, hit Edit. It has an entry ResKey (the ID), update the group ID here with the new one generated for the duplicate file.
    Be sure to make a copy (as in copy to the Clipboard or CTRL+C), of this ID afterwards, omitting the 0x prefix.
  • Click Apply to save the changes to the XML file.
  • Open Tools / TGI Editor from the file menu.
  • In the group box, paste the ID you copied before. Below make sure every entry in the list is selected/highlighted, then click Apply and close the window.
    Now all the Group IDs have been updated, don't worry, all the other parts of the model will still be linked together.
  • Now remove the duplicated XML file used to generate the ID we needed. Try to remember it's position (example: pasted right after the original). If you need to double check, the one to removes ID of the ResKey property won't match (because it's the original).
  • With it gone, save and close the file in reader.
  • Now, just paste the (hopefully) still in the clipboard ID to update the filename's ID, which is good practise.

Seems more complex when I type it all out, but once you get familiar with the process, you can speed through them.

thingfishs

#11
Thanks again mgb, my understanding has taken another leap forward.  :thumbsup:
I really appreciate the detailed explanation.

A couple of things though:

1:
Quote from: Simmer2 on May 30, 2017, 01:55:10 PM

2) Take a look at any model you already have in your plugin made by other than you. They all end with 0x30000.

I noticed that most of them do but not all - case in point, the Tokyo Buildings by art128


Is this something to be concerned about?

BTW, the model that I've just tested your method on ends in 0x20000, not 0x30000...?

2: Could someone please have a look at my attached test file to see if I've done it right?

Thanks,
Ryan

EDIT: There are two files in there, the original (marked as such) and the modified one).

mgb204

Quote from: thingfishs on May 30, 2017, 11:42:22 PM
Quote from: Simmer2 on May 30, 2017, 01:55:10 PM

2) Take a look at any model you already have in your plugin made by other than you. They all end with 0x30000.

I noticed that most of them do but not all - case in point, the Tokyo Buildings by art128


Is this something to be concerned about?

This is the point I made before, that some models are grouped by the instance ID. You have to be careful when the instance ID is not 0x30000, because altering the instance IDs rather than the group IDs can have unintended effects. It's not a sign something is wrong, but I really don't know why so many people end up with such IDs? I've never had a single model export that didn't have the 0x30000 instance ID scheme with the unique ID being the Group ID. Then again I've had the modelnames (ID fix) in place from the get go, I'm always surprised how many people missed it. I do wonder if it's related somehow?

The basic problem with having to alter the Instance ID rather than the Group ID, is that you will need to re-link all the textures to the models manually. This is a PITA, although model tweaker might be able to help you out with it's replace texture function. Provided you don't edit the Instance IDs, you won't run into this issue. However if you do have such models, I'd just re-render them because it's likely quicker, especially if they are small props and the like.

QuoteBTW, the model that I've just tested your method on ends in 0x20000, not 0x30000...?

2: Could someone please have a look at my attached test file to see if I've done it right?

It looks fine at a glance. Again 0x20000 is another oddity that I've not yet come across before. However, the key factor is that the group ID for all objects in the file are the same. So once more you know it's safe to change them to a new ID, everything will still work without further thought. Updating the data in the XML file and file name doesn't affect the functionality at all, but I like to keep things correctly labelled.

The best way to test such things if you aren't sure, is to place it in-game and check every zoom/rotation (which ideally you should do for every model you export), to ensure it works as intended. If the IDs are wrong somehow, you'll most likely see a series of multi-coloured squares rather than the intended texture. But no matter how badly you might screw up the model, it wouldn't harm the game in any way, so you don't need to be overly cautious.