News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

City code error correction.

Started by DrSuperGood, January 26, 2015, 06:11:40 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DrSuperGood

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.



  • Minor: Incorrect city bridge speed logic. - Solved
    Currently what happens is that cities order bridges with a recommended speed of 50 km/h. The city road speed however is based on the way type used which can vary with time. This means that in periods where road speed is lower than 50 a more expensive bridge than necessary might be constructed. Additionally in times where road speed is higher than 50 a bridge that is too slow might be built.

    The solution is to search for a bridge with speed being at least that of the current public road. Older bridges might be too slow for newer speed limits but they might be that anyway due to the availability of bridges at the time.

  • Major: Incorrect growth logic based on transport metrics. - Solved
    Currently the current month average for passenger, mail and goods is used to determine the amount of growth for a city. To many this seems appropriate however it results in major biasing of shipment times with respect to growth. Since the current month stats are comprised of shipments that occur from the beginning of the current month until it ends this means that shipments made early during the month will result in more growth as they are used more in the computation than shipments made towards the end which get used less. Specifically if you were to ship 100% for half a month and then 0 for the rest you would get two extreme cases. If the shipment occurred at the start of the month you would end up with probably over 75% of the maximum possible growth. On the other hand if the shipments occurred towards the end of the month you would end up with probably less than 25% of the maximum possible growth. Both cases if the logic was correct should generate approximately equal growth since approximately the same quantity of shipment satisfaction occurred. This is made worse by excessive month length as you might have to wait out half the month before reasonable growth occurs.

    The solution is to change how growth is compute to use the previous month shipment statistics which are constant with regard to time so all shipments are equally weighted across the entire month. This however would result in unresponsive growth so growth should be based on the satisfaction of the demand that occurs between growth cycles. This means that transport that occurs between growth cycles is equally weighted as it only is used for a single growth cycle and growth becomes highly responsive as it uses only the immediate past. In the case that nothing needed shipping between cycles (small hamlet?) you can default to last month metric with if that had nothing to ship (new town) 0 growth occurs.

    For save determinism extra variables need to be saved that represent the difference that occurred since the last growth tick otherwise upon resuming incorrect (non-deterministic) growth will occur due to changes in the computed difference.

  • Moderate: Town road conversion ignoring ownership. - Partly, Solved
    In the current implementation town roads will happily convert other player's roads into town roads giving them pavements and the appropriate town road type. However if a player already owns a road of the same type as the town road type it will get paved but not have its ownership changed. This means that players can end up being left with roads in the middle of towns that look like town roads but are owned (so others cannot build stops on them). What should happen is that they correctly change ownership to the town (null currently) just like all other roads. Roads under depots are also ignored and can end up being paved, owned and having the wrong way type for a city road.

    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).

  • Major: Inconsistent city building upgrade logic with respect to elevated ways.
    Elevated ways cannot be built over buildings which have a second story image. The logic behind this is that the building is in the way of the elevation way instead of under it due to its height. However nothing stops the city upgrade logic from placing a multi-tile high building under an elevated way (even though you cannot do it the other way round!). The result is that an elevated way that runs through a city might not be re-constructible due to tall buildings appearing under it without having to demolish such buildings (not something one wants to do). It is not just limited to city upgrade buildings but also stops and support buildings which can be multiple tiles high can get built under elevated ways yet themselves cannot be built over with elevated way. This is a logical inconsistency that can confuse new users, annoy existing users and overall makes no practical sense.

    The result is to check for the presence of elevated ways. Town upgrade logic should make sure that only upgrades are chosen that meet the required clearance (so upgrades do occur still, just not to buildings that are too tall). Additionally placing of station buildings should make sure that the clearance is sufficient to build them. Clearance should be based on how high the elevated way is above the building with each image tall the building is requiring 1 (2 with half heights) elevations below the elevated way for construction. Clearance is not really important for this solution (as elevated ways above buildings likely have none) however it is needed for bridges and possible improvements to elevated ways (so you can build them above taller buildings).

  • Moderate: Players can replace city roads with other road types violating city speed restrictions.
    Currently it is possible to replace city roads with another type of road not meant for use inside cities. Although the city may reclaim some if not all the road over time it does allow players to both prevent other players making stops in a city and raise speed limits. It also results in inconsistent logic with roads in cities which can confuse beginners as to why their roads keep converting to a slower road type.

    The solution is to make all roads that run next to a building (not sure about corners but certainly edges contain a building) automatically turn into city roads owned by null. The player still pays some fee for the construction (if any are built) and can determine where roads go. However they cannot make any road other than city road next to city buildings keeping the integrity of city roads intact. It also speeds up the citification of player made roads so that roads intended to become city roads might do so faster and so the player pays less maintenance. The mechanic will also be more intuitive for new players as they would notice that city roads occur every time they build next city buildings so will not try to run a high speed road through a city. It also solves an issue of "dead" city roads (city roads that were made for structures that cannot upgrade anymore) having to stay as possibly obsolete city road type as players can replace them.

  • major: Bridges have no idea of clearance.
    Currently bridges do not check if they will intersect with structures during construction. It is possible to build a bridge right through some skyscraper city buildings and both function correctly. However you cannot build elevated ways through such buildings despite the apparent height being identical. The result can be very messy and also annoying to beginners as it is inconsistent with the elevated ways despite looking similar. Additionally when upgrading houses a tall sky scraper might pop up under a bridge resulting in it appearing to be chopped in half.

    The solution is that bridges should run a "clearance" test similar to elevated ways but more advanced. The difference is that it should make sure that the bridge is 1 (or 2 for half-height) elevation levels above the structure to avoid it appearing to intersect. This would still allow bridging over cities however it would require a bridge at considerable elevation to clear the sky scrapers involved. Tests with the upgrade code for both elevated way and bridge clearance should prevent upgrades which can potentially make the bridge not re-buildable (building intersection).

  • major: Inconsistent bridge build logic.
    It is possible to bridge over buildings with way bridges. However it is not possible for buildings to be built under bridges with a UI error message being generated when trying to do so. Run a bridge over a small town and allow it to grow. The buildings under the bridge will upgrade fine as expected. Clear ground under the bridge around the old town will still be clear with all other areas next to the bridge being consumed by buildings and road. This behaviour is inconsistent and heavily ruins the use of bridges inside cities.

    The solution is to modify building placement tests to ignore section with a bridge over them (if clearance permits) and treat them as empty land. Cities should be able to place buildings under bridges much like how you can place bridges above buildings.

  • major: Inconsistent ownership test with elevated way construction.
    Currently elevated ways test for ownership of buildings for permission to build above them. This test means that only self-owned, public owned or null owned buildings can have elevated ways placed on them. However nothing stops a player from placing a building under someone else's elevated way as no tests are run. This makes other player buildings a hazard when running elevated ways around the map (such as a stop blocking a road through a city). It also means that other players can make a station under your elevated way preventing you from re-constructing the elevated way. A clear case of inconsistent logic which can confuse beginners and annoy players.

    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.

  • minor: Lost growth if no consumer exists nearby. - Solved
    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 however having multiple consumers nearby does not make growth faster. This limits city growth for cities without consumers nearby that is not the fault of the transport companies as consumers are generated highly randomly. In the case of pak64 this would be a loss of 25% potential growth as 40 weight comes from passengers and 20 weight each from both mail and goods.

    The solution is to roll over the growth weight for goods (or other metrics) if no demand occurred during the measured time period. This means that players still have to aim to ship 100% of every demand for maximum growth but will not get a penalty to growth if the city has no such demand.

  • 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. This is often the case for industries like the pak64 "Pharmacy" where Chemicals are often the only product available for it until a "Medicine Packaging Plant" opens up.

    The solution is for the goods demand metric computation to ignore consumer inputs which do not have a supplier. Due to the complexity of this algorithm (testing all linked suppliers) it would be recommended to cache the result against each consumer input when the suppliers are linked during construction or map load.

Ters

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.

Aquin

@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.

DrSuperGood

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.

Ters

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.

Aquin

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.

DrSuperGood

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.

Ters

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.

prissi

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.)

DrSuperGood

#9
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.

Ters

2 and 9 are probably related enough.

DrSuperGood

Updated my post while you were posting. It has the patch for problems 2 and 9 and a better fix for 3.

prissi

#12
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).

DrSuperGood

#13
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.

TurfIt

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]

DrSuperGood

#15
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).

Dwachs

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.
Parsley, sage, rosemary, and maggikraut.

Leartin

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.

Sarlock

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.
Current projects: Pak128 Trees, blender graphics

prissi

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.

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

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).

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

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.

Ters

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.

jamespetts

Dr. Supergood - what was your preferred solution for each of these issues?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

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.

Ters

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.)

kierongreen

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.

Ters

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.

kierongreen

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.

Ters

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.

kierongreen

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.

DrSuperGood

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.

Ters

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.