Author
Topic: DSG Development Blog (Read 8454 times)

This is a front for feedback, suggestions and goals relating to my work on Simutrans. It is intended to add some transparency and thought process behind the making of changes and hopefully document them for future developers to better understand why something was done.

Bug fixes I make will not be covered here because they are documented by the bug report thread itself.

My current aim is to revise the logic and inner workings of several in-game tools players can use. These changes are being based on a combination of personal experience and feedback from multiplayer server administrators and players.

A big recurring complaint is the sacrificial company exploit. Players who's company cannot afford an expensive permanent action would start a new dummy company and then bankrupt it doing the action while their main company reaps the rewards from the action. Most commonly seen with terraforming and city building etc. This was especially a problem on servers where city building was meant to be disabled as sacrificial companies could be used to build such cities even if their price was intended to be impossible.

To combat this fund checks are being added to many of the tools. So far these include plant trees, build city, build artificial wall/incline, build headquarters and make public. These actions can no longer be performed if a company has insufficient funds (in the form of equity) for the action to fully complete. Although this will not stop actions such as plant tree, it will stop people building cities if they are set to a high enough price as well as prevent them from accidently bankrupting themselves.

The complexity trees add has been a bane for server owners for some time due to increased map transfer times. This is why most server games have the "no_trees" configuration flag enabled so random maps are generated without any trees on them. Although they might start out treeless, players can still add trees to them possibly out of malice. Since trees grow and spread, a few trees planted around the map can end up into massive forests after 200 years or so which do have noticeable effects on map size. To stop this the no_trees option now completely disables planting of trees, even by the public service player.

The make public tool can be very useful in server games for making or rebuilding public ways which are useful for other players to use but not used by the responsible company. However the tool has several strange mechanics to it such as not functioning on bridges or inclines. Ways built on inclines before required some hacky artificial wall work to be made public which cost the player extra and tunnel entrances were just impossible to be made public. This has been changed so that the tool will now also function on ways that are built on an incline, including tunnel entrances. Bridges still cannot be made public however it is something I plan to eventually look into.

The cost of the make public tool was unclear, lacked the ability to be configured and seemingly random. This has been changed so that it now costs a configurable number of months of maintenance (default 60 or 5 years of operation) which is then transferred to the public player. Public player takes ownership of ways for free. As mentioned above it also gets fund checked hence setting the configuration to something ludicrous such as 36,000 months (3000 years) could in theory make its use impractical/impossible.

A piece of code was removed from the make public stop method that seemed to be dead. After many tests in practically every conceivable station join configuration from both players and public service provider using the tool the branch of code was never executed and hence why I am fairly certain it is dead. I am guessing it was left in from when the method used to join any two stops and make them public and hence had to cope with another non-public stop rather than assuming it is already public which is what the current implementation forces.

The tool error string translation constants are being placed in string constants. This is for maintainability as otherwise the same string constant ends up declared in multiple locations so is hard to change and can be error prone with typos or copy mistakes.

I plan to apply my last JIT2 revision at some stage after updating it for compatibility before going on to see if the problems with JIT2 can be ironed out. I also intend to hack around with more of the tools, revising code and adding fund checks. I am open to suggestions for minor things as well.

I still find treeless maps boring, so manually adding a few trees is more beautiful. Maybe instead forbidding tree creation on your maps, decoupling tree planting and tree removal cost could forbid planting trees just by making them too expensive while removal was still possible.

A map without trees would be treeless until the public player adds the trees. SO both side could do without forcing no_trees = never trees.

I still find treeless maps boring, so manually adding a few trees is more beautiful. Maybe instead forbidding tree creation on your maps, decoupling tree planting and tree removal cost could forbid planting trees just by making them too expensive while removal was still possible.

One can turn the flag off after creating the map allowing them to be planted (not a problem in single player). I checked this and can confirm it works. Some server owners with faster servers or small maps do not mind the trees so keep the flag off anyway. It is mostly aimed at multiplayer where server owners purposely want no trees to optimize save/load sizes and I have seen trees used to troll/vandalize to some extent (no other reason why they were planted individually over a huge area of the map).

Some exception could be added for the public service player however I feel this would degrade the meaning of the flag. Perhaps adding "no_trees_spread" flag so that they do not naturally grow might be more useful in such a case? One can leave no_trees off and not have to worry about huge forests eventually showing up everywhere.

The main problem is the tree spread, since even 1 tree after a few hundred years can cover a significant area with trees. Each tree tile can only be deleted 1 tile at a time so cleaning up from a player who purposely planted trees everywhere in a no trees server is not viable effort wise.

Quote

One could perhaps forbid players other than the public player from planting trees in a network game? Transport companies do not usually plant trees, after all.

It really depends on the server though. Some people have no problems with trees at all while other owners do.

I also pulled out some more of the translator text identifiers into constants. The general intent it to make the code more maintainable as one can easily see what translated text is available and be sure not to make any typo errors when referencing one or accidently creating a new reference for text that already exists. Since the identifier string is in one place it can be changed fairly easily as well, not that there is a reason to do so. Another advantage is that each text identifier can be commented as to its purpose and meaning, which is useful for those text identifiers which were written in German that some people might have problems understanding (abstracts away the German). Eventually it might be a good idea to pull them out into a separate header file that is included every where translated text is needed by the engine.

The complexity trees add has been a bane for server owners for some time due to increased map transfer times.

The default forest settings for both pak64 and pak128 tend to create too dense of forests IMHO. A few parameter tweaks and the created forests are much better suited for online games - 1/2 the initial file size and still looks good.

But, the real problem is after ~80 years the entire map suddenly get filled with trees - surely this is a bug, but I've not had a chance to track down...

The make public tool can be very useful in server games for making or rebuilding public ways which are useful for other players to use but not used by the responsible company.

No. The tool is called make_stop_public. It should only work for it's original purpose to create public interchange stations. The ability to use it on ways, etc. seems an oversight and should be completely removed to eliminate the exploit of players ending up with no maintenance costs. If necessary, a second tool to create public ways etc could be created, but must be disable-able for a sane multiplayer game.

Related issue: when a player exploits a shell company to make all the ways public, and the shell goes bankrupt, the ways end up owned by 'null' instead of the public player, hence tolls don't even apply! Nice to fix that too...

Also, changes of this magnitude to game mechanics should ideally have a patch posted for comments first.

The tool error string translation constants are being placed in string constants. This is for maintainability as otherwise the same string constant ends up declared in multiple locations so is hard to change and can be error prone with typos or copy mistakes.

Again, such a change should IMHO have had some discussion first... makes it harder to read as you now have to find the string defined somewhere other than where it is used to see what it actually says.

Changes to translated strings are still all but impossible. Simutranslator is a mystery, and whoever admins it for adding new accounts doesn't respond (still waiting after 10+ months...) I.E. your change to the make_stop_public tooltip breaks (orphans) all existing translations. Also, the base.tab file wasn't updated with the new text.The added "Trees disabled!" also wasn't put into base.tab.

I plan to apply my last JIT2 revision at some stage after updating it for compatibility before going on to see if the problems with JIT2 can be ironed out. I also intend to hack around with more of the tools, revising code and adding fund checks. I am open to suggestions for minor things as well.

I know I'm still negligent at getting to it. If it only affected JIT2, then go ahead. But it affects electricity overall in JIT0/1 as well, and there was just something in the changes that gives me a gut feeling of being wrong. I'll get there...

---The added fund checks are good. (atleast I can get one good comment into my bloody negative post)

No. The tool is called make_stop_public. It should only work for it's original purpose to create public interchange stations. The ability to use it on ways, etc. seems an oversight and should be completely removed to eliminate the exploit of players ending up with no maintenance costs. If necessary, a second tool to create public ways etc could be created, but must be disable-able for a sane multiplayer game.

It is no oversight. Code was purposely written to make ways public long ago.

There is a setting to adjust its cost. To make a way public people have to pay by default 60 months maintenance (5 years) to the public service player. This can be quite substantial for pak128. If it is set to some insane value like 36000 (3000 years) then people will either not be able to afford the tool or if they can then the public service player gets enough money to maintain the way for 3,000 years so it is not free.

Quote

Related issue: when a player exploits a shell company to make all the ways public, and the shell goes bankrupt, the ways end up owned by 'null' instead of the public player, hence tolls don't even apply! Nice to fix that too...

Its on my to do list. Also city roads to be owned by public (not null) so they charge toll and to force city roads near public buildings (stops replacing them with fast roads in cities, all those kids playing in the streets will be safe!).

Quote

Also, changes of this magnitude to game mechanics should ideally have a patch posted for comments first.

I have discussed them with people online for a while. Including some other devs, people like fifity and several server owners. Also I made this thread to discuss such changes and gather feedback for that very purpose.

If one wants Simutrans to progress ultimately things need to get done rather than only talked about.

Quote

Again, such a change should IMHO have had some discussion first... makes it harder to read as you now have to find the string defined somewhere other than where it is used to see what it actually says.

However the constants are given a meaningful English name. Also the problem existed before except you had to search through a 5 thousand lines of source looking for what strings have been declared, or go to Simutranslator and look them up there and make sure to copy them perfectly.

Quote

I.E. your change to the make_stop_public tooltip breaks (orphans) all existing translations. Also, the base.tab file wasn't updated with the new text.

I tested it in game and translations appeared to still be working. I was not aware of the base.tab file, will look into it. The same strings are used (except the ones I added), just they are stored in a constant which is referenced rather than having multiple copies spread around over 5 thousand lines of code.

Quote

I know I'm still negligent at getting to it. If it only affected JIT2, then go ahead. But it affects electricity overall in JIT0/1 as well, and there was just something in the changes that gives me a gut feeling of being wrong. I'll get there...

Well if something is wrong then it can be fixed. I ran tests with it and no major crashes or errors occurred. Simutrans is not perfect as is, hence all the bug reports and fixes. Although it is a good idea to try and avoid introducing new bugs and errors, if progress is to be made then ultimately new errors or bugs might be introduced. After all that is how the existing ones which get fixed made their way into the game in the first place. Ah the development cycle

The cost of the make public tool was unclear, lacked the ability to be configured and seemingly random. This has been changed so that it now costs a configurable number of months of maintenance (default 60 or 5 years of operation) which is then transferred to the public player. Public player takes ownership of ways for free. As mentioned above it also gets fund checked hence setting the configuration to something ludicrous such as 36,000 months (3000 years) could in theory make its use impractical/impossible.

This seems like a good start but 5 years of opperrating cost is not alot if a player is gone use a massive tunnel for a 100 years. And if you are gone set the cost to 100 years it might be to expansive to share a (train) station where it is needed when a new player is starting. I should rather see a way to have the player that build the shared object to keep paying opperrating cost.

you would still be able to get around the opperrating cost by bankrupting companies unless everything shared is removed when a company goes bankrupt.

You could just adopt the system in Experimental, where ways and stops can be made public (nationalised) only by the public player, but players can connect their lines and give each other permission to run on each others' lines and stop at each other's stops.

This seems like a good start but 5 years of opperrating cost is not alot if a player is gone use a massive tunnel for a 100 years. And if you are gone set the cost to 100 years it might be to expansive to share a (train) station where it is needed when a new player is starting. I should rather see a way to have the player that build the shared object to keep paying opperrating cost.

you would still be able to get around the opperrating cost by bankrupting companies unless everything shared is removed when a company goes bankrupt.

I'm wondering if this idea could work?

Quote

You could just adopt the system in Experimental, where ways and stops can be made public (nationalised) only by the public player, but players can connect their lines and give each other permission to run on each others' lines and stop at each other's stops.

Public ways and stops are not a problem. In fact they are very useful for things like public roads between cities. The tool is needed so that a player can modify public roads (those which the map generator places, or even ones that it does not) around their ways like rails without having to forcefully take ownership of the way preventing it from being upgraded etc.

As a counter example of why the experimental system is bad. In the server of the last release, players made a lot of rails and cannals everywhere which had to be bridged over. Since they owned those bridges and roads it meant that only they could upgrade them. Since the bridges used lacked the weight loading for cars the result was a mess of islands that could not be driven between by cars despite there being a ton of bridges. If these were made public and could be modified by the players then the player who wanted to use a connection could personally upgrade the required bridges without having to beg the other company to do so and then waiting several days for a response.

Quote

This is becoming a tangle of different topics, but I think that if a stop is made public, which means the player no longer has to pay for its upkeep, then the players should have to pay to use it.

Maybe a system of returning non-shared assets? Such as if the station is not shared by at least 2 companies after 5 years (only the person who built it is using it) then it reverts back to them?

Another approach might be to improve tolling for the public player. It sums up some kind of usage metric for each player which it then charges them for at the end of month.

Alternatively some kind of taxation system could be used where players have to pay for the public player maintenance based on the fraction of total transported.

I think a lot of public way and stop abuse cases are more a job for server moderating than having the feature removed entirely. There are cases for fair use of the tool. However based on feedback here I will look into adding configuration flags to disable the tool working on ways (except if used by public service provider) .

If mixed stop ownership was allowed (where the same stop can be composed of buildings owned by different players) then public stops could be removed entirely. This would even be a usability benefit since then each player can modify the parts they use (unlike now where public stops can only be modified by the public service player and Experimental's approach where only the owner can modify and expand a stop which is very inconvenient to other companies). However I doubt this is a simple job despite ownership being tracked on a per building level as a lot of the code probably presumes a single owner.

As a counter example of why the experimental system is bad. In the server of the last release, players made a lot of rails and cannals everywhere which had to be bridged over. Since they owned those bridges and roads it meant that only they could upgrade them. Since the bridges used lacked the weight loading for cars the result was a mess of islands that could not be driven between by cars despite there being a ton of bridges. If these were made public and could be modified by the players then the player who wanted to use a connection could personally upgrade the required bridges without having to beg the other company to do so and then waiting several days for a response.

The difficulty with allowing a non-public player to make something public is that that can amount to seizure of assets of another player. This could allow vandalism of others' networks. Further, if the making public tool were made so expensive as to discourage its use to reduce costs (such as using a long tunnel for a century), then it would likewise be too expensive for players to deal with the issue that you describe by seizing other players' ways.

Experimental has been changed since the last large online game to allow players to alter roads built on map generation, which are now null player rather than public player, but makes them all public rights of way, meaning that they can only be upgraded (not downgraded), anything that they are upgraded with will also be a public right of way (and thus passable by any player's vehicle), and can only be removed if a short diversionary route (which, on deletion of the original way, becomes a public right of way itself) be provided. This also works for rivers. This effectively deals with the issue so far as roads and rivers created on map generation are concerned.

Quote

Alternatively some kind of taxation system could be used where players have to pay for the public player maintenance based on the fraction of total transported.

Taxation is a very interesting idea and one that has been considered for Experimental for some time; it would make more sense to have a realistic tax system in which taxes are based on a proportion of profits.

Due to the lack of sufficient artificial intelligence, it seems clear to me that someone must take on the role of the public player to provide the common infrastructure. Realistically, this would be pretty much all intercity roads. Depending on era, it would also include airports, stations and bus terminals. Whether such realism makes for good game play, especially for the one playing the public player, is a good question.

Experimental has been changed since the last large online game to allow players to alter roads built on map generation, which are now null player rather than public player, but makes them all public rights of way, meaning that they can only be upgraded (not downgraded), anything that they are upgraded with will also be a public right of way (and thus passable by any player's vehicle), and can only be removed if a short diversionary route (which, on deletion of the original way, becomes a public right of way itself) be provided. This also works for rivers. This effectively deals with the issue so far as roads and rivers created on map generation are concerned.

The problem had nothing to do with pre-placed bridges and roads, but rather the roads built by players to bridge over their ways. Since ways intersected the map everywhere dividing it into a grid of sorts players owned a lot of such overpasses. As they never bothered to upgrade these or could not make them publically modifiable the result was a mess of roads no one could use.

To stop the proxy company problem I have suggested tracking player IP addresses. Servers can then limit company creation to 1 per unique IP. Although this will not stop people with dynamic IP addresses from making more companies and will stop multiple players who share a NAT from doing so, it would make it largely inconvenient to exploit the trick. A setting for such a system would be useful as some server owners might object to it.

Generally exploiting public ownership to save on maintenance is kind of pointless in standard. In most server games I play for both pak64 and pak128 I end up making so much profit that I could completely absorb the public service player and still be sitting in tons of profit. Often I am not alone, with at least 3-4 other people ending up in a similar situation. Hence why I think exploiting of the tool should be more an act of moderating the server rather than physically limiting it.

When I use the tool its because I needed to change a public way for my own ways so I moved the way in some form (eg onto a bridge, or into a tunnel). I do not want to own that, because later on (eg pak128 where fast roads get introduced later) someone might want to upgrade it when they use it. Many servers have run rules like "repair all public ways" etc.

Quote

Due to the lack of sufficient artificial intelligence, it seems clear to me that someone must take on the role of the public player to provide the common infrastructure. Realistically, this would be pretty much all intercity roads. Depending on era, it would also include airports, stations and bus terminals. Whether such realism makes for good game play, especially for the one playing the public player, is a good question.

Having the public service player as an actual player, instead of some kind of super administrator, has been in my head for a while. Although I think it could bring some interesting game play decisions and could even add to servers (if he goes broke, you lose), the problem is that it would need major game play changes to implement. So for now is probably not worth thinking about.

@riverSince the cost check would apply to make things public, then making a massive tunnel network public will not work too.

You can still use multiple companies to connected the tunnels to create a big one.

Quote

Due to the lack of sufficient artificial intelligence, it seems clear to me that someone must take on the role of the public player to provide the common infrastructure. Realistically, this would be pretty much all intercity roads. Depending on era, it would also include airports, stations and bus terminals. Whether such realism makes for good game play, especially for the one playing the public player, is a good question.Having the public service player as an actual player, instead of some kind of super administrator, has been in my head for a while. Although I think it could bring some interesting game play decisions and could even add to servers (if he goes broke, you lose), the problem is that it would need major game play changes to implement. So for now is probably not worth thinking about.

I think this would be a interesting option, i would love to play as the public player. i wouldn't put it in as a default setting thought.

I should hope that the way wear mechanism would help with automatically upgrading thoroughly obsolete ways. In any event, this sort of problem is not otherwise resolvable without giving opportunities for players to seize and/or vandalise other players' networks, as far as I can make out, at least not without super-intelligent A. I..

The ways of liquidated companies should now go to public player as opposed to NULL. There may be a logic error with the maintenance for tunnel and bridge ownership transfer when under a public stop. There should be methods that automatically manage ownership change and maintenance rather than every location it occurs having to do so with the same several function calls. There might also be a minor graphic bug as I do not see any of the ownership changed objects being made dirty to be redrawn.

I spent an hour odd restructuring the make public tool code. Looking at the logic there was a potential NULL dereference in there if the position input did not represent a valid ground object, but I am unsure if it would have ever been able to occur.

Way objects are now treated separately from ways and are chosen if no suitable stop or way exists to be made public. The reason for this was to stop obscure situations where one could build privately owned way objects on public ways and not make those objects public yet if one made them on a privately owned way and made that way public they would also become public. This was made worse by a company being able to build a stop on the public way while it had a different companies way object on it.

I really want to add logic to make bridges public. Seeing as they have to be done as a single transaction of all bridge components it might need its own special case logic.

Added basic drag support to the make public tool. Dragging apparently was implemented before, but did nothing useful as far as I could tell. I am guessing it was meant to mark an area to be made public, displaying a cost preview, and then when released make the entire area public. Instead it showed some costs which would follow the tool around in a buggy way and do nothing when released. The new drag behaviour is similar to building stops, addons or any such drag and it does work tools.

To prevent the public way notification messages from generating a lot of spam on multiplayer servers similar messages are now discarded. A message will now only show once for every 32*32 area within the last 20 messages. This will mean upgrading a sizable stretch of road to public would generate at most a few messages, rather than hundreds. This change was made to counteract the possible spam the new drag support could generate as it is now much easier to make long stretch public very quickly and each tile would otherwise generate a message. The messages were kept as it can help people keep track of what is happening when away from multiplayer server games.

At some stage it might be recommended to add a proper message filtering system rather than hacking in filters into the add message function. This is because such hacks are adding specific and possibly unexpected behaviour to the function which could lead to errors in future (people wondering why certain messages do not show).

Currently localization is a big issue with multiplayer Simutrans. Everything is localized only on creation, using the current simutrans locale. This is fine for singleplayer where one does not expect to change localizations often. However for multiplayer it results in all clients who join being sent a map localized into the server's locale with all new events occurring since joining being localized into the client locale until they rejoin. Not only is this inconsistent but also is bad for usability as people end up seeing a mixture of various locales. For example if an English player currently was to join a Japanese server running a pak which featured Japanese translation then all factory names, convoys, stops, previous game messages etc would be in Japanese even though they are using standard names. What should happen is that all default (not user changed) names are saved as such and then localized to the client locale on load.

The most complex and efficient way to implement this would be to create some kind of abstract string stream which concatenates the results of different abstract functional string units into a concrete string which gets displayed to the client. Names of factories are stored as such a stream rather than as a concrete string. This could potentially save space as storing a default factory name could take as little as 1 byte (special value describing the objects default name).

Another more simple way would be to use some kind of string markup language to represent translatable strings. In such a case the language allows one to store translatable references which when evaluated expand to the localized string. For example a factory of type BookFactoryA would store a string like "{BookFactoryA}" rather than "Printing Works" which still gets displayed the same in game. For formatted translatable strings which get saved (eg some notification messages) the formatted arguments would need to be either packed into the language, or stored separately in a list which accompanies the internal string. This has the obvious advantage that users could use these abstract translatable references in custom names, for example line name "{BookFactoryA} In" could be automatically localized to "Printing Works In".

If I will look into implementing such a thing I am still thinking about. Until then I will look into making powerlines and/or transformers public, possibly even with a configuration to force it. Reason for this is that powerlines on multiplayer games can become a big hazard and companies often have inefficient networks due to ownership boundaries and no way to join them without help from the public service player.

I happened to stumble upon the network core of Simutrans and noticed the sockets were implemented incorrectly. The structure length resolution was violating the sockets API as it was using hard coded constants instead of the dynamic value assigned in the lookup structures. Local addresses were not being enumerated properly, trying to bind the same address for every iteration. Added support for service names instead of port numbers to network URNs.

A URI parser might be recommended at some stage instead of a hacky string parser.

Why do clients have declarable local addresses for sockets? The sockets API should automatically find a local address for a socket to connect from without the need for one to be given explicitly.

What uses the IPv4 only code? As far as I am aware Simutrans minimum supported Windows is XP which did support IPv6, and Linux/Mac has supported IPv6 for ages now. Even if IPv6 is not supported the sockets API should still work, although only returning and using IPv4 addresses. It might be time to remove all the IPv4 only code to improve maintainability of the network core.

As this was a substantial change to the network core please report if there are any Linux compile errors. I can only guarantee the build works on MSVC2015.

Could you please post patches for review before doing such substantial changes?

This change was hardly substantial though. It was mostly fixing already existing errors in the socket logic. Hence maintenance work.

Quote

Dr. Supergood - is there any possibility that this might be related to the desyncs between Windows and Linux clients on recent builds of Experimental?

Unfortunately not. The network core was working because it was correct enough to work. It would only not work under some obscure, probably unlikely, situations. For example if a protocol other than IPv4 or IPv6 was returned from a name resolution provider it would fail due to incorrect address structure size. Or if the first local address found failed to bind to the socket then it would keep retrying to bind that address each iteration rather than trying any others, if any, that were found. The ability to resolve port services as well as port numbers was the result of treating the destination port as a string rather than pointlessly converting from string to integer, which loses all service names, then from integer back into a port string.

Quote

r7924 compiled on linux, without any problems, connect to "regional" game OK.

Thanks for confirming. Although the code should have worked (I made sure to read both Linux and Windows socket APIs) there was always the possibility of some obscure problem. However I guess everything is good.

This change was hardly substantial though. It was mostly fixing already existing errors in the socket logic. Hence maintenance work.

Maybe one of you are thinking qualitatively and the other quantitatively. If a lot of lines are changed, it can be difficult to be sure that the changes are just a simple fix, and that no other changes have slipped through, intentionally or unintentionally. That is when I appreciate having a good set of tests verifying behavior during every build, even if I sometimes hate writing those tests in the first place and the tests take a long time.

That is when I appreciate having a good set of tests verifying behavior during every build, even if I sometimes hate writing those tests in the first place and the tests take a long time.

I do run through a variety of user level tests for every change I make. Firstly I make sure the code compiled with MSVC2015 (which does not mean GCC unfortunately, hence why an occasional error slips through). I then make sure that I get vaguely what I expect from the area of the change, in this case the multiplayer tab of the main menu. At first I did not, but it turned out to be URN parser code changes I made due to some obscure stuff which was done with the old code, hence the migration to std::string which also solved some other problems such as maximum name length. After it was working I then joined the regional server, which should be sync compatible at the moment due to no changes with the game results, and waited to see for any issues. As the joining worked and the game was stable for a long time I assumed the changes were correct. On top of that I tried to querry a variety of servers to check both name resolution and service resolution were working. The results were as expected, with port numbers making a difference to finding or not finding a server. The service resolution results are still not strong as no server currently uses a service name for its port (I only can assume it works based on the socket specification for resolving port numbers).

My point was that with good test coverage, one does not have to just trust each developer to manually test every possible case. Any change in behavior can often also be seen much clearer in the tests, making reviewing the changes much easier. Of course, one has to obtain good test coverage first, which is no small feat for a complex system.

DrSuperGood, I appreciate that you, as every developer, endeavours to fully test changes before committing. However unless these are entirely trivial (a handful of lines at most) as Ters says, there is the possibility of unintentional changes occurring. We all try to write good code, sooner or later we will all make mistakes. Bugs may happen which result in intermittent issues and peer review minimises the possibility of this.

DrSuperGood, I appreciate that you, as every developer, endeavours to fully test changes before committing. However unless these are entirely trivial (a handful of lines at most) as Ters says, there is the possibility of unintentional changes occurring. We all try to write good code, sooner or later we will all make mistakes. Bugs may happen which result in intermittent issues and peer review minimises the possibility of this.

My JIT2 and power network revisions still have not been reviewed... At that rate I might be able to push out 3-4 commits a year!

I will be working to replace all/most of the magic constants used to reference the public service player with a method call. This should result in no functional or performance change (get_player(1) to get_public_player()). However it should make the code more maintainable in future as it reduces the usage of magic number constants.

Been working on bridge consistency improvements with regards to city interaction. I plan to commit the patch on 13/11/2016, a week from now.

Since as long as I have been playing one has always been able to build bridges over cities. Even tall buildings could be bridged through. However if the bridge used pillars then houses under it could no longer upgrade (not sure why, maybe just luck with the tests I ran) and empty spaces under the bridge could not be used to build new houses. This behaviour is inconsistent in that it is order dependent and certainly not what people would expect.

This patch changes it so that cities can build houses under bridges with pillars and that such houses will upgrade. Code was added to ignore pillar objects when looking for suitable build spots as well as when building new houses. How this fixed the upgrading issue I am unsure. Tests show that with this patch applied houses are now built under bridges with pillars and that such houses as well as existing houses do upgrade as one would expect.

One can argue if this is the "correct" behaviour for bridges and cities. However it is at least going to be consistent and most people should be able to understand it.

I would rather forbid bridges with pillars over houses, as these are quite often mortar bridges which could not accomodate houses; however there are japanese highways and special houses for these bridges. Updating such houses would certainly not welcomed.

I would rather suggest: No house updates below any bridge. Pillars must by built on empty tiles or bridge building fails: Any object on a tile is "not nature" and thus not building space.

Pillars must by built on empty tiles or bridge building fails: Any object on a tile is "not nature" and thus not building space.

I see no reason why the bridge builder can not automatically remove the same kind of objects that are automatically removed when building plain ways, such as trees and (non-moving) ground objects, when building pillars. Furthermore, some ground objects, or even some trees, could co-exist with pillars that are on the edges (like the viaduct in pak64), but it might be too difficult to make a distinction between what works and what doesn't (the tiny watchtowers in pak64 "physically" fit under a bridge, but it still seem odd for them to be there).

I would rather forbid bridges with pillars over houses, as these are quite often mortar bridges which could not accomodate houses;

Hard to implement retrospectively due to how many such bridges exist. Look at the average server game. Would need load logic to detect and remove them in a sensible way, but that would break a lot of people's work.

Quote

however there are japanese highways and special houses for these bridges. Updating such houses would certainly not welcomed.

Except there are no such special houses? Sure the artwork might exist however neither city or bridge builder build them with such rules. It makes no sense that one can build a bridge over something but that same sort of something cannot be upgraded to when under a bridge.

Such mechanics might be something to do in the future. Such as special buildings for under bridges, limitations for pillared bridges and different sorts of pillared bridge with short bridges not needing pillars. Let us not forget more sensible height checks as well as pillars for elevated ways. If such mechanics are implemented perhaps a game option should be added as I think some people enjoy the freedom, especially in servers where one often is forced to bridge or tunnel big distances due to other players.

For now I think the improvement in consistency is certainly welcome. At least it feels polished and intended instead of the mechanics conflicting. Currently one can delete bridge pillars by deleting the ground they touch anyway, which in theory would have allowed cities to build there. Nothing stops elevated ways from magically floating in space either. Some nonsense bridges over huge buildings or with dense pillars inside houses is probably not the most illogical thing one can do.

If people use such houses for model railroads then perhaps they can buy the house to stop it upgrading as upgrading is ownership tested. If not then one can always stop the city growth and occasionally increment it manually.

Quote

Any object on a tile is "not nature" and thus not building space.

That method is poorly named. It actually means that the underlying ground is natural, as opposed to a bridge, tunnel, water etc. It seems to be a test of ground type and not ground content.

Quote

I see no reason why the bridge builder can not automatically remove the same kind of objects that are automatically removed when building plain ways, such as trees and (non-moving) ground objects, when building pillars. Furthermore, some ground objects, or even some trees, could co-exist with pillars that are on the edges (like the viaduct in pak64), but it might be too difficult to make a distinction between what works and what doesn't (the tiny watchtowers in pak64 "physically" fit under a bridge, but it still seem odd for them to be there).

I think it might be because not all bridges were intended to have pillars originally. It makes no sense for anything to be removed under a bridge with no pillars as it is suspended in the air.

One could perhaps forbid players other than the public player from planting trees in a network game? Transport companies do not usually plant trees, after all.

Unless transport companies are fined or required to "compensate" for tree cutting, on a sort of "1 tree cut = 2 new trees planted" basis or something around these lines. But IMO it could be rather a hurdle in Simutrans.

Unless transport companies are fined or required to "compensate" for tree cutting, on a sort of "1 tree cut = 2 new trees planted" basis or something around these lines. But IMO it could be rather a hurdle in Simutrans.

(late and odd reply, I've just found this topic today)

I don't think you understand Igor, we don't want any trees in the map to increase load time when connecting.

I think removing pillars should be forbidden. Buldings under the bridges should have limited height/level, to fit under the bridge. I think that in many cases the area under the bridge had to be cleared (demolished) during construction works, and only new small buildings were allowed to be built under the bridge later.

Some bridges (viaducts) should even limit roads that are under them to be perpendicular to the bridge.

Sometimes the arches of viaducts serve as a roof of small shops that cannot be built any where else. But that is too special case.

Imho cityhouses should not be build under bridges on tiles with pillars (patch part 1). Not removing the pillar if a house gets removed should be submitted (patch part 2).

But why should one be able to build over houses yet houses cannot build underneath? This is order dependent and can appear to players as inconsistent, hence the patch.

The patch makes it so that houses can be built under bridges just like how currently bridges can be built on top of houses. It is not intended to be a major mechanic revision, but rather just fix an inconsistency in gameplay mechanics. Importantly this is backwards compatible with existing maps as it does not change where bridges are allowed to be built.

Quote

I think removing pillars should be forbidden. Buldings under the bridges should have limited height/level, to fit under the bridge. I think that in many cases the area under the bridge had to be cleared (demolished) during construction works, and only new small buildings were allowed to be built under the bridge later.

Some bridges (viaducts) should even limit roads that are under them to be perpendicular to the bridge.

Such restrictions would be useful for new games, as long as they are implemented consistently. The aim of the patch was not to considerably change the mechanics of bridges, but rather make the existing mechanics more consistent. One should not be left asking why one can bridge over a house but a house cannot be built underneath the same bridge.

For now I plan to remove the building height check (not way height check) from elevated ways until a more complete implementation is added (elevated ways, bridges and building under/over them, a huge amount of work). Having skyscrapers pop up and block elevated ways from being upgraded is getting annoying. However that is another patch for another day.

I mostly agree, but since it is not possible to mix bridge styles without touching the ground, which might look unrealistic, I like to be able to remove the dense pillars of the high speed rail bridge/viaduct in pak64 on a single tile to let a way pass under it. These particular pillars don't combine well with anything else.

Sure there can be high buildings under very high bridge. But they cannot be higher...Ideally the limit on building height/level should match the height of the bridge above given tile.

And although the bridge in Millau is really high - there are no buildings undernath. Moreover you can see the destruction of landscape caused by construction works. See this bridge in Prague: http://zpravy.idnes.cz/foto.aspx?r=domaci&foto1=JB37b1a7_385499.jpg17 houses in the path of the bridge (and at its sides) were demolished, to make place for the cranes, etc. Only one house was saved.

So I think that building bridges over any house should be forbidden, and later building small buildings underneath allowed.

With pillars I'm split - many bridges are painted to have the pillars on tile borders and then it might be OK to have buildings at the same tile. Perhaps a dat file option where pak designer could specify if the pillar occupies the centre - thus forbidding anything (including ways), or the border - allowing ways, or even houses underneath.

Building bridges over/through buildings with no proper height check should be 'fixed' (this would be a large patch not a small fix). Why should the program be consistent with respect to flaws?

Being consistent feels polished even if the result might be broken or too strong with respects to gameplay. I am purely looking at it from a pollished gameplay perspective. Later in development one could add more strict, or realistic restrictions. I personally view this as a bug fix.

Quote

I mostly agree, but since it is not possible to mix bridge styles without touching the ground, which might look unrealistic, I like to be able to remove the dense pillars of the high speed rail bridge/viaduct in pak64 on a single tile to let a way pass under it. These particular pillars don't combine well with anything else.

Again a reason why I am reluctant to change current mechanics. Instead this patch aims to make such mechanics more consistent. It removes some nonsense build order restrictions which were more the result of a programming oversight than intentional (they were not intentional due to being inconsistent).

Quote

I think tall buildings under the bridges should definitely be kept:

China has tons on such elevated ways which really do have skyscrapers under and next to them. Sure they are only 10-20 stories, but even the tallest pak64 building is probably not much higher. Personally I find being able to build ways everywhere one of the charms of Simutrans and in multiplayer environments it can lead to impressive results.

Quote

Sure there can be high buildings under very high bridge. But they cannot be higher...Ideally the limit on building height/level should match the height of the bridge above given tile.

I agree, however no such mechanics currently exist except only for elevated way construction. Hence I want the removal in future until a more thorough implementation which affects both building under bridges/elevated ways as well as their construction. Fractionally implementing a feature feels sloppy.

Quote

So I think that building bridges over any house should be forbidden, and later building small buildings underneath allowed.

This is an inverse consistency of currently. It also makes little sense as its the same consistency problem as the patch is trying to fix. In such a case maybe the player should have to pay a penalty for "spoiling" the property value of the house (compensation), but again that is a new feature.

Quote

With pillars I'm split - many bridges are painted to have the pillars on tile borders and then it might be OK to have buildings at the same tile. Perhaps a dat file option where pak designer could specify if the pillar occupies the centre - thus forbidding anything (including ways), or the border - allowing ways, or even houses underneath.

In future new restrictions and mechanics should be added. The viaduct for example should not mix well with housing while a pillar-less bridge should have no problem going over housing. I also agree that running roads through viaduct pillar walls looks stupid. However one cannot suddenly make that illegal for all bridges which do not have walls.

I would recommend such features be developed separately in the future for adding into new paksets.

Quote

That why my suggestion: Basic correction: No houses under bridges with pillar on a tile. If there is a tile every 2nd, then you must clean that tile for building the pillar.

However again applying this retrospectively to existing game is a problem as no such restriction existed and houses and pillars mix.

I also support this as a restriction. However it needs to be developed as a new feature. Either a pakset author must enable it for a bridge type (more flexible, recommended) or some simuconfig setting needs to be added (less flexible, maybe good enough).

Quote

Advanced: No houses for bridges within single clearance (one level for pak64/twp for pak128). And then one could determine the house height from the pak image size ...

Not sure what is meant by this. If a bridge is above a house it is still above the house and this is possible even in real life. Exceptions are needed for bridges like pak64 viaduct which take a tile below the way for the arches. However again this would need new pakset features where one can explicitly define bridge construction restrictions. Some way to relay these to the player are also needed.

General height clearance for buildings is lacking except for ways. Hence I suggest removal from elevated ways (only logic and it is only for building the way) until some kind of complete solution is ready which affects all building.

Quote

And then one could determine the house height from the pak image size ...

Apparently some people argue otherwise. I raised this a year or so ago when first suggesting elevated way consistency improvements. The arguments included that some parts of buildings were purely aesthetic, eg a lighting conductor, and hence in reality would be removed to make way for something above them.

I am planning to finally merge in my power system and JIT2 fixes which I made all those months ago. The patch is attached and the commit will happen on 08/01/2017.

To summarize...Fixes power tick on save load.Fixes distribution transformer payment accumulator lost on load.Power net information now shows the correct demand for the supplied. Before it used to be 1 tick out of sync allowing nonsensical values.Distribution transformer overloaded graphics now correctly modulate instead of suffering arithmetic overflow.Fixed incorrect power payment scaling. Monthly revenue from power is now proportional to month length instead of constant.Distribution transformers now pay out at regular intervals, currently set to 10 seconds. This stops message spam for high powered consumers as well as fixes rare messages for low powered ones.Revisions to JIT2 production rate stability. I forget the exact details but it should result in smoother production scaling and less oscillation.

It is worth noting that some of the save/load changes will only take effect once version is incremented.

I plan to work on JIT2 some more after this. Specifically I have thoughts to address the most talked about issues. Instead of a feedback production regulator, a periodic think regulator run every minute would set the production rate for the next minute. It would track how much demand was dropped due to undersupply and so be able to throttle back production to track supply and hence solve the pulse width modulation like activity that JIT2 factories that are undersupplied suffer from. Additionally input storage maximum behaviour would be completely discarded (no penalty for overflow) and output storage would be adjusted based on production rate to guarantee at least 1 think time (minute) worth of output production. Every month some magic algorithm (not thought of it yet...) would determine if the input storages need trimming and if so it would drop some orders over the next month. This would make JIT2 more compatible with pak64 and other paksets as well as fix issues such as power network stability. It might also make industry tick logic simpler as fewer values need computing every tick.