Commuters from/to SimNation

[Null 45 3,112]

6 hours ago, Kel9509 said:

I don't know if there's a way to account for that other than a DLL mod.

That bug is a omission Maxis made in a few of the RCI demand exemplars, and CAM already includes a patch for it. Specifically Maxis forgot to include IR in the property that tells the game which industrial values need to be added up to get the total.

[Kel9509 1,479]

57 minutes ago, Null 45 said:

That bug is a omission Maxis made in a few of the RCI demand exemplars, and CAM already includes a patch for it. Specifically Maxis forgot to include IR in the property that tells the game which industrial values need to be added up to get the total.

That's news to me.  Is there a non-CAM version of that patch?  I don't have CAM.

I wonder if it's a good idea to bake that patch into the Census Repository Facility?  I don't know if it'd conflict with CAM if it's merely there twice...

[Null 45 3,112]

8 minutes ago, Kel9509 said:

Is there a non-CAM version of that patch?

The patch is independent of CAM as the necessary exemplars would traditionally need to be merged into SimCity_1.dat, replacing the Maxis ones. Memo also made an exemplar patch for use with the submenu DLL that applies the fixes without needing to modify SimCity_1.dat.

[Kel9509 1,479]

1 hour ago, Null 45 said:

The patch is independent of CAM as the necessary exemplars would traditionally need to be merged into SimCity_1.dat, replacing the Maxis ones. Memo also made an exemplar patch for use with the submenu DLL that applies the fixes without needing to modify SimCity_1.dat.

I found it with your help.  Thanks.  Memo's patch is on the releases of v1.1.0 of the submenu DLL mod.  For anyone who wants to download it, here it is.

@memo, you really should upload that file to Simtropolis.  It's an important bug-fix, particularly the use of IR freight to raise the IR cap.

Also @Null 45, I was hoping to include tax revenues generated from each of the 3 different zone types in the Census Repository, but the game only includes a total tax income variable.  Do you know if it'd be possible to generate a new variable for tax income for each particular zone type? 

 

[Null 45 3,112]

12 minutes ago, Kel9509 said:

Do you know if it'd be possible to generate a new variable for tax income for each particular zone type? 

It is. I am in the process of finishing up the documentation before I commit that change.

[Propfam 2,305]

1 hour ago, Kel9509 said:

Is there a non-CAM version of that patch?

Yes, it's even included in the CAM installer itself. It's called the I-R Patch (only). You can select that when you're installing CAM and with that, you can have the patch while not installing the CAM.

[Kel9509 1,479]

50 minutes ago, Jidan said:

Yes, it's even included in the CAM installer itself. It's called the I-R Patch (only). You can select that when you're installing CAM and with that, you can have the patch while not installing the CAM.

Thanks for that info.  I was too afraid to run the CAM installation when I didn't want to install it, so it's good to know that there's only an option for that fix in the CAM installation.  Although to be fair, I think it should also be separate from CAM entirely.  I see that InvisiChem separately posted the CAM IR Patch only to Moddb (I'm not sure if that file is the exact same version included in CAM 2.1.0a although it might be).  It's strange it never ended up here separately.  Anyway, @memo's version is much more preferable since it's not a replacement Simcity_1.dat file, is easily removeable if needed, and is a much smaller download.

I cannot believe I never noticed this fix until now.  I thought I had them all!

[Ulisse Wolf 4,457]

9 hours ago, Kel9509 said:

I wonder if it's a good idea to bake that patch into the Census Repository Facility?  I don't know if it'd conflict with CAM if it's merely there twice...

It will surely conflict with CAM since CAM 2.5 contains the file already placed in the CAM folders. After I release CAM 2.5 I will take care of releasing the patch for users without CAM.

7 hours ago, Kel9509 said:

I'm not sure if that file is the exact same version included in CAM 2.1.0a although it might be

is the same file since on moddb it contains the modified version of simcity_1.dat

[Kel9509 1,479]

On 12/16/2024 at 9:18 AM, CorinaMarie said:

For this one, it's not a change, but simply the 3 month total. So: "Total net commuters or available jobs over the last 3 months."

As an example let's say the January Population of a city is 10,000 and 3 months later it's 12,500. The change over the last three months is 2,500, but the more useful information is simply the new total of 12,500.

And your formula is adding months ago 0, 1, and 2 to get a total. Right?

I want to make sure I'm doing this correct, so let me show what's there now:

For the current #, the formula for "Commuters or Vacant Jobs" is:

#game.trend_value(game_trends.G_C_POPULATION,0)
+game.trend_value(game_trends.G_I_POPULATION,0)
-game.g_city_workforce_population#

For the 3-month number, the formula is:

#game.trend_value(game_trends.G_C_POPULATION,0)-game.trend_value(game_trends.G_C_POPULATION,3)
+game.trend_value(game_trends.G_I_POPULATION,0)-game.trend_value(game_trends.G_I_POPULATION,3)
-game.g_city_workforce_population*(1-game.trend_value(game_trends.G_R_POPULATION,3)/(game.trend_value(game_trends.G_R_POPULATION,0)+0.01))#

For the 12-month number, the formula is:

#game.trend_value(game_trends.G_C_POPULATION,0)-game.trend_value(game_trends.G_C_POPULATION,12)
+game.trend_value(game_trends.G_I_POPULATION,0)-game.trend_value(game_trends.G_I_POPULATION,12)
-game.g_city_workforce_population*(1-game.trend_value(game_trends.G_R_POPULATION,12)/(game.trend_value(game_trends.G_R_POPULATION,0)+0.01))#

Since this uses the "game.trend" variable, I'm not entirely sure if it's correct to say if it's a total for now, over 3-months, and over 12 months.  Or, if it's the total for the current peroid, and a change over 3 months and 12 months.  The numbers are strange if you compare them:

If this is really a Total, it's unclear to me why the current number would show a "higher" (negative amount, meaning more commuters out in my Residential city) figure than the 12 month period which presumably would include amounts for all months including the current period.  I'm thinking that the use of "game.trends" means it's an average or change figure, right?  So the 12-month figure shows an average amount of commuters over the 12 month period, right?  Or am I wrong?  This is the same data that I used in my overlay image, so you can see from that there was significant increases in residents over the past year, from approximately 10,000 to 20,000 (as shown in the Residential Capacity figures above), which probably resulted in about at least a +5000 in workforce (as shown in the workforce line above) which turned into commuters, so a -4000 number.  So these are change figures, I'm certain.

Also, the Total Workforce line is a change number also.  It's not a total.  And since this calculation uses that number, this would also be a change number and not a total as well.

Finally, I note the Region number for Commuters or Vacant Jobs.  That formula is different from the others, as it does not use "game.trends" since there's no variable for game.trends that has regional data.  Instead, that formula is:

#game.g_region_c_population+game.g_region_i_population-game.g_region_workforce_population#

And the tooltip reads:

Quote

Vacant commercial and industrial job capacity in #region#, based on existing regional commercial and industrial capacity and regional projected workforce.
This number may take into account other factors.
It is unlikely that this number reflects regional commuters, unlike the city data.

The tooltip cautions people that it's merely regional industrial and commercial capacities, minus regional projected workforce, and hence unlikely to have anything to do with net commuters like the City data.  And the line saying "This number may take into account other factors" is copied from the Regional Industrial and Commercial Capacity Total figures, which is a native Maxis variable and doesn't add up with the individual regional capacity figures from @Null 45's SC4MoreDemandInfo DLL.  So there's an "X" factor in that total.  

Anyway, the screenshot above of the Census Repository shows my latest upgrades, to include Tax Revenue for each of the zones.  I moved the Neutral Tax Rate to main window and centered the City Name.  Now I'm just double-checking the formatting of all tooltips and style.  I'm close to releasing it soon.

[Propfam 2,305]

1 hour ago, Kel9509 said:

Anyway, the screenshot above of the Census Repository shows my latest upgrades, to include Tax Revenue for each of the zones.  I moved the Neutral Tax Rate to main window and centered the City Name.  Now I'm just double-checking the formatting of all tooltips and style.  I'm close to releasing it soon.

If you can revamp the UI further, I'd put the city name, neutral tax, and total revenue into a dedicated field. BSC probably only designed the UI for the original purpose, which is okay, till there are many flaws with the information given and the UI was changed. Anyway, still decently tidy.

[Kel9509 1,479]

On 12/19/2024 at 1:07 AM, Jidan said:

If you can revamp the UI further, I'd put the city name, neutral tax, and total revenue into a dedicated field. BSC probably only designed the UI for the original purpose, which is okay, till there are many flaws with the information given and the UI was changed. Anyway, still decently tidy.

You mean something like this, where the new items are in the red box instead of spread out elsewhere?  (Note I just made a crude red box by copying the top one, so it still has things like City Name there):

While I think that looks nice, I'm not sure it's necessary.  I don't know if people would want an even larger query.  It is pretty big already.  But I don't mind doing that if it's a clear consensus.  I do like that Red, though.  

[Propfam 2,305]

4 hours ago, Kel9509 said:

You mean something like this, where the new items are in the red box instead of spread out elsewhere?

Yup. But I do agree that the window is too large already for my 768p display. Can't imagine with that red box.

[Null 45 3,112]

The screen size is an issue, but I think it looks nice with all the tax revenue in its own section. I made a quick mockup based on @Kel9509's red UI Above.

The individual wealth groups would be stacked vertically below the total for each RCI group.

I am not sure if increasing the dialog width and aligning the C and I sections with the tax income and R section (a 2x2 grid) could be a solution to the size issue. That would be a lot of work, and the dialog is already wide as is.

[Kel9509 1,479]

5 hours ago, Null 45 said:

The screen size is an issue, but I think it looks nice with all the tax revenue in its own section.

I feel like Al Pacino in the Godfather 3: Just when you think you're out, they pull you back in.

I'll admit that the Red box looks nice and might be a nice feature.  However, I'm afraid that it might be too big for some people who run at lower resolutions, although perhaps many will like it.  Also I was nearly done and this will add probably another week or so of work.  I might do a version with the Red box, and one without.

There is no way I'm editing the width of the Query.  Everything is already neatly set in stone elsewhere, and to re-order it all will be a nightmare.  I can try playing around with things but it will be a lot of work. 

I'll mention here also that as a result of this work on the Census Repository, I found a slight error in my RCI DLL Query mod that needs to be fixed, and so a new version is in the works for that already.  Additionally, I was hoping to create more "Default Override" queries for things like Power Plants, Garbage, Water, and Fire Stations (police stations were already done by @Cyclone Boom and @CorinaMarie).  I also was considering creating some custom queries for new Reward Buildings (repurposed buildings as new lots, as I can't create models) for things like a Department of Education query, a Department of Transportation, etc.   I am mostly not trying to duplicate information, but this Tax revenue might be ok since it's not really anywhere else except the budget window and I've found that so long as I keep earning money each month (as I usually do) I don't really go there so often.  I'm in the CRF query or my own RCI DLL Query, or the ModPacc Zero City Hall Query, a hell of a lot more than the budget window.  So Tax information might be ok to add to the CRF.  

Back to the drawing board....

[Propfam 2,305]

Well, I was wrong about the screen size. Sure, it's small. But it's not dang small. There's still a room for the red box. So, go ahead!

29 minutes ago, Kel9509 said:

this Tax revenue might be ok since it's not really anywhere else except the budget window and I've found that so long as I keep earning money each month

Me too! It's just a hassle to find that small building, especially in the sea of skyscrapers. Budget window otoh can be access in an always-on-top UI. I do wish there's a way to access census info outside hovering that type of buildings. Maybe a cheat code, I guess?

[Nite Owl 79]

7 hours ago, Jidan said:

I do wish there's a way to access census info outside hovering that type of buildings. Maybe a cheat code, I guess?

That is a great idea. Getting the nice Census Repository Information without having to Plop, Find, and then Hover over a Census Repository Building. Is that possible?

 

[Kel9509 1,479]

Ok, instead of a week I worked on this most of today.  Here's what I came up with.  It's a bit hard to get most items in there but I did my best to align things with the existing columns.  Each new item also has its own tooltip.  Also, for the City finances section it was a little compressed so the total is only net income (which the game doesn't actually show you anywhere).  The tooltip has the complete description of the math and shows the numerical amounts (total overall income minus expenses).

I'd like this expanded query to be an option.  The other query is basically what I've shown in my last in-game screenshot already: the same size as the existing census repository.  Call it the compressed version or normal version, versus this expanded version with the red City Budget Overview window.  The documentation will discuss how to install one or the other, as they overwrite each other.

Let me know if anyone has any comments.  Otherwise, I'll try to get this published soon.

[Propfam 2,305]

7 minutes ago, Kel9509 said:

Let me know if anyone has any comments.

Pretty good actually. It turns out that splitting tax revenues into a red box wasn't a bad idea at all. At least the total for all tax revenues, compared to just individual revenues in the previous UI.

[Null 45 3,112]

1 hour ago, Kel9509 said:

Let me know if anyone has any comments.

The industrial section looks cramped, my concern is the the industrial totals could get truncated in the UI.

Would it be possible to reduce the blank space between the residential labels and totals? Then the other values could be moved over to the left.

Although, I may be misunderstanding the UI layout and how the labels are implemented.

[Kel9509 1,479]

1 minute ago, Null 45 said:

Would it be possible to reduce the blank space between the residential labels and totals? Then the other values could be moved over to the left.

Yes I could do that.  But I was trying to maintain the existing column structure.  I'll try playing with it more.

[Kel9509 1,479]

I decided to remove the word "tax" and merely use the zone shorthand names, aligning them with the proper columns.  I moved some columns to the left, still in line with others in the query.  However, this results in the Commercial Service shorthand names being a bit to the left, since it's aligned with the "CAP" column.  

Also, the IR information has been moved "into" the Commercial tax revenue section.  There was really no place to put it, unless I add another line underneath everything and expand the query below.  But I don't know if that'd look any better.  I do have a tooltip saying that the IR information is there for organization and is not a Commercial zone.

I also separated the descriptions in the "City Finance" section and moved those to the left, keeping the numbers on the right.  The other totals are still as they were, since I think they're ok.

Anyway, let me know what you think about it now.  Better?

[CorinaMarie 29,884]

On 12/16/2024 at 9:18 AM, CorinaMarie said:

For this one, it's not a change, but simply the 3 month total. So: "Total net commuters or available jobs over the last 3 months."

I've finally got time I can look into this some more.

After you quoted me on this, I had some doubts and it turns out I was still thinking about the extrapolated data which you've already fixed.   I believe you are entirely correct that the 3 and 12 month calculations are differences. 

 

However, I am still a bit concerned with the calculations. Don't we already know for certain that the game_trends.G_I_POPULATION value does not include agriculture? Without it, that'll manifest as seemingly vacant jobs and/or commuters. Right?

On 12/18/2024 at 11:28 PM, Kel9509 said:

For the current #, the formula for "Commuters or Vacant Jobs" is:

#game.trend_value(game_trends.G_C_POPULATION,0)
+game.trend_value(game_trends.G_I_POPULATION,0)
-game.g_city_workforce_population#

^ I've changed that to a mono spaced font so it makes it look more like the programming code it is.

You'll already know this, but I'm going to explain for other peeps who might be peeking in. The game.trend_value() is a function and then what follows inside the parentheses has two pieces of information. It looks like this generically:

|-FunctionName-| |-Parameter 1-|  |---Parameter 2----|
game.trend_value(data_array_name, number_of_months_ago)

Each data array is up to 6,000 elements of information (with one element per month for 500 years) and each would be separated by a comma if it were in a .csv file.

In the quoted code the first line will be equal to the Commercial Population zero months ago meaning the current month. The next line is the Industrial Population also from the current month. Those two are added together and then we subtract the total Workforce Population from them.

This brings up another question for me. Do we know that the game.g_city_workforce_population does not include commuters from outside our city tile who have a job here?

tl;dr:

• Are the farmers included in that calculation?
• And are incoming Sims included in the Workforce total?

 

On 12/18/2024 at 11:28 PM, Kel9509 said:

For the 3-month number, the formula is:

#game.trend_value(game_trends.G_C_POPULATION,0)
- game.trend_value(game_trends.G_C_POPULATION,3)
+ game.trend_value(game_trends.G_I_POPULATION,0)
- game.trend_value(game_trends.G_I_POPULATION,3)
- game.g_city_workforce_population
*(1 - game.trend_value(game_trends.G_R_POPULATION,3)
/(game.trend_value(game_trends.G_R_POPULATION,0)
+0.01))#

^ Also tweaked for readability.

Since the Workforce for prior months isn't stored by Maxis, RJ does some fancy footwork to calculate it. He takes the ratio of the Residential population from three months ago compared to the current month and uses that as a multiplier to the Workforce. As long as the Workforce includes only Sims who live in our city tile, this will be fine. (I'm not certain if we know that for sure about the game.g_city_workforce_population or not.)

And like for the current month calculation, there is the concern that the farm workers are not included in the 3rd and 4th lines of the equation. (The same questions are relevant for the one year data.)

 

On 12/18/2024 at 11:28 PM, Kel9509 said:

Since this uses the "game.trend" variable, I'm not entirely sure if it's correct to say if it's a total for now, over 3-months, and over 12 months.  Or, if it's the total for the current peroid, and a change over 3 months and 12 months.

We do know this for certain. Any in the form of game.trend_value() are exact values for the month queried.

There are four different "game.trend" functions defined by Maxis:

game.trend_slope = function (trend_type, period_in_months) return 0 end --returns a trand value between from (-100, +100) for the period of time (see game_trends for trend types)
game.trend_value = function (trend_type, num_months_ago) return 0 end --returns a value the trend variable had 'num_months_ago'
game.trend_count = function (trend_type, period_in_months) return 0 end --returns a sample count for the period of time
game.trend_delta = function (trend_type, period_in_months)  --returns a growith percentage
   local past_value = game.trend_value(trend_type, period_in_months) + 0.00001 -- for avoiding the division pbolems
   local present_value = game.trend_value(trend_type, 0) 
   local result = (present_value / past_value - 1) * 100 
   return result 
end 

And trend_type is what I call the data_array_name since it's more descriptive.

 

On 12/18/2024 at 11:28 PM, RJ said:

This number may take into account other factors.

I can fully relate to this because there are unknowns. Until the DLL peeps started poking inside, we could often only guess at what was going on under the hood. However, even as such I believe we could do some tests and the empirical evidence could guide us to be able to say for sure what may or may not be included.

If the displayed numbers aren't factual then I feel it'd be better to ditch them rather than make up whimsical descriptions for them as RJ did.

 

9 hours ago, Kel9509 said:

Better?

Yes! Much better.

And then you could left justify the labels in their columns.

  CS$
 CS$$
CS$$$

becomes:

CS$
CS$$
CS$$$

That way they'll match the style of the R$, R$$, and R$$$. Then do the same for Commercial Office and the Industrial. (And yes, IR is  best placed how you have it above CO and no one will get confuzzled.)

[Kel9509 1,479]

6 hours ago, CorinaMarie said:

Don't we already know for certain that the game_trends.G_I_POPULATION value does not include agriculture? Without it, that'll manifest as seemingly vacant jobs and/or commuters. Right

No, that value does contain agriculture.  It is easily testable, as I did when I made a new city in a new region, with only farm jobs and nothing else.  And it doesn't matter if you use the CAM IR patch (or @memo exemplar patch). I tested it both with the patch installed and without, and the numbers were the same.  For whatever reason, game_trends.g_i_population includes farms, but the CAPACITY counts of game.g_region_i_population and game.g_city_i_population do not include agriculture.

Here's some screenshots, all without the IR CAM fix patch.

First, the jobs bar graph:

You'll notice that Agricultural jobs are slightly above the middle between 300-400, on the red line I drew.

Here's the industrial Query, showing  Agricultural Jobs capacity of 354.  Note that the City/Regional capacity numbers are zero, because I'm not using the IR fix from CAM or memo.  IF you install that fix, only those numbers would change.

 

Finally, here's the Census Repository:

It reports 339 workers in the city.  I actually believe that's 100% accurate, because the Route query does show a bunch of residents going to work on those farms.  I'll bet if I manually added those up, it'd be at or close to 339 if I clicked on every farm:

Note that the Census Repository shows the number 354 twice.  The first, for IR (Farming) capacity, is a function: #game.trend_value(game_trends.G_IR_POPULATION,0)#.  Note the IR in this function.  It works fine.

The second, for the total Industrial job capacity, is also a function: #game.trend_value(game_trends.G_I_POPULATION,0)#.  It also works fine and shows the same number since there's no other industrial jobs to add up along with the farms.

My RCI Query  also reports 354 jobs.  That number is a direct Maxis variable: game.g_city_ir_population.  It works fine and reports the exact same information that the Trends variable does, since it's a current month amount.  The other number reported, regional IR capacity, comes from @Null 45's SC4 More Demand Info DLL, which reports regional IR capacity of 2045.  That individual number won't add up with the total regional capacity # if you install the IR Fix from CAM or @memo, for some odd reason (hence, other factors involved).

So since we know that the game.trends function works to include agricultural jobs, we can also see that the calculation will work when we discuss Commuters.

6 hours ago, CorinaMarie said:

This brings up another question for me. Do we know that the game.g_city_workforce_population does not include commuters from outside our city tile who have a job here?

That is easily tested, as I saw in my Industrial and Commercial cities which had many more jobs than people.  In those cases, the workforce did not include outside commuters.  HOWEVER, when looking at my Residential city, in which the majority of people commuted outside the city, the workforce DID include those commuters but only because they were from the residential population of that city who held jobs outside of the city.  So "workforce" is not a CITY workforce number, it's a function that examines the number of jobs held by residents within the city, whether inside or outside, or whether from civic jobs (which otherwise count as unemployed) or zoned jobs.

Here's the jobs/population graph from my industrial city.  Note the excessive number of industrial jobs in comparison to the minimal populace:

And here's the Census Repository: 

Total workforce is 101 jobs, but only from those residents within the city.  The real story is the "Commuters or Vacant Jobs" number, which as we discovered does contain Commuters.  

Here's another screenshot from my Residential city:

Note the high populace and minimal jobs.  Here's the Census Repository:

See the workforce of 8320?  Pretty high for a city that has only 86 commercial jobs and 1115 industrial jobs.  The rest are Commuters, approximately 7119 of them working in my neighboring Industrial and Commercial cities.

So "workforce" does include commuters OUT, but not IN.  And the reason it's this way is because workforce is a function of jobs held by the in-city residents.  Heck, it might even be a total of all jobs for the Pathfinding query from in-city residential zones.

I note that "workforce" also includes Civic jobs.  I made a Civic city with Residents, and only civic jobs.  I plopped a police station, fire station, elementary school, the Census Repository, and Mattb325's Ikea, which provides 1,472 civic jobs across all job levels.

Here's an older screenshot from when I was  testing all of this and started establishing the city.  It was still growing and had no neighbor connections yet, and the only jobs were Civic and the entire workforce was shown with those jobs.  Note also that since Civic jobs are considered "unemployed" the vacant jobs matches perfectly:

 

Later I built a neighbor connection.  The city grew enough to fill the Ikea and all other civic jobs, and started commuting to a "Mixed zone" city I made.  There were zero other jobs in the Civic City.  The workforce showed 3556 ofthem as in the Civic jobs and also as commuters or vacant (because that's a combo of commuters and unemployment or civic jobs) again perfectly matching:

Finally, for the new displayed of City Budget Overview, I aligned the CS, CO and Industry to the right because the vertical columns they're matched with align to the right.  CAP is aligned right, 3-month data is aligned right.  The only stuff aligned left are those on the left.  But I'll try it and see what it looks like.

[CorinaMarie 29,884]

@Kel9509

Sounds like you've researched and tested it thoroughly. That should cover all the bases then. Nice work!

[Propfam 2,305]

5 hours ago, Kel9509 said:

The workforce showed 3556 ofthem as in the Civic jobs and also as commuters or vacant (because that's a combo of commuters and unemployment or civic jobs) again perfectly matching:

But why is the other income negative? Would be better if we spell it like -$2 or ($2) to borrow from accounting practices? And also, this is very minor thing. But it'd be nice if we can change the background (you know, inspired by the game's news UI) of the CRF query to better suit the current size. I guess @Panda would be able to help with minor things in the UI.

[Kel9509 1,479]

On 12/22/2024 at 11:10 PM, Jidan said:

But why is the other income negative? Would be better if we spell it like -$2 or ($2) to borrow from accounting practices? And also, this is very minor thing. But it'd be nice if we can change the background (you know, inspired by the game's news UI) of the CRF query to better suit the current size.

The function to show "Other Income" is: "#game.g_income_monthly-game.g_tax_income#", or, Total Income minus Monthly Tax income.  There is no variable yet that shows "Other Income by itself.  The reason the result is negative is because the value for "game.g_tax_income" is not always up to date, and also appears larger than the real amounts. 

Here's a screenshot to show what I mean:

The budget at the bottom-left of the main screen shows monthly income of 441 and expenses of 1282.  Also above, there's 356 of residential income and 85 of industrial.

The Census Repository shows 356 residential income and 85 industrial (those are @Null 45's variables), which add up to 441.  So those are consistent with the main budget screen.  However, the RCI Income line, using the Maxis Variable #game.g_tax_income#" is 444 though.  Very odd.  When you hover over the Total Net Income, the details shows the following:

Monthly income in the tooltip is 441, and the variable is #game.g_income_monthly#, which aligns with the main budget window.  

So the error is in the Maxis variable "game.g_tax_income".  As it turns out, the Maxis variable "game.g_tax_income", does not actually update on a current month basis.  I've noticed a delay with that variable and it doesn't populate until approximately 2 months later.  As far as I can tell also, that variable is not actually used by the game.  In searching Simcity_1.DAT, that variable only appears in the complete list of variables but it doesn't appear to be used by the game itself or any of the advisors.  So I might replace it with the variables @Null 45 made instead.  The fact that it's inaccurate suggests it should be replaced.  Still, I'd hate to not use a variable if the game actually uses it in a proper manner.  But I can't seem to figure out if it IS used properly.  

[CorinaMarie 29,884]

30 minutes ago, Kel9509 said:

But I can't seem to figure out if it IS used properly.

You are correct that it only appears one time ever and that's in Lua 0xFFBF9CCF. This means for certain there are no advisor messages which ever even peek at it.

 

31 minutes ago, Kel9509 said:

So I might replace it with the variables @Null 45 made instead. 

Agreed. This is the best plan so you have more accurate info displayed.

[Kel9509 1,479]

3 hours ago, CorinaMarie said:

Agreed. This is the best plan so you have more accurate info displayed.

Well I've got partial success.  Substituting Null 45's variables for the useless Maxis one worked fine.  The total RCI income is now correct.  But unfortunately, I also learned through testing that #game.g_income_monthly# only is updated on the 28th of each month.  The regular budget numbers are updated the first of each month.  So the line for total net expenses is accurate only on the 28th, 29th, 30th, and 31st of each month.  Then, when the new month starts, the regular budget updates but the Census Repository's Total Net Income line will still be last month's #s from the 28th.

I looked and it appears that #game.g_income_monthly# is used in some advice scripts.  But I have no idea why it's only updated on the 28th of the month.  It's like all the other census numbers in the Census Repository being updated then.  But unlike the others, which are "filled in" on the 1st after being updated on the 28th, this one updates on the 28th and is shown that way immediately.  

@Null 45's variables, however, update on the 1st of each month.  Does anyone know why this is the case and if it can be addressed somehow so the variables align?

[Null 45 3,112]

26 minutes ago, Kel9509 said:

But unlike the others, which are "filled in" on the 1st after being updated on the 28th, this one updates on the 28th and is shown that way immediately.  

The monthly income/expense are calculated on-demand when the methods are called by adding up the income/expense from taxes, ordinances, neighbor deals, etc. But I have no idea why it would appear to update on the 28th. I doubt a one month delay would have been noticed by Maxis as they appear to only be using that data for Lua trigger conditions.

18 minutes ago, Kel9509 said:

Does anyone know why this is the case and if it can be addressed somehow so the variables align?

The only thing I can think of would be a race condition in the game code. Both the budget simulator and advisor variable update code are listening for the same 'new month' message, and I doubt there is any guarantee which subscriber gets notified first.

If you are only using them in the UI, I could add new occupant query variables (similar to growth_stage, building_summary, etc.). But IIUC the new total income/expense variable could function as 'total to date', instead of 'total per-month'. As I mentioned above, the result is calculated when the methods are called.

[CorinaMarie 29,884]

8 hours ago, Kel9509 said:

I also learned through testing that #game.g_income_monthly# only is updated on the 28th of each month.

Have you tested game_trends.G_INCOME = hex2dec('6a51178b')?

• Like this: #game.trend_value(game_trends.G_INCOME,0)#