Programmatically generating a city: A savegame experiment

[smf_16 1,835]

I thought I'd add in some eye candy to keep you guys warm during all the technical stuff. I've tried out the skyline on a medium city tile and created two clusters with different radiuses and maximum heights. This is the result:

9 hours ago, rivit said:

There's only one way I know of to distinguish base from overlay and that requires reading the texture to see if it has transparency - base have none, overlays do.

I'm going to do some tests and see if the game actually uses that priority byte, or whether it has other ways to figure out what the base and overlay textures are. If I will have to parse every single texture file before plopping and check it for transparency I fear that the time to generate a city will increase dramatically. The medium tile you see above was generated in 2.6s, which is acceptable, but having to parse all texture files will probably increase it a lot, even with appropriate caching strategies. I wonder how the PIM-X does it though, but unfortunately the code of it seems to be lost.

[smf_16 1,835]

3 hours ago, smf_16 said:

I'm going to do some tests and see if the game actually uses that priority byte, or whether it has other ways to figure out what the base and overlay textures are

Well good news on that front. I could leave the priority byte set to 0x00 and the game was able to find out what the base and overlay textures were on itself. That's probably because it uses them from the Lot Exemplar anyway. As long as the record in the Texture Subfile contains the correct coordinates that correspond to the lot coordinates, but inset with 0.1, the game will reuse the record, but look up the Lot Exemplar to build up the textures again.

Now, concerning the brown boxes. I've managed to track down a specific lot where a brown box appears, the lot has TGI 0x6534284a 0xa8fbd372 0x600029b0 and hosts the Euro Lux Boutique - yuk! I opened the lot in PIM-X Lot Editor and went looking for the prop on the position of the brown box. As @carlosmarcelo already noticed, this is related to the graffiti:

Apparently though it's the graffiti artist that is the issue here with TGI 0x6534284a 0xc977c536 0x213b0000: if I leave out that prop the brown box doesn't show. In that Prop Exemplar, the Resource Key Type 0 (RKT0) is set to 0x29A5D1EC 0x2A2458F9 0x213B0000, which is an ATC File. This thing is new to me, but it looks like those animated props need to have some specific values in the Prop Subfile that I'm not setting yet.

In order to be able to hunt this down, I've modified the small 1x1 R§ lot from @CorinaMarie to include that specific animated prop on it. Subsequently I "hand plopped" the lot and also programatically plopped one and then inspected the differences. Apart from the coordinates obviously, the only difference I could find was the state byte in the Prop Subfile. The wiki doesn't really explain what the state byte was doing, but for some reason my code set it to 0x01, though I cannot remember anymore why I did this. I changed this to 0x00 and poof! All the brown boxes were gone and the graffiti artist nicely showed up:

Well, that was definitely a lot easier than I thought. Note that I didn't even have to set anything concerning the animations: I could leave them all uninitialized (so set to 0x00) and still they were all properly playing in the game. That's probably for the same reason as with the textures: the game probably serializes those animation states, but just doesn't reuse them when opening the city again and as such we can leave it out - phew!

Now, let's quickly recap at where we are now. Given a lot exemplar TGI, I'm now able to plop the lot anywhere in the city. This means that the lot is properly inserted with its building, props and textures. Using this method I'm able to create a skyline by defining what lots I allow at which positions in the city.

However, I'm not really done yet. There are still a few issues that I noticed:

• First of all, in my skyline city some lots are immortal. They probably have overhanging buildings so I need to figure out why that is happening. I'm thinking that the buildings are asymmetrical. I recall @rivit mentioning something about assymmetric props. Currently I'm simply positioning the buildings & props using the (x,y,z) position stored in the LotConfigPropertyLotObject and then add halft the width or detph to both sides (inherently assuming that the building is symmetrical). I will probably need to use the minX and maxZ coordinates instead which are also present in the LotConfigPropertyLotObject.
• The lots don't have a zoneType set yet. That's what @carlosmarcelo already noticed as well and this is probably what caused the residentials that were facing a road to abandon in the same fashion as what happens with the ploppable residentials. Adding the zoneType should be easy though: I can simply look it up in the building exemplar.
• The buildings don't show up in the city overview. That's probably going to be the hardest part because I will need to figure out where to insert this. Could be that I will need to touch the SimGrids for this, but I have decoded those already back in July.
  
  

I'm quite satisfied with the progress I'm making however, so I'm confident that I'll get there soon as well!

[xxdita 1,097]

This is fascinating work. Is there any way to reverse what you've done? As in remove or replace a lot/building that is in a city? Or to track each instance of a given lot/building around the map? 

z-position deals with the starting height level of a prop/building. This is almost always 0, unless a building is rendered in multiple parts and needs to be stacked, and I'm quite certain this has to be done manually in Reader. I'm not aware of any tricks to do it in LE or PIMX's LE-X. 

[carlosmarcelo 975]

1 hour ago, smf_16 said:

The lots don't have a zoneType set yet.

Yesterday I tried use command "SC4 growify", but didn't have success. No one build became growified: the command's answer was "0 builds". 

His work is very incredible and the results have been excellent.. 

[smf_16 1,835]

2 hours ago, xxdita said:

This is fascinating work. Is there any way to reverse what you've done? As in remove or replace a lot/building that is in a city? Or to track each instance of a given lot/building around the map?

In short, everything is possible. It's just a matter of finding out how the Savegame works and how the different components are related to eachother. The key thing here is that it was long thought that Savegames could not be modified because they are protected by a checksum. Since the checksum algorithm was discovered, it means that we can modify anything we want in the Savegame.

In fact, reading was always already possible, so tracking each instance of a given lot/building was already possible before. If you want more info on the subject, I suggest you give my other thread a read as well. It's here that I've reported about the discovery.

2 hours ago, xxdita said:

z-position deals with the starting height level of a prop/building.

Be aware tham I'm referring to coordinates in the plane as (x, z) coordinates. Coordinates out of the plane are referenced as y. I know that this is different as in the Lot Editor of PIM-X, but it's the convention that was already used in the Wiki on the Savegame.

[xxdita 1,097]

I'm a big believer in calling things what they are. I'd rather have inaccuracies on the wiki updated to be factual than to keep using them and confusing people. 

[smf_16 1,835]

6 minutes ago, xxdita said:

I'd rather have inaccuracies on the wiki updated to be factual than to keep using them and confusing people.

Do you mean that you want to update the wiki to have horizontal coordinates be references as (x, y) instead of (x, z)? That doesn't seem like a good idea to me. If you look at the Prop Subfile for example, you see that the bounding box coordinates there are given as (x, y, z) and here in fact x and z are the horizontal coordinates of the city tile, the y coordinate is the height in the city, so the sign convention feels right. Moreover, this makes for a right handed coordinate system. Changing y and z would result in a left handed coordinate system. I wouldn't really call it an inaccuracy by the way, it's just a convention.

Additionally, the order of the reps in LotConfigPropertyLotObject follows the same convention. It's just the Lot Editor in the PIM-X that displays it this way:

[smf_16 1,835]

For those of you wondering what a Large City tile would look like, have a look at the picture below. I've modified the algorithm a bit so that it only uses low density residential for the suburbs. As such we don't end up with a blue roofed city full of low density commercial.

Thinking of it, it might be neat to have the algorithm generate "randomized" suburbs wihtin a fixed grid, as commonly seen in many North American cities (image below is from Denver):

Would be a nice challenge as well to write such a pseudo random algorithm. I've never really done anything like that.

[rivit 3,391]

You are going to have us running random cities for a long time. It will be particularly interesting to 'fix' the logistics in such a map as it will be an instant transport snarl-up asking for urban reorganisation just to get from A to B. Love it. If you use a Peano or Hilbert space filling algorithm then there would be complete chaos on just one road.

~~~

Nice that the overlays sorted themselves - a bonus win from time to time sure helps.

~~~

I too agree with XZY - its the DirectX rendering convention that the game is based on.

[smf_16 1,835]

1 hour ago, rivit said:

If you use a Peano or Hilbert space filling algorithm then there would be complete chaos on just one road.

You mean like this 

 

  Edited March 16, 2020 by smf_16  
Changed the grid from 3x3 to 4x4

[rivit 3,391]

LOL - try finding a way out of this buster!

[smf_16 1,835]

Allright, after having some fun last night with the Hilbert curve, back to the technical stuff. As mentioned above I'm now setting the zoneType in the Lot Subfile based on what I can find in the Lot Exemplar: I just have to read in the LotConfigPropertyZoneTypes and then pick the most appropriate one, meaning that if a lot only grows on medium density residential, I pick medium. If it grows on both low density residential and medium density, I pick low density. I tried generating a small city with it as can be seen below. All lots are grown by my program, only the road and the power plant are hand plopped.

As can be seen, all citizens were properly able to find their way out to the one and only shop in the city that was providing jobs. Neat! Now, there were still a few things to note:

• All residential lots in the city have set their occupancy to 5/5 after running the simulation for a while. Still, the mayor mode view shows a population of 0, even after running the simulation for several months. I actually expected that the simulator would recalculate the city's population after every game month but apparently it does not do so. I think we can also draw the conclusion that occupancy shown when querying a lot has nothing to do with with the population of the city. I remember reading an article once on "virtual jobs" if you plop a commercial building somewhere when there's no demand for it - think it was made by Ripplejet. Probably a similar effect is going on here: virtual residents.
• When demolishing a residential, the green zone texture properly shows up. However, running the simulation doesn't cause the building to redevelop. Note that this behavior was also observed with the growification: if you demolished a growified building, it would never redevelop. My guess is that the game stores a flag somewhere that marks whether the lot is suitable for redevelopment or not. Just to be complete, if I created new zones, they became properly occupied. If I can fix this, I will probably update my growification command as well to make it fully functional.
• When turning on and off the zone view, the commercial lot had its textures disappear, as can be seen in the picture. Interestingly, after saving and reopening the city the textures did not reappear. Note how this didn't happen with the residential lots. It seems related to the fact that the commercial lot is a Maxis lot, while the residential lot is the lot that @CorinaMarie made. I've noticed that if I plop "native" Maxis lots, the same happens for residentials.

Allright, let's try to tackle this texture problem first. I plopped the shop that was causing us issues twice in a city: the left one was "hand plopped" using the LotPlop cheat, the right one is generated by my program.

I then inspected the differences between the two - both in the Texture Subfile and in the Lot Subfile - and then tried to find out what difference between the two caused the textures to disappear. It turns out that it was the IID field in the Lot Subfile that was causing the issue. I noticed that my code accidentally used the IID of the building exemplar for this, while it should've been the IID of the lot exemplar. Fixing this caused the textures to properly reappear when turning off the zone view.

My guess here is that the game wants to rebuild the textures from the lot exemplar when you turn off the zone view and as such it couldn't find them because the IID that was set was not correct. Still it's weird that it didn't bother the game at all when opening the city, most importantly because it seemed to ignore the texture subfile anyway while opening the city! Strange behavior, but let's just be happy that it works now. 

A quick thought on the population not showing up: after looping all known C++ classes from the Savegame, my guess is that this information is probably stored in cSC4City with TID 0x8990c372. Unfortunately it is not yet decoded, so that's probably on the list for the coming days!

[smf_16 1,835]

I started the quest to find out why demolished buildings were not properly redeveloping. I've triple checked the Lot Subfile, tested various things but there seems to be absolutely no variable that controls whether the lot can be redeveloped or not.

So, I decided to go back to basics: instead of plopping lots, let's try to create RCI zones. That should be easy: just create an entry in the Lot Subfile with no building set. At least that's what I've seen when inspecting the Lot Subfile of a city with only RCI zones. However, when I tried this out no zones were showing up. I had to turn on the zones view to show them. When turning the zone view back off, the zones remained visible.

Therefore I inspected a city with a zone that was created "in game" again and found out that it also requires an entry in the Texture Subfile. This entry then has to be built up from these textures:

Now I noticed something intereseting here. The textures are black, but in the game they appear colored. Well, this explains what those 4 unknown bytes in the Texture Subfile are doing they are simply the rgba values for the textures! As a proof I set this to 0xff0000aa and it did indeed appear red in the game:

Great, nice that we have that one figured out as well. Of course turning the zone view on and off just painted the zone back to green, but at least we know that this is how the game colors its zones.

Now unfortunately just inserting the zones didn't allow any development. I verified that the city allowed development by plopping some jobs and then "hand zoning" some residential and all of them properly developed. I'm fairly sure now that upon zoning, the game inserts an entry somewhere in another subfile that marks a given tile or lot as "growable". The game probably only does this when you're actually zoning. So in the case of the growification, the initial building is a plopped building for which the game does not insert this entry. Setting the zoneType from 0x0f to something residential (0x01 for example) does fix the no road access problem, but as the game never marked the lot as "growable" it will never redevelop, not even when the building is demolished.

So the big question is now: where could the game store this? I'm planning on doing some research on this, but we'll probably have to look at 0x0990c138 (cSC4GrowthDeveloper) first. Odds are that it is simply a grid data structure that marks all growable lots, or perhaps an array with the coordinates of all growable tiles. In any case we're on for some more decoding!

[rivit 3,391]

5 hours ago, smf_16 said:

My guess here is that the game wants to rebuild the textures from the lot exemplar when you turn off the zone view and as such it couldn't find them because the IID that was set was not correct. Still it's weird that it didn't bother the game at all when opening the city, most importantly because it seemed to ignore the texture subfile anyway while opening the city! Strange behavior, but let's just be happy that it works now.

The same is probably true coming out of underground view or rather any view that redraws the textures.

16 minutes ago, smf_16 said:

Great, nice that we have that one figured out as well. Of course turning the zone view on and off just painted the zone back to green, but at least we know that this is how the game colors its zones.

There is an exemplar that controls these colors and textures - 6534284A-E7E2C2DB-E9482490   called Simulation - Zone Manager in  SC4DIR:\SimCity_1.dat.  

The textures you have shown are overlays - only the black outlines show in-game, the rest is the zone colors (in Simcity5.dat) - also rendered semi transparent - and the underlying lot and or terrain. These seem to be used in various different ways - as usual there seem to be three ways to do things, as the zones when dragged are just straight color pens/brushes from the exemplar.

[xxdita 1,097]

Other zone types are also possible. RippleJet experimented with a number of them. 

[CorinaMarie 29,605]

3 hours ago, rivit said:

There is an exemplar that controls these colors and textures - 6534284A-E7E2C2DB-E9482490   called Simulation - Zone Manager in  SC4DIR:\SimCity_1.dat. 

@smf_16

If it would help to see other values in your tests, here's the Deuteranopia version of the zone manager: Deuteranopia Zone Manager v1.4.dat

 

[Terring 6,473]

3 hours ago, xxdita said:

Other zone types are also possible. RippleJet experimented with a number of them. 

Wait, what? Can you please give us more information?

[CorinaMarie 29,605]

29 minutes ago, Terring said:

Wait, what? Can you please give us more information?

I imagine @RippleJet's experiments were over on Devotion, but I do know @simmaster07 investigated and implemented them in this post:

 

[xxdita 1,097]

9 hours ago, CorinaMarie said:

I imagine @RippleJet's experiments were over on Devotion, but I do know @simmaster07 investigated and implemented them in this post:

 

 

Probably a combination of SC4D and our BSC forum, like most BSC tests of the era. I know his zones were color-coded, but I don't remember which ones he was able to get growing anything, if any. Obviously, there's a lot more to it than just zoning. 

[smf_16 1,835]

18 hours ago, rivit said:

The same is probably true coming out of underground view or rather any view that redraws the textures.

Interestingly it didn't! I tried the pipes and the subway view, both did not redraw the textures. I think that this is because the zones view actually requires textures to be replaced. I think that the underground views simply hide the textures.

So, about that GrowthDeveloper that I was talking about yesterday. I had a look at it and it looks like it has always 12 records, each with a size of 62 bytes. The bytes didn't seem to make much sense at first sight. But given that it has always the same length, I didn't look into it any further because I don't think it contains what I'm looking for.

Therefore I decided to do some diffing of cities. I created a city with a 1x1 RCI zone, saved it, then created another 1x1 RCI zone and immediately saved the city again. I then wrote a small script that checks what files in the savegame have a differing length, and if the length did not differ, I checked the contents of the file itself for equality. The result is given below:

Spoiler

BUFF 0x499b23fe cSC4COMSerializer::SaveClassObjects
BUFF 0x49b9e604 cSC4SimGridUint16
BUFF 0x49b9e602 cSC4SimGridUint8
BUFF 0x2a5f877d cSC4AdvisorCityPlanning
BUFF 0xeac937b4 cSC4Advisor
BUFF 0xea19e825 cSC4AdvisorSafety
BUFF 0xca2c2a2f cSC4AdvisorUtility
SIZE 0xc9bd5d4a cSC4Lot FROM 86 TO 172
SIZE 0xc97f987c cSC4LotBaseTextureOccupant FROM 91 TO 182
BUFF 0xaa5292d7 cSC4AdvisorFinance
BUFF 0xa7e7f929 cSC424HourClock
BUFF 0x89c48f47 cSC4PropDeveloper
BUFF 0x6a5f8755 cSC4AdvisorHQ
BUFF 0x6a0f82b2 cSC4TrafficNetworkMap
BUFF 0x4be372cd cSC4AdvisorCitySituations
BUFF 0x4a3ad3e1 cSC4AdvisorTraffic
BUFF 0x49b9e603 cSC4SimGridSint8
SIZE 0x498f9b01 cSC4ZoneDeveloper FROM 16410 TO 16414
BUFF 0x298f9b2d cSC4ZoneManager
BUFF 0x0990c005 cSC4PowerSimulator
SIZE 0x098f964d cSC4OccupantManager FROM 148282 TO 148290
BUFF 0xe9c622d8 cSC43DRender
BUFF 0xe990be01 cSC4BudgetSimulator
BUFF 0xca14ca03 cSC4AutomataControllerManager
BUFF 0xca027edb SC4ReadRegionalCity

 

Phew, that's a reasonably small amount of differences. Let's look at them more in detail:

• It's logical that the COMSerializer differs: it just stores how many records there are of each file type and given that we created a new lot, it differs as well.
• Three SimGrids have changed: cSC4SimGridUint16, cSC4SimGridUint8 and cSC4SimGridSint8.
• There's a bunch of Advisory subfiles that has changed, we can probably ignore them.
• The Lot and Texture Subfile have a different length, but that's logical: we added a new lot.
• cSC4PropDeveloper differs from before, but we can probaby ignore it as it is related to props.
• cSC4TrafficNetworkMap differs from before. It's the Network Index Subfile. No idea why it has changed, but we can probably ignore it.
• The size of the zone developer has changed, but that's logical because the zone developer file simply contains references to all lots in the city.
• cSC4ZoneManager has changed as well, though the size remained the same. That's interesting. The file hasn't been decoded yet, but I have a strong feeling it might be related.
• cSC4PowerSimulator has changed, we can probably ignore this.
• cSC4OccupantManager has changed in size: that's logical because it's the Item Index. We know that if textures are added, they are added to the Item Index as well.
• cSC43DRender, we can probably ignore this
• cSC4BudgetSimulator has changed, that's logical because creating a new zone cost me §10.
• cSC4AutomataControllerManager, we can probably ignore it
• cSC4ReadRegionalCity, we can probably ignore it

The conclusion is that we should probably focus on the cSC4ZoneManager first. Remember that the SimGrids store the city data views so it's logical they have changed: I created a new lot which has a fire hazard, crime rate etc. etc. which means that it changes the SimGrids. I don't know yet if the SimGrids have an actual impact on the simulation, or whether they are just the output of the simulation. I'm inclined to say that they're merely views, so I'll put my focus first on decoding that cSC4ZoneManager file.

I inspected the cSC4ZoneManager file of a few cities and it looks that it always contains 1 record of 791 bytes, regardless of city size. I inspected the file and it looked like this:

Spoiler

17030000 4924bd9c 1c5cc211 0100
98815e1d 03e6b949 ff0f0000 01000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00100000 00100000 00100000 00100000 00100000 00100000 
00100000 00100000 00100000 00100000 00100000 00100000 00100000 00100000 
00100000 00100000 00100000 00100000 00100000 00100000 00100000 00100000 
00100000 00100000 00100000 00100000 00100000 00100000 00100000 00100000 
00100000 00100000 00100000 00000000 00000000 00000000 00000000 01000000 
01000000 01000000 01000000 01000000 01000000 04000000 01000000 01000000 
01000000 01000000 01000000 01000000 02000000 01000000 00800000 20000000 
20000000 20000000 20000000 20000000 20000000 30000000 20000000 20000000 
20000000 20000000 20000000 20000000 20000000 20000000 00000000 00000000 
0a000000 00000000 14000000 00000000 32000000 00000000 0a000000 00000000 
14000000 00000000 32000000 00000000 0a000000 00000000 14000000 00000000 
32000000 00000000 01000000 00000000 01000000 00000000 01000000 00000000 
01000000 00000000 32000000 00000000 01000000 00000000 00000000 00000000 
01000000 00000000 01000000 00000000 01000000 00000000 01000000 00000000 
01000000 00000000 01000000 00000000 01000000 00000000 01000000 00000000 
01000000 00000000 01000000 00000000 01000000 00000000 01000000 00000000 
01000000 00000000 01000000 00000000 01000000 00000000 19100000 15100000 
16100000 14100000 03100000 04100000 02100000 10100000 11100000 0f100000 
12100000 00100000 18100000 1b100000 05100000 1a100000 ff0000ff ff00c400 
ff009a00 ff007200 ffff774f ffff5320 ffe22014 ff32dbff ff33b2ff ff1f90ce 
00000000 00000000 00000000 00000000 00000000 00000000 aa000000 00000000 
001c60c2 1172c390 8918fdc0 024d968f 091caac9 1d25958f e92064c2 1165c090 
895c2c66 0f01be90 e9

 

The header is clear: that's Size, CRC, Memory address and Version. From then on it becomes less obvious though. However, given that the ZoneManager did not seem to change with city size, I decided to leave the file for what is was for now and tackle the SimGrids first after all. I already decoded them anyway so that should be faster. The only unknowns here were what the specific data ids were. However, the SimGrids are not decoded yet on the wiki so I decided to add a page for it so that you can all follow along.

In order to find out what SimGrid is controlling the zones, I tried filling up a few SimGrids with 0x01. I was lucky quite early: if I filled the SimGrid with dataId 0x41800000 - which is a Sint8 SimGrid - and opened up my city, it looked like this: 

Sweet. Now that we have that one sorted out, let's see if it actually impacts the "growability" of a zone that was created by my program. Unfortunately it didn't. Nothing was growing.

TL;DR: The quest to finding out what variables are preventing zones from developing goes on. Fortunately it wasn't all useless though. We're at least able now to fix the Zone Data view. This is what it looks like for the skyline city:

It looks like my initial hypothesis was true after all: the SimGrids are merely data views which don't really impact the simulation. I guess there's no other option than fully decoding that ZoneManager file first.

[smf_16 1,835]

Well, I'm absolutely baffled. I managed to decode a large part of the Zone Manager and added a page for it on the wiki. It was unclear to me what it was actually doing as the values that appeared in it did not seem to be related directly to the zones that I created. Hence I decided to replace the zone manager entry in a file with 1 "hand zoned lot" and 1 programmatically zoned lot from a file with 2 "hand zoned lots". It did not do anything.

After that, I used this "replacement" strategy for all subfiles from my list in the post above and it looked like the hidden value was in the Lot Subfile after all! I was so sure that I had verified anything. Turned out that it was the "flag2" that was causing the zones not to develop! I set it to 0x03 by default - which is a normal value for developed lots. Setting this flag to either 0x00 or 0x01 caused the zones to develop. As mentioned, I really don't understand how I could have missed this after verifying it hundreds of times, but ok, it's working now.

Having found that it was the "flag2" that was controlling whether zones could develop, I wanted to verify the impact of the flag on lots that were already developed, but then demolished. Again, I was completely taken by surprise. I didn't touch anything and left the flag set to 0x03 and everything was working. In picture below I plopped lots with my program, then opened the city and demolished them and they properly redeveloped.

Even though it remains a mystery to me how it was possible, the most important thing is that it seems to work now. I'm going to check now if I can also get it to work with my growification command.

[rivit 3,391]

Well done, this means that you could generate a random city without actually placing any buildings by just zoning it and just let it explode into life. (and give the CPU apoplexy)

so x00 is just zoned?, x01 demolished ?, x03 developed,?  x07 historical?, anything else Immortal  perhaps

3 hours ago, smf_16 said:

the most important thing is that it seems to work now

There is the chance that because you've fixed everything else it now works as you originally had it - time will tell.

4 hours ago, smf_16 said:

cSC4ZoneManager

Bottom of the block just before the Class IDs starting ff0000ff  looks like a list of ARGB values. Other parts also look like a copy/version of (parts of) the Zone Manager exemplar - zone sizes, etc.

4 hours ago, smf_16 said:

Interestingly it didn't! I tried the pipes and the subway view, both did not redraw the textures.

That's surprising (even if its very logical to only redraw what you have to) as you can place utility lots - water pumps and the like - which I would have thought would force texture changes. Still its not really a relevant/useful diversion.

[smf_16 1,835]

17 minutes ago, rivit said:

so x00 is just zoned?, x01 demolished ?, x03 developed,?  x07 historical?, anything else Immortal  perhaps

According to the wiki:

0x01 (00000001b) - Flag Byte 1 = 0x10 - Powered (empty growable zones)
0x02 (00000010b) - Flag Byte 1 = 0x50 - Powered and built
0x03 (00000011b) - Flag Byte 1 = 0x58 - Powered, watered and built
0x04 (00000100b) - Seen it once on a tall office under construction
0x06 (00000110b) - Seen it once on a water tower without power

Historical is actually stored in flag byte 1. This flag byte 2 seems to have 4 meaningful values: 0x00, 0x01, 0x02 and 0x03. The zones were growing only when I set the flag to either 0x00 or 0x01.

19 minutes ago, rivit said:

There is the chance that because you've fixed everything else it now works as you originally had it - time will tell.

Perhaps that it was the combination of the SimGrid and the flag byte that had to be right. That's about the only explanation I can give.

11 minutes ago, rivit said:

Other parts also look like a copy/version of (parts of) the Zone Manager exemplar - zone sizes, etc.

Interesting, I didn't know that this exemplar existed. I assume you're talking about this? Anyway, I don't really plan on decoding the zone manager further, as it has proved to not be of any importance. But I think you're right, it will probably contain some of that exemplar data. Looks like this is the class that the game uses to draw the zones and the subfile simply contains the serialized version of this class: a few pointers to other objects it is using and then some "configuration" which is probably taken from that Zone Exemplar.

[smf_16 1,835]

Hello everyone,

I just wanted to pop in to inform you that I will not be able to continue my research in the coming days: a while ago I created a website to play cards which has absolutely skyrocketed during the last days due to the Coronavirus quarantine. The server desperately needs some technical updates to be able to cope with the extreme amount of traffic I'm experiencing lately so it will keep me quite busy for the coming days. I imagine @CorinaMarie and @Cyclone Boom boom can relate. 

[CorinaMarie 29,605]

@smf_16

Thanks for letting us know. Ofc, we'll still be here in the future if'n you get more time to totally amaze and astound us some more.

[smf_16 1,835]

Well, it's been a while, but the project remains fun to play with. Something that was still missing from the code was the ability to take the terrain into account. I noticed that I already decoded the terrain map subfile a while ago. So I used it to find the heights where to insert buildings and props. The game has quite a complex logic here by checking if the terrain is suitable and also levels it in some cases, so I decided to ignore this for now and just insert every prop and building at the height of its centroid. 

I've posted the result below and I really like the result. The roads were drawn manually to accentuate the hills a bit more, I'm not yet able to programmatically draw roads.

 

[smf_16 1,835]

Now that the technical stuff of plopping lots is pretty much done, I've decided to do some research about how to generate city layouts. I've stumbled upon this post which led to an interesting website that generates random layouts based on a few parameters that you can set. I'm now experimenting a bit if I can adapt this algorithm to work with the grid. It will require some efforts, but I already wanted to post the link here because it's fun to play with. You might even get some inspiration from it on how to layout your next (small) town!

[carlosmarcelo 975]

On 04/07/2021 at 3:40 PM, smf_16 said:

interesting website that generates random layouts based on

I thought interesting the city generator.  Some detail may have escaped me, but I understood that, in fact, this is essentially a path/street generator.
From what I understood from your previous post, to generate a city, it would be a prerequisite to have the streets drawn in advance, which I think is good.

A few months ago I came across a map generator for Doom 2 called "Oblige". After generating several maps, I noticed that, in fact, it makes a composition of several sections and "prefabricated" halls that are composed or mixed according to parameters such as size, themes, difficulty, requirements, etc. The variety is so great that it's impossible for it to generate 2 identical maps, but every map you enter you recognize props and compositions from other maps.

Anyway, I think it would be easier if you had already pre-molded small blocks or neighborhoods to be composed or, much in the future, these blocks were shaped according to the parameters available in the generator. 

[smf_16 1,835]

8 hours ago, carlosmarcelo said:

I thought interesting the city generator.  Some detail may have escaped me, but I understood that, in fact, this is essentially a path/street generator.
From what I understood from your previous post, to generate a city, it would be a prerequisite to have the streets drawn in advance, which I think is good.

Yes, it's just an algorithm that generates a street layout in more or less an organic way. If I want to generate realistic looking cities, it's indeed a prerequisite to start from a realistic street map. Note that I don't need to actually draw the roads per se, I just need a street map so that I can determine the positions of the buildings to insert. Nevertheless I definitely want the program to be able to draw roads as well. I've been doing some research already and have learnt a lot about how network tiles are stored in the savegame, so I will definitely add it later.

It would indeed be easier to have pre-modeled blocks put together, but the street map generator algorithm seems more fun though. 

[smf_16 1,835]

I'm currently experimenting a bit with generating roads. One thing I noticed though is that the textures are somewhat independent from the paths. This surprised me because there's only one ID that I had to specify, so I thought the textures and the paths were to be considered as one. Apparently I need to rotate them both in place when generating roads. I'm not an expert in this field here, so I was wondering if someone could explain a bit how textures and paths are related to better understand what's happening. Thanks!