The International Simutrans Forum

Development => Patches & Projects => Topic started by: DrSuperGood on January 26, 2015, 06:11:40 AM

Title: City code error correction.
Post by: DrSuperGood on January 26, 2015, 06:11:40 AM
Over the past few weeks I have slowly been working on revising part of the city code to correct a number of errors and inconsistencies I have identified in Simutrans standard. Currently I am not ready to provide a patch file (still WIP) however I am making this thread to bring awareness to the issues I am trying to correct. If for some reason my patch fails someone else may want to look into them and consider the solutions recommended.

Title: Re: City code error correction.
Post by: Ters on January 26, 2015, 06:45:10 AM
Quote from: DrSuperGood on January 26, 2015, 06:11:40 AM
Currently I am not ready to provide a patch file (still WIP)
(emphasis mine)

Please provide one patch for each point in the list. They seem quite distinct. That makes it easier to review what changes solve which problem. It also means that we won't get into the situation where none of the issues are fixed because there are issues with the solution for one of them.
Title: Re: City code error correction.
Post by: Aquin on January 26, 2015, 08:16:13 AM
@2: Incorrect growth logic based on transport metrics.

I would go for a simpler approach, completely base the city growth on the statistics of the last month. And spread that out over the growth ticks of the next month.
So at the end of June you check the statistics and get a growth of 5, then you spread these 5 growth equally over the course of July.
I don't think that's to unrealilstic, as moving to a new city takes some time.
Title: Re: City code error correction.
Post by: DrSuperGood on January 26, 2015, 03:52:43 PM
QuoteI would go for a simpler approach, completely base the city growth on the statistics of the last month. And spread that out over the growth ticks of the next month.
So at the end of June you check the statistics and get a growth of 5, then you spread these 5 growth equally over the course of July.
I don't think that's to unrealilstic, as moving to a new city takes some time.
Not suitable for long month length because growth would appear unresponsive. Having to wait a whole month (possibly over an hour) for any growth would potentially irritate some players even if it averages the same in the long run.

QuotePlease provide one patch for each point in the list. They seem quite distinct. That makes it easier to review what changes solve which problem. It also means that we won't get into the situation where none of the issues are fixed because there are issues with the solution for one of them.
Easier said than done seeing how I did not start fixing them from a list. In any case so far I am focusing on 1, 2, 3,8 and 9.
Title: Re: City code error correction.
Post by: Ters on January 26, 2015, 04:35:57 PM
Quote from: DrSuperGood on January 26, 2015, 03:52:43 PM
Easier said than done seeing how I did not start fixing them from a list. In any case so far I am focusing on 1, 2, 3,8 and 9.

It's also easier said than done getting the patch approved, then.
Title: Re: City code error correction.
Post by: Aquin on January 26, 2015, 04:49:32 PM
Quote from: DrSuperGood on January 26, 2015, 03:52:43 PM
Not suitable for long month length because growth would appear unresponsive. Having to wait a whole month (possibly over an hour) for any growth would potentially irritate some players even if it averages the same in the long run.

Actually, I don't know how many growth cycles there are in a long/short month, but let's just put that number to N for the following
But I think a running average might do the job. At the start of each of the N cycles calculate the statistics for the last segment, and add that value.
stat_new = stat_last + stat_old - stat_old/N
This should give a fairly smooth while still responsive curve, without being oversensitive.
Title: Re: City code error correction.
Post by: DrSuperGood on January 26, 2015, 08:47:17 PM
QuoteThis should give a fairly smooth while still responsive curve, without being oversensitive.
There is no problem with over sensitivity as growth is already averaged due to being sub-unit. There is no need for any filter. It also needs to keep track of delta change which is what my solution also requires expect I do not use a filter.

QuoteIt's also easier said than done getting the patch approved, then.
Except it is not like I have a list of things to do and choose one from it. Changes like for problem 1 were found when trying to solve problem 3 which lead on to me solving problem 8 etc. Problem 2 was found in a conversation with Fifty as to why cities were growing so slowly on the server game.
Title: Re: City code error correction.
Post by: Ters on January 26, 2015, 09:49:22 PM
Quote from: DrSuperGood on January 26, 2015, 08:47:17 PM
Except it is not like I have a list of things to do and choose one from it. Changes like for problem 1 were found when trying to solve problem 3 which lead on to me solving problem 8 etc. Problem 2 was found in a conversation with Fifty as to why cities were growing so slowly on the server game.

I know how looking into one thing leads to finding something else. At work, putting me on the task of figuring out some problem almost inevitably leads to me finding at least one other problem, usually two or three. One of which is usually quite bad. Happened as late as today, when I noticed that something didn't work, and I'm now in the process of rewiring the build system to get it to work. Code freeze is Wednesday, and launch is Friday or Monday! (And I only work on that particular project two days a week.)

It's just that a patch touching upon several different things reminds me of the GUI patch from a year back that stranded after becoming too big and touching upon too many things (simgraph, tab-files and pak-file format). Endless debates on how to do one thing held back everything else. On the other hand, it was also requested that the patch had to be complete, so it had some conflicting requirements.
Title: Re: City code error correction.
Post by: prissi on January 26, 2015, 10:02:21 PM
On a more contructive note: r7511 will update also player owned city roads and build bridges matching the current city road speed (still there might be wodden bridges in the old town centre. See them as listed structures.)
Title: Re: City code error correction.
Post by: DrSuperGood on January 26, 2015, 10:24:23 PM
I will merge up, however when I was fixing that I also performed a minor code tidy on it since I noticed that the road conversion mechanism shared a lot of code between the building construction and building update methods (since they do the same things to convert the roads).

I am not taking on any more of the problems mentioned. I am primarily focusing to solve 2 and 9 at the moment (since they use the same code). If desired I could hack out changes needed for 9 into a separate patch however that would depend on the patch for 2 since they both interact on the same code.

EDIT (update)
Issue 1 is now fixed.

Issue 3 is not fixed. The solution commited recently was only partial missing another case of road conversion in the upgrade building method. It also did not extend to road under depots, something I recommend for consistency sake (since you do not take ownership of roads you build depots on). I have the more extensive fix in the attached patch.

The attached patch targets issues 2 and 9. It revises the growth code so that the metrics between ticks are used to determine growth with previous month backup (in case nothing needed to be shipped) to solve 2. It also re-scales missing growth factors (nothing to ship for that tick, usually goods due to lack of nearby consumer) to cover the remaining growth factors to solve 9.

Tests with well built games show that overall growth will appear to be the same. Towns lacking consumers will appear to grow slightly faster. Growth will also appear to respond faster with immediate growth results occurring when transport improves independent of what stage month progression is at.

If this patch is unacceptable please feedback what needs changing/fixing.
Title: Re: City code error correction.
Post by: Ters on January 27, 2015, 05:50:04 AM
2 and 9 are probably related enough.
Title: Re: City code error correction.
Post by: DrSuperGood on January 27, 2015, 06:23:28 AM
Updated my post while you were posting. It has the patch for problems 2 and 9 and a better fix for 3.
Title: Re: City code error correction.
Post by: prissi on January 27, 2015, 10:22:51 PM
Personally I think a town without goods does not need to grow as fast as one with goods. Generally growth was deemed rather too fast. So welcome more the higher precision.

Other than that, depot once depended on owning their ground to avoid waypoints in other peoples depot. (Although that may have been fixed since then.)

EDIT:
Those suspicious looking function pointer are indeed not compiling with MSVC ...


// Array implementation. Compile time constant so should inline well.
static city_growth_factors_t const CITY_GROWTH_FACTORS[GROWTH_FACTOR_NUMBER] {
{ HIST_PAS_GENERATED, HIST_PAS_TRANSPORTED, &settings_t::get_passenger_multiplier },
{ HIST_MAIL_GENERATED, HIST_MAIL_TRANSPORTED, &settings_t::get_mail_multiplier },
{ HIST_GOODS_NEEDED, HIST_GOODS_RECIEVED, &settings_t::get_goods_multiplier } };

gives C2420: look like function declaration bis disfunct (if this retranslates correctly from german).
Title: Re: City code error correction.
Post by: DrSuperGood on January 28, 2015, 12:14:19 AM
QuotePersonally I think a town without goods does not need to grow as fast as one with goods. Generally growth was deemed rather too fast. So welcome more the higher precision.
Late game I agree. Early game people can argue as some times it feels early game lasts too long. As it is moblet and 50 had to drop the month length in their game as growth was just too slow with really long month lengths.

In the future some form of global economic model is needed. This throttles growth up and down based on the global economic situation and limits maximum population to something reasonable. That is a major mechanics change, I was focusing primarily on fixes ATM.

I decided on this solution because it rewards players for doing a good job the most. It is not their fault that a city has no supplier to satisfy so why should they get punished with lower growth? It also appeared to be absolute as the same growth could be achieved no mater how many supplies the city had (4, 8 or even more!) as long as it was greater than 0. As such the change only changes the number of consumers needed to maximize growth from 1 or more to 0 or more allowing people to maximize city growth by doing a good job at transport satisfaction. The weight from lack of industry is re-distributed to passengers and mail appropriately (based on their weights) so a city without goods and without a passenger/mail service will still not grow (no free growth).

QuoteOther than that, depot once depended on owning their ground to avoid waypoints in other peoples depot. (Although that may have been fixed since then.)
The reason I choose that as the solution was that if you build a depot on a player 1 or null owned way they still retain ownership of it anyway so the lack of conversion is an inconsistency. You could get a free road under your depot unless you use your own roads which is kind of strange. It should either take ownership of roads or deny building a depot on null/player1 roads or it should allow them to be converted to neutral like city roads.

I could be work with this, I will re-test as it is not something one really makes a record of. If I am wrong maybe the best solution would be the inverse and to disallow depots on cityways so that players do not get free roads. In any case improving consistency is always good as it makes the game easier to understand and feel more polished.

QuoteThose suspicious looking function pointer are indeed not compiling with MSVC ...
Except they are compiling with MSVC... I mean I developed and tested the entire thing using the free Community edition (derived from 2013 Professional). I compiled both a debug and a release version using it and both worked. I even fixed an error (I am not perfect, accidently used monthly power use somehow...) using them. I even ran the current moblet server save (downloaded a few hours before) for 4-5 months fast forward to check growth was correct (which I can even confirm it remained the same for stable cities and increased for ones without consumers).

The documentation I found for that error says it is for a very old Visual Studio 6.0.
QuoteVisual Studio 6.0 
'identifier' : illegal symbol in context

Maybe the dereference symbol is evaluated before the namespace change operator? Would brackets help improve portability in that case? I can confirm that the patch code does build with MSVC 2013 Community.
Title: Re: City code error correction.
Post by: TurfIt on January 28, 2015, 12:32:50 AM
Quote from: DrSuperGood on January 26, 2015, 06:11:40 AM
Minor: Incorrect city bridge speed logic. - Solved
IMHO the previous behaviour was more correct. City roads will slowly upgrade to the 50km/h variant, bridges are stuck forever at whatever speed they were built at. --> best to build them at the final state. Or add a bridge upgrade routine.


Quote from: DrSuperGood on January 26, 2015, 06:11:40 AM
Major: Incorrect growth logic based on transport metrics. - Pending
This should be fixed using the same mechanism as the factory pax/mail boost rather than inventing a new aging/averaging model.


Quote from: DrSuperGood on January 26, 2015, 06:11:40 AM
Moderate: Town road conversion ignoring ownership. - Partly, Pending Revision
The solution is to force such roads to always be owned by null and have a pavement even if they are already the same type as the town road kind. This should be extended to ways under depots for consistency sake (no roads in city that are not city type road).
Maybe for depots have the road under it forced to be owned by the player?


Quote from: DrSuperGood on January 26, 2015, 06:11:40 AM
Major: Inconsistent city building upgrade logic with respect to elevated ways.
Quote from: DrSuperGood on January 26, 2015, 06:11:40 AM
major: Bridges have no idea of clearance.
Building have no height information at all. The number of .y images cannot be used as a height indicator, if elevated ways are using that, it should be removed.  To run any sensible height check, such would have to be added to all paks.


Quote from: DrSuperGood on January 26, 2015, 06:11:40 AM
Moderate: Players can replace city roads with other road types violating city speed restrictions.
Seems reasonable.


Quote from: DrSuperGood on January 26, 2015, 06:11:40 AM
major: Inconsistent bridge build logic.
Certainly building things needs consistent rules; Simutrans seems to have a history of strange and wonderful workarounds allowing construction of bizzare structures!
I'd consider bridge building completely busted at the moment as it takes 3, 4, or even 5 tries to get a simple high level bridge built. Sometimes you must drag it, sometimes single clicking works, sometimes you have to drag it the other way, sometimes.... no idea what the bloody thing wants...


Quote from: DrSuperGood on January 26, 2015, 06:11:40 AM
major: Inconsistent ownership test with elevated way construction.
The solution is to remove the ownership test. I do not see there being a reason why you should not build over other player building, especially now that multi-level stations are supported and elevated ways are a useful tool to deal with congestion in busy (lots of players) areas.
Seems reasonable.


Quote from: DrSuperGood on January 26, 2015, 06:11:40 AM
minor: Lost growth if no consumer exists nearby. - Pending
Currently if no consumer industry exists nearby a city the city will lose the appropriate growth from goods. Some people might argue this makes sense as the city economy would be worse off without a consumer
Current behaviour is more correct. If you set growth to depend 40% on goods, then there must be goods...


Quote from: DrSuperGood on January 26, 2015, 06:11:40 AM
moderate: Lost growth from goods if a consumer lacks a supplier.
Currently if a consumer is nearby a city and lacks a supplier for one or more of its inputs the city will lose an appropriate amount of growth from goods. Some people might argue this makes sense seeing how it is not fully satisfied however it is not fair to the players as they have no control over if a consumer is fully linked or not.
They can spend their money to build a factory then... fairness is not included.
Really what it sounds like you want to fix is the factory distribution. I agree it could use a major overhaul.


Quote from: DrSuperGood on January 28, 2015, 12:14:19 AM
Except they are compiling with MSVC... I mean I developed and tested the entire thing using the free Community edition (derived from 2013 Professional). I compiled both a debug and a release version using it and both worked.
Perhaps you're set to too new a standard? GCC is complaining: simcity.cc:86:76: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11 [enabled by default]
Title: Re: City code error correction.
Post by: DrSuperGood on January 28, 2015, 02:00:46 AM
QuoteIMHO the previous behaviour was more correct. City roads will slowly upgrade to the 50km/h variant, bridges are stuck forever at whatever speed they were built at. --> best to build them at the final state. Or add a bridge upgrade routine.
Except the pakset could define a city road as being faster than 50 km/h in which case the bridges might be too slow. On the other hand paks like pak128 Britain have very slow city roads in the 1800s and there are no 50 km/h road bridges then so future proofing is not a problem.

Upgrading city bridges is a separate problem that should eventually be dealt with. Much like how cities should take ownership of manually constructed bridges if they seem to fit with the city. However that is a new feature and not an easy fix.

QuoteThis should be fixed using the same mechanism as the factory pax/mail boost rather than inventing a new aging/averaging model.
Which is? Does that not use arrival slots? City growth is based on departures. Feel free to come up with a better implementation, however the fact remains that the original one was incorrect as the current month graphed statistics results in value variance with time.

My current implementation does not have anything to do with aging or averaging. Instead it simply takes the metric delta between growth ticks and computes satisfaction based on how well those were satisfied. If average satisfaction remains the same throughout the month the results will be the same as currently however this implementation will correctly handle the two half all half nothing cases I described resulting in the appropriate and expected half growth for that month.

QuoteMaybe for depots have the road under it forced to be owned by the player?
Yes except what if they remove the depot and it is in the city? How much do city roads even cost to maintain (normal users do not see that info in the UI). As you can see it is not simple from a user perspective. As far as usability is concerned having the city take ownership of the way under the depots would be more intuitive for users as it will not manifest in any special cases or expose them to any hidden mechanics (how much does a city road cost to maintain?).

If way ownership under depots causes problems with other systems they could exclude such cases by testing for a depot.

QuoteBuilding have no height information at all. The number of .y images cannot be used as a height indicator, if elevated ways are using that, it should be removed.  To run any sensible height check, such would have to be added to all paks.
Well I can assure you they are (well I cannot, I at least think they are from the code which given its size can be confusing at times). I even agree with you and it would certainly make playing much easier (elevated ways become super awesome for use in cities). Here is the line.


//This is @ ~ line 561 in simutrans/trunk/bauer/wegbauer.cc.
if(!check_owner(gb->get_owner(),player_builder)  ||  gb->get_tile()->get_hintergrund(0,1,0)!=IMG_LEER) {

As you can see, it gets the building tile image and then checks if the background image above exists or not. If it does exist it fails and will build around the building. The other check is also inconsistent as it stops you building over other player stops and station buildings (something that they can build under your elevated ways no problem). Removing both these error checks would solve everything related to elevated way inconsistency.

QuoteCertainly building things needs consistent rules; Simutrans seems to have a history of strange and wonderful workarounds allowing construction of bizzare structures!
I'd consider bridge building completely busted at the moment as it takes 3, 4, or even 5 tries to get a simple high level bridge built. Sometimes you must drag it, sometimes single clicking works, sometimes you have to drag it the other way, sometimes.... no idea what the bloody thing wants...
I have yet to even see a "high-level" bridge. I can only get the new amazing flat bridges and the 1 height ramp bridges. Maybe the paksets I use just lack them or maybe I just have no idea as to the tricks they require.

QuoteCurrent behaviour is more correct. If you set growth to depend 40% on goods, then there must be goods...
The issue is that it does not depend on the amount of goods, just like passengers and mail does not depend on the total amount. Unlike passenger and mail which almost every city no mater how small should generate (the townhall will generate it even if it is the only building in the city), goods are not always guaranteed to be there as suppliers are randomly created. As such it is easily possible that some cities may never see any goods values. Even if you were to completely transport all mail and passengers in these cities they could never obtain maximum growth due to lacking that final growth factor completely.

As such the implementation provided will re-distribute this missing goods weight to both passengers and mail allowing maximum city growth. As soon as goods do come available for the town they will need to be shipped for maximum growth to occur.

When finally some form of global economic manager is added this could be reverted by forcing the foundation of consumers near all towns so that every town will have at least some goods per month. Currently on moblet's server game there are towns with 3-4 consumers and others with no consumers which hammers total growth.

QuoteThey can spend their money to build a factory then... fairness is not included.
Really what it sounds like you want to fix is the factory distribution. I agree it could use a major overhaul.
They cannot build a factory ATM as only the public service provider player (player 1) can found factories and has no restrictions on doing so (kind of cheating).

You still need to not count inputs that cannot be supplied. The reason is because the required factory for the input type might not be available at the current period of time (introduced later) so until then you cannot ever supply 100% of goods to a town. I do agree that as soon as possible (next factory or the factory becomes available) it should make one to supply the missing input so that it can be counted.

Not punishing players for something out of their control is always a good thing.

QuotePerhaps you're set to too new a standard? GCC is complaining:
I did not even think MSVC 2013 supported C++11, with the release notes for 2015 stating it has such compliance.

I wonder if it has to do with how I initialized it and not the actual initialization? Specifically I do not use the '=' assignment to initialize it as the documentation I was reading online said that it was not necessary for C++. Try initializing the constant array with an assignment and see if it fixes it. I will do more research and post a fixed patch if I find proof this is the cause.

EDIT:
This sort of initialization appears to be supported by C++03 and later revisions (which inherited it from standard C). What standard of C++ does Simutrans target?

Any suggestions as to how I could initialize such a structure to be constant? Or should I manually unwrap the logic and hard code it? I used it to try and reduce procedural coupling when computing growth (loops through each growth statistic and performs the same computations).
Title: Re: City code error correction.
Post by: Dwachs on January 28, 2015, 07:36:30 AM
QuoteAs you can see, it gets the building tile image and then checks if the background image above exists or not. If it does exist it fails and will build around the building. The other check is also inconsistent as it stops you building over other player stops and station buildings (something that they can build under your elevated ways no problem). Removing both these error checks would solve everything related to elevated way inconsistency.
This works as long as the base image of the building is limited in height. However, this is not guaranteed. There can be buildings in game (theoretically) that have only base images of arbitrary height.

The check if the building consists of a stack of images is rather suboptimal. It would be much more consistent to encode the height in the pak and dat files. Only the the creator of the building knows the exact height. You cannot exactly devise the height of something from a 2d image.

Btw, you can see now why it is not a good idea to discuss a multitude of issues in one thread. It leads to miles-long posts, which makes it hard to follow the discussion imho.
Title: Re: City code error correction.
Post by: Leartin on January 28, 2015, 11:07:59 AM
Quote from: Dwachs on January 28, 2015, 07:36:30 AM
The check if the building consists of a stack of images is rather suboptimal. It would be much more consistent to encode the height in the pak and dat files. Only the the creator of the building knows the exact height. You cannot exactly devise the height of something from a 2d image.
The architect of a building can already state the height - if it is too high for an elevated way to go over it, he can just define a second layer above with an empty image. That's hackish, sure, but I don't think any architect ever did it - maybe they did not think of it, sure, but maybe they just didn't care - and wouldn't add a height parameter either.
Don't get me wrong, I'd like a height parameter. But in case of a lack of that parameter, I would not like it to be zero, but either "infinity" (no building over it at all) or fallback to approximation.
Title: Re: City code error correction.
Post by: Sarlock on January 28, 2015, 03:35:44 PM
There will be a few exceptions to the rule, but generally one can determine the approximate height of a building based on how many tiles high the image is.  It is possible that the front of the image is higher in appearance and the back is not, thus not requiring an additional tile in height, but as a rough approximation it should work for 90%+ of images.  At least the extra height will not be seen clipping above the roadway.
Title: Re: City code error correction.
Post by: prissi on January 28, 2015, 10:09:11 PM
And one can even get the pixel height to judge it it is higher than a height step (use back corsre + tile step for y-dimension.

To the initialiser lists: There are a C11 feature, and only supported in the latest compiler. Neither amiga nor some less common platform, nor the nightly compile farm supports this. Moreover, these settings are not const but can change with each new game.

Anyway, since you introduced defines anyway, that job of the structure could be also done by a define. Submitted in r7515.

Thank you.
Title: Re: City code error correction.
Post by: jamespetts on August 14, 2015, 05:57:01 PM
Interesting. I am looking at this topic for the first time now. Did this work die out or is it still in progress?

As I have written elsewhere, I am looking to improve the city growth code of Experimental by making it dependant on tile level rather than town level transport metrics, and also by having, as Dr. Supergood suggested here above, global growth constants (I believe that Neroden suggested something of the order of 1% per annum).

Some of these things have an implementation in Experimental already (elevated ways cannot be built above buildings with level > 2, nor can buildings with level > 2 be built under elevated ways), but it would probably be sensible for Standard and Experimental to converge in the implementation of this if Standard is to deal with this issue comprehensively.
Title: Re: City code error correction.
Post by: Ters on August 14, 2015, 06:12:46 PM
Quote from: jamespetts on August 14, 2015, 05:57:01 PM
Some of these things have an implementation in Experimental already (elevated ways cannot be built above buildings with level > 2, nor can buildings with level > 2 be built under elevated ways)

Judging from this discussion, that probably came from standard originally. Or (inspired) covergent evolution. It's just that level apparently does not have to be related to actual height, so there is a desire to unimplement this (if it isn't already).
Title: Re: City code error correction.
Post by: jamespetts on August 14, 2015, 07:13:26 PM
Yes, I can see the logic to that: this is an area where convergence between Standard and Experimental seems sensible if Standard develops in the way planned here.
Title: Re: City code error correction.
Post by: DrSuperGood on August 15, 2015, 05:29:13 AM
I stopped working on it after people could not agree how elevated ways and bridges should work.

Some wanted to simply ignore height so as long as there is 1 (2 for double height) levels from ground it can be built. Others wanted to make it so that the height of an object is based on the number of images high an object is. Some even suggested to remove images as a measure of height but rather give each object a declared height.

All in all the problem never got solved as no agreement was reached. Elevated ways still can get massive sky scrapers built under them. Bridges can still be built completely ignoring structure height.

There is a third issue with double height elevated ways. They force a minimum clearance of 2 above water yet bridges have no clearance constraints above water. As such you can build lower bridges than you can elevated ways. Again no agreement was reached as to the correct behaviour with some wanting to support low bridges but make them water un-passable while others wanting to force normal bridges up to the appropriate clearance.

To solve the building upgrade problem a search function is needed to find the most appropriate building upgrade with a height constraint. This would be like the current one except excluding results which fail the clearance parameter.

The "free land" test needs to be improved so that area under bridges is determined as free land rather than built.
Title: Re: City code error correction.
Post by: Ters on August 15, 2015, 06:51:03 AM
Quote from: DrSuperGood on August 15, 2015, 05:29:13 AM
Some wanted to simply ignore height so as long as there is 1 (2 for double height) levels from ground it can be built.

Actually, for some "buildings", I think a half-height bridge might be acceptable.

Quote from: DrSuperGood on August 15, 2015, 05:29:13 AM
The "free land" test needs to be improved so that area under bridges is determined as free land rather than built.

As long as there are no pillars at least. Which leads to the pillar removal issue from a recent discussion.
Title: Re: City code error correction.
Post by: jamespetts on August 15, 2015, 08:54:51 AM
Dr. Supergood - what was your preferred solution for each of these issues?
Title: Re: City code error correction.
Post by: DrSuperGood on August 16, 2015, 01:25:57 AM
Personally I would have gone with using number of Z images as a simple height metric but abstract the call so that it could be replaced in future with more accurate height measurement. Elevated ways would then be buildable at 1 (or 2 for double) heights above the current height of the tile. This would mean tall buildings could have even taller elevated ways above them.

One could argue that such high routes do not make sense, but if you look at some modern cities you do have roads 10-20 odd stories above the ground. Additionally it would keep in line with Simutrans being user friendly.

Bridges would have the same checks added as elevated ways use. So that buildings cannot upgrade above a certain height under them and that the bridge itself needs to clear everything under it. The ground under bridges would also be known as clear up to a certain height. Eventually elevated ways of "half height" would also have been looked into so that they match bridges.

The results would be consistent between bridges and elevated ways. Growth implications to towns would be manageable and easy to understand. The mechanics also allow for elevated ways and bridges to cross cities opening up the possibility for impressive (although possibly unrealistic) transport solutions.

Obviously in experimental you would probably want height limits (how high an elevated way/bridge can be above ground) and weight limits.
Title: Re: City code error correction.
Post by: Ters on August 16, 2015, 08:38:52 AM
Quote from: DrSuperGood on August 16, 2015, 01:25:57 AM
Personally I would have gone with using number of Z images as a simple height metric but abstract the call so that it could be replaced in future with more accurate height measurement.

I would have added the accurate height measurement first, so that height checking code just have one simple value to check, rather than having to count images all over the place. It also saves having to track down where such checks are made a second time. There are several degrees of implementing this, from just having a cached value in the besch class to fully exposing it the pak and dat formats. The latter has the bonus that pak authors can fix wrongly interpreted cases right away, and shouldn't be that much extra work.

And did you mean virtual, not abstract, because having only an abstract method makes no sense? I'm not sure even that makes sense, because there is no common base class for things that can be built under bridges that doesn't also include ways, vehicles, pedestrians, animals and smoke, neither of which does it make sense to check the height of. (For vehicles, you could perhaps define some vehicles as able to pass under low bridges, but I think all buses, trucks, trams, trains and ships would realistically be too tall anyway. It would just be for some city cars, and old horse drawn carts.)
Title: Re: City code error correction.
Post by: kierongreen on August 16, 2015, 11:18:05 AM
I'd go with setting a value in the file, a value which where not present can be estimated from number of z images. It also allows for buildings to prevent construction over them in different ways - while industrial units might look fine under a viaduct directly above, gardens wouldn't, although under a much higher bridge they could still be ok...

Adding checks on heights to calculating routes is likely to slow things down too much, which is why all checks on bridges over ways, or ways under bridges are done at build time.
Title: Re: City code error correction.
Post by: Ters on August 16, 2015, 12:27:03 PM
Quote from: kierongreen on August 16, 2015, 11:18:05 AM
Adding checks on heights to calculating routes is likely to slow things down too much, which is why all checks on bridges over ways, or ways under bridges are done at build time.

That rules out vehicles of different heights, but since building a low bridge over a river, even one big enough to be navigable, or water seems reasonable, clearance does become an obstacle in route calculation. In that other bridge discussion, I proposed masking the ribis like signs and signals do, although I'm not sure about the effect on open water. It doesn't make much sense for roads, railroads or taxiways, so those could still be hard at build time. The big issue for me is whether this should require a "secret" modifier (which led to a discussion on how to make them less secret), or be possible by default in the hope that it never will actually interfere with any ships, future or present.
Title: Re: City code error correction.
Post by: kierongreen on August 16, 2015, 02:40:44 PM
If it is going to block waterways then the default behaviour has to be to not allow this - it's less confusing for bridges to need to be double height than for vehicles to suddenly not work, although thought has to be given to imports of existing saved games as well. Any secret modifier, and I'm not convinced at all that's a good idea, should therefore be to allow low bridges over open water or navigable bridges.

I'd rather just block low bridges over open water. When dealing with 1km/tile scale this is reasonable realistic I think, as in real life bridges of that length almost always have at least some part which is high enough to permit large ships to pass underneath.
Title: Re: City code error correction.
Post by: Ters on August 16, 2015, 03:13:11 PM
Quote from: kierongreen on August 16, 2015, 02:40:44 PM
If it is going to block waterways then the default behaviour has to be to not allow this - it's less confusing for bridges to need to be double height than for vehicles to suddenly not work, although thought has to be given to imports of existing saved games as well. Any secret modifier, and I'm not convinced at all that's a good idea, should therefore be to allow low bridges over open water or navigable bridges.

My concern is that getting a bridge up to double height is a lot more work, involving many tools from two different toolbars, since the normal approach is to not have ramps going up two levels. This also costs a lot more, causing rivers to demand a lot more knowledge and money from new players to overcome. It also causes vehicles to lose more speed going up.

In the context of this discussion, the city AI must also be taught how to raise a platform from which to build bridges. On the other hand, even if low bridges were legal, having cities blocking your ships buy building low bridges all the time isn't nice either. I'm leaning towards just blocking the rivers because I don't use many ships myself, and even less going far up rivers. (They are slow, which doesn't work well with JIT1 on big maps.) There haven't been many ships in the screenshots I have seen posted on this forum either. Then again, I play pak64, so for me personally, there is no concern. I just worry about he players, especially the less computer savvy.
Title: Re: City code error correction.
Post by: kierongreen on August 16, 2015, 03:52:24 PM
Well, the main issue is for railways in pak128, as that allows steep slopes only for road bridges as far as I'm aware. pak64 as you point out isn't affected, and pak128.Britain allows steep slopes for everything. Personally I'm ok with there being a bit more of a steeper learning curve for railways than roads, but I do understand the concern, particularly for AI...

Rivers may be more useful earlier on, particularly paks which simulate earlier eras.
Title: Re: City code error correction.
Post by: DrSuperGood on August 16, 2015, 07:40:32 PM
Current hand-made maps like Fifty's server have water occupying a level below the shore. As such all that is needed is a shallow ramp to bridge across with correct clearance (since the rail is already 1 above the ocean). Obviously flat water would need a double ramp (which may not be possible) but that is usually only used for internal lakes and not oceans.
Title: Re: City code error correction.
Post by: Ters on August 16, 2015, 08:42:19 PM
Quote from: kierongreen on August 16, 2015, 03:52:24 PM
Well, the main issue is for railways in pak128, as that allows steep slopes only for road bridges as far as I'm aware.

Having little experience with pak128 beyond the tests I did regarding gauthier's bridge problem, I thought it didn't have double height ramps at all, but it turns out low speed road bridges have them. High speed does not, however that's not what the cities will be building anyway.

I also notice that Ctrl does already toggle construction of double height bridges. Does this mean that the only issue with gauthier's problem was a misleading error message, assuming blocking rivers should be forbidden?

Quote from: DrSuperGood on August 16, 2015, 07:40:32 PM
Current hand-made maps like Fifty's server have water occupying a level below the shore. As such all that is needed is a shallow ramp to bridge across with correct clearance (since the rail is already 1 above the ocean). Obviously flat water would need a double ramp (which may not be possible) but that is usually only used for internal lakes and not oceans.

I don't think cities will need to bridge lakes and seas, as it can build around lakes, and have no realistic incentive to bridge seas (Istanbul is perhaps the exception to the rule, but it's bridges are as much a national project as a municipal). Intercity roads and AI players could perhaps have to deal with crossing bays and sounds, though.
Title: Re: City code error correction.
Post by: DrSuperGood on August 17, 2015, 02:50:21 AM
Road bridges support double height ramps. Forcing shallow ramps was only ever intended for railways.
Title: Re: City code error correction.
Post by: Ters on August 17, 2015, 04:47:48 AM
Quote from: DrSuperGood on August 17, 2015, 02:50:21 AM
Road bridges support double height ramps.

Not all of them, according to my tests. Whether such steep bridges are realistic is another question. When I think of bridges crossing navigable rivers in a city, they do need at least a city block to ramp up. And partially related: Cities should not build bridges for every city street meeting a river, and less so if the river is wide.
Title: Re: City code error correction.
Post by: DrSuperGood on August 17, 2015, 05:04:49 AM
Cities actually need some intelligence when playing bridges and terraforming capabilities. They really perform badly in hilly terrain.