How to duplicate and then modify vanilla lots/buildings?

[Psiman 177]

For my mansions mod, I think I will need to create an additional set or sets of the vanilla mansion lots and buildings, so there would be two or three types of mansions, graphically the same but differing in one or two Exemplar properties.

A couple of questions:

1) There are several dozen each of Lots and Buildings. Do I have to right-click on every single one and then click "Add to Patch" or is there an easier way to make a .DAT copy of lots of files?

2) Once I have made a .DAT duplicating the relevant vanilla files, I will need to modify them in order that they have their own separate IDs. My belief is that to do this, the entries I will need to modify will be "Parent cohort" and "Exemplar Name" properties.

"Parent cohort" entries have three parts: Type, Group, Instance. Parent cohort entries are found in various places, and the third "Instance" one appears to be the unique identifier. So I think I would need to change the third "Instance" entries to unique IDs.

I would also need to create unique "Exemplar Names" for "Building Cohorts", such as "R$$$24x14_123_2000002c", and Buildings, such as "R$$$16x20_123EuroMansion11_01FA".

Does this sound right?

[rsc204 21,808]

On 20/11/2018 at 3:48 AM, Psiman said:

1) There are several dozen each of Lots and Buildings. Do I have to right-click on every single one and then click "Add to Patch" or is there an easier way to make a .DAT copy of lots of files?

If you find all the relevant exemplars and highlight them, you can Copy/Paste them into a new DAT. Would that be easier?, I guess that depends on which method you prefer. You can filter the files within a DAT so you only have to sift through Exemplars. But the main SC DAT will contain plenty of items you won't want and there is no easy way to display all Building/Lot Exemplars only, which complicates matters.

In case you had not realised it, Maxis lots tend to use a lot of Parent Cohorts too, so if the properties being altered are contained in those, you might need copies of these also.

On 20/11/2018 at 3:48 AM, Psiman said:

2) Once I have made a .DAT duplicating the relevant vanilla files, I will need to modify them in order that they have their own separate IDs. My belief is that to do this, the entries I will need to modify will be "Parent cohort" and "Exemplar Name" properties.

Are you looking to substitute the original lots with your modifications (an override), or add to them as additional mansions. If the former, leave these properties alone, or you'll end up with both sets of lots. All overrides work precisely by using the same IDs as the original items.

If you want new, unique ones, you need to give your lots and buildings new TGI IDs. In reader you can highlight all your exemplars, right click and select "Generate new group and Instance" to do this, but that won't work by itself. The buildings and lots should retain the same IID (instance ID) for each pairing. Then you have to ensure the properties for these IDs, where used in the buildings exemplars, are updated to match the new IDs. Equally every LotConfig Exemplar will have a building item upon it, a LotConfigPropertyLotObject starting 0x00000000. The final Rep here should be the IID of the matching Buildings Exemplar. Put simply, if you do want these as new, unique instances, it's going to be a lot of work with IDs/Properties to make duplicate lots.

On 20/11/2018 at 3:48 AM, Psiman said:

"Parent cohort" entries have three parts: Type, Group, Instance. Parent cohort entries are found in various places, and the third "Instance" one appears to be the unique identifier. So I think I would need to change the third "Instance" entries to unique IDs.

Not necessarily, generally speaking the Type ID is an identifier, i.e. a Cohorts all share the same unique Type ID. But the group and instance IDs could probably both be unique. That's not to say that's how Maxis used them, but certainly they will work with both. Bear in mind too, changing the Parent Cohort Property, is NOT changing the Parent Cohort ID. This simply sets the ID of the Cohort that your exemplar is looking for, if no actual Cohort with that ID exists, you will run into trouble.

On 20/11/2018 at 3:48 AM, Psiman said:

I would also need to create unique "Exemplar Names" for "Building Cohorts", such as "R$$$24x14_123_2000002c", and Buildings, such as "R$$$16x20_123EuroMansion11_01FA".

Names are irrelevant, they are simply labels and only useful for either you or others using items to identify them. Everything in the game works on IDs, duplicate names will never cause conflicts. That said, if you are going for a new, unique set, it would be helpful to differentiate your lots from the originals. But rather than faff about renaming everything, I'd just prefix each name with something like "Psi_", so it was clear which were the originals and which were the modified versions. That said, most of this is only seen when working in LE or Reader, most Maxis content links to LText (text) files which display the actual names/labels seen in game with queries and the like.

[Psiman 177]

Thanks for the info!

18 hours ago, rsc204 said:

Are you looking to substitute the original lots with your modifications (an override), or add to them as additional mansions.

My aim is this - in the vanilla game, there are many different-sized mansion Lots, but they use the same Building(s), and therefore have the same in-game stats. So the smaller the mansion Lot's footprint size the better. I want to reverse this, which will mean having to have more than one category of mansion building, each with different values for "Building Value", which is used to calculate tax income.

There are two potential ways I can think of doing this. The first works, but is cumbersome, while the second sounds more elegant in theory, but I don't know if it's possible.

1) The first method would be to duplicate the vanilla mansion Buildings (twice), give them unique IDs and add a "Building Value" Exemplar property to each of them.  Then the mansion lots of each category would link to the relevant set of mansions.  Exemplar properties in the Building Exemplar override over those in the Building Cohort.

2) By default, the "Building Value" Exemplar property is held in the Building Cohort Exemplar, not in the Building Exemplars themselves. So maybe it would be possible to create two new Building Cohorts, duplicates of the original except for modified "Building Value" (and unique IDs), and then have all of these Cohorts linked to exactly the same vanilla Buildings? Since the Buildings themselves don't have a "Building Value" Exemplar property, the Building Cohort would then impart the "Building Value" on the individual Building plopped on the map. So multiple Building Cohorts would therefore be sharing the same vanilla Building file, but each imparting a different "Building Value" on the plopped end product.

For this second option to work, one would need to be able to:

a) Create new Building Cohorts
b) Use the same Buildings with multiple Building Cohorts

EDIT: Okay, I've managed to find the Building Cohorts and made a .DAT of them.

2ND EDIT: I don't think the second plan is going to work, as it looks like every Exemplar is tied to one particular Building Cohort. So I think the Buildings will need to be duplicated whatever.

[rsc204 21,808]

On 22/11/2018 at 12:28 AM, Psiman said:

The first method would be to duplicate the vanilla mansion Buildings (twice), give them unique IDs and add a "Building Value" Exemplar property to each of them.  Then the mansion lots of each category would link to the relevant set of mansions.  Exemplar properties in the Building Exemplar override over those in the Building Cohort.

But if you don't want to original lots to still be in the mix, making these with unique IDs would just add to the existing mansions. If you want to override the behaviour of the default lots, you should not make new, unique instances of these lots, which will also be more work for you.

Cohorts work in such a way that when an Exemplar (in this case a Buildings Exemplar), links to a Cohort Exemplar. The properties contained in the Cohort will override those of the original exemplar that links to it. A Cohort can itself have a Cohort, this chain could theoretically continue onwards. If a property is dealt with by a linked Cohort, there is no need for that property to be included in the Exemplar, because it's essentially redundant. Cohorts exist, because many properties are duplicated between Buildings, so to save space and be more efficient, they can be linked via Cohorts. Of course here in 2018 that seems a little unnecessary, but in 2003 being super-efficient like this was a mainstay of coding/game design.

:EDIT:

A Buildings Exemplar will NEVER override properties of a linked Cohort. Seemingly it will do so, but only for nested Cohorts, if the properties are in the actual parent (the Cohort ID specified in the Parent Cohort Property), then it will be overriden by the Cohort. If you don't want the Cohorts to affect your Buildings Exemplars, you must remove the link to the Cohort. But, you must ensure that you correctly add all the necessary properties of any Parent Cohorts and nested Cohorts. Some of these may be necessary for the building to work or prevent unintended behaviour. To give you a better idea of this, here is one such Maxis mansion Building, showing the nested Cohort Properties (view from PIM-X):

You can see here that in total 3 nested Cohorts are used. So this is maybe more complex that you might realise. PIM-X makes it much easier to visualise this data than Reader, since it shows these linked files.

So the main Buildings Exemplar links to

• "Parent" Cohort ending 2B (R$$$20x20_123_2000002b)
  • "Grandparent" Cohort ending 04 (R$$$)
    • "Great-Grandparent" Cohort ending 01 (Residential).

If you edit the properties of the Cohort "R$$$", which has the Building Value property, you need to ideally understand what other Buildings will be affected. There is no easy way to do this, without looking at all the Buildings and checking, at least that I know of.

But rather than go down that path, the simpler solution is to edit the existing Building Exemplars you want to change and use a new set of Cohorts for them. By using a set of "Parent Cohorts" and "Grandparent Cohorts", the later of which would link to the original "Great-Grandparent Cohort", i.e. the one ending in 01 (Residential). You'd need a set of two Cohorts for each different variant of settings you wanted. Then to apply those alterations to the existing Maxis Buildings Exemplars, use a copy which has the Parent Cohort Property modified to instead link to the relevant new Parent Cohort you've created.

Of course all of this assumes you go down the path of making an override of the original data. If you choose to make new instances, then either you need a new set of Cohorts as explained here. Otherwise, you could simply have all the properties for each and every Buildings Exemplar and set them one by one. Either way, adding new lots will not suppress the existing ones, so once more, I am pretty sure that's not what you want to do here.

[Psiman 177]

Thanks. I'll go through it in more detail over the weekend.

Just one thing first, though...

9 hours ago, rsc204 said:

A Buildings Exemplar will NEVER override properties of a linked Cohort.

I tested a few days ago by adding a "Building Value" property to all the Euro mansion Exemplars and I then added a zero to the values. I loaded up the game, selected Euro building style and the mansions that spawned were producing phenomenal tax, so I know it works. I've also just double-checked it - seems to be ten times as much.

There is another thread here which discusses Cohorts, which I will quote from and put in bold the part which may be relevant here:

A few things about cohorts:

- A cohort is like an exemplar. It contains a list of properties. While the cohort itself is not a lot or building exemplar (ie it does not act as a building or lot), it "inherits" its defined properties to all its "descendants" (exemplars and cohorts referencing it). Setting a property in a cohort amounts to setting this property to all its descendants. Thus it can be useful when you want to define properties common to building or lot exemplars of a pack.
- A cohort can reference (by setting the Parent Cohort property) another cohort. This can reasult in a sort of a "hierarchy". A building or lot referencing the last "descendant", will "inherit" the properties set in all its "ancestors".
- If a property set in an ancestor is set in a descendant as well, the value set in the descendant will "override" the one in the ancestor - only for the cohorts/exemplars referencing the descendant; those referencing a cohort "above" the descendant containing the override will instead "see" the "old" (the ancestor's) value.

So it looks like that's what must be happening here. I'm not sure if this makes things any easier.

[Psiman 177]

Is there a way to manually rename Cohorts instead of using "Generate new instance"?  Can I, for example, add a 1000 to the number of the original cohort, so 0x2000002B becomes 0x2001002B?

[rsc204 21,808]

On 24/11/2018 at 4:54 AM, Psiman said:

Just one thing first, though...

I tested a few days ago by adding a "Building Value" property to all the Euro mansion Exemplars and I then added a zero to the values. I loaded up the game, selected Euro building style and the mansions that spawned were producing phenomenal tax, so I know it works. I've also just double-checked it - seems to be ten times as much.

There is another thread here which discusses Cohorts, which I will quote from and put in bold the part which may be relevant here:

That's interesting, since the first Cohort (Parent) in a chain overrides the main Exemplar, it wouldn't have occurred to me this doesn't happen further down the chain. I did wonder, since in the example image, you can see Building Value properties included not only in the main exemplar and one Cohort, but also in the Family too. However, given that the Parent Cohort doesn't include this value, you'd be safe to modify the property in the main Buildings Exemplars and simply not bother with the Cohorts. This would be a whole lot simpler too.

On 25/11/2018 at 3:22 AM, Psiman said:

Is there a way to manually rename Cohorts instead of using "Generate new instance"?  Can I, for example, add a 1000 to the number of the original cohort, so 0x2000002B becomes 0x2001002B?

Bear in mind, renaming and re-IDing are two very different things, the ID is not the name. Sure a little pedantic, but for the sake of understanding, some nomenclature is important. In the file menu, click on Tools / TGI Editor and a new window appears. You can now select any exemplar/component of the open file, or multiples, and quickly re-ID them manually. One slight problem is that the order of files in this window is in reverse of the order in the main Reader window, i.e. listed with the last file showing first.

Note the windows all contain 8 hash symbols (#), you can simply replace single digits at a given point of an ID for multiple files, without messing with the rest of the ID. For example, if you entered ####1### in the Instance ID field, all selected files would have the 5th digit changed to 1 regardless, whereas the remaining 7 digits would be unchanged.

Do bear in mind, this is not the best method of generating IDs, because manually IDing files increases the odds of potential ID conflicts. Random ID generation (use of Generate function), is much better, since it reduces the odds of conflicts by generating an ID based on the date/time. Humans will often use similar patterns and tricks when making a new ID, but a randomly generated one has no such bias. It's probably OK for a small number of files, but it's really a bad habit to get into IMHO.

[Psiman 177]

3 hours ago, rsc204 said:

ThaHowever, given that the Parent Cohort doesn't include this value, you'd be safe to modify the property in the main Buildings Exemplars and simply not bother with the Cohorts. This would be a whole lot simpler too.

No new cohorts then? Not sure what I'm supposed to be doing next then... 

- I have a DAT with copies of all R$$$ Lots and Buildings. I suppose it will be better to separate Lots from Buildings and put them in separate DATs for now. 

- The 3x3 Mansions are completely vanilla and don't need anything done to their Lots or Buildings. I don't think the modded 3x4 Lots and the 2x3/3x2 Lots need new instance IDs because they are replacing the vanilla Lots. So the new content being created is two duplicate copies of the mansion Buildings. So I make an additional copy of the Buildings DAT so there are two of them, each duplicates of the original vanilla mansion Buildings.

- I suppose I next need to give the Buildings in these new files new instance IDs. I highlight the Exemplars and right-click. Do I still want to choose "Generate new group & instance" or should I choose "Generate new instance", if cohorts are no longer being used? 

- Then.. Not quite sure what to do next. 

[rsc204 21,808]

I guessing there is still some confusion regarding IDs/Overrides from your response. So let's break things down into the changes for the buildings and lots you would need to make.

In the first instance I would finalise any changes to the lots themselves. If you are using the Maxis LE, it can not save files contained within a DAT file, so these changes are best handled first. You can then DAT Pack these modified lot files into a single DAT.

Next go through the Buildings one by one and modify the Building Value property for all those you want to change.

In the case of both the Lot and Buildings, you only need keep those specific files you are changing. Even if you alter a Lot, it's matching Building only needs to be included in your mod if that too is also being modified. Likewise if only altering the Building, you won't need it's matching Lot.

As these files are all intended to override (replace) the originals, you neither need or want to alter any IDs whatsoever. You'll be left with a bunch of modified Lots and Buildings, from a distribution perspective I'd keep those in one file. But when working, it can be easier to keep things separate, whatever you find easiest. If you open more than one instance of iLives Reader, you can very easily copy/paste the individual parts of them between the open windows. Just right click and use "Copy/Paste Properties" with the required files selected, CTRL + C / V keyboard shortcuts are also supported too. Using this method, you can organise your files quite flexibly, although if you just have a couple files and you want everything in one, DATPacking them can be quicker.

[Psiman 177]

5 minutes ago, rsc204 said:

I guessing there is still some confusion regarding IDs/Overrides from your response. So let's break things down into the changes for the buildings and lots you would need to make.

In the first instance I would finalise any changes to the lots themselves. If you are using the Maxis LE, it can not save files contained within a DAT file, so these changes are best handled first. You can then DAT Pack these modified lot files into a single DAT.

Next go through the Buildings one by one and modify the Building Value property for all those you want to change.

In the case of both the Lot and Buildings, you only need keep those specific files you are changing. Even if you alter a Lot, it's matching Building only needs to be included in your mod if that too is also being modified. Likewise if only altering the Building, you won't need it's matching Lot.

As these files are all intended to override (replace) the originals, you neither need or want to alter any IDs whatsoever. You'll be left with a bunch of modified Lots and Buildings, from a distribution perspective I'd keep those in one file. But when working, it can be easier to keep things separate, whatever you find easiest. If you open more than one instance of iLives Reader, you can very easily copy/paste the individual parts of them between the open windows. Just right click and use "Copy/Paste Properties" with the required files selected, CTRL + C / V keyboard shortcuts are also supported too. Using this method, you can organise your files quite flexibly, although if you just have a couple files and you want everything in one, DATPacking them can be quicker.

Thanks.

Surely the two duplicate sets of Buildings will need unique IDs, as there will be three sets of Building files - the vanilla, and two modified sets? (If so, will it be "Generate new group & instance" or "Generate new instance")?

[rsc204 21,808]

1 minute ago, Psiman said:

Surely the two duplicate sets of Buildings will need unique IDs, as there will be three sets of Building files - the vanilla, and two modified sets?

I am missing something, why are there three sets and not two? If you want to replace the original vanilla items, you must not change the ID. Doing so will make your new files an addition to the existing content instead.

So you have two modified sets, are these different choices someone could select between? Again though, if the intention is to replace the Maxis files, altering the IDs will prevent that from happening.

[T Wrecks 10,209]

To make matters more confusing, you could also use a Maxis blocker (you could even create a selective one that only blocks mansions) and use any amount of custom mansions exclusively, even without explicitly overriding Maxis lots. Just mentioning it so you have this possibility on your radar, too.

[Psiman 177]

4 hours ago, rsc204 said:

I am missing something, why are there three sets and not two? If you want to replace the original vanilla items, you must not change the ID. Doing so will make your new files an addition to the existing content instead.

So you have two modified sets, are these different choices someone could select between? Again though, if the intention is to replace the Maxis files, altering the IDs will prevent that from happening.

There will be three types of mansions. The 3x3 mansions will use vanilla Growth Stage and "Building Value" and so don't need to be modified. The 4x3 mansion Lots/Buildings will have "Building Value" increased to increase tax level, and also have their Growth Stage changed from 2 to 3. The 2x3/3x2 mansion Lots/Buildings will have their "Building Value" lowered to reduce tax, and their Growth stage changed from 4 to 3. So there will be a vanilla set of mansions and two modified sets.

I'll test later to see whether "Building Value" can be added to the 4x3 and 2x3/3x2 Lots, rather than Buildings, and if it will impart the "Building Value" on to the Building. If this works, then I don't need to create anything new. If it doesn't work, I will need two duplicate sets of the mansion Buildings, each of which which I will then add a "Building Value" to. They will presumably need unique IDs. Then I will need to link one of these sets of Buildings to the 4x3 mansion Lots and the other to the 2x3/3x2 Lots.

4 hours ago, T Wrecks said:

To make matters more confusing, you could also use a Maxis blocker (you could even create a selective one that only blocks mansions) and use any amount of custom mansions exclusively, even without explicitly overriding Maxis lots. Just mentioning it so you have this possibility on your radar, too.

I don't know the details of a Maxis blocker. If I'm not using the larger-sized mansion lots, I will need a way to make sure they can't grow. At the moment, their Growth Stage is set to 255, but I don't know whether that will prevent them growing. If "Desirability Threshold Growth" can be added to a lot or building, and was set to 255 then I think that would prohibit any chance them appearing.

EDIT: Adding "Building Value" to the Lots didn't work, so it'll need to be added to the Buildings.

[T Wrecks 10,209]

1 hour ago, Psiman said:

At the moment, their Growth Stage is set to 255, but I don't know whether that will prevent them growing

This should work just fine. There are other methods, such as setting minimum slope to a higher value than maximum slope, but setting the stage to FF is easier to do.

1 hour ago, Psiman said:

Adding "Building Value" to the Lots didn't work, so it'll need to be added to the Buildings

Yep, this is a property that's associated with buildings and not with lots.

[rsc204 21,808]

1 hour ago, Psiman said:

There will be three types of mansions...

Yes, this part I get. The question is though, are any of those you are modifying not intended to alter the existing buildings? Put another way, are you looking to add them as additional ones?

1 hour ago, Psiman said:

Adding "Building Value" to the Lots didn't work, so it'll need to be added to the Buildings.

Indeed pretty much any properties for Buildings will simply never work with LotConfig Exemplars. If they did, we wouldn't need Buildings Exemplars.

[Psiman 177]

7 hours ago, rsc204 said:

The question is though, are any of those you are modifying not intended to alter the existing buildings? Put another way, are you looking to add them as additional ones?

All the mansion Lots being modified will use modified Buildings. There are two mansion Lots that will need a new Building, but will not need to change Growth Stage as they are already at Stage 3, because the 4x3 Lots are split over two Growth Stages. Here's a list of all vanilla R$$$ Lots at Stages 1-4, and what is being done to them in the mod.

-----------------------Growth Stage 1 --------------------------

□ R$$$1_4x5 - Not currently being used
□ R$$$1_4x5 - Not currently being used
□ R$$$1_4x5 - Not currently being used
□ R$$$1_4x5 - Not currently being used
□ R$$$1_4x5 - Not currently being used
□ R$$$1_4x5 - Not currently being used

□ R$$$1_4x6 - Not currently being used
□ R$$$1_4x6 - Not currently being used
□ R$$$1_4x6 - Not currently being used
□ R$$$1_4x6 - Not currently being used
□ R$$$1_4x6 - Not currently being used
□ R$$$1_4x6 - Not currently being used

-----------------------Growth Stage 2 --------------------------

□ R$$$2_3x4 - Not currently being used
□ R$$$2_3x4 - Not currently being used
□ R$$$2_3x4 - Not currently being used
□ R$$$2_3x4 - Not currently being used

□ R$$$2_4x3 = Lot: Growth Stage 2>3 / Building: Tax Rate>Higher 
□ R$$$2_4x3 = Lot: Growth Stage 2>3 / Building: Tax Rate>Higher 
□ R$$$2_4x3 = Lot: Growth Stage 2>3 / Building: Tax Rate>Higher 
□ R$$$2_4x3 = Lot: Growth Stage 2>3 / Building: Tax Rate>Higher 

□ R$$$2_4x4 - Not currently being used
□ R$$$2_4x4 - Not currently being used
□ R$$$2_4x4 - Not currently being used
□ R$$$2_4x4 - Not currently being used
□ R$$$2_4x4 - Not currently being used
□ R$$$2_4x4 - Not currently being used

-----------------------Growth Stage 3 --------------------------

□ R$$$3_3x3 - No changes to Lot or Building
□ R$$$3_3x3 - No changes to Lot or Building
□ R$$$3_3x3 - No changes to Lot or Building
□ R$$$3_3x3 - No changes to Lot or Building
□ R$$$3_3x3 - No changes to Lot or Building
□ R$$$3_3x3 - No changes to Lot or Building

□ R$$$3_3x4 - Not currently being used
□ R$$$3_3x4 - Not currently being used

□ R$$$3_4x3 = Lot: No changes. Building: Tax Rate>Higher 
□ R$$$3_4x3 = Lot: No changes. Building: Tax Rate>Higher 

-----------------------Growth Stage 4 --------------------------

□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower
□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower
□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower
□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower
□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower
□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower
□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower

□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower
□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower
□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower
□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower
□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower
□ R$$$4_2x3 - Lot: Growth Stage 4>3. Building: Tax Rate>Lower

----------------------------------------------------------------------------

Also, I'll need to check whether there's any difference between the Stage 2 and 3 4x3 Lots.

[Psiman 177]

I have a proposed hypothetical process for doing this:

1) Duplicate the vanilla Buildings.

2) Generate new Instance IDs (or Group and Instance IDs) for Buildings.

3) In Reader, open up LotConfig for Lot and open every "Type 0: Building" sub-menu.

4) In each "Type 0: Building" sub-menu, change "Resource Key Type 1"'s third number (Instance) to the new Instance ID of the new Building duplicate.

This is my current guess based upon comparing the "Type 0: Building"s. "Resource Key Identifier 1" is the property that changes when comparing between the "Type 0: Building"s, and is the Instance ID of the vanilla Buildings. "User Visible Name Key" also changes, but that I think relates to a Building's in-game name.

[Psiman 177]

Testing my hypothesis proved a mixed success. Lots that had been linked to new duplicate Buildings with unique IDs and increased "Building Value"/tax rate did indeed produce higher tax rate in the game. However, they were not a graphical success, and the "Type 0: Building" submenus have disappeared from the LotConfig sections.

 

[T Wrecks 10,209]

Well, "Resource Key Type 1" points to a building model, so if you enter an ID for which the game doesn't find a model, you will see a brown box instead. You can create as many building exemplars that all point to the same model as you want, but you need a model for the game to know what to display.

However, the game also contains some building models that are invisible. This is because not every lot needs a visible model on it, but the building exemplar is needed to acommodate some stats and properties that cannot be assigned to the lot - tax value being one example. The open grass lot is one such example: It has typical stats that are bound to a building exemplar (plop cost, maintenance cost, power/water/garbage, pollution, park/landmark effect, bulldoze cost, and so forth). Nonetheless you don't see a building on the lot in game. If you open the lot in the Lot Editor, however, you will see a grey building box.

Therefore, you need to duplicate building exemplars that refer to the same building model.

For example, you could use any random building to create a new building exemplar. You'd get an .sc4desc file that holds the usual properties, but has a new IID. Then you could delete all properties that you'd want to replace and copy the ones that you need over from the Simcity_1.dat file - explicitly including the "Resource Key Type 1"! The result would be a new, unique building exemplar with the properties you need and a reference to an existing building model.

It might also be possible to hook into the aforementioned invisible buildings by making your building exemplar point to it and adding the visible building as a prop.

[Psiman 177]

5 hours ago, T Wrecks said:

Well, "Resource Key Type 1" points to a building model, so if you enter an ID for which the game doesn't find a model, you will see a brown box instead. You can create as many building exemplars that all point to the same model as you want, but you need a model for the game to know what to display.

However, the game also contains some building models that are invisible. This is because not every lot needs a visible model on it, but the building exemplar is needed to acommodate some stats and properties that cannot be assigned to the lot - tax value being one example. The open grass lot is one such example: It has typical stats that are bound to a building exemplar (plop cost, maintenance cost, power/water/garbage, pollution, park/landmark effect, bulldoze cost, and so forth). Nonetheless you don't see a building on the lot in game. If you open the lot in the Lot Editor, however, you will see a grey building box.

Therefore, you need to duplicate building exemplars that refer to the same building model.

For example, you could use any random building to create a new building exemplar. You'd get an .sc4desc file that holds the usual properties, but has a new IID. Then you could delete all properties that you'd want to replace and copy the ones that you need over from the Simcity_1.dat file - explicitly including the "Resource Key Type 1"! The result would be a new, unique building exemplar with the properties you need and a reference to an existing building model.

It might also be possible to hook into the aforementioned invisible buildings by making your building exemplar point to it and adding the visible building as a prop.

Thanks.

Do I still need duplicate sets of Buildings then to hold the modded stats, or can the Building Exemplars hold the information? 

Which of these options will I most likely have to do?

1) Only modify existing Building Exemplars.

2) Modify existing Building Exemplars and create new sets of Buildings with unique IDs.

3) Create new Building Exemplars and create new sets of Buildings with unique IDs.

If I do need to duplicate the Buildings, should I only change for each the Instance, or the Group and Instance?

[rsc204 21,808]

As TWrecks points out, you really don't want to mess with the RTK IDs, which has caused the brown boxes to appear in place of the buildings.

When I talk about overrides v.s. additional content, I am not talking about the files themselves. If you duplicate a file, but keep the ID the same -i.e. the TGI or three groups of 8 digits shown in the left pane in reader. That file will replace the original file or override it. If you make no changes to the properties or connected lot, you will see no difference. But if you alter these things, your new settings will apply to them. SC4 only works based on the IDs, it doesn't care what file something is in. The last file to load with the same ID, is the version of the ID that the game will use.

In other words, unless you want to add new lots/buildings that never previously existed into the mix, you will want to keep the IDs the same as the originals.

So, keep a copy of only those Buildings Exemplars you've modified. Likewise for any LotConfiguration Exemplars you've altered. Do not change any IDs. Then your changes will be reflected, replacing those setttings/lot layouts of the originals.

[Psiman 177]

As outlined in this thread, I have a theory that, because Stage Limits are based on the ratios of Buildings, not Lots, that there are a load of mansion lots that the game doesn't build since R$$$ at Growth Stages 1-4 (and partially 5) use the same sets of Buildings.

Help me prove this theory to be right, or wrong! If the theory is correct then it will see a MAJOR fix/improvement to the game!

Duplicate sets of the mansion buildings will need to be created so each Growth Stage has its own set(s) of Buildings, rather than them all using the same sets.

EDIT: Could perhaps test it by adding some new residential lots/buildings from STEX, setting them to Growth Stage 4 and seeing if they appear in the game.

[Psiman 177]

What's this "LD" page, associated with a Lot?

I've changed the Wealth Type and Growth stage in the Exemplar, but this "LD" page still shows the old values.

[rsc204 21,808]

3 hours ago, Psiman said:

I've changed the Wealth Type and Growth stage in the Exemplar, but this "LD" page still shows the old values.

An LD file simply displays a number of properties of the lot and a basic dependency listing. That said, often the data within it is wrong, since it doesn't always get updated from it's original creation. However, none of this affects the function of your lot in any way, it's like an XML data file, which was used by the official EA SC4 Exchange. Their site would read this data and populate the listing of the download with it. Frankly, you are best off using another method, since these files are often woefully inaccurate. As you've noted, when editing properties, they don't always update to reflect the changes, especially if you use non-Maxis tools.

Similarly, the Maxis LE embedds a PNG file as a Lot Preview into your SC4Lot files. Again, used to display an image of the lot on the official download exchange. Once more, this file is totally useless today and simply wasting space.

As such, if distributing files, ideally you should delete these. Be careful not to delete any PNG icon files, those are necessary for all Plop lots, but should not be present for growables. If you DATPack files, usually such redundancies are taken care of and only the useful Exemplars/related files will be kept.

[Psiman 177]

It was a lot/building I downloaded from STEX.

[Psiman 177]

So we have a plan: to try and create a duplicate copy of Growth Stage 4 mansion buildings, and to get them to appear in the game.

ETA: Never mind, am yet to make a decision on this.

[Psiman 177]

Observations so far:
 
- Vanilla Stage 4 mansion Lot and Building will not (or will rarely) appear in game.

- User-created Stage 4 mansion Lot and Building will appear in game.

- User-created Stage 4 mansion Lot with vanilla Building will not (or will rarely) appear in game.

Which leaves us with the Building as the next thing to try and modify, and I'm trying to ascertain the process needed to do this.

Looking in PIM, each building has a unique TGI Instance (underlined in red in the following screenshot). This value is repeated in the "Resource Key Type 1" property (also underlined in red). So this would suggest one would need to create a unique TGI Instance for each duplicate Building, and then change the relevant value in the "Resource Key Type 1" property to match it.

Looking In Reader at the mansion Lot Builing Exemplars, they also have this Instance, so they should also be changed to match the new Instance.

I'm assuming, at the moment, that new Building Cohorts will not need to be created. So if this doesn't work, new Building Cohorts will be the next step.

[Psiman 177]

Latest test results...

All I did for this test was to create new Instance IDs for the mansions (not Group & Instance).

Within a couple of minutes, my test area was filled with Stage 4 2x3/3x2 mansions.  So that would suggest that whatever blocks Stage 4 mansions from growing normally is related to the Instance IDs of the mansions. This is the first time that Stage 4 Maxis mansions have been created under laboratory conditions.

However, the game was only building Stage 4 2x3/3x2 mansions. This corresponds with the general mansion-spawning behaviour observed previously, whereby the game will build the smallest size mansion Lot that will fit in an available space (that being 3x3 under normal unmodified conditions). The same test results had previously been observed when 2x3/3x2 mansion Lots were changed to Growth Stage 3.

So the objective of trying to get the game to produce mansions of various sizes remains unattained. The aim would be for the game to try and maintain a proportion of mansions of various sizes, so there'd be some large 4x3 mansions, medium 3x3 mansions, and smaller 2x3/3x2 mansions. Things just seem to operate differently when comparing Growth stages 1-4 and 5-8. 

Possible further avenues of experimentation:

a) Change "Resource Key Type 1" value to match new Instance IDs.

b) Change Group and Instance.

c) Create new Building Cohorts.

[Psiman 177]

Some more tantalizing, yet unsatisfying tests.

I downloaded and added Wilford House, a Stage 4 mansion that can appear on 3x3 or 3x4 Lots. I changed its density from medium-high to low-medium-high. I let the game run, and, unlike the normal mono-selection of mansions, it spawned a pretty balanced proportion of vanilla sub-Stage 4 mansions and Stage 4 Wilford House mansions, as can be seen in the screenshot below.

So that looked very promising. Then, however, I changed the Wilford House Lot size in the Lot Editor to 3x2, and they didn't appear in the game. Since the Wilford House Lot size when it was working was 3x3 and 3x4, it cannot be proved that it was trying to maintain proportions of Stage 4 mansions to other-Stage mansions. Instead, it could have just been building the lowest possible size of 3x3, like it normally does.

It's still a mystery why it won't build 2x3/3x2 at Stage 4, since it will build them if they are set to appear at Stage 3.

[Psiman 177]

I tested again a mod I made in which 4x4, 3x3, 3x3 and 3x2 mansions are all set to Stage 3, which leads to it building all mansions in the smallest size possible - 2x3/3x2. I noticed that the modified Wilford House was appearing in the small 3x2 size. 

So when the game was building all 3x3 vanilla mansions, it would also build 3x3 Wilford House, but not 3x2 Wilford House. When the game was building all 2x3/3x2 vanilla mansions, it would also build 2x3/3x2 Wilford House, but not 3x3 Wilford House. So there's a correlation there.

I think the 2x3/3x2 mansions should appear in medium density zoning. That would make them equivalent to R$ Boxy Apartments, which are also at Stage 4, but appear only in medium-density. It would be nice to try and make it a smoother transition, though, between 3x3 mansions and luxury condo apartments, as its currently fairly abrupt.