neroden's list of current bugs in his working copy

[neroden]

This is sort of a scratchpad so I don't forget them.  I figure I'll cross them off as I fix them?  (Updated, fixed bugs removed)
Short-term bugs:-
1 -- when compiled with DEBUG==1 (but not with DEBUG==0) -- so this is an effect of inlining -- city boundaries blow up to huge sizes (during loading, possibly at other times).  (Updated.) This is a side effect of the curious way the city boundary enlargement routines work.
2-- industries cluster way too close to city hall.  Waaaay too close, if I've left any open space anywhere near it.  Like, as close as possible.  A better spread is needed.  (Higher priority now...)
3 -- factories like to face away from roads rather than towards them  (Higher priority now...)
4 -- upgrading a road (by click-and-drag) fails to update maintenance costs
5 -- canal/river upgrade logic is wrong, and frequently replaces rivers with deep draft with canals with shallow draft, causing all manner of irritation.  The upgrade logic needs to takeeither weight limits or way constraints into account to avoid this.
6 -- choice of bridges built by the city for city roads is bad.  There needs to be a config option for this.
7 -- well, I've managed to eliminate the bug where city roads didn't have sidewalks, but now roads built by the public player *do* have sidewalks.  Oy...
Medium-term bugs:
1 -- attractions, city hall do not have good "distance from stop" behavior
2 -- factories, attractions, city hall don't know what tiles they're on quickly (caching this would speed the game up)
3 -- city generation routine is seriously buggy and hangs half the time
4 -- intercity roads never get updated or rebuilt after game start
5-- countryside attractions never get built after game start
6-- attractions are never demolished (actually this may be reasonable)
7 -- simcity.cc contains all the passenger generation code... which arguably belongs in gebaeude.cc.

Longer-term issues I've noticed recently:
1 -- map enlargement only operates right-and-down
2 -- dingliste_t is not as efficient as it could be for display purposes.  Given that objects are usually displayed in multiple separate runs, through part of the list each time, it should be broken into multiple lists.  (List one: non-moving objects with backgrounds.  List two: vehicles.  List three: objects with foregrounds only -- mostly powerlines.  Possibly: list zero: ways, but I'll have to think about that.)  It's still quick to run through the lists.  The memory consumption is the only question.  Subclassing grund_t might actually deal with the problem.
3 -- grund_t/dingliste_t records one and only one display order.  (Rather than the appropriate four...)  Fixing this most cleanly will involve separating grund_t into two extremely tightly linked classes: one representing the unchanging and eternal features, one representing the viewport aspects. Most of the current grund_t is actually the viewport, but a small number of things represent game status.  Separating the pure game status material out will use more memory, potentially a lot more, but should allow for a faster server.  Most of the extra memory will stay out of the resident set, so this would only be an issue on highly constrained devices.
4-- the passenger generation algorithms have a lot of oddities.  I have some ideas for changing them.

[jamespetts]

Thank you very much for enumerating this - this is most helpful. One or two comments. Firstly, should short term 6 not be in the medium term list? Adding a configuration option generally involves stepping the saved game number, and this does not seem to be much of a priority if one is starting a game in 1750 or even 1825 when all the road traffic is powered by creatures with four legs.

As to medium term 6, this is an interesting question of design and should probably be considered. On one view, it is the function of the (human) public service player to do this, as what is involved is effectively the re-engineering of the road network. Alternatively, I had thought some time ago of introducing a renewals cost for ways, whereby, after a certain amount of usage, a way would have to be (automatically) renewed. This was intended for economic reasons, and to go along with a feature whereby the way maintenance cost would vary with the number and weight of vehicles using the way. Although the preference would be for it to be renewed with an identical way, if the identical way had become obsolete, it would instead replace it with the cheapest currently available way with no less than the same weight and speed limit of the current way. This might well address this to some extent in any case.

Medium term no. 7 raises interesting design questions, too. I agree that it would be good to have countryside attractions built after the game's start: but what would decide when new ones are built, how often and where?

As to medium term no. 8, I think that it probably is reasonable for attractions not to be demolished, especially non-city attractions. With city attractions, this is a more interesting question. One of the potential uses of these "attractions" is to have public buildings such as schools, hospitals, libraries, courts, swimming baths and so forth (schools and libraries are already present in Pak128.Britain). Sometimes buildings of this sort are demolished and renewed (or even demolished and not renewed: hospitals are often centralised, and three or so hospitals demolished and one new one built or an existing one extended).

As to medium term 9, is this really necessary? What would moving it to gebaeude.cc do to the interaction with private cars, the data for which are stored in stadt_t?

As to long term 2 and 3, it would be unfortunate if Experimental differed substantially from Standard here as it might make future merging difficult. Perhaps we could look to getting these changes into Standard?

As to long term 4, perhaps we should have a separate thread for the passenger generation algorithms? As indicated elsewhere, I had planned on making some significant changes to this at some point in the future, as discussed on more detail here.

[neroden]

Thank you very much for enumerating this - this is most helpful. One or two comments. Firstly, should short term 6 not be in the medium term list? Adding a configuration option generally involves stepping the saved game number, and this does not seem to be much of a priority if one is starting a game in 1750 or even 1825 when all the road traffic is powered by creatures with four legs.

Actually, this is exactly the problem.  Running in 1750, I keep getting lots and lots of heavy stone bridges, when the city really ought to be building wooden bridges...  it's nice to get huge numbers of heavy, expensive bridges for free, but... it shouldn't be happening.

As to long term 4, perhaps we should have a separate thread for the passenger generation algorithms? As indicated elsewhere, I had planned on making some significant changes to this at some point in the future, as discussed on more detail here.

Perhaps.

[jamespetts]

Were bridges in towns not generally of the stone rather than wooden type?

[isidoro]

I also think that medium term number 6 is very interesting.  And I agree with James that they can be renewed based on usage...  But the appropriate way to be built instead, can be not the cheapest but based on something in the dat file.  A kind of parameter, recommended maximum traffic density, or something like that.

That way, cities would build high speed highways where traffic congestion is big and would keep dirt roads in places where there is seldom a car...

[Michael Hauber]

Related to medium term 6, there are still significant intercity roads in 1st world countries that are still dirt roads.  Australia's highway one is mostly multi-lane freeway in the populated south east corner of the country, but along the isolated northern part of the continent we have over 3000 kilometres of road which is mostly unsealed, with most of the population along this stretch found in Darwin (roughly 100k) and Cairns (roughly 250k), and after that only a handful or two of towns that would be even 1000 population. 

http://www.savannahway.com.au/

The upgrading of an unsealed road to sealed status, or the construction of a new bridge allowing significantly shorter access roads to an area can be a significant boost for development. 

[neroden]

Were bridges in towns not generally of the stone rather than wooden type?

Perhaps the problem, then, is that too many bridges are being built.  Cities should have an anti-bridge bias during construction, rather than building a bridge every chance they get.  (Bug list updated.)

[jamespetts]

Ahh, yes, that makes more sense - cities do seem to have too many bridges, and to build them as readily as roads.

Michael - that tends to vary by country: what applies in Australia (and thank you for that interesting link) does not apply here in the UK, where even rather minor public roads are almost invariably metalled. This will need to be pakset specific.

Isidoro - this is an interesting suggestion, but would first need a comprehensive simulation of congestion of private cars per tile of road, which, because of the simplified private car routing method employed to make it not excessively computationally intensive, is not possible at present. It would be desirable if anyone could ever think of a way of having a fully detailed private car routing system that was not too computationally intensive.

Edit: As to the mail revenue, I have just noticed commit ef4871750d5ae889a51756e9f2102338f8ad3695, which has the following comment:

Add passengers discarded due to waiting too long to the "too slow" graph, not the "unhappy" graph (which represents overcrowding)

and the following code:

Code Select Expand


// Waiting too long: discard
                         if(tmp.is_passenger())
                         {
-                            // Passengers - use unhappy graph.
-                            add_pax_unhappy(tmp.menge);
+                            // Passengers -- add to "too slow" graph.
+                            add_pax_too_slow(tmp.menge);
                         }


This needs to be reverted, I think, as the current logic is clearer: "unhappy" passengers are those that cannot board their transport at the initial stop because of problems at the initial stop (either it is too crowded for them to be let into the stop, or they are let in, but there is such a long queue of other passengers waiting or some temporary disruption preventing there from being a convoy arriving any time soon) they do not get to board their transport in a reasonable time; "too slow" are those that do not even bother turning up to the station/stop, because they know that the estimated journey time for that journey will exceed their journey time tolerance. "Too slow" should be specifically reserved for when the total estimated journey time exceeds passengers' journey time tolerance. In any case where the normal (average) wait time is too high, this will in any event record as a "too slow", as passengers will not take the journey in the first place because the overall journey time (including that wait) is too high. It is only when there is overcrowding or some temporary disruption that passengers will be discarded as having waited too long where they did not register as "too slow" in the first place. I think that it is important to maintain the conceptual distinction between estimated journey times exceeding tolerance and problems at the stop showing between "too slow" and "unhappy".

[neroden]

Ahh, yes, that makes more sense - cities do seem to have too many bridges, and to build them as readily as roads.

Michael - that tends to vary by country: what applies in Australia (and thank you for that interesting link) does not apply here in the UK, where even rather minor public roads are almost invariably metalled. This will need to be pakset specific.

Isidoro - this is an interesting suggestion, but would first need a comprehensive simulation of congestion of private cars per tile of road, which, because of the simplified private car routing method employed to make it not excessively computationally intensive, is not possible at present. It would be desirable if anyone could ever think of a way of having a fully detailed private car routing system that was not too computationally intensive.

Edit: As to the mail revenue, I have just noticed commit q6e9f2102338f8ad3695, which has the following comment:

and the following code:

Code Select Expand


// Waiting too long: discard
                         if(tmp.is_passenger())
                         {
-                            // Passengers - use unhappy graph.
-                            add_pax_unhappy(tmp.menge);
+                            // Passengers -- add to "too slow" graph.
+                            add_pax_too_slow(tmp.menge);
                         }


This needs to be reverted, I think, as the current logic is clearer: "unhappy" passengers are those that cannot board their transport at the initial stop because of problems at the initial stop (either it is too crowded for them to be let into the stop, or they are let in, but there is such a long queue of other passengers waiting or some temporary disruption preventing there from being a convoy arriving any time soon) they do not get to board their transport in a reasonable time;

Which means that these passengers should not be on the unhappy graph, because this logic triggers at transfer stops.  Think about is more carefully.

Please examine what the unhappy count is actually used for.  Answer: it's used for the revenue penalty.  (And as far as I can tell, nothing else.)  Creating a revenue penalty for the passengers who *did* get their train, merely because a *different* passenger waited too long and gave up, makes no sense.

As I mentioned in another comment, however, the revenue penalty is not making sense at all.

If we delete that revenue penalty, then it isn't so important which list we add the people to, because then it's simply information for the player.

In short, I will revert this change if we delete the revenue penalty.  Discussion over to revenue penalty topic, please.

[jamespetts]

Ahh, yes, I hadn't thought of the old revenue penalty: see my response in the relevant thread. In light of that, and subject to any contrary views expressed by others  that might be adopted, it is probably still worth reverting this.

[neroden]

(List updated.)

[jamespetts]

I have merged your latest dingliste-cleanup branch into my 11.x branch, which includes your revenue improvements. I have fixed some bugs (including Windows specific compile bugs).

However, there seems to be an issue with the new speed bonus system. In the goods list window, all speed bonuses are displayed as "X%%". Removing a single % from the format specifier seems to result in an obscure (fatal) error.

Edit: Removing a pair of the percentage signs worked - I had forgotten how this worked. However, was the "%%" thing purposeful? If so, what was the intention?

[neroden]

I have merged your latest dingliste-cleanup branch into my 11.x branch, which includes your revenue improvements. I have fixed some bugs (including Windows specific compile bugs).

However, there seems to be an issue with the new speed bonus system. In the goods list window, all speed bonuses are displayed as "X%%". Removing a single % from the format specifier seems to result in an obscure (fatal) error.

Edit: Removing a pair of the percentage signs worked - I had forgotten how this worked. However, was the "%%" thing purposeful? If so, what was the intention?

Speedbonus simply aren't percentages.... but they arguably are per-thousand units (represented with "%o" if you have that symbol in your font).  I was reminding myself of that.  The percent sign is horribly misleading.
--
List updated.  Fun new bug which occurs with DEBUG=1 and not with DEBUG=0.

[jamespetts]

Hmm - I see. Might it be better simply to remove the "%" sign entirely and leave it as a generic numbered rating?

Thank you for your updates to this - your work is appreciated.

[neroden]

Hmm - I see. Might it be better simply to remove the "%" sign entirely and leave it as a generic numbered rating?

That would be fine by me.

I'm currently banging my head against the city limits code, which has some severe breakage associated with the "mininum_building_density" setting -- breakage which only shows up with inlining on.

The current algorithm is... subtle... and I don't think I can debug it.  Unless someone else debugs it first, I think I will have to rewrite it.

[jamespetts]

Hmm - the trouble is, if I remove the % sign, it is not clear what that number is. Perhaps we need some other symbol or abbreviation instead. Any suggestions, anyone...?