Census Repository - Support and Discussion

[cogeo]

Yes, there is a certain reason for that...
the tiptexts (the text you see when hovering above them) only work with buttons.

Now I see. It definitely does make sense. Just wanted to keep them from receding (but that's really minor).

Now about the BAT, I'm leaning towards making something small and not very much "great". How about a building like this?



The actual building houses the Chamber of Commerce and Industry in my home city.

The building will look quite small (for a civic building) ingame if it's accurately scaled, so I wouldn't even attempt it. There is no need to make an accurate re-creation of a real building, just keep the style and/or use some architectural elements. So the final model can have windows at the side walls (this one is W2W), and be some 24-30 meters wide. And of course forget the stupid shop at the left - entrances like the one at the middle (but smaller) could be used instead, or else windows, or even plain walls.

If you are for something better, a more knowledgeable BATter should be employed (btw Debussyman is the first who comes to mind  ).

[z]

That looks great to me, Cogeo.    Although it definitely has a European flavor to it, that's the type of classical building that would be at home in just about any city.

[cogeo]

Tage, I have tinkered a little with the format strings and the LUA, and found that the problem (and the solution) was as I had described in the previous page. First of all, this indeed depends on the computer's regional settings. If you set the decimal separator to the comma (,) rather than period (.) it works. You can easily reproduce the error by setting the decimal separator to the period.

The solution is to change the format strings or the LUA script. I have a attached a patch in this post (dl and then delete it - Others, pls do NOT dl). It contains the following (changed) items:
- The R$ tax format string (modified as I had suggested). This should work no matter what the decimal separator is, and in addition the decimal separator displayed (the output) now depends on the computer's regional settings (it's no longer a hardcoded period).
- The R$$ tax format string as it was in V3.0. This should not work if the decimal separator is set to period (US-like). I added this so that you can easily verify the error conditions (dependency on the regional settings).
- A modified LUA script, with the RJCR_TaxRate() function using the format() function instead. This should fix all other tax rates.

So if you want to get rid of the "dirty, but certain, way of convering..." you have two options:
- Either change the format strings like the one the R$ tax in the patch (this is easier to do on V3.0, instead of V3.1)
- Or replace the LUA string with the one in the patch.
Pick the method you prefer.

As for the BAT, I have started it, but it's still in the very early stages of development. Here is a pic:



I may need some help here, with the LUA scripts - activate it and display the "offer" dialog (I think I'll finally make it a reward, but with an easy to meet condition, eg 1000 or 5000 C+I jobs, and no caps relief, just some civic jobs and some little landmark effect). But this will take some time, as I haven't made such BATs before.

Hope it turns out good.

[RippleJet]

Cogeo, you've given an explanation and a solution that nobody inhouse of "that other place" managed to give...
I'll save this for the next upgrade of the CRF (imminent with the upgrade of CAM).

Enjoy a karma point!

[cogeo]

Is it possible to extend the query a little, to display civic jobs too? Or they are included in the commercial ones?

[RippleJet]

Unfortunately there is no variable avilable to read the number of civic jobs in a city...
I really would have wanted to be able to report them as well!

[z]

I like the CRF and the CRV very much, but I also liked the Version 2 CRF since its small size allowed me to easily plop it into existing cities.  Since Version 2 now uses the Version 3 query, how can I get it back in my menus?

Also, could you either please explain how the Projected values are calculated, or point to a post where this is explained?  Thanks!

[RippleJet]

I like the CRF and the CRV very much, but I also liked the Version 2 CRF since its small size allowed me to easily plop it into existing cities.  Since Version 2 now uses the Version 3 query, how can I get it back in my menus?

Use the attached enabler, and you'll have it back in your rewards menu (a little further down in the menu).
It needs to be loaded after RJ - Census_Repository_Model_and_Query_3.1.dat.
Placing it in the same folder, \Plugins\BSC\RippleJet, will suffice.

You will of course also need RalphaelNinja's original CensusRepository-0x5ad0e817_0x6dd414f2_0x30000.SC4Model,
which is available on STEX. You will not need anything else than the model from his original upload.

Also, could you either please explain how the Projected values are calculated, or point to a post where this is explained?  Thanks!

That is the total regional demand, most likely the sum of the local demand and extrapolated demand from all cities in the region.

[xxdita]

My problem is generally finding the  thing once my city's grown up. So I use a remodded  Taipei Lite to serve as my CR. Stands out much better. 

[SC4BOY]

I agree. Findability is a key.. can't find it? Useless!

[Indisguise]

To avoid having to search for it, I ussually place it on the edges of the city near  a corner or a city to city connection, that or place it in the space that is left by a fourway highway intersection.  the 4x4 or smaller CR fit perfectly there 

[cogeo]

Hi,

I have found another problem with CR. I just noticed that the numbers of Commercial and Industrial Commuters reported are way too high. In some cases, the total may even exceed the workforce. Take a look at the pic below:



If you count the people working in civic services too, the discrepancy becomes even more apparent. I couldn't explain this, so I checked the script, and found that these values are actually the sum of extrapolation occured in EVERY game month, that is the historical total! I don't think the description of "Total number of commuters living in city, but working in your neighbourhood." in the tooltip, agrees with what this actually is. Neither the 3 MONTHS and 1 YEAR entries ("The change over the last 3 months in commercial commuters living in city, but working in SimNation") which are actually the total extrpolation over the last 3 and 12 months respectively, not the change (btw I have never seen negative values here).

So I think there is a logic error here.

I will check the thing a little more, and post again.

[SC4BOY]

I have noted incongruities as well.. you may be onto something.. RJ posted in the support thread that is the extrapolations.. I'm sure he'll get around to give us his view in due time.. The thread says it is an extrapolation that is carried over to  the next city when you open it, and that if you don't use it in "x time" that is goes away. Have you tested this issue as you go through different city tiles? The suggestion is that if you don't "use it up" when you switch to the next city tile that it goes away.. but I have never tried to test this issue. When I play regions I very often have a clear idea of how large I want a given city so the fact that I am losing "carryover demand" has never been an issue to me.

[cogeo]

I think demand (and its balance region-wide) is quite consistent, so the situation sooner or later balances out. This rather suggests that demand is not permanently "lost" (or conversely "gifted"). Sorry Tage, but I rather have indications that the opposite is true.

Say you have a new region, and you start developing city A (zoning R, C and I). Run the city gradually adding zones as needed, until R and C demands almost flat out (I'm not talking about I, as it's usually strongly positive and it's hard to flat out, so just zone only a few blocks, just to support some R population). If R demand is still somewhat up, you can start a new connected city (B), and develop a quite decent R population with minimal I and C; most of your population will be considered "commuting" to A. If you expand B further (zone more R, C and I) you will see commuters to A increasing, which is strange, as there are no many vacant jobs there actually (this must be the 10% Ripplejet is talking about). Now, if you open A again (or even start a new connected city), you will face a strong negative R demand. Then you have two options:
- Develop more jobs in A. A will be specializing more as a "business center" and B as a "bedroom community".
- Admit the negative demand. Just run the city for 1-2 months (I think even some days may be enough - look at your demand graph). Then stop the city, save and exit. Open B again, and you will see the negative demand... returned back! This is very much OK, as there are more residents than jobs. You can then create more jobs in B. Choose this option if you prefer balanced, rather than specialized cities.

So I think the regional demand is actually consistent, and all discrepancies are rahter short-lived, and occur due to the "asynchronicity" feature. In our example above, while city B was developing, city A could not report that its job market was saturated, because it was not simulated.

[RippleJet]

This is the post SC4BOY is referring to (thanks, btw!):

The commuters are the total of all extrapolated growth that has occurred during the lifetime of your region.
Note that unless this extrapolation is allowed to be fulfilled elsewhere in the region, that extrapolated growth has actually been lost:

Regional Extrapolated Demand

All census data is stored with each city's savegame file.
Now, while playing a city, inactive connected cities can satisfy this city's demand with their unused zone capacities,
but only to the tune of 10% of their existing populations and only if the demand cannot be satisfied in the city being played itself.

At the end of each month, demand not satisfied by building construction in the city being played is tossed to other cities in the Region.
When returning to another city in the region, in which such extrapolation has occurred, the presumed growth will sprout.

Always when entering a city, give it some time to grow (10%) before leaving it.
Otherwise the extrapolated growth from the Region will be lost forever.

As far as other cities are concerned, when exiting a city that you haven't given enough time to grow,
the city played has lost its extrapolated growth and has actually shrunk in size, leading to recession and abandonment elsewhere.

That last quote (within the quote) is directly from Prima's official guide.

The extrapolations which are available to be read for each month since the city was founded (a rather large array) are indeed either positive or zero, but never negative.
In accordance with the Prima Guide, every such extrapolation which is not fulfilled in your neighbouring cities would be lost.

However, I'm pretty sure that in such a case, that extrapolation might occur over and over again, if you go back and play the first city over and over again.
Thus, the total sum of all extrapolations throughout the city life is certainly not a precise science.

Lots of those extrapolations have most likely been lost, and thus the sum is often larger than the true extrapolation.
There is however no way of knowing to what extent the extrapolation has been fulfilled as growth in your neighbouring cities.

Generally we know a lot more about the extrapolated demand than I did when I originally made my Census Query, some 4-5 years back.
I will certainly need to change some "commuters" into "extrapolations" in the next update of the CRF.

[travismking]

I dont really understand anything in that post tbh. Ive often wondered what those numbers were.

Always when entering a city, give it some time to grow (10%) before leaving it.
Otherwise the extrapolated growth from the Region will be lost forever.

what does this 10% number refer to?

[RippleJet]

what does this 10% number refer to?

That is good question...
I'm not even sure if it's got any backing anywhere in the simulator, or if that's something Prima just came up with...

[cogeo]

I think most players (incl me) have little, or no interest in the "historical extrapolation" (which is reported as "commuters" in the CR query). And they will of course tend to compare them with the monthly data, to figure out what the (current) supply/demand situation is. And that's the purpose of CR, to provide a "snapshot" view of Supply and Demand of the city, and to some degree of the region too. Of course, this is a matter of definition, but is CR defined to provide historical data? I think not. So how about replacing the total historical extrapolation with the one of the current (or last) month?

As for the demand being "permanently lost", I have doubts about it. Consider a new city, with abundant ID demand. If you don't want much ID industry in your city, you just don't zone for it, and develop your city in other ways (R, C etc). But even if you play your city (and region), for many years demand will still be there, so what is really "lost"?

[RippleJet]

So how about replacing the total historical extrapolation with the one of the current (or last) month?

Those are the ones you see under "3 months" and "1 year".
Since the monthly extrapolation is 0.00 in more than 90% of the cases, I never saw the need to specifiy it in any more detail than the sum of the last three months, the sum of the last 12 months and the very total.

As for the demand being "permanently lost", I have doubts about it. Consider a new city, with abundant ID demand. If you don't want much ID industry in your city, you just don't zone for it, and develop your city in other ways (R, C etc). But even if you play your city (and region), for many years demand will still be there, so what is really "lost"?

Well, I can only quote what Prima said...
I know myself though, that growth does become slower if you quickly jump between your cities, without allowing any growth to occur.

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.

"permanently lost"

That is why I said that I'm pretty sure any extrapolation that has been lost (hasn't been fulfilled in the surroundings) may appear anew.
Thus, even if the first extrapolation was permanently lost, nothing that I can see would stop that demand to be extrapolated once more if you return to the first city.

Let's take an example:

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

Now, returning to the first city, that extrapolation would spur residential growth.
If however, you did not let the second city have that industrial growth, no residential extrapolation would have occurred either.

Since the first city to a certain degree (while you were playing it, and this is probably where that 10% comes into play) was assuming that industry did grow in the neighbourhood,
it will now find itself back in a situation where that growth has not yet occurred, and thus it will have to start extrapolating that industrial demand a second time.

[SC4BOY]

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.