Parent TID Conflict

[Wiimeiser 436]

I've found what seems to be a conflict between Max's Grill (A diner by DK1 that I can't seem to re-find the download for) and Capitol Records (One of the official Maxis landmarks), installing both causes the former to load the top of the latter into the visual box its building normally occupies. A quick search in SC4 Datanode shows the Max's Grill lot's building and the Capitol Records lot configuration both have the same TID of 6534284A, but the GID and IID are different. Does the TID do anything special that could be causing this?

[Cyclone Boom 16,851]

I found this DK1 set which contains a Max's Grill model file and a lot. Can you confirm this is the one causing the trouble?

Here's what it looks like from the lot preview image embedded in the file (as the LE creates):

For the Type ID being the same, I'm aware how this is common for many content items. Also some do share the same Group ID when related, such as FSH files as part of a model, and then the S3D files themselves. It is odd that there's a conflict when the Instance ID is different. Perhaps it's worth experimenting around with loading order by placing one or the other in a different folder. For having Max's Grill load last and that might prevent Capital Records from appearing in place.

[CorinaMarie 29,571]

While y'all are investigating I'd noticed one of dk1's Bowling Alley buildings will get replaced with part of the Maxis Stonehenge graphics. That was long ago before I knew how to research it myself and this topic reminded me.

[Wiimeiser 436]

Apparently someone left a comment pointing out the problem already, so I'm not the only one.

 

RRetail also has a lot pack that appears to use it, haven't tested to see what happens with that one yet, though. I'll get back to you when I do. I'll also try swapping the load order.

[rivit 3,391]

9 hours ago, Wiimeiser said:

A quick search in SC4 Datanode shows the Max's Grill lot's building and the Capitol Records lot configuration both have the same TID of 6534284A, but the GID and IID are different

The Building IID needs to be unique, always.  For the Capitol Records Building it should be TGI  6534284A-CA386E22-04B10000.

The MAXIS plugin buildings do seem to be a little different in some way - I can't get them to show in my Landmarks at all and I cant figure out why.  I have noticed that many buildings and Lot configs have a Cohort TID that is actually rotated when compared to other Buildings - this seems to affect foundations and some other properties. In the example you give the 6543284A is usually the Type indicating Exemplar. 

  

[Wiimeiser 436]

TGI  6534284A-CA386E22-04B10000 is the case with me.

 

On both lots, some entries are highlighted in yellow, others are in orange text and even pink text, what do these mean? I know red text means the reference is missing...

[rivit 3,391]

The highlight in the yellowish color means that something is missing in the dependency - usually in a building or prop if looking at the lot config. This helps figure out what is wrong below. Orange text is a valid null reference labelled as such,  red text missing item also labelled as missing.

What is the TGI of the Max's Grill?  Lot and Building - maybe someone else has them too.

[Wiimeiser 436]

Changing the order doesn't change anything.* The lots still conflict in exactly the same way. Since the Capitol is in dat format there might be some unknown data, or maybe compressed overrides non-compressed.

Every file I checked has a "DIR" entry with TGI E86B1EEF-E86B1EEF-286B1F03 that appears in pink text, not sure what that is...

Can't figure out how to get the lot TGI, but the building TGI on the Max's Grill lot is 6534284A-73156766-16E3C4D1, entry type is "Building", name is "Max'sV2LM" and bytes = 358. The lot file's LD entry (whatever that is) is overridden by OK Diner, which is the next file in the same folder. Nothing else seems unusual to me...

EDIT: An update: The problem occurs with both RRetail's and DK1's versions of the lots, so it's not the lot, but rather the building (or building model) they share. Still no idea what's causing it

*Still needs further testing, though...

  Edited February 21, 2020 by Wiimeiser  
Update

[rivit 3,391]

1 hour ago, Wiimeiser said:

Can't figure out how to get the lot TGI

fastest way is to go to the file view for that Building and look at the exemplars there - lots configs are TGI 6534284A-A8FBD372-IID  - can  also be found in the TGI View Lots/Props.

[Wiimeiser 436]

So it's in the filename... Then Max's Grill IID is 16E3C4D1, and Capitol Records doesn't have a lot file, it's all in a dat file. CB549981 is the IID of a LotConfiguration with matching TID and GID, and it's missing 4 prop exemplars, 2 LTEXTs, 2 cohorts, and 5 FSH files.

There are also 4 LUA files in the dat, shared TID and GID are CA63E2A3-4A5E8EF6-########, and the individual IIDs are FF017EF3, FF0E3922, FF664AD7, and FF85EA81. No idea what the LUA files are for, but they may be related to the LTEXT entries suggesting the existence of some kind of mod manager.

I think unpacking the dat file might be necessary to find the conflict here...

[CorinaMarie 29,571]

9 hours ago, Wiimeiser said:

No idea what the LUA files are for,

1. Adds the building to a ploppable tool type and to the special buildings counting table.
2. Adds some fluff news when the game detects the building in a city tile.
3. Package file to call and execute 1 & 2.
4. Package file with code to disable debug mode (which by default is turned off elsewhere and this is to trip up those of us who've played with toggling that, but we are wise to Maxis's tricks).

[rsc204 21,806]

On 20/02/2020 at 2:08 PM, Wiimeiser said:

A quick search in SC4 Datanode shows the Max's Grill lot's building and the Capitol Records lot configuration both have the same TID of 6534284A, but the GID and IID are different. Does the TID do anything special that could be causing this?

Type, Group and Instance IDs are all used to define objects, then give them unique IDs. Type IDs almost always are identical for every object of a given type, for example textures always use the TID 0x7ab50e44, whereas Exemplars use 0x6534284a. For some objects, the Group ID is then used as a sort of additional classification, for example FSH with the GID 0x1abe787d are defined as Network Textures, whereas 0x0986135e are defined as Lot Textures. This is why only textures designed for lots are usable in the Lot Editor. Whatever is left, either the combination of Group and Instance or simply just the Instance ID, that is what makes an object's unique ID.

However, the game's code is not something that is generally accessible or understandable, I've personally come across scenarios where despite the use of unique IDs, clearly a conflict is present. Not often, but in every such eventuality, the full TGI ID is a similar format to the Maxis content. I feel with this in mind, there is merit to avoiding the use of any ID's in the range of those Maxis used. It may explain why you're seeing a conflict, even if the IDs aren't identical.

On 21/02/2020 at 2:09 AM, Wiimeiser said:

Changing the order doesn't change anything.* The lots still conflict in exactly the same way. Since the Capitol is in dat format there might be some unknown data, or maybe compressed overrides non-compressed.

DAT files are always loaded after all other file types. Therefore it would be simply impossible for any file other than a .DAT to override data in another .DAT file. You can just manually change the file extension of any SC4 file to .DAT and it will still work just fine.

On 21/02/2020 at 5:05 AM, Wiimeiser said:

I think unpacking the dat file might be necessary to find the conflict here...

SC4 Addons, i.e. the Landmarks, can be a little wired, because some of the content they need is in the other SC4 DATs, so may appear missing. Some of the linked content simply never existed, but this is true of other Maxis content too. Likewise duplicate S3D/FSH and other files are loitering in these files too. However, there is no such thing as "unpacking" a DAT file, you can MANUALLY move individual contents to other files. However, if you can neither find nor scan for a conflict between this addon and the custom content in question, having these files separated won't change anything, nor will it help you understand better what you are seeing.

On 21/02/2020 at 5:05 AM, Wiimeiser said:

No idea what the LUA files are for

LUA is a scripting language, i.e. code the game uses that can be added as a Plugin. Cori's documented what this particular script is doing, but let's look at the original problem, a building/lot or model is being overridden and therefore not displaying correctly. We're at the point now where you are dissecting in tiny detail every aspect of the .dat file. Sorry to be the bad guy, but this really is a worthwhile methodology here, if all you want to achieve is to resolve the conflict.

Long and short, change the other addon to a .dat file, DATPack all files together from the download if need be. Now you can absolutely control the load order between it and Capitol records. You should through the load order be able to get the right object to load, bear in mind if you fix Max's Grill, you can expect the Capitol Records lot/building to now have a problem. This should be pretty easy to setup/test and confirms a conflict, even if the ID's don't match.

After that, just give the conflicting item (most likely the model), a new, unique ID and edit all linked IDs to update them, problem solved.

[Wiimeiser 436]

So basically the only real fix seems to be a complete overhaul of the diner... I'm not sure if DK1 is still active, but we can only try. I wouldn't know what to do on my end, though... I've never really had to edit exemplars before...

[CorinaMarie 29,571]

58 minutes ago, Wiimeiser said:

I'm not sure if DK1 is still active,

They were last seen near the end of 2012 so I'm guessing it's not likely they'll be back.

So, if peeps want to patch up these files, we can update them under @dk1's account as custodians of the content. I'm certain they did not intend for the files to go all goofy like this and so would appreciate the repair of them.