How to make certain Maxis props disappear?

[smurfN 26]

Hi.

What do I need to do in reader to make certain maxs props to disappear? I'm guessing I have to copy the exemplar file of the props, but what property or properties do I need to change?

[Raymond7cn 6,773]

1 hour ago, smurfN said:

Hi.

What do I need to do in reader to make certain maxs props to disappear? I'm guessing I have to copy the exemplar file of the props, but what property or properties do I need to change?

Hiya @smurfN, I'm not pretty sure that if i understand your needs well, I thought you'd like to make a Maxis's prop to disappear from every Lots related, Before our experts come along with much better advice, There are two approaches occur to me:

1, make an override model with the same ID as the prop's model, but it's a very small invisible model which looks transparent.

2, make an override Exemplar with the same ID as the prop's Exemplar, then modify the RKT1 values all to zero.

I hope we could make some tests carefully before go far away, since I don't know if these will lead to problems. (Prop Box, Brown Box) I can help if you show me the specific one you want to be disappeared.

Sincerely,

-- Raymond

[smurfN 26]

@Raymond7cn The props I would like to get rid of first are the fruit trees that are on maxis farms, apples/oranges or whatever fruits they are. 

 

Would be nice knowing the technique though should I feel the urge to get rid of something else

 

[Raymond7cn 6,773]

On 10/23/2020 at 4:50 AM, smurfN said:

The props I would like to get rid of first are the fruit trees that are on maxis farms, apples/oranges or whatever fruits they are. 

Ah, If you only want make prop to disappear from specific Lot, i thought you'd better hide it from that Lot's Exemplar, Sorry i don't know too much about Vanilla farm Lot, Anyway, here is a test i made for hiding a Maxis's tree prop.(all relevant Lot will be influenced):

1, Open Maxis's playground, seems most of Maxis's Lots use Prop family for tree props.

2, Open Simcity_1.dat With ILiveReader, Analysing and locating the tree Prop's Exemplar, right click the Exemplar then click "Add to patch"

3, Confirm if it's what we want from its S3D file.

4, Click "Patch" from the top of reader, press "Create DAT" to create a override file for testing. save it into a Plugins folder.

5, Make a Test Lot with Lot Editor before next step.

6, Open the Dat file we just created with reader, set its RKT1 's value to zero.

7, The tree disappear from the Test playground.

I hope it helps.

Sincerely,

-- Raymond

[Raymond7cn 6,773]

Hiya @smurfN, Just as a side note, If you hide the prop with my way above, I highly suggest test it enough with a blank city, I'm just a Newbie Lotter,  And in terms of vanilla farm Lot, dimly remember that @CorinaMarie @Cyclone Boom have more knowledge of it from a thread, Good Luck there!

Sorry to beep you rudely CoriBoom™.

Sincerely,

-- Raymond

-- Edit --

Frankly, i thought replace the RKT1 with a invisible (extreme tiny) model is more appropriate in this case, since i'm just afraid that by replacing it with zero would result in a brown box(prop box) if the model cannot be found, Anyway, Just be careful.

[BartonThinks 3,416]

EDIT: Please disregard the advice in this post about using blank models instead of null keys. As @rsc204 has explained below, my advice was based off of a misunderstanding of how models function in-game. It is perfectly safe to use null keys, as @Raymond7cn suggested.

 

This is something that I do a lot on my own lots, and the technique recommended by Raymond should work well.

However, I would strongly recommend against using all zeros for the resource key values, for the reasons that Raymond mentioned in his most recent post. Instead, I would suggest using a blank model. To do that, you can replace the "Resource Key Type 0" or "Resource Key Type 1" value of a prop with the following value:

0x5AD0E817,0xBADB57F1,0x0E110000

That's the blank model that Maxis uses for invisible buildings, so it's included already in the game.

So, basically the steps you would take would be:

1. Open SimCity_1.dat in Reader
2. Find the exemplar for the prop that you want to make invisible
3. Create a patch containing a copy of that prop exemplar
4. Open up the patch DAT in Reader and open the exemplar file
5. Find the property labeled "Resource Key Type 0" or "Resource Key Type 1"
6. Replace the value of this property with the TGI for the blank model
7. Save the patch and keep the patch DAT in your plugins folder

As Raymond mentioned, fiddling around with Resource Key values can trigger prop pox and other serious problems if you're not careful. So a couple of quick points you'll want to keep in mind:

• If you use the above technique, you can make props invisible in an existing city. However, if you make a mistake, you could end up corrupting the city and causing a bunch of unwanted problems. Generally speaking, I would be very careful about using this technique on existing cities, and I would make a backup of any city before trying this out.
• DO NOT use this technique on props that use a different type of resource key, such as Resource Key Type 4 (RTK4). If you follow the steps listed above on an RTK4 prop, you will trigger prop pox in your cities. There's a way to make RTK4 props invisible using blank models, but you need to take additional steps when you edit the resource key. (You need to make sure the RTK4 value retains the same length and structure.)

Finally, if you're editing Maxis prop exemplars, make sure (a) that you create a patch and (b) that you only edit the patch. Do not edit the original SimCity_1.dat file -- that's a recipe for disaster.

Edit: In case you're unsure how to find the prop files you need, there are four Maxis props for apple trees and orange trees. Here's the exemplar information for each of these props.

[Raymond7cn 6,773]

@BartonThinks Thank you so much Barton! Yes you are one of the best Lotter who be able to give such much more coherent explanation for this issue, i breathed a sigh of relief after reading you post,  @smurfN please forgive me lack of experience, i believe Barton's method  (blank model) is the best and decent approach, Thank you again, Barton!

Sincerely,

-- Raymond

[smurfN 26]

Thanks @BartonThinks for your throughout explanation, much appreciated 

 

@Raymond7cn No problem, we live and we learn

[rsc204 21,836]

On 23/10/2020 at 3:58 AM, BartonThinks said:

However, I would strongly recommend against using all zeros for the resource key values, for the reasons that Raymond mentioned in his most recent post. Instead, I would suggest using a blank model. To do that, you can replace the "Resource Key Type 0" or "Resource Key Type 1" value of a prop with the following value:

0x5AD0E817,0xBADB57F1,0x0E110000

That's the blank model that Maxis uses for invisible buildings, so it's included already in the game.

Using all 0's, otherwise known as a Null Key, is a perfectly safe and valid practise that has been well used, including by Maxis themselves, who presumably coded this to be a thing. Every single timed prop, relies on calling a Null Key for those situations, where a given prop should not be visible. Of course functionally it's very similar to using a blank model, with one big difference, no actual model or verts get placed, which means other models won't need to avoid its space. Just because you don't see anything, doesn't mean there is nothing actually there (blank model). The big drawback to using a blank model, is that your lot now needs a dependency, of course not a problem if you use one of the two blank models Maxis provided with the game, such as the example you give. Quite a few high-profile modders fell into the trap of using one Blank model for every Exemplar, which is not only totally redundant data. But, where as happened these dependencies were neither listed, nor included, it led to many problems.

A null key is both the most convenient approach, with zero drawbacks and as such, for me is the recommended solution. Not to mention remembering 0x0,0x0,0x0, all you need type for 0x00000000,0x00000000,0x00000000, is a darn sight easier too.

On 23/10/2020 at 3:58 AM, BartonThinks said:

As Raymond mentioned, fiddling around with Resource Key values can trigger prop pox and other serious problems if you're not careful. So a couple of quick points you'll want to keep in mind:

• If you use the above technique, you can make props invisible in an existing city. However, if you make a mistake, you could end up corrupting the city and causing a bunch of unwanted problems. Generally speaking, I would be very careful about using this technique on existing cities, and I would make a backup of any city before trying this out.
• DO NOT use this technique on props that use a different type of resource key, such as Resource Key Type 4 (RTK4). If you follow the steps listed above on an RTK4 prop, you will trigger prop pox in your cities. There's a way to make RTK4 props invisible using blank models, but you need to take additional steps when you edit the resource key. (You need to make sure the RTK4 value retains the same length and structure.)

It's really only the very specific change from an RKT1 to an RKT4 exemplar that has ever been associated with Prop Pox. In other words turning an item from non-timed (or seasonal) to a timed prop, but only when overriding existing items. It's totally safe to do this, provided the new object is given a unique ID.

Making backups is generally considered a good idea, but provided you are only changing the RKT ID and NOT the RKT type, there really is very little chance of problems here. Worst case scenario if your override breaks something, remove it and everything should go back to normal. It helps that these links (where the Exemplar IDs have not changed), are dynamic, i.e. if you change the exemplar to point at another model, it would not need to be re-plopped or grown for that change to appear. In other words, whatever might go wrong, will quickly return to normal after removing the files causing problems. To be absolutely clear, this only applies if you change only the RKT ID, other properties being changed may not work like this.

As stated, don't edit anything directly in SimCity_1.dat, always a golden rule, but use a copied exemplar to override the original. Another good rule to follow when trying out new self-made mods is to avoid saving your city or better still, do such testing in a blank new city, kept specifically for the purpose of testing things, i.e. a throwaway tile you don't care about.

It's totally possible to make an RKT4 item invisible, if you aren't clear on them, the specific properties such items use are detailed in this post (SC4D). Each 'state' of an RKT4 prop has 8 Reps, the last three of which are the TGI ID of the model being linked to. So if a timed prop was set as Normal (Rep 1 = 0x0), then had one or more Special states (Rep 1 = 0x01), you could just use a null key for the last 3 Reps of every state, then nothing would ever appear in-game. Of course this is all rather illogical for most purposes, if we don't want to see something, you wouldn't set things up this way. Specifically in the case of overriding things you didn't want to appear, you can alter the relevant exemplars in this manner. But even then, if you really don't want to see such things, usually you just would uninstall the mod in question, it would be a very niche scenario indeed where doing this made any sense.

[BartonThinks 3,416]

9 hours ago, rsc204 said:

Using all 0's, otherwise known as a Null Key, is a perfectly safe and valid practise that has been well used, including by Maxis themselves, who presumably coded this to be a thing. Every single timed prop, relies on calling a Null Key for those situations, where a given prop should not be visible. Of course functionally it's very similar to using a blank model, with one big difference, no actual model or verts get placed, which means other models won't need to avoid its space. Just because you don't see anything, doesn't mean there is nothing actually there (blank model). The big drawback to using a blank model, is that your lot now needs a dependency, of course not a problem if you use one of the two blank models Maxis provided with the game, such as the example you give. Quite a few high-profile modders fell into the trap of using one Blank model for every Exemplar, which is not only totally redundant data. But, where as happened these dependencies were neither listed, nor included, it led to many problems.

A null key is both the most convenient approach, with zero drawbacks and as such, for me is the recommended solution. Not to mention remembering 0x0,0x0,0x0, all you need type for 0x00000000,0x00000000,0x00000000, is a darn sight easier too.

It's really only the very specific change from an RKT1 to an RKT4 exemplar that has ever been associated with Prop Pox. In other words turning an item from non-timed (or seasonal) to a timed prop, but only when overriding existing items. It's totally safe to do this, provided the new object is given a unique ID.

Making backups is generally considered a good idea, but provided you are only changing the RKT ID and NOT the RKT type, there really is very little chance of problems here. Worst case scenario if your override breaks something, remove it and everything should go back to normal. It helps that these links (where the Exemplar IDs have not changed), are dynamic, i.e. if you change the exemplar to point at another model, it would not need to be re-plopped or grown for that change to appear. In other words, whatever might go wrong, will quickly return to normal after removing the files causing problems. To be absolutely clear, this only applies if you change only the RKT ID, other properties being changed may not work like this.

As stated, don't edit anything directly in SimCity_1.dat, always a golden rule, but use a copied exemplar to override the original. Another good rule to follow when trying out new self-made mods is to avoid saving your city or better still, do such testing in a blank new city, kept specifically for the purpose of testing things, i.e. a throwaway tile you don't care about.

It's totally possible to make an RKT4 item invisible, if you aren't clear on them, the specific properties such items use are detailed in this post (SC4D). Each 'state' of an RKT4 prop has 8 Reps, the last three of which are the TGI ID of the model being linked to. So if a timed prop was set as Normal (Rep 1 = 0x0), then had one or more Special states (Rep 1 = 0x01), you could just use a null key for the last 3 Reps of every state, then nothing would ever appear in-game. Of course this is all rather illogical for most purposes, if we don't want to see something, you wouldn't set things up this way. Specifically in the case of overriding things you didn't want to appear, you can alter the relevant exemplars in this manner. But even then, if you really don't want to see such things, usually you just would uninstall the mod in question, it would be a very niche scenario indeed where doing this made any sense.

The reason I recommend using a blank model rather than a null key is because using a null key is irreversible -- that is, once you've used a null key, you cannot bring the props back or switch to new props. Using a blank model allows you to keep an invisible placeholder where the prop used to be, so if you want to bring the original model back or use a new model in the future, you're okay to do so.

Part of the reason I recommend caution with these is that I've run into some really weird bugs and behaviors with the game when editing props in this manner. One of the most common issues I've run into is that, when a lot tries to grow with a corrupted prop file, other props stop generating completely. The issue in this case isn't prop pox -- I've had this happen with new city tiles when I've tested props -- but once the problem occurs, it can be a nightmare getting rid of the issue.

That said, I believe I made a mistake when I said that applying the blank model TGI (three reps) to an RTK4 prop (eight or more reps) would trigger prop pox. I misremembered part of simmaster07's explanation of how prop pox works, and thought that the issue would be triggered by messing up the number of RTK4 reps when overriding a prop.

[rsc204 21,836]

On 29/10/2020 at 1:36 AM, BartonThinks said:

The reason I recommend using a blank model rather than a null key is because using a null key is irreversible -- that is, once you've used a null key, you cannot bring the props back or switch to new props. Using a blank model allows you to keep an invisible placeholder where the prop used to be, so if you want to bring the original model back or use a new model in the future, you're okay to do so.

Where are you getting this information from, because that simply doesn't fit with how the game works. As I mentioned before, we have both Static and Non-Static Properties in SC4 files and the RKT IDs represent Non-Static 'linked' data. In other words, anything Non-Static will be dynamically refreshed upon re-loading the game, in the case of your example, removing an override to a Maxis Prop for example, which had used a null-key, will revert to showing the linked model of it's original Exemplar. On the flip-side, let's take a Static Property, for example the radius of a police station. If you mod this with existing version of the object already saved in a city, it causes problems, in this case the 'Slider Bug'. The key difference being, Static data is stored in the save file when an object is placed or appears, it will only refresh any such data if you remove the object before loading the mod. Whereas Non-Static Properties are simply linked, so in the case of a Prop Exemplar, it's only the link to the Exemplar that's in the save data. This means when the object needs to be loaded, the game will read whatever the current RKT ID is, even if it's changed, then show the linked model.

I even tested this myself, to be 100% sure of the facts and indeed what you state here is simply not correct. I've attached an override for the Maxis Small Police Station, which when installed overrides the main building on this lot, using a Null Key. Anyone can add this to their Plugins folder, load the game and see any previously placed Small Police Stations have the main building missing. 

You can, if you want to test this for yourself, safely save the city with this override installed, then confirm how they automatically return once the override is removed.

zSmallPolice_NoBuilding_NullKey.dat

On 29/10/2020 at 1:36 AM, BartonThinks said:

Part of the reason I recommend caution with these is that I've run into some really weird bugs and behaviors with the game when editing props in this manner. One of the most common issues I've run into is that, when a lot tries to grow with a corrupted prop file, other props stop generating completely. The issue in this case isn't prop pox -- I've had this happen with new city tiles when I've tested props -- but once the problem occurs, it can be a nightmare getting rid of the issue.

This suggests that something is perhaps very wrong with the modding of those items. As described above, if you only change the RKT IDs, I simply can not explain what is going on. It sounds more like you are editing the links to the Exemplars themselves, from within the LotConfig Exemplar?

One of the easiest ways to break a LotConfig Exemplar, is to manually edit the Props on it, honestly if looking through the Hex doesn't click with you, stick with PIM-X or other more user friendly tools. You should only ever edit the last Rep* of a 0x01 entry, this is the IID of the linked Prop Exemplar. Never mess with the preceding Rep, it is NOT the GID of the linked Prop Exemplar, nor a value that you can edit freely. The same applies to 0x00 entries too (Buildings). Also, never forget you MUST right click the Exemplar pane in Reader and select "Reindex LotConfig" whenever you edit any LotConfigPropertyLotObject lines. If the Index is not correct, it can cause all sorts of problems, but usually prevents the lot from appearing/working altogether.

If you can give us a run down of your process for creating these Props, we should be able to see what is behind the issues?

Creating new Props is super-easy to do, start by finding a good template for your purposes, usually that's best found in SimCity_1.dat from a similar type of Prop. Remove all Properties you don't need to adjust and set any Defaults too. Then just copy/paste this Exemplar when you need a new Prop, making sure you give it a random new ID (right click, Generate New Group and Instance). Just make sure you thoroughly test the template before using it en-masse and you literally can't run into these problems. But from my experience, you simply must be making some error or copying one for things to be going wrong in such a manner.

*Obviously you can correctly mod all the Reps, if you fully understand how they work and can give the correct data. But it's usually safe to alter the last Rep since it will just change the linked Exemplar.

On 29/10/2020 at 1:36 AM, BartonThinks said:

I misremembered part of simmaster07's explanation of how prop pox works, and thought that the issue would be triggered by messing up the number of RTK4 reps when overriding a prop.

The issue is very complicated, but also incredibly specific too. If you override an RKT1 prop, with an RKT4 prop, only possible because this data is Non-Dynamic, that's where problems can arise. The game's save data, like all computer code, has to follow some pre-set defaults, this is all connected to something known as an array of data. Say you make toasters, you need a box to package them into, you know your toaster will fit in a 30x15cm box, so that's the size you order. In the same way, most stored data is given a data array which defines how much data can be stored. Like when a website asks for your phone number, it may define how this data can be entered, for example not allowing letters or restricting the number of digits in each field. If data is entered into the save file as a linked RKT1 value, it needs to hold 3 reps of 8 digits of data, i.e. the TGI ID. But, RKT4 props, always contain more than 3 reps of data, 8 being the minimum, but it could be much larger.

This is where overriding RKT1 Props with RKT4 Props becomes a problem, since it causes the data to be Out of Bounds, as the original space allocated for the data isn't large enough. However, this doesn't immediately cause Prop Pox, it merely creates the conditions for it to happen. Like all well-written code, or perhaps just by luck, despite the data being where it shouldn't, the save files still function as normal, it doesn't cause any harm. For that to happen, a specific set of data known as the Network Subfile, needs to undergo compression at some point. This only happens if the amount of data exceeds a certain limit, at which point the game needs to use compression to continue expanding this data. Only when this happens, does this data in the wrong place become a problem. Because the compression re-orders the data, but the data in the wrong place get's "mixed" into the other data. This corrupts the data, but gets worse with every subsequent save, as it truncates the data to the expected data array size. This is what SC4Fix handles, it modifies the save files such as to re-jig the data, so this bug can't get triggered. In theory it's so good, we can deliberately make mods that override RKT1 data with RKT4 data, provided users have SC4Fix installed, they will not suffer Prop Pox. Think about being able to override RKT1 (non seasonal) to RKT4 (seasonal) Trees, because not being able to do so adds so much work if you want consistent Seasonal Trees right now.

Now if all this is as others have documented, it may or may not follow that changing an RKT4 to RKT1 prop would cause problems. I really don't think anyone ever bothered to test this, it's a very niche thing that I can't imagine many would care to do. Changing between RKT 0/1/2/3 should not be an issue, since the data array of 3x8, is still valid for all these RKT formats. Again though, these situations are so niche, I don't think I can even provide examples of them.

[BartonThinks 3,416]

@rsc204

You're right. I went ahead and tested your mod of the police station and then went back and made a couple of tests on my own using RTK1 and RTK4 props. Switching the models to a null key instead of a blank model didn't cause any issues.

A (feeble) attempt at explaining myself: I originally tested this out several months ago when I was still new to Reader and exemplar modding. During those tests, I tried to make props disappear and reappear by switching back and forth between the prop models and null keys. When I tried this, I repeatedly ran into issues. I then switched to using blank models, and the problem disappeared. At the time, I was confident that I'd run those tests using similar files. In hindsight, there must have been a serious error with the null key prop files that I didn't notice and/or understand.

I've been using this technique constantly over the past six or so months, and since the blank models have worked perfectly, I never thought to go back and run a new set of tests once I had a better handle on the Reader. It seems a bit foolish in retrospect that I trusted that initial set of tests.

Obviously, whatever issues I was having with the props in the early days was unrelated to using null keys. I suspect that I made a few different errors at that time. One that I know caused serious problems was making props that contained the "Item Name" property, but did not contain the "User Visible Name Key" property (which should be set to a null key for the "Item Name" property to work). This mistake caused a couple of serious issues: 1) the props that contained this mistake would not load, 2) once these props were introduced to a city tile, other props would start to disappear when saving and reopening city tiles. (Note: these were new cities, so this was different behavior from prop pox.)

I'm not sure if some of this behavior was caused by other errors in the prop files when I was running initial tests. However, I did run a series of tests containing two identical sets of props--one of which contained the "User Visible Name Key" property, and another which did not. When the UVNK property was included, all of the props worked fine. When it was missing, the props would not load properly.

At this point, it's been months since I've had any issues with props, but it looks like my understanding of how some of these properties function is a little spottier than I thought.

I appreciate the clarification, and it's very helpful to know that I was wrong about whether a null key would work in this instance.

On a marginally related note: You mentioned that changing an RTK4 prop to an RTK1 prop would have niche uses, but one side project I've toyed with is making prop overrides for seasonal flora props that convert the props to evergreen flora. Unless I'm mistaken, this could be easily done if you converted the summer prop exemplars to RTK1 props and then switched the resource keys for the spring/fall/winter prop exemplars to null keys or blank models. There are a couple of other workarounds that would work if you can't switch from RTK4 to RTK1, but given the strong preferences some players have for evergreen flora and the widespread use of seasonal props, I figured there might be demand for something like this.

[rsc204 21,836]

1 hour ago, BartonThinks said:

One that I know caused serious problems was making props that contained the "Item Name" property, but did not contain the "User Visible Name Key" property (which should be set to a null key for the "Item Name" property to work). This mistake caused a couple of serious issues:

Actually if you plan to use the Item Name property, you can simply delete the UVNK property, which is actually the best thing to do. You will find many Properties to be superfluous depending on your needs.

1 hour ago, BartonThinks said:

I'm not sure if some of this behavior was caused by other errors in the prop files when I was running initial tests. However, I did run a series of tests containing two identical sets of props--one of which contained the "User Visible Name Key" property, and another which did not. When the UVNK property was included, all of the props worked fine. When it was missing, the props would not load properly.

Honestly that doesn’t sound right to me, if the UVNK exists, the game displays the linked ID’s LText file, which is mostly worthwhile if you intend to offer multiple language options. In the case of Props, I would not otherwise bother with them.

If the UVNK didn’t link to an actual LText, I suppose it would either revert to the Item Name or otherwise show nothing. But I do wonder if perhaps simply, that you can’t use Null Keys for this property, since so far as.I know, it was intended for use with Props. It may well be trying to link to it causes wired behaviour, since it’s expecting an LText file, not some model or other function.

1 hour ago, BartonThinks said:

I've been using this technique constantly over the past six or so months, and since the blank models have worked perfectly, I never thought to go back and run a new set of tests once I had a better handle on the Reader. It seems a bit foolish in retrospect that I trusted that initial set of tests.

Certainly I don’t want to give the impression that using Blank Models is bad, I do on occasion use them myself. SC4 PIM (PIM-X), uses them as part of the templates, if you select the relevant options creating an Exemplar. As you stated, if you are going to use them, at least use the Maxis ones that everyone already has. You can link many Exemplars to one object, but you only ever need one copy of the object.

I hope it’s clear I’ve no intention to embarrass anyone, I’ve made enough mistakes myself, but sometimes tracking though problems can help understand things better. Then again, so much modding can become a process of trial and error, you learn what doesn’t work the hard way. I know there are things I can just ‘see’ these days in Reader, because of my familiarity with working on things. But equally, there was a time when I couldn’t make sense of most of it, there’s so much to learn.

1 hour ago, BartonThinks said:

On a marginally related note: You mentioned that changing an RTK4 prop to an RTK1 prop would have niche uses, but one side project I've toyed with is making prop overrides for seasonal flora props that convert the props to evergreen flora. Unless I'm mistaken, this could be easily done if you converted the summer prop exemplars to RTK1 props and then switched the resource keys for the spring/fall/winter prop exemplars to null keys or blank models. There are a couple of other workarounds that would work if you can't switch from RTK4 to RTK1, but given the strong preferences some players have for evergreen flora and the widespread use of seasonal props, I figured there might be demand for something like this.

Now all I can give here is really conjecture, the manner in which the data corruption occurs comes from adding more Reps than a Prop originally had, i.e. the data is too long. So what would we expect to happen, if the original data had more Reps than needed, but due to an override, now only needs 3? It could be, that this is something the save file system could cope with. It could also be the case that a similar data corruption as Prop Pox occurs, sort of in reverse in terms of how it disorders the data. It’s probably fair to think the latter, since the code clearly can’t handle this scenario, one never envisaged by Maxis no doubt. Of course, presumably if this were the case, the changes to these functions may mean like with RKT1.- RKT4 props, the data is written such as to correct the save file if SC4Fix was being used. Or it could be the case that extra/modified code would be needed to handle this different scenario. It’s all unknowns and to my knowledge no one ever did any tests to look into the effects of this.

The safer solution is not to alter the Summer prop at all, nor the RKT type. Just give all three seasons the Summer model’s ID. It does mean the game technically changes the trees between the three seasons, although you may not notice it, since each shows the same model.

In other words, if the Flora Exemplar contains 24 Reps, it covers three seasons, that’s three groups of 8 Reps. Copy the Reps 14-16, which should be the TGI of the summer model. Note this is true only for items which are to be planted around 1st Sep in-game. Otherwise, the order of each 8-rep grouping in the RKT4 Property, follows that in game. So Flora to be planted around the 1st Mar, would be in order Spring, Summer/Autumn, Winter, but only three of the four seasons can be used, the usage varies. Use the copied summer model’s ID for the other two TGI IDs, Reps 6-8 & 22-24. I hope that makes sense to you, but if you need further clarification, just ask. This method would be totally safe to use as an override to an existing mod too.

[BartonThinks 3,416]

@rsc204

A quick clarification: When I said that the UVNK property had to be present for the files to function properly, I should have specified that I meant adding the UVNK property with a null key.

For what it's worth, I've gone back and tried to reproduce the problem without any luck. That surprised me, because unlike the null key vs. blank model tests, I originally ran multiple controlled tests for the UVNK/item name issue. At the time, I used two otherwise identical sets of props, one with the UVNK property present, the other one with the property missing, and I tested each set multiple times. I repeatedly ran into issues with the one set, and had zero issues with the other. When I tried to reproduce the problem earlier today, I ran a very limited test with only a small number of props, so I might have more luck if I ran some larger or more extensive tests. But at this point, I would simply guess that there were other problems with the files that I was too inexperienced to notice at the time. That seems the most likely explanation.

In any case, I'll need to stop relying on any of the conclusions I made when I ran those early tests. I've become a lot more familiar with the Reader in recent months, and I've helped troubleshoot a few exemplar-related issues for other users, so I've felt increasingly comfortable advising other players on these kinds of issues. But it looks like I've become a little too confident in just how well I understand some of these properties and game mechanics.

As for the seasonal-to-evergreen mod -- swapping all of the spring/fall/winter resource keys to the summer models was my original idea, but I quickly realized it would take too much time to individually convert hundreds of seasonal flora props in this way. With an RTK4 to RTK1 conversion, I figured there might be a way to script the conversion (i.e., for 8-rep RTK4s, run a script to delete reps 1-5 and then convert the RTK4 property to RTK1), which would make this a much less time-intensive project. In any case, it's not a pressing matter for me. I have other projects to prioritize, and I use seasonal flora in my own cities. So this is more of a thought experiment than anything else.

 

Edit: One thing I can confirm from trying to reproduce this problem is that the Item Name property will not function as intended if the UVNK property isn't also present. See below.