Census Repository - Support and Discussion

[cogeo]

And especially in the case where you have three (or more) cities in a row...
Consider playing the first city, which at the end extrapolates an industrial demand to the neighbours.

Then you play the next city, but only for a very short time.
In that short time no industrials grew in the city, and also none of it was further extrapolated to its surroundings.

If you play the third city in that row now, it wouldn't see anything of the original extrapolation from the first city.
.
.
.
Lets consider that the first city extrapolated an industrial demand of +10,000.
Then, let's assume that the second city allows that industry to grow, but won't allow any residents to grow.
That would in turn lead to an extrapolated residential demand of some +20,000 (if HQ is 100 out of 200).

I guess in either case the extrapolated I demand would be extrapolated again, with the potential to cause industrial growth somewhere else. And running a city for 1-2 months is more than enough to make extrapolated and local demand consistent. The 2nd city won't "eat" the extrapolated demand, it may "merge" it with its local one (and if this was negative, you will see a reduction) but this is not actally a "loss", it's just balancing the situation out. Anyways.

I have attached a small patch for the CR query. It's for development and debugging only. The tooltips for the R, C and I "Commuters" (or what) have been replaced with a dump-list of the historical data. The length of the list is limited to 300 months, and the limitation comes from the tooltip size. You may increase or decrease the limit according to your resolution/screen size. I can't understand what these nunbers really stand for. They are much lower than the number of actual commuters. And I'm not sure if it's really extrapolated demand either. I developed a new city, connected in a way that didn't allow any real commuting to occur. It got the demand from the region and developed a nice CS$$ and CO$$$ area (these clearly came from the region), and many R$ and R$$$ residences (R$$ was impossible to develop because the demand extrapolated from the region was strongly negative). So no real commuters from/to the region. only demand. The (historical) values reported here as "Commuters" in the CR query were ALL 0! So these have indeed something to do with commuters, but I can't figure out what they really are.

Another change in the script is the function that calculates the neutral tax rate (why calculate it, and not just take it from the game variables?). Pls check out the attachment and delete it (Others, pls DO NOT download).

Yes I think that is the concept.. it is simply a mechanism to make up for the fact that SC4 actually knows little to nothing about what "would be" happening in an adjacent city. The function of the "extrapolated demand" over is a tool to make it work rather than going to the other city only to find you could not stimulate any growth of the type you need.. By "lost" I believe it simply ceases to serve further purpose, therefore is discarded. As you continue to progress through various city tiles, you have the opportunity to "carry over" some demand to the newly opened city. If you don't take advantage of it, it isn't really of long term consequence. It isn't needed as you can generate new demand in various ways.. it's simply a convenience to facilitate city-to-city progression. You may either use it or ignore it as your growth plans dictate, but nothing is really "lost" other than perhaps an opportunity.

Yeah, that's exactly what I meant.

[RippleJet]

I can't understand what these nunbers really stand for. They are much lower than the number of actual commuters.
And I'm not sure if it's really extrapolated demand either. I developed a new city, connected in a way that didn't allow any real commuting to occur. It got the demand from the region and developed a nice CS$$ and CO$$$ area (these clearly came from the region), and many R$ and R$$$ residences (R$$ was impossible to develop because the demand extrapolated from the region was strongly negative). So no real commuters from/to the region. only demand. The (historical) values reported here as "Commuters" in the CR query were ALL 0! So these have indeed something to do with commuters, but I can't figure out what they really are.

My original reason for believing those numbers were indeed commuters came from these LUA scripts in the CITY PLANNING advices (TGI 0xCA63E2A3, 0x4A5E8EF6, 0xFFF88AB4):

Code Select Expand


----------- Advice record ----
--#City# Workers Calling Elsewhere Home
a = create_advice_cityplanning ('2a5a686a')
a.trigger  = "game.trend_value(game_trends.G_R_EXTRAP_OUT,6) > tuning_constants.POPULATION_STEP_2"
a.frequency = 600 
a.timeout = tuning_constants.ADVICE_TIMEOUT_MEDIUM
a.title   = [[text@2a54083c]]
a.message   = [[text@2a540840]]
a.priority  = tuning_constants.ADVICE_PRIORITY_MEDIUM
a.mood = advice_moods.NEUTRAL

----------- Advice record ----
--Some #city# Residents Choose Long Commute
a = create_advice_cityplanning ('8a5a68ac')
a.trigger  = "game.trend_value(game_trends.G_C_EXTRAP_OUT, 6) + game.trend_value(game_trends.G_I_EXTRAP_OUT, 6) > tuning_constants.POPULATION_STEP_2"
a.frequency = 600 
a.timeout = tuning_constants.ADVICE_TIMEOUT_MEDIUM
a.title   = [[text@6a540845]]
a.message   = [[text@2a540849]]
a.priority  = tuning_constants.ADVICE_PRIORITY_MEDIUM
a.mood = advice_moods.NEUTRAL


Those advices appear 6 months after a month with more than 500 "commuters" either way (if that's indeed what they are).

Another change in the script is the function that calculates the neutral tax rate (why calculate it, and not just take it from the game variables?). Pls check out the attachment and delete it (Others, pls DO NOT download).

Wow, I hadn't even noticed that ingame function (game.g_tax_rate_neutral) myself...   Thanks!

[whatnameshouldi]

Quick question:
Is this campatible? All the info will be reliable or it will be affected by the CAM in someway?
Thanks for any answer and great job
whatname

[Lowkee33]

Totally Campatible.  CAM would effect the values, but the CR works independently.

[whatnameshouldi]

Thanks for the answer. For anyone still wondering there are specific tooltips (eg caps) for the CAM.
Now combined with the CAM counter ill get a clue of why my cities are not growing the way i want.


Edit:
Lastest testing seems to point the CRV is not the cause of the following.
Been having some fun with the CR but i believe ive found a bug. Every time i hover (no need to click) the transint query over the CR Vault i get a CTD with no  error message (i dont think ive had random CTD before). At first i was surprised but then realised what was happening and was able to reproduce it by hovering the transit query over . Im using CAM NAM and the CR latest version (installed in that order; also SPTool for DAMN Manager, but i havent added the CRs to the menus).
Any idea of why that happens? It is not that terrible as i dont need to transit query that place too often but i have a ferry close by and sometimes forget and hover by mistake. I havent checked on the CR Facility, ill let you know if same happens, that would be troublesome.

Thanks again
whatname


Edit 2: Rechecked and it seems the CRV doesnt have anything to do with my issue. Ill do some more testing, but it seems to have to do with the transit query and a specific part of my town, almost empty but for CRV, BSC Farm Bureau, Car Ferry, Train station, roads and rails. Too tired to keep trying now. Wish me luck

[scadamsc]

I'm not sure I understand how to install this on a mac.

I believe I've installed the (BSC) dependencies, but the file names of the CR .dat files don't match the ones in the table (the one showing NAM compatibility.

My CR .dat files appear as shown in the attachment. I'm guessing I simply pull one of them into the plugins folder, but I'm not sure which one.

See the attached image. You'll see the .dat file names don't match those in the instructions.

I unpacked these .dat files from the .exe using file juicer. I'm on a mac.