rsc204

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. 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. 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. 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.

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.

In the first instance start a new region having removed all your Plugins temporarily. If demands are working as expected, then somewhere you have a mod that is causing the altered behaviour. Then the Binary Search method is the way to find it.

These are almost certainly from Rivit's collection on OneDrive: https://1drv.ms/f/s!AphvaLJG-tShgsIPfB0UQh7KK6Fv7Q It's the Maxis Lookalike set.

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.

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. 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.

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.

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.

Have you limited SC4 so it only runs on a single core of your CPU? The most common reasons for scrolling/zooming issues, is from not having done this. The best solution is to use the following DLL mod, mandatory for modern P/E Core processors:

You’d need both.

Are you aware that no Street Tunnel portals were included with the original game?, it appear Maxis intended to support Streets but never finished it. As such, in order for this to work you need the NAM.DLL from here:

If anything you could offer SCLIT with Paeng’s Sidewalk mod at this point. But it has all the wealth options so hard to cover all bases.

its worth noting also, not installing such Legacy features, doesn’t mean existing instances of them are affected. You just can’t place new ones because the menu items aren’t there. It doesn’t mean you don’t have textures, models and paths etc, that’s retained regardless for backwards compatibility.

You can make intersections with street WRCs, in fact it’s almost unique to streets. But these are no plops or PPs, rather achieved through draggable patterns. See this tutorial for how to make these and many other setups.