Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

Destruction of the trolley bus wire by barbarian city

Started by Ranran, September 09, 2019, 12:46:21 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Hi there, Ranran's back from the summer vacation!  :)

Anyway, Ranran's trolleybus company has long suffered from damage caused by barbarians destroying overhead wire.
A trolley bus that had been operating normally for a long time suddenly showed "No route" and got stuck. It was a mystery. (´・ω・`)
Detective Ranran searched for the cause and found that someone had cut the trolley wire that was previously connected. This is a criminal act.
This happened over and over again. Scotland Yard is famous for incompetence. Their notoriety has reached as far as Jalapagos. They do not work this time too.
However, fortunately, detective Ranran finally succeeded in capturing the video of the criminal destroying the overhead wire.
Check it out.

OH MY PIG! See? The barbarians are the people of the city hall!
The city destroyed my trolley wire and road to make an intersection without my permission. IT'S MINE! (´・ω・`)らんらんのー
Not only that, that devil stole its removal cost from me. NO WAY! (´・ω・`)そんなー

This time I used the "Grow city tool" to reproduce, but this should also occur in natural city growth. Because I have suffered many times from this barbarism. Silly vandalism also paralyzes road traffic and sometimes blocks bus and truck routes.
The name of the city is simcity, but this game is not simcity. So I cannot build a new police station and increase their budget.  :::)
If this is Civilization I will definitely bring that city back to the ash though...  ::(
Anyway, we must always monitor the occurrence of disasters and deal with abnormalities manually.
Thus it is difficult to operate a trolley bus. (´・ω・`)


I don't know why the diagonal roads are replaced to the other rectangle route when the city growth.
I thought that the issue came from, but I couldn't find it...


This is not the only act of barbarism that the city councils do! Cities think nothing of build low bridges over rivers and so blocking most river traffic that needs double clearance.


Thank you for your report. In principle, this code should be unchanged from Standard, as I have not altered the city growth code, although there may be some peripheral parts of code that do not appear to be city growth code that are used by it in this connexion.

Can anyone confirm whether this can be reproduced in Standard (with Pak128.Britain, as the pakset may make a difference)?
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.


I remember there was a recent (maybe a few years?) change in city growth regarding diagonal roads. Cities growing over diagonal roads were quite ugly, so the algorithm was modified to rebuild them to be more rectangular. I'm not sure it it was modified in standard or extended (experimental at that time).


Replacing diagonals is not a bad idea, however it should consider trolley bus catenaries and optimally place these on the new road tiles, replacing the diagonals. Alternatively, it could simply prevent destructing those roads.

Additionally, there needs to be some consideration for other objects that can be placed on the same tile as a (diagonal) road. E.g. tramways or roadsigns.


I think this bug is unrelated to
In cityrules we can define road and building construction conditions, but not destructive conditions.

I tried to reproduce this bug in standard, but this behavior doesn't seem to be in the standard.

On the other hand, Extended will remove roads that are no longer needed when an intersection is made. And at the same time as the road is removed, the trolley wire is also removed.
I think this behavior is specific to extended.

Roads on tiles outlined in red will be destroyed automatically in Extended.

Certainly the intersection is not beautiful.


I read the code and identified a function that does this, also I found the thread at the time it was implemented.
Yes, this is a feature that only existed in extended. This function is remove_excessive_roads.
This feature is currently flawed as I reported as a bug. Also Freahk pointed out the possibility of road signs being removed.
But this was not correct. At that time, the barbarians somehow leave it without destroying the road sign. And if the player clicks on that left sign, Simutrans crashes!
Ughhhhh! Ranran stepped on a landmine set up by Barbarian. (´・ω・`)

In any case, it is necessary to correctly implement the processing related to the road of the tile d3 and the objects on the road.
Currently, city road expansion is performed in this way:

Yellow is an electrified road; Blue arrow is road sign; Red tiles are about to build a new road; Gray is a non-electrified road
:warning: NOTE: A landmine in the form of a sign is placed in d3. Don't click it!  ;)

As Freahk suggested,
A. Don't destroy roads with overhead wire and road sign
B. Reposition overhead lines and signs to new routes

I think we should choose either method and add it.
B may be a little more work.
It is necessary to deal individually with the relocation of overhead wires and relocation of signs.


Another point that just came in mind are waypoints. These also have to either prevent road destruction or have to be moved automatically.

I guess a mix of A and B would be best, except if someone wants to do some really careful thoughts about the roadsigns.
For your simple example, moving the sign one tile ahead should work but what happens if one tile ahead already is a T crosssing?
as simply moving these one tile ahead or placing these on the newly constructed tile, whic is a T crossing, will for some setups create unexpected behavior.
Moving overhead catenaries should not be a problem as these road destructions always happens to a 2x2 square of roads.
r r
r r
will become
r -
r r

So the only thing we have to do is moving trolleybus wires and waypoints from the road tile that should be removed over to the tile on the opposite side of that square.


In the example shown above, if the roadsign ribi points 'east' it should be moved down; if the ribi points 'south' it should be moved left -- is that correct?

Also, could it be problematic that neighboring tiles can now be one-way?
I do hope Ranran's "B" can be implemented.


QuoteAnother point that just came in mind are waypoints.
You've made a good point. Road destruction that is unrelated to the player's will may cause "no route" regardless of electrification.
When I tried it, I couldn't reach the coordinates specified in wyapoint so it caused "no route".
Is it easy to reposition scheduled coordinates automatically?

QuoteIn the example shown above, if the roadsign ribi points 'east' it should be moved down; if the ribi points 'south' it should be moved left -- is that correct?
Yes. Sorry, my image shown above was misleading.  :-[
Strictly speaking, a sign placed on the diagonal is specified as an image facing the exit.

In the case of B, it may not be possible to move the sign because the another tile is already occupied by another sign.
That said, it doesn't make sense to leave a sign on the excessive road, because vehicles can avoid it.


QuoteIs it easy to reposition scheduled coordinates automatically?

I don't know, but it is possible to programmatically create and delete waypoints, so if you know the location of the new and the old waypoint and you know all waypoints on the old location, this should not be too hard.
We know the old location as this is the one to be destructed. Calculating the new one in that square is also not a problem.
However, I don't know if there is any location->waypoint map in the game. If not we have to look into all lines, which could potentially be too slow.
On the other hand, stations know which lines use them and when you place a new stop on a tile that has a waypoint on it, the stop will immediately know of this line serving that stop, so this also should not be an issue.

As I got Simutrans integrated into CLion IDE (creating the cmake files was awful for a cmake newbie), I'll have a look at it and will try to fix this.


Function names are quite confusing as two out of thre remove_excessive_roads functions do not actually remove any roads from the map. The only one that does is never used. The others only mark roads around the current groundas "to be removed" in the passed road network plan by adding a koord=>false entry to the road network plan.
Same goes for fixup_road_network_plan, which does the same for multiple grounds.
So I propose refactoring this to something like locate_excessive_roads and locate_road_network_fixes.
This is just some cosmetics however, I consider it to be very important for code readability.
As there is only exactly one external usage for fixup_road_network_plan and remove_excessive_roads, refactoring should be safe.

Also, removal/fixup itself does not have a function on it's own but exactly the same code is used twice. This is done at two places:
We should move this to an apply_road_network function, removing (koord=>false) and adding(koord=>true) roads on the map, otherwise it is very likely that a bug in these will be fixed in the future at only oe place, leaving the other bug intact.
I guess such a function would be best placed in karte_t, as it makes changes to the map and is not related to an instance of any ground as it affects many.
Alternatively, maybe add it statically to the grund_t class?
I don't know what fits best to simutrans conventions.

The falsy roadsign itself is caused in weg_entfernen as it does not check at all if there is still something on that way.
So we should either remove anything related to that way when removing the way or the function should fail if there is still something on it.

So far, I've got that trolleybus wire fixed by adding it to the new road but for further fixing (e.g. roadsign bug) I want to discuss the above.


Thank you all very much for your work in identifying this issue: this is most helpful. The issue that Philip identified in the thread from 2014 (which I had forgotten about until Ranran found it) is a real issue: before his patch was implemented, there were far too many redundant roads in towns, which looked ugly and caused the towns to have too low a density.

The ideal solution would be to have the code for building new bits of town to adapt automatically to use the existing diagonal ways and not require anything to be removed, but this would be very likely to be very challenging to implement.

The next best solution, I think, would also be the simplest: check each tile that is about to be removed for a road sign or electrification and do not remove any that have either such feature. This would then prevent players' routes from being broken by this feature whilst preserving the effect of this feature for most purposes.
However, if Freahk has already got a working system to put electrification in the diversion, it may be preferable to adopt this, depending on how well that this works; perhaps this might be used when only electrification is on the tile, and the non-deletion option used when there is also a road sign?

As for waypoints, it would in theory be possible for the road removal code to iterate through every schedule to check whether any waypoints impinge on the tile before deciding whether to delete it, but this would be likely to be too computationally intensive (it could, perhaps, be threaded (parallel rather than concurrent), but this would take a lot of work) and also take quite a bit of work to implement. A more universal solution, that would also deal with the deletion of roads at waypoints for other reasons, would be to change the routing algorithm so that, every time that there is no route to a waypoint, the schedule would automatically advance to the next stop.

One thing that will need consideration in relation to this latter algorithm is whether to confine this to roads or whether to make it universal.
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.


However, if Freahk has already got a working system to put electrification in the diversion, it may be preferable to adopt this, depending on how well that this works; perhaps this might be used when only electrification is on the tile, and the non-deletion option used when there is also a road sign?

That's exactly what I implemented yet. However, I completely rewrote the remove_excessive_roads function because the given information (please remove road at koord) was not enough. To move stuff over I also need know which road will replace the one to be deleted.

However, it does not yet face the waypoint problem. I didn't have a look at the code that detects new stops at existing waypoints but given your post I guess there is no location->waypoint mapping in the game.
I would need such a mapping to move the waypoint to the new road.
Otherwise, as mentioned, it would be potentially pretty slow.
Not moving the waypoint at all is not really an option, as this could still cause "no route" at city growth.

Mentioned "skip invalid" is fine but there should be at least a message to the player in that case.

I can work on this again after the next weekend, as I am not in range of my computer for the next days.


Thank you for the reply. The skip invalid option should certainly be the easiest to implement; adding a whole memory structure to map locations to waypoints (and then keep this updated for all the various possible things that might happen to schedules) is likely to be a very large task. Adding a message to the player should not be too much difficulty, although one should be careful that it does not create message spam in a large game with huge numbers of 'buses skipping the same waypoint.
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.


For reference, replacing waypoints can already be done by a player using the stop mover tool - see tool_stop_mover_t::do_work in I suspect running a similar process when roads are automatically deleted would be feasible, although I don't know how often road deletion happens.


I am back home now. I'll have a look at the reference and will include waypoint moving, but give me a few days, I'll have a free sunday.


I have found yet another bug related to this...

`remove_excessive_roads` and `would_create_excessive_roads` are implemented purely 2d using `welt->lookup_kartenboden`, which assumes a flat kartenboden or at least no changes in height without slopes. This leads to odd behavior when using elevated roads (never considered at all) or adjacent tiles at different height without slopes in between (will detect these as excessive and remove these "excessive" roads while they are not excessive)

That given, I have to switch over to `welt->lookup` and in that case, handling elevated roads should not be too hard.
I am not yet quite sure how exactly elevated ways are handled.
From what I have seen so far these create a new grund one full height above the grund.
Is this correct?

Additionally, is there a function that can tell us to which directions an existing, given way (on a given grund) can connect from it's local situation, that means considering other obects on the same grund like other ways, stations or whatever?
If I understood it right, ribi and masked ribi will tell to which directions these actually are connected.
In case of masked, also considering the direction of that connection.

I have written a few lines of code specific to the excesssiveness problem of roads, but after that, was wondering if there really is no general function to detect this for any waytype, as detecting to which directions a way could connect sounds like a pretty common thing to me as we need to know this whenever constructing ways.

As this bug is pretty related, there is still a bit more to do than expected as leaving that bug unfixed does not make sense to me.
However, things are not too complicated.


Freahk - thank you for looking into this in detail, and apologies for not having been able to revert to you on this hitherto.

First of all, I realise that I did not answer your question about electrification diversion in my previous message: my apologies. Yes, if you have a working diversion system, that would be better than a preserve function for electrification; preserving can indeed then be confined to tiles with road signs. I also agree with refactoring the code to have clearer names, as I do not believe that any other branches make changes to this such as would require refactoring multiple Git branches at once.

If you are able to implement a waypoint relocation algorithm, that would be splendid, and very helpful.

In relation to the 2d/3d bug, thank you for spotting that. I have not looked into this myself, so have not fully comprehended how this interacts with adjacent tiles of different heights without transitions, but if you have tested and found this to be a problem, then it would seem to be worthwhile testing to see whether using "lookup" will assist this, although you will then have to specify the height by using a 3d co-ordinate and find an algorithm to find the correct height.

In relation to elevated ways, this is not a part of the code that I have looked into in detail; however, from what I understand, an elevated way creates an elevated way base ("boden", I think) beneath the way at the appropriate elevated height. I am afraid that I do not know beyond this the details of how it works; you might be able to discover more by asking the Standard developers.

Thank you again for working on this; the suggested fixes to this would be most welcome.
Edit: In relation to connecting grounds, I am not aware of a method to do this, but I have never got to the bottom of the direction system fully; the relevant code is in ribi_t. There are a number of basic functions in there, some of which do give some connexion information, but I am not sure whether any of them do what you suggest. If you think a feature of this type to be sensible, then I suggest that you add it in ribi_t with the others. Thank you again.
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.


After two years and no sign of this problem being solved, I tried a simple fix.
Pull request #482 prevents barbarian cities from destroying trolleybus wire.
Please note that several problems and solutions were raised in this thread, but only simple fixes were made as the code is complex and difficult for me to carry out.
Anyway, this bug is currently ruining the trolleybus, so it was necessary to solve this problem.

I'm hoping that with this patch, we won't have to worry about barbarians destroying trolleybus wires and the trolleybus operators will be able to sleep at night. ;)

I noticed that somehow  this thread is in the closed bug report board.


Excellent, thank you for that: fix now incorporated.

Apologies that this was moved to the closed bug report thread: I must at some point incorrectly have thought that this had been fixed - this may be why it had not been addressed for so long. Thank you very much for fixing this. I have not moved the thread because, there now in fact being a fix, it is now in the right place.
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.