Help with Everseasonal Flora

[oathbound_hunter 10]

Good afternoon, all! First post here, it's been amazing to see just how far SC4 has come since I played it in my teenage years, even surviving the dark times of the webhost purge. Been having some difficulty with the restored Everseasonal Flora mod.

I've installed the mod through SC4PAC and though it seems like it installed but I've not seen it work in game. I've been using the Cascadia Tree Controller to test it but the god mode flora still plants as seasonal. Lots that have seasonal props, though, seem to stay to the Summer flora as intended.

I'm hoping to get it so that Cascadia will work just as a Summer tree controller as I prefer it to the others but don't like how it stutters when trees shift over. Aerden is a good second best, but I love the mix of pine and deciduous trees Cascadia gives. Is Everseasonal Flora only meant for props on lots, or should it also affect god mode trees. If the latter, is there anything else other than installing it through SC4PAC I need to do to adjust the tree controller or mod files to use the Summer-only flora that EF designates?

[nos.17 5,215]

Hello, I'm not a user of the Everseasonal Flora myself, but my understanding from the description is this does not affect tree controllers - just flora and props from the packages listed. So, my reading is it would never work with god mode flora, and would only work with the mayor mode MMPs (and the one tree controller) listed. If you're using the Cascadia supplied MMPs to plant the flora I believe those would not be included in the Everseasonal Flora, unfortunately.

To make it work with Cascadia, you'd need to add your own patch. I took a look at what smf did, and in the grand scheme of things it's not super complicated - for each of the flora items/MMPs, there's a small patch that replaces the IID (unique identifier) of the seasonal flora item with the single season item. I could help walk you through that if you're interested.

[oathbound_hunter 10]

 

21 hours ago, nos.17 said:

Hello, I'm not a user of the Everseasonal Flora myself, but my understanding from the description is this does not affect tree controllers - just flora and props from the packages listed. So, my reading is it would never work with god mode flora, and would only work with the mayor mode MMPs (and the one tree controller) listed. If you're using the Cascadia supplied MMPs to plant the flora I believe those would not be included in the Everseasonal Flora, unfortunately.

To make it work with Cascadia, you'd need to add your own patch. I took a look at what smf did, and in the grand scheme of things it's not super complicated - for each of the flora items/MMPs, there's a small patch that replaces the IID (unique identifier) of the seasonal flora item with the single season item. I could help walk you through that if you're interested.

I wouldn't mind the assist. Looking through 11241036's Making and Editing a Tree Controller tutorial, if I'm otherwise fine with how the controller works I imagine it'd be a matter of creating a patch that changes the Exemplar IDs to only use the Summer flora items? Or do you mean a patch in EF itself?

[Dead_End 1,625]

On 6/29/2026 at 6:37 PM, oathbound_hunter said:

Good afternoon, all! First post here, it's been amazing to see just how far SC4 has come since I played it in my teenage years, even surviving the dark times of the webhost purge. Been having some difficulty with the restored Everseasonal Flora mod.

I've installed the mod through SC4PAC and though it seems like it installed but I've not seen it work in game. I've been using the Cascadia Tree Controller to test it but the god mode flora still plants as seasonal. Lots that have seasonal props, though, seem to stay to the Summer flora as intended.

I'm hoping to get it so that Cascadia will work just as a Summer tree controller as I prefer it to the others but don't like how it stutters when trees shift over. Aerden is a good second best, but I love the mix of pine and deciduous trees Cascadia gives. Is Everseasonal Flora only meant for props on lots, or should it also affect god mode trees. If the latter, is there anything else other than installing it through SC4PAC I need to do to adjust the tree controller or mod files to use the Summer-only flora that EF designates?

No advice to offer on the matter, but following this out of interest. Using the seasonal variant of Aerden, but mostly because of the pretty autumn colours. Would love a permanent version of that.

[nos.17 5,215]

16 hours ago, oathbound_hunter said:

I wouldn't mind the assist. Looking through 11241036's Making and Editing a Tree Controller tutorial, if I'm otherwise fine with how the controller works I imagine it'd be a matter of creating a patch that changes the Exemplar IDs to only use the Summer flora items? Or do you mean a patch in EF itself?

For now it would just be a patch for yourself, though if you wanted to reach out to @smf_16 to get the EF itself updated, I think he would be willing to include that.

What is your familiarity with SC4 modding with iLive's Reader? The first thing I would do is open up an existing EF dat file and look at it's contents. You'll basically want to follow the same pattern for the Cascadia flora. For each flora item, you will need one Cohort file that contains:

1. Property 0x0062e78a (Exemplar Patch Targets). This is the list of exemplar files this patch applies to. So, you'll want to grab the Group Id and Instance Id of the Cascadia flora exemplar, and include them here. Note that in the Reader, this may show up titled "Unknown" - update the new_properties.xml file from here to include the definitions of the newer exemplar properties.
2. Property 0x27812824 (RKT4). This is the model definition. You can find an explanation of what each of the values mean here. Basically this is listing all of the models that this flora item should use. If you look at a flora item in Cascadia, you will see it's RKT4 lists multiple different models, one for each season. The RKT4 exemplar in the EF mod follows the same pattern, but instead of showing different models, it lists the same model multiple times (which has the intended result of showing the same model year-round). So, find the TGI of the model you want (winter or spring or summer or fall), copy paste the RKT values from Cascadia, and update the TGI to point to just the model you want. Hopefully that makes sense. As an example, this is from 11241036's tree controller, but you can see what has changed:
   • Original flora: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0x7DD101DA, 0x00030000, 0x00000001, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0x3DAC2AE2, 0x00030000, 0x00000002, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0xFD06549F, 0x00030000
   • EF patch file: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0xFD06549F, 0x00030000, 0x00000001, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0xFD06549F, 0x00030000 0x00000002, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0xFD06549F, 0x00030000

[oathbound_hunter 10]

4 hours ago, nos.17 said:

For now it would just be a patch for yourself, though if you wanted to reach out to @smf_16 to get the EF itself updated, I think he would be willing to include that.

What is your familiarity with SC4 modding with iLive's Reader? The first thing I would do is open up an existing EF dat file and look at it's contents. You'll basically want to follow the same pattern for the Cascadia flora. For each flora item, you will need one Cohort file that contains:

1. Property 0x0062e78a (Exemplar Patch Targets). This is the list of exemplar files this patch applies to. So, you'll want to grab the Group Id and Instance Id of the Cascadia flora exemplar, and include them here. Note that in the Reader, this may show up titled "Unknown" - update the new_properties.xml file from here to include the definitions of the newer exemplar properties.
2. Property 0x27812824 (RKT4). This is the model definition. You can find an explanation of what each of the values mean here. Basically this is listing all of the models that this flora item should use. If you look at a flora item in Cascadia, you will see it's RKT4 lists multiple different models, one for each season. The RKT4 exemplar in the EF mod follows the same pattern, but instead of showing different models, it lists the same model multiple times (which has the intended result of showing the same model year-round). So, find the TGI of the model you want (winter or spring or summer or fall), copy paste the RKT values from Cascadia, and update the TGI to point to just the model you want. Hopefully that makes sense. As an example, this is from 11241036's tree controller, but you can see what has changed:
   • Original flora: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0x7DD101DA, 0x00030000, 0x00000001, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0x3DAC2AE2, 0x00030000, 0x00000002, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0xFD06549F, 0x00030000
   • EF patch file: 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0xFD06549F, 0x00030000, 0x00000001, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0xFD06549F, 0x00030000 0x00000002, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0xFD06549F, 0x00030000

This seems relatively simple, if a bit tedious. Then again, editing a tree controller: seems like it comes with the territory. To summarize for my benefit, though:

1. In the new patch, create a Cohort file for every Cascadia flora exemplar with an RKT4 property,
2. Grab the Group ID and Instance ID for each exemplar and add them to the Cohort file under the Exemplar Patch Targets property
3. Find the TGI of the model of tree I want to use, copy-paste the RKT values from Cascadia into the RKT4 property, and update the TGI to point to just that model

Looking at the example given, it looks like the third Instance ID, FD06549F, is pointing to the Summer model. Given how TCs work, would it be fair to assume that, unless the TC explicitly has special models for Spring or for Snow (such as some evergreen trees), the third Instance will always point to the Summer model and can be used to replace the other two?

[rsc204 21,857]

To really do it properly involves altering all those timed RKT4 values to non-timed RKT1 values and properly converting the mod to a non-seasonal one. The problem with that is that in order to do this, you must remove all god mode flora planted with the existing tree controller or face potential problems. So if you have not been using Cascadia previously or only intend to use your altered version in a new region, all will be fine.

• Original flora (RKT4): 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0x7DD101DA, 0x00030000, 0x00000001, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0x3DAC2AE2, 0x00030000, 0x00000002, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0xFD06549F, 0x00030000
  Becomes
• RKT1 (you have to change the Property Type): 0x5AD0E817, 0xFD06549F, 0x00030000

Essentially you just keep the final three values or Reps, because you no longer need to define three separate models or other data on how and when to display them.

5 hours ago, nos.17 said:

For now it would just be a patch for yourself, though if you wanted to reach out to @smf_16 to get the EF itself updated, I think he would be willing to include that.

The problem with this method is that you are still switching between 3 models, likely even though they won't appear to change, this will still trigger the stuttering, because the game in that moment has a lot of work to do. The only difference is now each model is the summer one, rather than a unique seasonal variant.

So again, if you really want to convert a Seasonal Mod into a non-Seasonal one, it is much better to actually do that, than continue to use a seasonal mod but force it to show Summer trees in every season.

If you wanted an even easier method, you could simply make two copies of the Summer tree textures (FSH). Alter the IDs of one to the Autumn ID for the same tree, then likewise for the Winter variant for the second copy. Now, instead of altering all the 'links' so they end up with the same Summer tree, what you've done is alter the Models directly. This means, regardless of where Seasonal versions of them were used, every instance of those trees would now always show the Summer version. But of course, there is once again the drawback that you are still technically running seasons, when you don't need or (trust me on this), want to be.

[rsc204 21,857]

47 minutes ago, oathbound_hunter said:

Given how TCs work, would it be fair to assume that, unless the TC explicitly has special models for Spring or for Snow (such as some evergreen trees), the third Instance will always point to the Summer model and can be used to replace the other two?

So it's more how Flora and Seasonal Timings work.

The data you see in the RKT4 property, is formatted as groups of 8 Reps of data, each is for one single model. For complex reasons, the order has to be Autumn, Winter, Summer for seasonal trees to work. You can not use more than 3 seasons with Flora, and the timings are sort of preset too. Hence, you can be fairly certain that regardless of what seasons were used, it's the final ID that will be the summer one.

[oathbound_hunter 10]

2 hours ago, rsc204 said:

To really do it properly involves altering all those timed RKT4 values to non-timed RKT1 values and properly converting the mod to a non-seasonal one. The problem with that is that in order to do this, you must remove all god mode flora planted with the existing tree controller or face potential problems. So if you have not been using Cascadia previously or only intend to use your altered version in a new region, all will be fine.

• Original flora (RKT4): 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0x7DD101DA, 0x00030000, 0x00000001, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0x3DAC2AE2, 0x00030000, 0x00000002, 0x00000000, 0x00000000, 0x00000000, 0x27812821, 0x5AD0E817, 0xFD06549F, 0x00030000
  Becomes
• RKT1 (you have to change the Property Type): 0x5AD0E817, 0xFD06549F, 0x00030000

Essentially you just keep the final three values or Reps, because you no longer need to define three separate models or other data on how and when to display them.

The problem with this method is that you are still switching between 3 models, likely even though they won't appear to change, this will still trigger the stuttering, because the game in that moment has a lot of work to do. The only difference is now each model is the summer one, rather than a unique seasonal variant.

So again, if you really want to convert a Seasonal Mod into a non-Seasonal one, it is much better to actually do that, than continue to use a seasonal mod but force it to show Summer trees in every season.

If you wanted an even easier method, you could simply make two copies of the Summer tree textures (FSH). Alter the IDs of one to the Autumn ID for the same tree, then likewise for the Winter variant for the second copy. Now, instead of altering all the 'links' so they end up with the same Summer tree, what you've done is alter the Models directly. This means, regardless of where Seasonal versions of them were used, every instance of those trees would now always show the Summer version. But of course, there is once again the drawback that you are still technically running seasons, when you don't need or (trust me on this), want to be.

Thankfully I don't have a region yet built up: I'm the sort that likes to get all my mod ducks in a row before I get started properly and the Tree Controllers have always been the bugbear. From what it seems like, then, all one would have to do (well... "all",  that's a considerable amount of data to alter in any given controller) is convert an RKT4 to an RKT1 and have it refer to the desired model?

Thinking about this from the perspective of something like SC4PAC, would one be able to follow this same method for fall or winter models and switch them at will by simply swapping to the requisite controller? Or would that break things like swapping between two entirely different controllers? In other words: would switching between a theoretical Cascadia_Summer and Cascadia_Fall break the flora in the same way that switching between Cascadia and Aerden would?

[rsc204 21,857]

11 hours ago, oathbound_hunter said:

From what it seems like, then, all one would have to do (well... "all", that's a considerable amount of data to alter in any given controller) is convert an RKT4 to an RKT1 and have it refer to the desired model?

Yeah essentially, with the added bonus that you don't need to find the new data to enter, simply retain the right part of the previous data and you are good to go.

11 hours ago, oathbound_hunter said:

Thinking about this from the perspective of something like SC4PAC, would one be able to follow this same method for fall or winter models and switch them at will by simply swapping to the requisite controller? Or would that break things like swapping between two entirely different controllers?

Well this gets a bit more complicated, honestly I am a bit muddled why it makes sense to de-construct a Seasonal mod, only to then retain Seasonality. I mean if that's what you want, it's a hell of a lot of effort to make the process of switching seasons manually. But the process is straightforward enough, start with your fully working Summer set, make a copy of that file for each additional season you want. Note that in this scenario, you could now have more than 3 Seasons, since it's no longer relying on the Flora mechanism to change them. Now just alter the RKT1 values to point to the Autumn, Winter or whatever model instead of the Summer ones, the only tricky part is knowing which IDs you need.

What causes switching tree controllers to be a problem is one of two things, a scenario where a Flora Exemplar (a tree placed using the controller), no longer exists in Plugins. The other would be where two Flora Exemplars conflicted with each other, for example both trying to do the same thing. You don't need to worry about the later in this case, and the former is also not an issue, provided you keep the same IDs for the Exemplars and each Season contained all of them. Done that way it is totally safe to switch between them at will, since all the same Exemplars with the same IDs exist, they just point to different trees.

[CorinaMarie 29,856]

9 minutes ago, rsc204 said:

I am a bit muddled why it makes sense to de-construct a Seasonal mod, only to then retain Seasonality.

Oh, my! I'm avidly following along and it's this sort of thing which could convince me to dip my toes into seasonal trees.  

When I play, I run time on the middle speed and it annoys me to have the seasons chaining every few minutes.  But if I can change what I'll see before starting up the game, I can now (perhaps) play all of real August with Summer Foliage, but come October I could switch over to Autumn, and ofc, in a another few months move on to Winter.  

[rsc204 21,857]

I get that having switchable trees does prevent the moments of lag. However if you intend to really use seasons, having to restart the game is surely more annoying? I guess everyone has different ideas and ways of playing. But I think this makes most sense if you just wanted control for screenshotting. But the rest of the time, ignored seasonal trees. Certainly you don’t have to synchronise a season with any particular date anymore. At least for the tree controller.

To cover MMPs and Lots (Props) is another matter altogether though. Since the instances (Exemplars) used for a tree controller are unique to it. 

[oathbound_hunter 10]

7 minutes ago, rsc204 said:

I get that having switchable trees does prevent the moments of lag. However if you intend to really use seasons, having to restart the game is surely more annoying? I guess everyone has different ideas and ways of playing. But I think this makes most sense if you just wanted control for screenshotting. But the rest of the time, ignored seasonal trees. Certainly you don’t have to synchronise a season with any particular date anymore. At least for the tree controller.

To cover MMPs and Lots (Props) is another matter altogether though. Since the instances (Exemplars) used for a tree controller are unique to it. 

I was actually about to respond more or less with this lol

That's more or less why I started off with this thread being about Everseasonal Flora: I agree with smf's philosophy on EF, that the only time I ever really have a need for seasonal trees is if I'm looking to make screenshots of a city in the fall or winter. Preventing the moments of lag is the other big benefit for me, as (though it's silly) even that tiny bit of lag is very distracting to me when playing the game as I don't tend to plop unless absolutely necessary.

[oathbound_hunter 10]

As an update on this (though at this point it's not really about EF anymore), from rsc's pointers I've managed to get Cascadia to only plant in the Summer flora! That's the good news...

The bad news is it still hitches at every season change as if the flora were still seasonal. Altering FloraParameters such that the first value (to my understanding, the parameter that governs how long a season is) is set to zero yielded some results in that it will hitch hard (like at a season change) at the start of the next month after planting god mode flora, but then after that it runs smoothly for seven months before you get another small hitch then and at ever seventh month thereafter. Altering the third value to be zero doesn't fix the hitch on the first month and makes the game hitch on every month as if it were growing flora using the Maxis TC.

At this point, I'm not quite sure where else I could go from here to solve the hitching, if it's even something that's doable given current knowledge of the game system. Unless I might be missing something obvious. I have a couple other ideas I'm going to play with, but for now this is where my experimentation stands.

[CorinaMarie 29,856]

3 hours ago, oathbound_hunter said:

I've managed to get Cascadia to only plant in the Summer flora!

Which method did you use? Changing all RKT4s to RKT1s? My understanding is that's the preferred method and then it's not seasonal at all so there shouldn't be any hitch. (Then for later manual change you'd make a copy of all fall trees and give each one the corresponding summer IID along with a separate set for winter.)

[rsc204 21,857]

Absolutely there is no requirement for this stuttering, it does suggest some timed element remains.

I have not personally created a tree controller, it’s a very complicated beast. Hence converting an existing controller is the way to go.

If you have converted everything to RKT1, then somewhere other properties must be in play. The best resource for trying to understand that is the how to make a tree controller tutorial. As far as I can tell, the only other property pertaining to seasonal trees seem to be the FloraParameters property, reps 1, 6 & 7. If there were some special values that trigger seasonal changes, then I’d find the equivalent values used in an existing non-seasonal controller and use them instead. However, that isn't as simple as it first seems, here's a snapshot of these properties from CP's Meadowshire River Tree Controller, which is not seasonal:

As you can see, there do appear to be patterns for the Rep 1, 6&7, but they are not clear patterns. So if these values are supposed to be connected to seasonal timing, why would they be so different.

For example, all but one of the 1st Item in a brush are using 3.2, 2, 3, however this is not the case for all. Making me question why these values would be so different if all they did was define the length an item was used for, wouldn't the values be more similar?

At this point you could use the values from another controller as reference, but its not clear which numbers would be right or how you work out which to use?

As such, do absolutely check you've not left any RKT4 properties behind, my understanding was this was the mechanism that made the controller use Seasons, the values of FloraParameters shouldn't matter if these are not Timed/Seasonal Flora.

[oathbound_hunter 10]

8 hours ago, CorinaMarie said:

Which method did you use? Changing all RKT4s to RKT1s? My understanding is that's the preferred method and then it's not seasonal at all so there shouldn't be any hitch. (Then for later manual change you'd make a copy of all fall trees and give each one the corresponding summer IID along with a separate set for winter.)

That was the method, yeah. Converting RKT4s to RKT1s does successfully force all god mode flora to render as your chosen season, but from what I can figure they still act as seasonal flora, they just redraw using the only available model.

[oathbound_hunter 10]

8 hours ago, rsc204 said:

Absolutely there is no requirement for this stuttering, it does suggest some timed element remains.

I have not personally created a tree controller, it’s a very complicated beast. Hence converting an existing controller is the way to go.

If you have converted everything to RKT1, then somewhere other properties must be in play. The best resource for trying to understand that is the how to make a tree controller tutorial. As far as I can tell, the only other property pertaining to seasonal trees seem to be the FloraParameters property, reps 1, 6 & 7. If there were some special values that trigger seasonal changes, then I’d find the equivalent values used in an existing non-seasonal controller and use them instead. However, that isn't as simple as it first seems, here's a snapshot of these properties from CP's Meadowshire River Tree Controller, which is not seasonal:

[Screenshot removed for clarity, see original post]

As you can see, there do appear to be patterns for the Rep 1, 6&7, but they are not clear patterns. So if these values are supposed to be connected to seasonal timing, why would they be so different.

For example, all but one of the 1st Item in a brush are using 3.2, 2, 3, however this is not the case for all. Making me question why these values would be so different if all they did was define the length an item was used for, wouldn't the values be more similar?

At this point you could use the values from another controller as reference, but its not clear which numbers would be right or how you work out which to use?

As such, do absolutely check you've not left any RKT4 properties behind, my understanding was this was the mechanism that made the controller use Seasons, the values of FloraParameters shouldn't matter if these are not Timed/Seasonal Flora.

I've been using the tree controller tutorial to good affect: it's how I cottoned onto the idea of changing parameter 1 to try and turn it off entirely. And to its credit, it did work to a certain extent, just not what I was hoping for. I've been using Cycledogg's Generic TC in a similar way and saw the same problem. And even those TCs stutter, just every month (similar to how the Maxis TC stutters when planting/growing trees) rather than every 3-4 months like with a seasonal controller.

I've checked over my copy of Cascadia and I'm confident I've not left any RKT4s behind, though what I find odd is there are some that use RKT0 and RKT5 properties. Given both are formatted like RKT1 I chose to disregard them. Which leads me to my next hypothesis: could the fact that the TC is referring to seasonal flora be causing the hitching still? IE., would simply having, for instance, Girafe's seasonal flora as a dependency be enough to prompt the TC to attempt to shift the flora?

[rsc204 21,857]

1 hour ago, oathbound_hunter said:

...it's how I cottoned onto the idea of changing parameter 1 to try and turn it off entirely. And to its credit, it did work to a certain extent, just not what I was hoping for.

Right, but I just don't think it's as simple as using 0 or some random value, hence I showed off those used in a non-seasonal tree controller. Here there are wide variances between the values used for the three mentioned Reps, although patterns or re-used values exist too.

1 hour ago, oathbound_hunter said:

I've been using Cycledogg's Generic TC in a similar way and saw the same problem. And even those TCs stutter, just every month (similar to how the Maxis TC stutters when planting/growing trees) rather than every 3-4 months like with a seasonal controller.

This is not my experience having many years with the game, for example I used the Meadowshire River example, because its about the only non-seasonal controller I ever used. I'm pretty sure I would have noticed performance issues along the lines of what you describe, so I found my archived region and filled a tile with as many trees as I could, then put the game on Cheetah. No noticeable slowdown or redrawing happening here, although the simulator inevitably pauses the date moving forwards occasionally, but not often.

So I've got to wonder if such stuttering could be a different issue, most likely performance/compatibility related. I should point out the stuttering for Seasonal Trees is the game literally having to re-draw every planted tree in your city all at once, on three dates during the year. Much in the same way the game needs to re-draw when you rotate or zoom during play, only a little less intensive because it skips everything not a tree.

1 hour ago, oathbound_hunter said:

though what I find odd is there are some that use RKT0 and RKT5 properties. Given both are formatted like RKT1 I chose to disregard them.

Yeah, there are at least 6 RKT types, it essentially defines what kind of model is being used, but yeah that's a whole other kettle of fish. Probably best to leave those alone, I'm pretty sure those Exemplars would have been a copy of the Maxis God Mode Flora, which all custom TCs need to include in such a manner that they don't get used by the new controller, but retain the Exemplars that link to Models. This is mentioned in the TC tutorial, but yeah normally you'll only be dealing with RKT1 or RKT4, which are typical SC4 BAT (models) in either Static or 'Timed' mode respectively.

1 hour ago, oathbound_hunter said:

could the fact that the TC is referring to seasonal flora be causing the hitching still? IE., would simply having, for instance, Girafe's seasonal flora as a dependency be enough to prompt the TC to attempt to shift the flora?

Short answer, no. So your tree controller is made up from a bunch of Flora Exemplars, which link to Models via the (RKT) IDs. Likewise, in addition to these Models, Girafe also includes Flora Exemplars, but to my knowledge only for the purpose of MMPs. Some of his packs also include Prop Exemplars and all these different Exemplars essentially use the very same model files. The reason one can not influence the other, is because the model files are inert, there is nothing to define seasonality there. You could if you messed with the IDs, alter an RKT4 reference to show a Car in Autumn which changes to a Lamp Post for Winter and becomes a Phone Booth during Summer. The bit that makes something Seasonal (technically Timed), is the RKT4 property, it literally means a multi-state item, as in models can be switched on or off based on a number of different conditions. So for what we call a Seasonal tree, essentially we're just telling the game to switch between State 0, 1 and 2 based on the calendar in game. All the settings surrounding that are part of the Flora Exemplars themselves, there is nothing about the Models they link too that sets this. Just in case it wasn't already clear, you can have one model of something and re-use it as many times as you like with different Exemplars, you only ever need one model of a given thing.

[oathbound_hunter 10]

25 minutes ago, rsc204 said:

Right, but I just don't think it's as simple as using 0 or some random value, hence I showed off those used in a non-seasonal tree controller. Here there are wide variances between the values used for the three mentioned Reps, although patterns or re-used values exist too.

This is not my experience having many years with the game, for example I used the Meadowshire River example, because its about the only non-seasonal controller I ever used. I'm pretty sure I would have noticed performance issues along the lines of what you describe, so I found my archived region and filled a tile with as many trees as I could, then put the game on Cheetah. No noticeable slowdown or redrawing happening here, although the simulator inevitably pauses the date moving forwards occasionally, but not often.

[Screenshot removed for clarity]

So I've got to wonder if such stuttering could be a different issue, most likely performance/compatibility related. I should point out the stuttering for Seasonal Trees is the game literally having to re-draw every planted tree in your city all at once, on three dates during the year. Much in the same way the game needs to re-draw when you rotate or zoom during play, only a little less intensive because it skips everything not a tree.

I guess I'm not sure what to say. Playing SC4 on and off for 10 or so years with seasonal and non-seasonal controllers across multiple machines, I've never had one that didn't stutter at least somewhat: whether on the seasonal changes (even the unmodified evergreen versions of CETC, Aerden, and the like stutter on the seasonal changes: changing RKT4s to RKT1s doesn't change this) or every month (the CycleDogg ones stutter if allowed to grow, which is something even the vanilla Maxis TC will do with enough trees planted by the brush: a function of the seeding system is my bet). 

[oathbound_hunter 10]

A further update on this. I'm not sure if I've found a way to fix it properly or am just brute forcing a solution, but from what I can tell setting parameters 1 and 6 to their maximum (10,000,000) seems to have done it at least for the Central European TC. I've yet to test it with Cascadia (my wrist hurts from copying parameter values and CETC has fewer exemplars to edit) but this might be the brute force way to prevent or at least drastically reduce the seasonal stuttering to a point of irrelevance.

Initially, I only set parameter 1 to 10,000,000 under the reasoning that, if this parameter denoted how long a season lasts in half-days, denoting a season as 10,000,000 half days (or around 13,700 in-game years) would slow it down. This did stop (or at least drastically slowed) the seasonal change as expected but introduced a yearly stutter. Changing parameter 6 to match parameter 1 seemed to either remove it altogether or stalled it to the expected result.

I'm planning to test this with the seasonal variant of CETC to see if what's happening is actually a change in the seasonal parameters, then moving to Cascadia for further testing, but at this point it might be more prudent to discuss this in a different thread. Once I've completed testing, I'll start up a new one. Thank you all for your assistance with this, it's been most enlightening!