CoriBoom Those Stretchy RCI Graph Demand Bars

[CorinaMarie 29,899]

Those Stretchy RCI Graph Demand Bars 
(Being a Comparison of, and a Diagnostic Panel for, the Differences Between Actual and Apparent Visible Demand in the Game's RCI Graph.)

Background

Some of y'all may have used The C.O.R.I. Reports and the parts of interest for this topic are the Active Demands.
I have confirmed the game variables for these are the very same shown in RJ's Census Repository query panel.

Namely:

• game.g_r1_active_demand
• game.g_r2_active_demand
• game.g_r3_active_demand
• game.g_co2_active_demand
• game.g_co3_active_demand
• game.g_id_active_demand
• game.g_im_active_demand
• game.g_iht_active_demand

And those are found in the Lua in entry ca63e2a3-4a5e8ef6-ffbf9ccf of SimCity_1.dat.

 

Initial Observation

I noticed that the numeric values for Demand often seem to be significantly different than what the RCI Bar Graph shows. At first I just assumed the known delay of the internal game.g variables updating was out of sync with the chart. However, in a stable city where those are not changing there actually is a difference.

In this pic, CB has cropped out the demand info from the repository panel to place alongside the graph:

^ It's apparent that the graph shows completely different values. Like in this example the Actual Demand for R$ is 2,582, yet the graph shows it at around 4,000.

So, what's up with that methinks?

 

Investigation

After peeking and testing, I found that this discrepancy is deliberate. If we change the Data Graph to have a baseline of zero (by removing the Graph minimum Y value property 0xea4aedc6), it then corresponds perfectly to the Actual Demand values:

^ See how that 2,582 of R$ (and all the others with a number in the repository panel) now match up?

Analysis

Next I set the demands to a fixed, unchanging amount and CB measured the pixel heights of the Y Axis tick marks and the visible bars:

^ I also altered the scale so they would be multiples of 512 and taller to insure better accuracy.

The idea worked perfectly to determine if there was an underlying formula for how much the bars are stretched. That turns out to be:

Visible Demand = (Bar Height / (Actual Demand * (Distance per Y Tick Line / Y Tick Value))) * Actual Demand
                                               ^--- All parentheses in equation added for clarity.

Ofc, this was only the first step since the game doesn't actually tell us the height of the bars in pixels.

 

Correlation

By running multiple sets of specific demands and CB measuring the bars to get the Visible Demand numbers, I then used polynomial regression and the best fit was when comparing the natural log of the Actual Demand to the natural log of the percent of the space used by the Visible Demand between the zero line and the maximum Y tick value.

CB created a nice UI panel where I could show the correlation between the two sets of data:

^ We've set this to be an override for the Maxis Park Query so it's relatively easy to access anywhere within your city. The upper left keeps the Maxis info for the Monthly Maintenance Cost and the rest is the new data display.

 

Technical Consideration

You might notice that the demand for CS-$, CS-$$, CS-$$$, and Agriculture are now included in our query panel. I discovered that one of the built-in Maxis Lua functions allows direct access to the Actual Demand for all 12 RCI types as follows:

1. game.trend_value(hex2dec("2A67A399"),0) -- Low Wealth Residential (R-§)
2. game.trend_value(hex2dec("AA67A3A0"),0) -- Medium Wealth Residential (R-§§)
3. game.trend_value(hex2dec("8A67A3A4"),0) -- High Wealth Residential (R-§§§)
4. game.trend_value(hex2dec("0A67A3A9"),0) -- Low Wealth Commercial Services (CS-§)
5. game.trend_value(hex2dec("AA67A3AD"),0) -- Medium Wealth Commercial Services (CS-§§)
6. game.trend_value(hex2dec("CA67A3B2"),0) -- High Wealth Commercial Services (CS-§§§)
7. game.trend_value(hex2dec("AA67A3B7"),0) -- Medium Wealth Commercial Office (CO-§§)
8. game.trend_value(hex2dec("2A67A3BC"),0) -- High Wealth Commercial Office (CO-§§§)
9. game.trend_value(hex2dec("EA67A3BF"),0) -- Agriculture (I-Ag)
10. game.trend_value(hex2dec("0A67A3C4"),0) -- Dirty Industry (I-D)
11. game.trend_value(hex2dec("EA67A3C8"),0) -- Manufacturing Industry (I-M)
12. game.trend_value(hex2dec("8A67A3CC"),0) -- High Tech Industry (I-HT)

With the actual demand info now available for all of them, I wrote some Lua code that can convert the real demand into the Apparent Visible Demand as seen on the RCI Graph. Well, most of the time. (It's not perfect.) The code is also scalable to any other graph Minimum and Maximum (excluding a zero minimum where the graph is already accurate and which would confuzzle the hell out of my code).

Caveats:

Since the above functions access the current month data the moment the query panel is opened, it can show a different value from what you will see in the RCI graph because said graph only updates once per month. Also, my calculations are not 100% accurate, only pretty damn close, so there can be a few percent of error depending on the particular values of the Actual Demand data. And further, the data in the query panel does not update unless closing it and reopening. (This part is the same as all UI panels which show Lua variable's info including the Census Repository's.)

 

In Game Results

Here's a city tile I've been playing for a long while which shows how our new Diagnostic Panel looks in the game and you can compare the calculated Apparent Demand with the Bar Chart:

 

Other Scales

Ofc, this wouldn't be of much interest unless it can work with custom content (which it does).

Here's the same city while using CAM 2.1.0's demand enhancements:

^ Notice how the game goes extra stretchy for the bars when the actual demand is lower?

Look at R$$$ with an Actual Demand of 3,706, but which comes in around 20,438 on the chart.

 

The Attachments

Note: Use only one at once!
 

For Vanilla Maxis Replacement:
CoriBoom Actual Demand vs Apparent (+6k to -6k ) as Park Query - v1.0.dat

• As long as you are not using any other RCI Demand Graph override nor any Park Query override, you can drop our file anywhere in your Plugins.

For SPAM:
Use the Vanilla Maxis Replacement file above. (SPAM does not alter the RCI graph.)

• Same as above, drop anywhere in plugins providing you have no other RCI Demand Graph override nor any Park Query override.

For CAM 2.1.0:
CoriBoom Actual Demand vs Apparent (+54k to -10k ) as Park Query - v1.0.dat

• This one can be placed in your ..\Documents\SimCity 4\Plugins\a__CAM\a__Core folder.
• It doesn't technically need to override any CAM exemplars, but that's a good place to put it.
• The only consideration is to not be using any other Park Query override.

For XX_Turbo:
zCoriBoom Actual Demand vs Apparent (+52k to -10k ) as Park Query - v1.0.dat

• This one is a slightly special case inasmuch as XX_Turbo includes an override for the RCI Demand Graph, but it is not consistent with the maximum enhanced demands it sets.  (The settings allow up to +52,000, but the graph has a maximum of 50,000.)
   
• This causes the bars to go above the top line like this:
  
  
  
   
• Our file therefore includes a modification to set the top of the graph to 52,000 so it looks like this:
  
  
   
• By default the installer for XX_Turbo places the XX_Turbo.dat file in ..\Documents\SimCity 4\Plugins\xxdita_bsc folder and ours needs to go in the same place.  (If you've moved their mod to some other location in your Plugins, just search for "XX_Turbo.dat" and add our file there.)

For the Radical RCI demand/graph mod:

• This one sets all the Demands to a Maximum of 65,536 and does not vary.
  We didn't make a Query for this since it would show the same numbers in both columns.

For my 40_MZ v0.01 - Demands Graph Increased Height (to 9000).dat:

• This seemed like a good idea at the time when I didn't realize changing the scale only stretched the RCI Graph bars rather than showing some new, hidden demand. Simply remove the file if you downloaded it then use the appropriate file attached above.

 

Tweaking for Any Other RCI Demand Graph Range

Since we don't know if there are any other Custom graphs, here's how you can modify the attached Vanilla file to work with other Heights. Download the Maxis Vanilla file attached above and open it in Reader 0.9.3. What you are looking for is entry ca63e2a3-4a5e8ef6-f8b44574 which is the Lua code.

The only two things which need to be revised are in this top section:

^ Notice the two variables:

• cmMaxGraphYTickValue
• cmMinGraphYTickValue

Change the cmMaxGraphYTickValue to match the maximum demand the mod you are using can have and change the value of cmMinGraphYTickValue to match the minimum demand.

 

Arbitrary Example:

If you happen to have a mod which uses, say, a range of 24,000 to -12,000 then the changes would look like this:

Apply the tweaks and save the file. It's a good idea to alter the file name so it reflects the range you've set.

 

Conclusion

Nothing in the attached mods change any demand settings nor alter gameplay in any way. Our new Diagnostic Panel simply provides detailed info about the Actual and Apparent Demands for peeps who might be curious.

 

Appreciation

Special thanks yet again to @Cyclone Boom for all the technical help measuring the data bars in graph after graph, fine tuning of all the pics, proofreading, and final post layout polishing.

[simster007 391]

13 hours ago, CorinaMarie said:

You might notice that the demand for CS-$, CS-$$, CS-$$$, and Agriculture are now included in our query panel.

Alway missed that in the Census Repository!

12 hours ago, CorinaMarie said:

For my 40_MZ v0.01 - Demands Graph Increased Height (to 9000).dat:

• This seemed like a good idea at the time when I didn't realize changing the scale only stretched the RCI Graph bars rather than showing some new, hidden demand. Simply remove the file if you downloaded it then use the appropriate file attached above.

 

Do you mean, both mods do not work  together or the "increased graph"  just does not make any additional sense?

 

13 hours ago, CorinaMarie said:

^ We've set this to be an override for the Park Query so it's relatively easy to access anywhere within your city.

In a quick test it did not work on all custom parks, but that does not bother me at all. Numbers are very close to the census rep numbers.

[CorinaMarie 29,899]

16 hours ago, simster007 said:

Always missed that in the Census Repository!

Yeah, by using only the game.g variables those four were not available and that function which can access the missing demands took a wee bit of figuring out.

 

16 hours ago, simster007 said:

Do you mean, both mods do not work  together or the "increased graph"  just does not make any additional sense?

I do mean that the 9000 one simply doesn't make sense to use. If you do have it and this Park Query mod, they will work together perfectly well, but the 9000 mod simply doesn't do what I initially thought (showing some hidden demand above 6000) before I discovered how Maxis deliberately stretches the bars.

Edit: With a caveat they would work perfectly together provided the Lua code is updated to be 9000 for the max value and the minimum would stay at -6000.

 

16 hours ago, simster007 said:

In a quick test it did not work on all custom parks, but that does not bother me at all.

Sure, that makes sense. Any custom content which does not set the Query exemplar GUID (property 0x2A499F85) to the Maxis Park UI (0x0A562A05) will not be overridden by our Diagnostic Query.

[TheMurderousCricket 5,112]

I love to read about your research and corilations! (See what I did there?)

Kudos to you for yet another piece of thorough research. 

[CorinaMarie 29,899]

58 minutes ago, TheMurderousCricket said:

corilations!

 

( I do see what you did there! )

[rsc204 21,867]

I wanted to add as well, how great some of your inspirations are, this is a classic CoriBoom mod, something you never knew you even wanted, until you realise there is more data to be had. Such modding is very often overlooked, I know I just got on with trying to add new pretty things, rather than sifting through the Exemplar, UI and LUA dump that is the SimCity_1.dat. But with each new mod you've tweaked or fixed something that adds real value for every player. This looks like another must have for me, thanks.

[Gn_leugim 858]

once again, you get things tackled brilliantly!

This is a very small yet hugely useful tool for playing the game, thank you both!

[TheMurderousCricket 5,112]

On 14.02.2022 at 6:49 AM, CorinaMarie said:

After peeking and testing, I found that this discrepancy is deliberate. If we change the Data Graph to have a baseline of zero (by removing the Graph minimum Y value property 0xea4aedc6), it then corresponds perfectly to the Actual Demand values

This is what I'd like to ask you about.

Isn't it just better to simply remove this value property then and have an accurate real-time demand chart? I'd rather have that instead of having to check demand through park query every time. 

EDIT: Whoa... that Cori statue...

[CorinaMarie 29,899]

7 hours ago, TheMurderousCricket said:

Isn't it just better to simply remove this value property then and have an accurate real-time demand chart?

That's exactly what I figured to do the moment I realized the demands shown were stretched from the real underlying data. However, when there is negative demand it's not intuitively proportional to the positive demand and the RCI bar(s) drop below the bottom of the graph.

Here's an early example before CB made the fancy UI:

^ And I imagine it'd be even more wildly misleading with demand enhancements like CAM (and other mods).

They key thing I've found for actual playing is the Maxis stretching of the bars doesn't adversely impact my ability to play and zone and grow things since they are still relative to each other within the graph. So, I felt using the zero baseline would make it appear like I didn't have clue how to create a proper graph.

 

7 hours ago, TheMurderousCricket said:

EDIT: Whoa... that Cori statue...

Yeah, I love that. @Raymond7cn made that model and then @Cyclone Boom lotted the park.

[actionreplaymax 2]

Hi! recenty created this account just to ask, how to install CoriBoom's actual vs apparent demand and how to use it when in-game? I've copied the .dat file in multiple Plugins folder (in My Documents, in SC4 main directory and in user-specific My Documents folder), but nothing happens. While opening RCI graphs it just shows vanilla RCI graphs ( as far as I can see )

I'm currenty using SC4Launcher mod and at the Mods tab, the CoriBoom plugin is visible, does this mean the mod already installed?

one rookie question just to make sure, is CoriBoom diagnostic panel is the same as CoriBoom actual vs apparent demand mod?

thanks

[CorinaMarie 29,899]

13 hours ago, actionreplaymax said:

While opening RCI graphs it just shows vanilla RCI graphs ( as far as I can see )

That's as to be expected since we don't change anything there (other than a height fix if using the xx-turbo one).

 

13 hours ago, actionreplaymax said:

I'm currenty using SC4Launcher mod and at the Mods tab, the CoriBoom plugin is visible, does this mean the mod already installed?

While I've never used the SC4Launcher, it does sound like our mod is installed fine.

 

13 hours ago, actionreplaymax said:

is CoriBoom diagnostic panel is the same as CoriBoom actual vs apparent demand mod?

For this particular mod, yes they are the same thing. It is a replacement query popup for Maxis parks. So, select a park and query it. If you don't get our diagnostic panel as shown in the main post then it's likely something is loading later and overriding our override.

Let us know how it goes.

[actionreplaymax 2]

22 hours ago, CorinaMarie said:

That's as to be expected since we don't change anything there (other than a height fix if using the xx-turbo one).

While I've never used the SC4Launcher, it does sound like our mod is installed fine.

For this particular mod, yes they are the same thing. It is a replacement query popup for Maxis parks. So, select a park and query it. If you don't get our diagnostic panel as shown in the main post then it's likely something is loading later and overriding our override.

Let us know how it goes.

aah I see, I missed the ‘query a park’ part, thanks for the explanation!