StarlitBeach

Lately I've been playing around with the dataviews, and I think at least one of my experiments might be useful to others so I'm hoping to get some feedback and ideas for improvement here. I use the Less Abandonment mod and find that it improves the game a lot for such a simple idea. Not because it reduces abandonment (which is mostly caused by mismatches between supply and demand of jobs in my experience), but because it gives you more control over where and when $$$ lots will develop. It does this by raising the desirability thresholds above which different wealth levels can grow. I thought it would be useful to be able to see these thresholds in the desirability dataview. Here's an example showing I-HT desirability (the colours are a slightly adapted version of the colour ramp from Cori's Parks Aura dataview): The important threshold here is 90 - the dark blue/purple area is where I-HT can grow. Another important threshold is 50, below which buildings start to become distressed, shown by the sharp boundary between green and white/light red. I have found this to be useful when play testing - I was able to control the pace and extent of R$$$ development by careful placement of parks and rewards, using Cori's Parks Aura and these dataviews. It was also useful to be able to see which areas were almost good enough for CO$$$, so that I knew where to put plazas to encourage them. The Less Abandonment threshold for R$$$ and CO$$$ is 120, and I found that they developed as soon as I started seeing areas of magenta on the dataview (and never before that) so I'm confident it's showing that threshold properly. High tech was developing just before I started seeing areas go blue, so that needs more testing in case it isn't calibrated properly. A couple of the desirability views are more or less useless. The C$ one is especially so because it typically shows desirability off the scale almost everywhere. The I-D one is also useless because it is usually very similar to the I-M view. R$ is another not very useful one, though I do look at it on occasion. I was thinking about other possible ways of displaying desirability data to replace these useless dataviews, and did come up with one idea. What if you could see which residential lots the CO$$$ developers would like to get their hands on? Here's an example: I've replaced the C$ dataview with a second view of the CO$$$ desirability data, but showing only residential lots where desirability is 90 or above. The small magenta blocks are where CO$$$ could develop right now if you zoned for them. The rest (blue/purple) have potential but are not quite there yet. Here's another using the same concept for I-HT (replacing the I-D view): In this case, because the growth threshold is 90, I-HT could grow in any of the highlighted lots if you zoned for it. Any comments on how useful this is? Any ways it could be improved? And if anyone has any other ideas for new ways to display desirability data, I'd be very happy to try them out. Data can be broken down in this way by any combination of lot type (R, C, I, or non-RCI) and density, but unfortunately not by wealth level as far as I know.

I've done more testing on it, and I'm reasonably sure this is how it works: Sea level is at 0x40 (64) in the terrain ramp, and 0x00 in the water ramp. The terrain ramp represents elevation in 5 m increments - so 68 represents 20 m above sea level, 44 is 100 m below sea level, etc. The water ramp represents depth below sea level in 1 m increments. Here is one test I did: The magenta starts at 0xA6 (166), which represents a height of (166-64)*5 = 510 m above sea level. Using the terrain query I found that the heights in that area were above 760 m (510 m above sea level) and below 763 m. When the magenta is set to start at 167 instead, it disappears because nothing is as high as 765 m. As an experiment, I tried setting up the terrain ramp to show contours every 100 m above sea level, and it sort of worked...

I found something interesting while looking for a way to change the building highlights. Not sure if this has been done before, but in case it hasn't I thought some people might find it useful (or at least fun to play with). Here's a tile with quite a lot of height variation: And here it is again, with a recoloured mini map: It's more difficult to see the height variation with neutral colours like that - the hillshading helps to some extent, in that it tells us where the hills are, but it also confuses things because there is no straightforward relationship between height and lightness. But these colours could have their uses. For example, here is my NAM Traffic Volume dataview, which I recoloured a while ago to use the same colours as all my other dataviews: Turns out that green wasn't a good choice to go on the mini map , but I liked how it looked on the main map. Here it is with the neutral mini map colours: Now the least busy roads don't show up so well, but most of the busier ones stand out much better. With some tweaking of the colour scale, the whole network could be shown quite nicely on the mini map, without the distraction of a coloured background. It might also help to make the mini maps more readable for colourblind people, because some colours could be difficult to distinguish against a green background. An alternative use of this could be to get the mini map colours to match better with terrain colours. The relevant properties are MiniMap: Water ramp and MiniMap: Terrain ramp in the Mini map exemplar (6534284a; 690f693f; 8a356fc2). I've only tried changing the terrain ramp so far, so I'm not sure how the terrain and water ramps interact. The terrain ramp defines the relationship between height (0-255) and colour.

That does seem the most likely place, if it is even possible - I still haven't found anything else. Problem is, I can't make head nor tail of what that exemplar is doing...

I wonder if anyone knows of a way to change the colour used for highlighting buildings on the main map? It defaults to bright green, which is problematic... Here is the Water Pollution view in my alternative colour scale: Normal Colour Vision Deuteranopia I changed the highlight colour to blue so that the buildings stand out better on the mini map, but it doesn't change the colour on the main map, so in the deuteranopia simulation the water treatment plant appears highlighted in bright yellow on a dark yellow background. You can still see it, but it isn't ideal, and it would be much harder to see if it was a little bit further south. I haven't yet found a property that would allow me to change this, but I'm hoping there's something I've missed.

Thanks, that's a very useful tool! Trying to get the lightness gradient right in my colourblind-safe palette has been tricky so I'll definitely see if that helps to improve it.

I've been working on a colour scale that is hopefully easier to read for people with red-green colour blindness. Here are the views I've recoloured so far - I used Coblis to simulate what they would look like for people with deuteranopia (green-blindness): R$$$ Desirability R$$$ - Deuteranopia CO$$$ Desirability CO$$$ Desirability - Deuteranopia IHT Desirability IHT Desirability - Deuteranopia These colours seem (to me) to work well for the desirability views - all the important thresholds that I wanted to show for use with the Less Abandonment mod are easy to see in the deuteranopia simulation (white/grey at 50; light grey/blue at 90; dark blue/bright blue at 120). I'm hoping that at least one colour-blind person will read this and let me know whether they really do work. Everything else is done - once I've made recoloured versions of all the dataviews and done a bit of testing it'll be ready.

Here's the latest version of the Abandonment view with all of those changes: And a comparison between the combined Fire Hazard and Abandonment view and @CorinaMarie's original in the same test run: I couldn't find any buildings in this test that were highlighted by one but not the other. I'm guessing that the number of potential false negatives is quite small, but I'll try to get one to build (probably in another city) to see what happens.

Thanks! Those changes are in the version I downloaded to have a look at (v 0.46). I do want to look into whether it is worth hiding some things (like trees) in these dataviews. And I think I will change the highlight mode for the version that shows just abandonment, because it doesn't make sense to highlight all the fire stations in that case, so could change it to highlight transit stations instead. Yes, I think that would be best for the just abandonment version. The combined view will either keep it as yellow, or change it to black (and shift the colour scale to use lighter reds so that there's no confusion between black and dark red).

If you're happy for me to do it, I could include the combined view as an optional replacement for the Fire Hazard view in its original position; and both the combined view and the 'just abandonment' version as optional replacements for where the Radiation view usually goes. (I wouldn't make it part of the 'default' full installation because of potential conflicts with fire mods.) I'd credit you with the idea of using flammability like this, of course. This is how it looks with the rest of the colour scale transparent: (I could change the colour to red or black so it stands out even better.)

I've played around a bit more with Occupancy, and I don't think it can be used to show abandoned buildings because: it shows the data in tracts, so it won't highlight a tract containing an abandoned building if the rest of the buildings in it are occupied it uses the same data sources as Desirability and Capacity, so only one developer type can be shown at a time tracts without any buildings of the developer type also show as zero occupancy, and quantizing doesn't help much with the above because you can't quantize by wealth level The combined Fire Hazard and Abandonment view is much more promising though... Two months later, strange symbols started hovering above some buildings. (Flammability has increased citywide, but nobody has abandoned yet.) A few months after that, half of the population mysteriously disappeared. (Lots of buildings have abandoned and are looking distressed, but they haven't fully abandoned yet, so no significant changes in flammability.) Four months later the abandoned buildings looked even more dilapidated and started making ominous creaking sounds. (Fully abandoned buildings now have very high flammability, shown in yellow.) (Three months later, some buildings have reoccupied and flammability is back to normal, except for buildings that are still empty.) It does seem to be able to highlight all buildings that have been abandoned. Here's a close up of some 1x1 sheds and other I-D buildings that needed water: And another showing an abandoned office building on a lot with lower flammability. The parking garage and grounds are either transparent or blue, but the building is yellow: Finally, an abandoned mansion showing the same effect: I didn't spot any abandoned buildings (either looking dliapidated or with No Water zots) that were not highlighted. The abandoned buildings do seem to all have a flammability of 255. I initially set up the colour scale to show only 255 flammability in yellow, and the same buildings were highlighted. But when the buildings were watered again their flammability decreased so they weren't highlighted any more, though they were still empty. At the moment it's set up to highlight flammability above 160, and that seems to work well (160 flammability is the point at which the chance of a fire starting reaches the cap of 50%, and I believe it is much higher than any Maxis building, so there should be no false positives).

What I was thinking of doing for my own setup was to make a combined Fire Hazard and Abandonment dataview. I do sometimes see R$$ abandon because they can't find jobs, if I'm not careful enough about keeping the pace of job creation in line with the pace of R$$ development. It usually happens on a small enough scale that I'll know where the abandoned buildings are, so maybe don't really need a dataview to tell me, but its still more useful than the Mayor Rating view. If I'm right in thinking that the non-quantized version can show the flammability of buildings separately from grounds, it should be easy to get it to show abandoned buildings (in black) because they should all have a flammability of 255 with your mod. I'll test it out a bit later and post the results here. I'll give this a try as well, and test the two approaches (occupancy vs. flammability) side by side.

The Fire Hazard view seems to be potentially a bit more useful when it isn't quantized or interpolated, because it is able to show the flammability of individual cells: Here's a slightly closer look: This shows the effect of trees on flammability: streets have no flammability rating so they are transparent, but street trees do, so the street cells with trees appear in blue the graveyard to the northeast is surrounded by trees, whereas the one to the soutwest has only a few cells with trees around it The graveyards and some of the gardens also show how it is able to distinguish between the parts of a lot that are more flammable (i.e. the buildings) and parts that are less flammable. The gardens which appear in darker blue are those without trees - gardens with trees are more flammable so they don't stand out from the buildings. @CorinaMarie This might be useful for your abandoned buildings dataview? I was rereading the thread where you were testing it yesterday and one of the problems was false negatives caused by flammability being averaged over large lots with small buildings. Turning off quantization might solve that, though I haven't tested it.

I've added a couple more replacement dataviews to the custom installation options: Mayor Rating Fire Hazard The percentages in the Fire Hazard view refer to the chance of a fire starting when ignited, according to the Percent Fire Start vs. Flammability property in the Flame simulator exemplar. One or other of these will also be included in the full installation (where Radiation is) as I've decided to remove the CO$$$ rezoning targets view. At the moment I have Mayor Rating there, but I could change my mind. Which one do people pay more attention to?

I've finished testing - the main thing I was checking was the calibration of the colour scales, and I'm now sure they are correct - so it should be ready to publish soon! It will have the full version, plus custom installation options: the Capacity views by themselves, in separate Low, Medium and High versions for each developer type (R, C, I and Ag), which can be mixed as needed a full set of Desirability views, in case some people don't want the Capacity ones or want to switch between them files to replace the other dataviews in their original locations, to be used with either of the first two options Plus a choice of colour scales for each - the current colours and a version that should be easier for people with red/green colour-blindness. Pulling it all together and testing that the installation options work properly will take a bit of time, but hopefully some time over the weekend it will be ready. I'm thinking of leaving out the CO$$$ rezoning targets view, or maybe including it with the full set of Desirability views (in place of Cs$). After testing it some more I'm not convinced that it works well enough to justify its slot. There are just too many false negatives - here's an example: Those houses in the centre look a promising target for CO$$$, but not quite there yet. If they were coloured magenta then CO$$$ could grow immediately. Maybe if we put one more plaza nearby... Except that the uninterpolated desirability view shows that they are already desirable enough: And when they are rezoned to C, a high wealth office grows immediately: The problem is that quantizing the data to lots automatically interpolates it, even if you set the interpolation property to false. The averaging of nearby tracts that is done by the interpolation causes it to look less desirable than it really is. In fact, I think I will also include a set of uninterpolated dataviews - they are not very pretty, but they are the only truly accurate reflection of the underlying state of the simulation, which I'm sure at least some people would be interested to see. Here's another example of what can happen when data is interpolated or quantized, this time for Average Age: Uninterpolated Interpolated Quantized The quantized view shows average age noticeably lower than it really is in many places, especially along some of the edges. Look at the left hand edge just above the start of the menu in particular - a row of lots that are light red or white in the quantized view, but in a tract that is light green in the uninterpolated view.

Now that you mention it, I have a vague memory of reading that thread - I'll have to see if I can find it. It would be nice if they did have some effect, but it looks to me as if they can't.

I actually discovered another bug today which I don't think has been discussed before (hope this doesn't become a habit! ) This one probably can't be completely fixed though. Like the industry slope effect bug, it is in the desirability calculations. Amongst the factors for R is proximity to other R of each wealth level. In theory, they prefer to be near other R of the same wealth. The problem is, the game doesn't actually calculate this proximity - it always looks like this in the query.txt file: | Desirability equation for R$ | desirability = base value: 25 | + land value effect, f(value: 190): 1 | + slope effect, f(value: 8.7): 0 | + R$ proximity effect, f(0): 5 | + R$$ proximity effect, f(0): -5 | + R$$$ proximity effect, f(0): -5 | + Co$$ proximity effect, f(0): 0 | + Co$$$ proximity effect, f(0): 0 Even if the nearest R$$$ is the other side of the tile, or there are no R$$$ in the tile at all, proximity is still 0 and the desirability effect for other wealth types is still -5. So all these factors do is subtract 5 from all residential desirability! Commercial also has these proximity factors - they should prefer to be near R and CO of the same wealth level - but in this case it has zero effect. The only 'fix' would be to change the residential developer exemplars to disable the proximity effects completely.

@CorinaMarie That's very interesting. It did occur to me to wonder whether the problem was already present in that particular tile but I hadn't tested it. The Making Money Tutorial tile has similar phantoms: In this case, I hadn't done anything at all in this tile when I loaded it. What I did was to bulldoze all the dirty industry while the game was paused, and saw that phantom I-D capacity was left over (the capacity dataview updated instantly without me needing to unpause). I unpaused and the industry regrew, then I paused and bulldozed it again. Exactly the same pattern of phantom I-D capacity was still there, even after I dezoned it all and ran on Cheetah for a while. Your second test suggests that Maxis may have changed the number of jobs in one or two of the dirty industry buildings after creating these tutorials, and that is what has caused the bug - when they are bulldozed the new amount of I-D capacity was removed, but the save file still had the old amount. I just reloaded, and this is what was there: Those chemical tanks are the one building that is common to all of the tracts where phantom capacity appears. So, as you say, this is probably yet another reason to be careful about using buildings with changed properties in tiles where they are already there.

Good idea. I didn't, but I've just tried it - bulldozed everything around those two tracts (plus some more to make I-M demand go positive), let I-M regrow and then saved and re-entered. The phantom I-D capacity was still there. I suspect that once it's in the save file there's no (simple) way to get rid of it. I had settled on keeping the maximum capacity shown by the Low version at 500 and tweaking the colour scale at the bottom end to show low capacity buildings better, but I might now include this 'Very Low' version as well so that the phantom capacity can at least be seen after bulldozing. The only solution may be to not save if it appears. Though if the amounts remain this small it might be better to just live with it, rather than checking for phantom capacity everytime you bulldoze something, because its effect on the game is probably minimal. Edit: of course, I'm just assuming that this is how phantom capacity is created. If it happens when the city the is saved then there would be no way to prevent it. It would be interesting to try and observe it happening in real time rather than after the fact.

A long time (well ok, a week) ago... I've tested it some more and this does seem to be exactly how the uninterpolated capacity data works - the colour of each tract is determined by its total capacity. Here's a simple example: I set up the colour scale to highlight tracts with a capacity of exactly 155 in cyan, and show everything else in black. The only Cs$ building in that tract is the one I've queried. Here's an example with multiple R$$ buildings in a tract: There are eight 2 Story Houses in this tract, each with a capacity of 11, and the colour scale has been set up to highlight tracts with a capacity of 88 in cyan. I also discovered something interesting while tweaking the colour scale for the Low version. Here is the uninterpolated data for dirty industry with the Maximum scale property set to 255 (I didn't change the legend though): I am very sure that there are no dirty industry buildings in those five tracts shown in black. They only appear at all when Maximum scale is set to 255. At 510, they disappear, which means they must represent a capacity of 1 (when Maximum scale is set to 255, each increment of 1 in the colour scale represents an increment of 1 in the data). There used to be dirty industry in these tracts but I bulldozed it, so this may be similar to the phantom park effect that can be left behind after a YIMBY/NIMBY building is bulldozed. I tried bulldozing and dezoning all the I-M buildings in one of the offending tracts, then ran it at Cheetah speed for a few months, but it would seem that I'm stuck with this phantom capacity: I also tried bulldozing everything in the area to the west and letting I-M regrow there, but that didn't get rid of it. I'm not sure if this particular form of this bug has been documented before. I wonder how common it is, and what effects it might have. Presumably no Sims can actually work at these phantom jobs so, in theory, if phantom capacity could accumulate to high enough levels it might cause subtle imbalances in demand. Or maybe it would be possible for Sims to try and reach these jobs but fail, causing them to abandon even though there are other non-imaginary jobs available. Or maybe it has no noticeable effect at all.

Here are some more screenshots, showing how the dataview panel looks in different languages. I've kept the original Maxis text where possible but for the RCI Capacity and Desirability dataviews I had to try to piece together an appropriate translation from other text in the game, with the help of Google Translate in some cases. I also had to shorten the Average Age label in a few languages to make it fit. Hopefully it makes sense in all of them - please let me know if you spot anything that isn't right. Danish Dutch Finnish French German Italian Norwegian Polish Portuguese Spanish Swedish

Thanks for the great test pics @CorinaMarie @Iodyne I just had another look at the Low version and it does show isolated buildings with a capacity below 10, but not very well so I need to work on that. I do plan to include it as an option, as well as the High version, so that (hopefully) all city densities and mod setups (residential halvers, commercial and industrial doublers/quadruplers etc.) can be covered. Apart from that, I think I have it more or less finished. It will be a few days before I publish it though, because there are quite a few things I'd like to test first. The only functional change I've made since the version I uploaded is to the Average Age view, which now goes up to 100 and looks like this:

Here's an almost finished version to have a look at: Dataview Replacements.zip It is fully functional but there are still a couple of things to do. In particular, the colour scale for Average Age needs to be extended to 100 and the legend for the new CO$$$ Targets view needs to be changed. There are also a few translations still to be added. It changes all dataviews except Crime, Water, Traffic, Zones, and Garbage. Here's a screenshot showing the layout of the dataview panel and the CO$$$ Targets view (quantized to show R and I lots the CO$$$ developers have their eyes on):

Thanks I'm working on adding the desirability views back in now, so should have a full version ready for testing either later today or tomorrow.

That (or a variant of it) was one of the things I tried, and it didn't look right. I ended up concluding that it only made sense to include blue at all if it was at zero. I now have something that I'm happy with, using yellow in place of white and controlling the transparency at 0x81 through to 0x84. It also has light red representing 296 pollution (just above the threshold where the desirability effect flips between positive and negative) and goes through orange to yellow below that. Air Quality Water Quality It is about as good as the blue version at showing low levels of pollution, but in more appropriate colours for what it's supposed to represent. I've also moved the Average Age, Health and Land Value dataviews to make space for the Desirability views in the third column. Moving or replacing Water caused the wrong dataview to appear when placing water pumps etc., and I couldn't find a way around that so it has to stay where it is. The changes work in all European languages - I added the LText files for each button label and changed their group and instance IDs so that they appear in the right place and in the right language. Where I've changed the titles or legend text (as in the pollution views), I only changed them for English and English (UK). Finally, I changed the title and legend of the Health dataview so that it shows life expectancy rather than HQ, because this seemed the most natural way of putting numbers to it.