About the fires, I believe that there is some amount of randomness involved. I think the fire risk doesn't increase linearly over time, but I certainly have no figures for you, sorry.

I think the fire risk doesn't increase linearly over time

Yes, it certainly does not. I built a row of buildings of the same type and they didn't burn in the order I built them. It makes it hard to figure out the exact maximum time interval for the service. I am ok with just an (under)estimation.

Equi,

All walker spawning is synchronised to the game's 50-tick 'cycle' (1/16th of a month. If you want that in tiles, it's three-and-a-third ). Some walkers, including prefects and engineers, will emerge on the next available spawning tick after they get back from their previous walk. Other walkers will rest for one or more complete cycles in addition to whatever remains of the current cycle before emerging - market traders, for example, rest two complete cycles. Therefore the exact rest period will vary on different walks. A market trader on a 50-tile walk will arrive home 750 ticks after she set off, while one on a 52-tile walk will arrive home after 780 ticks. Both will emerge on tick 900.

There is complication with prefects, engineers, entertainers and tax collectors because you don't always see them spawn. See this Pharaoh thread for the nitty gritty (Pharaoh works pretty much the same except that a cycle is 51 ticks).

I'm not aware that the information you seek on fire risk is known. The game appears to select a proportion of buildings each cycle and increments the fire risk in those buildings. I posted some information in fires in desert provinces (wherein I once again demonstrate my inability to reliably spell "Pharaoh") from which you can see that a desert tent would need to be passed by a prefect every two weeks to be absolutely guaranteed not to burn, but that it is highly unlikely to actually need that level of protection.

I don't remember whether the increment for Grand Insulae is also 10 points or some lower figure (I'll try and find out) but even at 5 points you would need a prefect every 5 weeks to be 100% safe for all time.

Your market buyer question I'm not certain about so I'll leave that for someone else.

Edit: Fire risk in GIs and most other buildings on central maps appears to be always a multiple of 5 (tents 10, Luxury Palaces and maybe other patrician houses 2). Fire risk in GIs in desert provinces appears to be always a multiple of 8 (tents 13, Large Villas and maybe othe patrician houses 5). That surprises me, since it suggests that GIs in desert provinces are 60% more likely to catch fire than those in central provinces while the figure for tents is only 30% more likely. Still, I've looked at enough saves...

[This message has been edited by Trium (edited 04-10-2013 @ 04:59 AM).]

Thank you for the good (as always) answer, Trium.

Quoted from Trium:

In all my references, a month is 816 'ticks, a week is 204 ticks.

50-tick 'cycle'...If you want that in tiles, it's three-and-a-third

a desert tent might combust after only two weeks without prefect attention while a Central tent might do so after 2.5 weeks

If I counted right, that means that a central tent might burn after 34 tiles. That's very fast
At 5 points increment it's 68 tiles. It's better, but it won't be easy to design a fireproof city.

I think you counted right, but note that the quote from a Pharaoh thread refers to Pharaoh time. Caesar 3 time has 50 ticks per cycle, but still 16 cycles per month so 800 ticks per month (200 per week). 2.5 weeks = 500 / 15 per tile = 33.33 tiles of travel.

But do bear in mind this is leaving nothing at all to chance. I don't know what proportion of buildings have their risk incremented each cycle but even if it's as many as a quarter the odds against getting the 20 consecutive increments required to torch a central GI in 5 weeks (~68 tiles of travel) is a million million to one. I'd bet against that ever happening, so I think you can afford to take a little more risk.

In case you missed it, I've added some more information to my last post.

[This message has been edited by Trium (edited 04-10-2013 @ 05:26 AM).]

Quoted from equi:

Does market buyer distribute all food and goods her market has or only what she is buying? i.e. when acting as market trader, is she completely equivalent?

As far as I know, a market buyer distributes goods like a market trader--the goods that the basket boys are carrying are not distributed until they get into the market.

That surprises me, since it suggests that GIs in desert provinces are 60% more likely to catch fire than those in central provinces while the figure for tents is only 30% more likely

It's now clear why tents in the desert are more combustible than those figures suggest - vacant lots increment by 3 points at a time in the desert. Once settled, the resulting tent has already accumulated some risk. Vacant lots do not accumulate risk at all on central maps.

I've also verified that the increments for shacks are the same as for tents (10 or 13 points central/desert), that all patrician housing increments at 2 or 5 points, and that all other combustible buildings increment at 5 or 8 points.

[This message has been edited by Trium (edited 04-11-2013 @ 05:03 AM).]

Too hasty. You'd think I'd learn.

Desert vacant lots do indeed increment 3 points, but only once. If a passing prefect resets them to zero risk they can increment to 3 points again, but they will not accumulate any more than 3 until they are occupied. So it doesn't make a lot of difference really.

Hi,

Here are my fire test results for Central Climate:



In the table earliest and latest fire is shown to give an idea about fluctuating. Obviously it is the earliest fire that matters.

1575 means, houses at these level will start catching fire 1575 ticks after a prefect has passed by. One month is 800 ticks so the next column gives a better idea about what 1575 ticks mean.

Max prefect loop is calculated by prefect's walk speed which is 15 ticks per tile. I allowed 65 ticks for dispatch time. I don't claim that a 100 tile loop will work for lower level houses. Of course it won't work if your prefect walks elsewhere or if the houses are in some of the seasonal fire risk areas. These numbers are meant to give an idea when making design choices.

Houses are divided into three groups according how quickly they catch fire. During tests to eliminate other variables I used the same houses at different housing levels at the same moment in the game.

For example I tested 30 luxury palaces starting from beginning of January in year 4 until they caught fire. Then I went back to an earlier save, devolved the houses to large palace and tested again starting from the same January with the same prefects making the same walks.

To be more precise, in earliest saves, I added long prefect lines, like 8 prefects next to each other to be able to delete them quickly. When the prefects were deleted, usually none of the houses had fire risk. If some house had, then the house was deleted too because the test is about measuring the duration from no fire risk to burning.

In early tests I tested with only one house, expecting to find fixed intervals but soon realized that there was a lot fluctuation.

During tests I used a single fruit farm and a granary to measure two different moments and then calculated the duration between these moments. I think we all know how to do this.

As a side note, the fire risk bars have 11 different levels. To see them press F on your keyboard and switch to fire risk overlay.

Industry, services and houses have all the same 11 levels for fire risk. If you mark the height of red bars on a piece of paper, you can hold it against the monitor and tell what level another house is at. Fire will start a short while after 11.th bar and never before the bar has reached 11.th level.

I decided to move this topic here to separate it from another topic which was unrelated.

Does anyone have any (perhaps very rough) idea on how often a house (say grand insulae) has to be passed by a prefect to ensure that it won't burn down? Of course it's different in central and desert provinces.

The answer is every 6 months.

[This message has been edited by Philon (edited 12-31-2013 @ 02:39 PM).]

Hi again, Philon. I seem to be (unintentionally) stalking you

Here are my fire test results for Central Climate

I'd be very wary of drawing hard conclusions about fire risk from relatively limited testing unless you can actually come up with a model that explains how the game calculates the risk. While I'd agree that your "minimum" figures will probably be OK for most situations, I wouldn't bet on a player not finding a tent torched somewhat quicker in some (perhaps exceptional) circumstances.

I took the career Valentia and flooded the space near the entry point with vacant lots. After merging, I had 247 small tents. I deleted the prefects and artificially zeroed fire risk everywhere by editing the game file. I counted (50-tick) risk increment cycles rather than ticks, since the tick count depends on exactly where in the cycle you start observing. Since central tents have an increment of 10 points the risk bars grow with every increment making it easier to see which tents are receiving an increment and which are not. Usually around 10% - 15% of tents at a time get an increment (though sometimes outside this range). I had some very hairy fire risk, but no fires until cycle 59 - almost 3000 "ticks" and considerably at odds with the upper limit you posted (if I understood the meaning of that column correctly). I appreciate that it is the lower limit that counts, but I'm surprised to find such a variance.

I did discover something after running several times. All the tents which eventually caught fire (30-odd of them) received their first increment on the same cycle (actually cycle #6). Watching carefully, they eventually received a second increment several cycles later, and so on. All the way from zero risk to catching fire, these same tents behaved as a group, all augmenting risk or none doing so. Focussing on the group of tents where risk first appeared, these too escalated in tandem. The process is therefore not quite so random as we thought.

I don't currently know what groups these tents together, or what they have in common. The obvious suspect is the value of the "random" number associated with each tile on the map but it doesn't seem to be so, at least not used in the way it usually is (taking just the last three bits of the binary representation).

In most tests where I've deleted tents to see if that changes the outcome the risk in the remaining tents has been exactly the same, except in one case (which I've been unable to replicate) in which three 1x1 tents broke rank and combusted a month early. No idea why.

More observation needed (but not tonight)

or if the houses are in some of the seasonal fire risk areas.

I'm not sure what you are referring to. Do you mean desert maps, or am I missing something?

[This message has been edited by Trium (edited 12-30-2013 @ 09:14 PM).]

After merging, I had 247 small tents. I deleted the prefects ...

This is different than a prefect passing by a tent. What we want to measure is the time between two prefect visits for a house not to catch fire.

Deleting prefects is pretty close to that but is not the same because when a prefect passes by a house, the house has no fire risk. So the moment you deleted the prefects, no house should have fire risk. Did you check that?

When I checked, I saw many houses that had fire risk the moment prefects were deleted because there wasn't a prefect that just passed by even though I build many.

So here is my test method:
1. build many houses
2. build many prefects (preferably all lined up for deleting easily)
3. run for a while
4. delete prefects
5 switch to fire view and delete houses that have any fire risk

Now the test is more accurate. Can you find house that burns in less than the minimum time the table shows?

Another thing I noticed is the flexibility the bar levels rise. They vary too much. But interestingly, the moment fire starts is more stable. So I would ignore bar levels. After all the test is not about finding about when each of the 11 bar levels will rise.

While I understand that there is a lot of fluctuation, in my opinion this doesn't matter because, if I have build a prefect that makes circling trips and I can control the time between his each visits (15 ticks per road tile) all I need to know is the minimum. Anything else than the minimums don't count.

For example lets say I have a large tent block and I have one of these circling prefects that makes 4/4 circling trips starting from a gatehouse. I can control exactly at what intervals he is going to pass by.

According the table the 100 tiles road tiles is the max. That's very good. So I build a 100 tile loop.

Afterwards I run it and no house catches fire. At this point I'm not going to say something like, "If I had build the loop 110 tiles instead 100, some houses still don't catch fire. I'm wasting valuable prefect loop length".

No, you can't say that. That's not a correct reasoning. It doesn't matter if 299 houses don't catch fire if 1 house does. We are not measuring houses that don't catch fire.

So, I stand by my table unless you can show me one of two things:
1) A tent that catches fire in less than 1575 ticks. In first tick when I switch to fire view there should be none.
2) A large group of tents where none of them catches fire after 1575 ticks or a short time after that.

[This message has been edited by Philon (edited 12-31-2013 @ 01:36 PM).]

or if the houses are in some of the seasonal fire risk areas.

I mean seasonal fire risk areas that happen every 5 years. I noticed that in a few maps. On the largest size map I saw maybe 6 areas. The areas were small. I would say 10x10. Every 5 years (could be 4, it has been long time since I saw that) in one of these spots fire bars will rise quicker than they normally do.

Another interesting thing is, if I intentionally avoid fire in one of these areas by going back to an earlier sav and building more prefects around that area, then the risk jumps to one of the other patch areas.

This is something I have known for years. That makes it difficult working in central climate because I want to control fire and this randomness ruins that or makes it very hard.

Recently I was reading one of Steph Amon's forum messages where he talks about the same.

I could try to find a sav file where this occurs.

[This message has been edited by Philon (edited 12-31-2013 @ 11:40 AM).]

Quoted from Philon:

Recently I was reading one of Steph Amon's forum messages where he talks about the same.

Please tell us where that was.

OK, I will check after dinner.

Brugle,

I can't find it. I used firefox history feature and manually checked a few topics of StephAmon that I might have opened but couldn't find it. From memory his paragraph was something like this:

"Every time I played this map my barber caught fire. Yes, maybe a barber is not one of the most important buildings but I don't want my barber to catch fire. It appears the barber is on one of the seasonal fire risk areas and I could just move the barber elsewhere."

Quote from Trium:
I had some very hairy fire risk, but no fires until cycle 59 - almost 3000 "ticks" and considerably at odds with the upper limit you posted (if I understood the meaning of that column correctly).

Yes, because the meaning is different from what you understand because of my poor wording. I have now replaced the table image. It now says "Latest First Fire".

In my tests I used a group of houses, usually over 30 houses. When I tested I saw that the first fire started after 1575 ticks. But that didn't always happen. Sometimes the first fire started later. That columns shows that later time "Latest First Fire".

The fluctuations are high. They could have been even higher. But again this doesn't matter. Let's say some tents don't catch fire for 10 months instead 2 months. This is not actually happening. maybe you could find a tent that doesn't catch fire for 4 months. That might happen. But let's just say you found one that didn't burn for 10 months.

Does that change anything? Do I need to change my numbers? No. Because my numbers show the minimum. If you can find a tent that burns in less than 2 months or if you build many tents and none of them burns in 2 months for many prefect circles, then yes I would have to change my numbers.

[This message has been edited by Philon (edited 12-31-2013 @ 02:45 PM).]

Quoted from Philon:

Deleting prefects is pretty close to that but is not the same because when a prefect passes by a house, the house has no fire risk. So the moment you deleted the prefects, no house should have fire risk. Did you check that?

With all respect, I stated in my earlier post that I zeroed all fire risk by editing the game file. This is at least as good as your method for establishing a level playing field.

I'd like to establish exactly how the game calculates fire risk. I'm not here to undermine your theories. I know you don't care much for mechanics but it's horses for courses and I'm unhappy to accept that "the answer is 6 months" because you haven't observed it being any less.

My test file (which begins with no risk anywhere) is transiently available here (this link will not persist indefinitely). There is a timberyard for counting cycles but it's just as easy to count how often bars increment in the fire overlay.

The fact that this save survives so long without fire is not really the issue. It demonstrates, if you look closely enough, that risk increments are "dealt" out to a particular group of tents each cycle and takes us a small step closer to understanding the overall picture. I dare say you are happy with the heuristic generality but I'd like to know more

Hi Trium,

I know you mentioned that you edited the file to reset fire in the code but I still think this is not the same thing. I think the time fire starts is not a result of the fire bars.

I have seen service buildings stuck at bar 11 for ages. However the time they started to burn was still similar to other buildings.

So my theory is that fire starts according to a master clock but the bars are loosely based on the same master clock. Because I don't care about the bars, I didn't make tests about them.

But if you say you zeroed the bars in the code and it is the same as a prefect just passing by and zeroing fire risk, I don't agree with that.

I understand that there might be an underlying formula according which fire is calculated. This formula might change the fire risk from house to house for this month. It might change fire risk for month to month for the same house. But this doesn't change the fact that what matters is the minimum duration regardless the particular house or the particular month.

At the end when we build a loop and let a prefect circle around it for years we don't want any fire for any month for any building.

Therefore your formula too will come up with a minimum regardless the month and regardless the house. If at the end you tell me the that the minimum should be 1600 instead 1575, I would say, yeah that's good to know. I would expect this kind of small error.

[This message has been edited by Philon (edited 12-31-2013 @ 04:09 PM).]

Trium,

I changed my mind. The underlying mechanism might be more important than my minimums that make more sense if building let's say a block of 80 large tents. But we are not building only housing blocks. I also use small tents for labour access and I only build one here and one there.

I have put the first four levels of houses (tents and sacks) in one group. But there appears to be many different clocks for this group. I don't know how many clocks but it is more than 8.

For example, I have build around 50 tents. 6 of them are on the same clock. This means their bars rise at the same time and they catch fire at the same time. The time it took for them to catch fire was 4575 ticks.

Now, I will admit that I wasn't expecting such a high number and that number being so high, has increased my curiosity.

Earlier when I was testing I used many houses. Naturally the first fire would start between 1575 to 1800 ticks because one of the clocks that runs quicker would exist.

But lets say there are 40 different clocks and a few of them run over 5000 ticks for tents. I would be happier to build my labour access tents on these clocks instead the 1575 clock. If I can do that, it would be great. So now, I'm all for testing and finding a formula. Let's try to do that.

I will check if the tents that are on the 4575 clock will switch to another clock later on, or if I build some roads around them. I want to know if this is hard coded into the terrain like 2x2 merging ability or if it is something that changes or something I can manipulate.

[This message has been edited by Philon (edited 12-31-2013 @ 08:38 PM).]

Quoted from Philon:

I want to know if this is hard coded into the terrain like 2x2 merging ability or if it is something that changes or something I can manipulate.

Me too. I'm still trying to find something in common between the buildings that increment risk on the same tick (not much time tonight with New Year celebrations). If it had been as simple as the last three bits of a random number that would only give 8 possible outcomes (and so, in your terminology, 8 clocks) which would really narrow things down. I'm sure you've recognised that the first group to get risk is not necessarily the first to catch fire, and I agree that the shortest time is what matters.

I know you mentioned that you edited the file to reset fire in the code but I still think this is not the same thing. I think the time fire starts is not a result of the fire bars.

I'll have to disagree. Zero fire risk occurs because the number 0 is stored in the appropriate field in the building table entry. Whether that's because a prefect walked by or because I put it there, it's the same. It will increment the next time that building's "clock" (or rather the clock for the group which includes that building) says it's time.

The bars relate directly to the number of points recorded in that same field. The smallest bar indicates 1 through 9 and therefore doesn't appear on tents on a central map (which go straight to 10). Progressively larger bars indicate 10, 20, 30 etc.

I've posted before that fire starts at 100 (10 increments for central tents). This is not strictly true - fire starts on the next increment after reaching 100 (so it takes 11 increments for central tents). As with all other increments, this can occur on the next (50-tick) cycle after risk reaches 100 ("this building could catch fire at any moment") or it might survive for several more cycles. Either way, I'm certain that fire only occurs in buildings where risk is 100* and it is showing the 11th bar.

For service/industry buildings central province fire risk increments five points at a time. The first two increments are visible on the overlay but subsequently it takes two increments to raise the bar another level. This might mislead a casual observation.

I have put the first four levels of houses (tents and sacks) in one group. But there appears to be many different clocks for this group. I don't know how many clocks but it is more than 8.

For example, I have build around 50 tents. 6 of them are on the same clock.

That is not very far from 1 in 8. I still strongly suspect that for the timing of increments some bits from the "random" seed are used in some way and that only a limited number of outcomes would be possible (2^n). I think we agree that the size of increments falls into one of only three groups as per your chart and my reply #7

*excluding fires caused by rioters, earthquakes, Mercury, etc or those spread from nearby burning buildings.

[This message has been edited by Trium (edited 12-31-2013 @ 09:24 PM).]

Trium,

I might have found something. I took one of the 6 houses that finished at 4575 ticks. I gave it a little longer prefect cover at the start, meaning I pushed the beginning of the clock further to see if it will remain on the same clock if the prefect had passes by later.

It didn't. It switched to a 4975 clock. Then I thought, let's look at the differences between from one bar level to the next. In excel that is easy to do. That's when I found something interesting.

The difference between bar levels seems to be in the same order. In one of them I have 1145 and 1150 but that must be a mistake on my part.

So the differences go like this:
400
1150
800
50
550
300
150
100

I colour coded a few of the matching pairs to make it easier to see. Both clocks use the same intervals but for different bar levels.

The clock on the left uses the 400 ticks difference when going from bar 3 to bar 4 while the other clock uses 400 ticks difference when between bar 2 and 3.

There is some odd numbers at the start and end bars. They don't exactly match but there must be some some rule like catching the closest 250 tick or something.



Bar 1 is left empty because tents don't have the shortest bar (the one without a column head). I will do more tests to see if I can find the rest of that list that starts with 400, 1150, 800, 50, etc and see if there are many of these lists.

Do you know these conveyor belt sushi restaurants? They have moving plates in a circle. The structure seems to be like that. You fill 12 (or 11 for tents) of these plates in a row. Each plate on the conveyor belt has a different size. The total food you can put in all plates is determined by from which plate you start filling.

Edit:
The reason why I earlier thought bar heights are not important is because I saw a service building waiting very long at bar 11 even though another service building waited much shorter at 11 and they bought caught fire around the same time. But you are right. Bar times do matter as seen from the conveyor belt structure and this structure explains the reason for all the fluctuations.

I have to say that is a nice way of adding randomness by the programmers. I don't know if most programmers are so good but Caesar 3 programmers seem to be all geniuses.

[This message has been edited by Philon (edited 12-31-2013 @ 10:04 PM).]

I gave it a little longer prefect cover at the start, meaning I pushed the beginning of the clock further to see if it will remain on the same clock if the prefect had passes by later.

It didn't.

I think it did (if we're thinking of a "clock" in the same way). It received all its increments in the same game cycle that it did first time. It's just that you reset to zero and so negated the first increment, so now it gets its second increment when it previously got its third.

The difference between bar levels seems to be in the same order.

To be honest, I wouldn't have expected anything different. I believe the increments come at intervals of game time (derived from some algorithm) and not according to when a prefect last passed. In other words, the clock does not start ticking when a prefect passes - it is already ticking. The next increment is due when it is due independent of any prefect activity.

[This message has been edited by Trium (edited 12-31-2013 @ 10:50 PM).]

Trium,

The list I posted above starting with 1150, 800, 50, etc is now over 100 numbers long and it doesn't repeat itself yet.

I have run some other tests. I deleted the house that I was using for this clock and build a new tent in the same spot about 3 years later than the first house. It is now June 3. I checked and re-checked and the new house doesn't join the clock at any point known so far. It's numbers were completely new.

Then I though lets build another tent in June 3 on same spot. This third tent repeated the numbers of the earlier June 3 tent. Then a July 3 tent repeated the same numbers like the two June 3 tents but started one number later.

In short, I drew two conclusions:

1. The spot the house is build (the northern tile, and it doesn't matter whether it is 1x1 or 2x2 that have the same northern tile) determines the clock the house is going to use.

2. The moment the immigrant arrives in game time (regardless when you build the vacant lot) determines at what point the house is going to join the clock. The calender month doesn't matter. The clock is already running for the terrain spot. If the immigrant arrives in late June 3 it will join the clock at some point.

If I delay the immigrants arrival by building some obstacles and he arrives early July but is still able to catch the same interval then he too will join the clock as the immigrant who arrived in late June.

If I delay the immigrants arrival even further, he will miss the first interval and join the clock on the next interval.

Because I can delete all houses and then rebuild a house at the same month at the same spot and it will use the intervals that I found earlier, that means the clock for that terrain tile is saved somewhere in the sav file.

I don't know how the game saves it. I will post the numbers and maybe you can find where these come from. Are they generated on the fly by multiplying game clock and a set of numbers that change according the terrain? Are they pulled from the long list that is written somewhere and the terrain has just a reference to which list it is using? I don't know that part.

400
1150
800
50
550
300
150
100
300
400
150
550
100
150
200
150
50
500
550
100
100
1250
1000
150
550
500
50
300
250
100
450
450
200
600
100
950
650
100
50
50
150
100
150
50
800
200
850
450
400
350
100
50
2150
150
800
450
600
450
450
1050
750
450
300
1100
1300
150
450
550
800
600
250
450
150
250
400
350
1000
1000
800
50
350
300
150
150
200
700
100
200
250
250
300
600
1450
550
550
500
200
50
150
50
200
100
50
700
400
100

[This message has been edited by Philon (edited 01-01-2014 @ 05:53 AM).]

Philon - you need to get out more

You appear to have been watching for about 46 years. In that time, the shortest time for 11 increments (enough to torch the tent from a zero start) is 2300 ticks. A prefect might set the risk to zero immediately before the first increment, or it might do so immediately after the previous increment. In the latter case, that would (in this instance) make almost 2600 ticks total. I'd expect all tents in the same group to give identical results.

I don't know how the game saves it. I will post the numbers and maybe you can find where these come from. Are they generated on the fly by multiplying game clock and a set of numbers that change according the terrain? Are they pulled from the long list that is written somewhere and the terrain has just a reference to which list it is using? I don't know that part.

I've always assumed (and continue to believe) that a computation is made once every 50 ticks, so I think on the fly is more likely (there aren't many parts of the game file where purpose is unknown and long strings of data might lurk). Lets suppose that the computation returns "true" for a minority of buildings each time and "false" for the remainder. Risk is incremented in those buildings which return "true". Once it is established that two or more buildings return "true" in the same computation on one occasion, they apparently will return identical results in every computation. Effectively, their risk increments are synchronised.

1. The spot the house is build (the northern tile, and it doesn't matter whether it is 1x1 or 2x2 that have the same northern tile) determines the clock the house is going to use.

This had always been my guess, however it conflicts with:

I deleted the house that I was using for this clock and build a new tent in the same spot about 3 years later than the first house. It is now June 3. I checked and re-checked and the new house doesn't join the clock at any point known so far. It's numbers were completely new.

I was trying to figure this out myself a couple of days back. If you have my save from reply #17 it can be seen that the northernmost tent (one of those that catch fire first) synchronises with 30-odd others including, for example, the 1x1's next to the engineer at the other end of the same road).

• If I reload and delete that northernmost tent, immediately replacing it with somethings else (with the northern tile in the same location) it synchronises with the clinic at the road-end.



• If I reload and replace that tent with another, it misses the next increment seen in the clinic because it is unoccupied. Once occupied, however, it continues to synchronise with the clinic.

What I think is happening is that when I replace the tent, the new structure is not appearing in the same place in the internal Buildings List because there are "holes" left when 2x2's formed.

The first-built tent is next-door-but-one to the northernmost and synchronises with the clinic. No "holes" can precede this one, so whatever I build in its place will occupy the same slot in the BL. Sure enough:

• If I delete it and replace it with anything the new building synchronizes with the clinic


• If I delete it, fill its BL slot by building something elsewhere, then replace the tent the new building it does not synchronise with the clinic

So is it simply Building List position that matters? No. In either of the above cases, putting the new structure in another location changes the synchronization. An explanation might be that a "random" seed is used as one of the inputs to the computation and a new seed is generated for the next computation. The game is working through the Buildings List in order, so changing this order changes the value of the seed that is used when a particular building is processed.

I suspect that in your 3-year example the new tent did not occupy the same position in the BL as the one you deleted (either because of merging or because of other deletions)

2. The moment the immigrant arrives in game time (regardless when you build the vacant lot) determines at what point the house is going to join the clock. The calender month doesn't matter. The clock is already running for the terrain spot. If the immigrant arrives in late June 3 it will join the clock at some point.

I think that supports my reply #22.

[This message has been edited by Trium (edited 01-01-2014 @ 08:30 AM).]

Getting these numbers was a long job. I was hoping they would start repeating after 100. In total it is 44050 ticks which is less than 5 years, but yeah it took longer than I was hoping.

Once it is established that two or more buildings return "true" in the same computation on one occasion, they apparently will return identical results in every computation. Effectively, their risk increments are synchronised.

Yes that would work if the computation has a variable that is fixed in the terrain and another variable that changes according game time.

I think maybe the next step is to find out how many clocks there are. The terrain alone couldn't have so many variables.

I checked my numbers again. There is indeed a conflict. The second house intervals were unrelated to the first. The third house was unrelated to the first two. Notice that all these houses are build to the same spot during the same game time.

Then house 4 and 5 was matching the numbers of 3.

Quoted from Philon:

I think maybe the next step is to find out how many clocks there are.

This was my agenda. I think we will find that there are only a few different synchronisations (perhaps 8 but maybe more) in any given map. However I think that the variation from one map to another is probably virually limitless.

I'd like to be proven wrong but if not I think we will never really solve the puzzle. The best we can expect to derive from our research is a close approximation to how much time is the absolute minimum we might expect a building to survive, allowing for everything we have learnt. In this respect, we come back to your original research, ie the analysis of observational data without necessarily understanding the underlying mechanics.

I found 8 clocks but didn't measure the intervals. It is too much work for little gain.

I think now I know enough to shelf my part of the reseach. I'm not too interested in finding the underlying mechanism if it isn't going to help much when designing a city. Because the intervals seem to be changing forever, that ruined the research for me. I was hoping it would be easier than that.

I bet some less creative programmers would just pick a few different fire risk rise speeds that increase by a factor of let's say 9,12,15 and 18 and then spread those randomly to houses. But Caesar 3 programmers decided to make the game more interesting than that.

What I'm wondering is how did they balance the level of randomness in fire with the random walk routes of prefects. Somehow these are exceptionally well balanced. The game is not too easy and not too difficult. It is just right.