Distinguishing road transport creatures that do not interfere with cars

[Ranran(retired)]

I made the basic function of the function I proposed here.

It's a parameter for creatures like mail guy that don't interfere with vehicles, not vehicle.
Small vehicles may also fall into this category. It will depend on the pakset author.

I used to call it a pedestrian type vehicle, but this time I tentatively named it a sidewalker.
I don't speak English so I would be very grateful for any opinions on more suitable names.



This is a parameter for road vehicles only.
To enable this, describe is_sidewalker = 1 in dat.


Please watch the demo (´・ω・｀)



They are mostly pedestrians, but they obey the traffic rules.
(However, sadly, real-life Uber eats delivery personnel often have problems with non-compliance with traffic rules.)
But for players suffering from traffic jams, they may be treated as heroes.
Also, cars are not disturbed by slow creatures, and there is no danger of running over and kill them as they are in reality.
(Rest assured. I changed the offset so they wouldn't be killed. They move on the edge of the road.)


But they are somewhat cheat-like and can take supremacy. In fact, people in Corona don't want to leave their homes, so it's proliferating in Japan.
Therefore, the dictator Ranran imposed a rule on them that no more than four people could enter in the same direction on the same tile. (´・ω・｀)
Currently this number is a magic number.


In the depot dialog, it is displayed on a dedicated tab like this.



There may be only these two types in pak briatin. But if you find this feature useful, you can expand your imagination and add a number of similar sidewalkers. e.g. motorbike.

Jalapagos examples:




Test branch is here:
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/pedveh
https://github.com/Ranran-the-JuicyPork/simutrans-pak128.britain/tree/sidewalker

I hope that traffic congestion will be improved.      (´・ω・｀)らんらん♪

[Mariculous]

Nice idea and these examples made me smile 

Just a technical thing: Why did you prefer is_sidewalker = 1 over something like waytype=sidewalk ?
As a sidenote: I imagine sidewalkers imply their own traffic rules, so in a clean-code world, these should be a vehicle_t subclass on their own.

[jamespetts]

This is very interesting. Since bicycles do not actually ride on the sidewalk/pavement, I think that "sidewalker" is not the best term here. It is difficult to think of a suitable better term, however. Perhaps "kerbside vehicle"? I should be interested in people's views.

[Phystam]

They should obey traffic lights as well as normal road vehicles, right? anyway, pak128britain has already had postmen and postal bicycles. They are potentially "sidewalkers".

[Ranran(retired)]

They are mostly pedestrians, but they obey the traffic rules.

I'm not saying they don't obey traffic rules, they obey traffic rules.


They are like other road vehicles, except that they do not interfere with each other like ships in simutrans.
So I don't think it's necessary to separate it. The amount of change is very small just by writing some conditions in the code.

For example, trams move on the road, but ignore the traffic lights. However, sidewalkers(?) work according to the rules of road vehicles.

[prissi]

Don't they bunch together at each traffic light an then continue to travel as pack of four?

[Ranran(retired)]

Don't they bunch together at each traffic light an then continue to travel as pack of four?

Yes, that's correct. But when approaching a tile with a lone wolf, one of the four will be discharged.
If someone succeed in making a code that doesn't happen in simutrans, I think it's possible to line up in the same lane on the same tile on a regular bus or car.
For example, it stops at a distance according to the length of the vehicle in front or continue at a certain distance from the car in front.
It's a long-term ambition. Allow advance to a specific position on the tile. Or if they overlap and stop, get an interval at the departure.
I'm not familiar with the behavior of convoys so it's currently unknown how difficult they are...

[jamespetts]

In relation to the numbers on a tile, might I suggest that two would be a more realistic figure than four? Two abreast cyclists might be fairly common, but one rarely sees cyclists four abreast. Alternatively, perhaps this ought to be a simuconf.tab setting?

[Ranran(retired)]

Considering the length of the vehicle may be one solution when considering the expandability of road traffic in the future. For example, the total length of one tile is 16. Occupies vehicle length +2. If the total length exceeds 16, it cannot entered the tile.

If the length of the bike is 3, one bike occupies length=5, so 3 bikes can fit in one tile. If pakset set sidewalker(?) length to 4, it can only enter 2 units((4+2)*2=12<16 OK, (4+2)*3>16 NG). In case of length=2, 4 sidewalker can be entered.

This allows pakset to make a difference in the number of tiles that can fit. e.g. mail boy=4, mail bike=2.

[jamespetts]

Considering the length of the vehicle may be one solution when considering the expandability of road traffic in the future. For example, the total length of one tile is 16. Occupies vehicle length +2. If the total length exceeds 16, it cannot entered the tile.

If the length of the bike is 3, one bike occupies length=5, so 3 bikes can fit in one tile. If pakset set sidewalker(?) length to 4, it can only enter 2 units((4+2)*2=12<16 OK, (4+2)*3>16 NG). In case of length=2, 4 sidewalker can be entered.

This allows pakset to make a difference in the number of tiles that can fit. e.g. mail boy=4, mail bike=2.

That is an interesting idea. Indeed, the same idea could in principle be applied to vehicles on a tile, too, albeit this would need careful graphical alignment to work well.

[Ranran(retired)]

That is an interesting idea. Indeed, the same idea could in principle be applied to vehicles on a tile, too, albeit this would need careful graphical alignment to work well.

I don't have any ideas for graphical alignment so far, but I've built in a specification where the number of bike-like vehicles that can fit in a tile depends on the length.

[jamespetts]

I don't have any ideas for graphical alignment so far, but I've built in a specification where the number of bike-like vehicles that can fit in a tile depends on the length.

That is very interesting.

As for road vehicles on tiles and graphical alignment, there are, internally to each tile, a number of tile steps, I believe 16. Each vehicle passes through these tile steps as it passes through the tile. If the code for determining how many vehicles were on a tile could keep a track of where on the tile that other vehicles are and not be allowed to take any tile step if there be another vehicle occupying that tile step ahead of it, then this might work well. The same code could then be used both for the bicycle like vehicles and the full road vehicles.

[Mariculous]

It's not THAT simple.
There are indeed 16 "car units" per tile but the internal movements works on a 256 "vehicle steps" per tile unit.

[jamespetts]

It's not THAT simple.
There are indeed 16 "car units" per tile but the internal movements works on a 256 "vehicle steps" per tile unit.

Thank you for reminding me.

I should imagine that the best way of dealing with this is to divide the 256 vehicle steps into 16 groups of 16 steps, and then monitor how many of these groups that a vehicle has passed, making sure to keep one group of 16 vehicle steps free between each vehicle, in order to calculate where the next vehicle should be.

[prissi]

Or even less steps for diagonals ...

[jamespetts]

Or even less steps for diagonals ...

Ahh, good point. The algorithm would need to adjust for this. There is an easy way of checking whether a tile is diagonal, I think.

[prissi]

Actually not, since the diagonal is shorter than the normal road tile. So leaving 64 steps space to the previous creature would work there too. Just capacity is less (but it is crossed faster then).

[Mariculous]

Is suspect we moved off-tipic quite far. I'll respond here but it might be best to spit the topic.

Splitting the road into fixed blocks of 16 vehicle step length might not the most sensible solution.
Why should we use "car units" here where "vehicle steps" technically and visually is the unit representing the position of a vehicle on a tile?

Further, when addressing this issue, it's a good time to consider the stop-and-go issue related overtaking:
A fast vehicle will attempt to overtake a slower one. If it can't it will halt immediately and accelerate from 0 as soon as the next tile is free.
If it successfully pased another vehicle, it will immediately switch back the lane, frequently causing a halt of the slower vehicle.

When implementing multiple cars per tile with a minimum spacing, cars have to look ahead anyways to check if there will be a car within the spacing.
To fix the above, that look ahead might consider a little more distance than the minimum spacing, so fast cars approaching a slower one can slow down to move as fast as the slower one. That way, cars keep moving.

Also, I am not sure about the fixed 16 step spacing. A simuconf setting might be better as different paksets use different graphical scales.
Speed related spacing might be even better in terms of realism.

[Ranran(retired)]

I am afraid that the goal of the patch has been moved to an endlessly distant point... (´・ω・｀)

The patch at this point only controls whether or not convoys can enter tiles.

At this point, location conflicts are a problem limited to kerbside vehicles.
Applying it to all road vehicles would first be a problem for citycars, which do not have langth.

What I'm finding difficult is
Stopping in the middle of a tile. Position determination and deceleration process (start position of deceleration). Currently, the stop position is the edge of the tile, which is simple.
After convoy stops in the middle of a tile, it has to check that the front of the same tile is no longer occupied. Currently, there is only one lane of the same tile, so it only needs to check the next tile.

The realization of these features means that road vehicles can be freed from the spell of tiles and operate in the bondage of length. This seems to be a kind of revolution in simutrans...
However, there is no doubt that such a feature has long been desired by many. I'd like to make it happen if I could, but the fact that it hasn't been done so far suggests that it would be a lot of work, and at this point I don't see myself being able to do it.

[jamespetts]

Adding a length parameter to city cars would be quite straightforward and I could assist with this if this is difficult.

However, the movement code I am not very familiar with. Stopping a vehicle part way along a tile would definitely be desirable if this can be done, as it would enable a very major enhancement of road vehicle movement code.

Can any of the Standard developers point us in the right direction for this?

[TurfIt]

I experimented with this in Standard a long long time ago - actually I don't think Experimental even existed yet.  A naive implementation of extending the existing code is relatively trivial. What's not trivial is the performance impact - hence was not pursued. Searching tile object lists is really expensive, 5000+ road vehicles doing so multiple times per tile moved (when in heavy traffic congestion) is prohibitive. Some fundamentally different data structures surrounding map objects and vehicle interactions are required IMHO to support such a feature.

[Mariculous]

True. A different way to store vehicles in the world or an additional structure might be needed to implement this performantly.
I recently had a look at object management on tiles (aka objlist)
searching for objects in the objlist is not an issue with the current search-rate, but searching for ALL vehicles on a tile each vehicle step is much more demanding and might be an issue.

The change needed might be rather simple though:
In each way maintain a little queue for each traffic lane (all straight roads have two lanes), storing vehicles on that lane ordered by their position.
There are not THAT many ways in the world, so the additional memory neded to store those queues shouldn't be a big deal.

Althernatively, maintaining a reference to the chased vehicle should be more memory friendly at cost code complexity around updating that reference properly.


Edit: See vehicle_base_t::do_drive as well as convoi_t::sync_step if you want to learn more about the actual vehicle movement.

[jamespetts]

Interesting - thank you both. Freahk - do you think that one of the existing Simutrans collection classes could handle this? There used to be a queue template class of sorts, but I believe that this was removed some time ago as it was replaced with a binary heap for the route search.

We probably need a real queue for these purposes - might a standard library class suffice for this, or would it be too slow? I do not have much exprience working with the standard library collection classes, and none with the queues.

[Mariculous]

Freahk - do you think that one of the existing Simutrans collection classes could handle this?

Sure.
A simple vector, minivec or std::vector should do the job. Just use it as a queue, which means "add to the back, remove from the front"

We will need the following operations: enqueue, dequeue, get_last and a way to iterate the structure, which is "a little more than just a queue".

The vectors offer those operations in a fast way. Just the dequeue could be implemented faster, but given the very small number of elements in those queues (I'd expect something around 2-4 vehicles in most cases), it shouldn't be a performance issue to move all the remaining vehicles by one slot when removing the first.
The following is is related to std::vector:
enqueue: vector.push_back(veh)
dequeue: vector.erase(vector.begin())
get_last: vector.back()
iterate: vector.begin() vector.end() Alternatively use vector.size() and vector

[jamespetts]

Interesting - thank you. Would you envisage this being in addition to or replacing the existing object list?

[Mariculous]

The existing objlist has to remain in any case. It's a good solution to store stationary/non-moving objects on a tile and I guess it's also the best solution to store non-way-bound vehicles on a tile.

In principle, we might store way-bound vehicles only in the lane queue, not in the objlist, but that will involve some additional code adjustments.
The naive approach might be to change objlist_t functions so they consider the the contents of ways stored in the objlist in addition.

I guess it's best to maintain way-bound vehicles in both structures for now.
If there is a memory issue caused by vehicles stored in the objlist or a performance issue caused by vehicles joining or leaving a tile, we can still re-consider this.

[jamespetts]

Interesting. We would have to check carefully the performance impact of using the existing objlist on a modern computer for all the traffic and compare this against the memory impact of a whole new collection class per tile of way.

What is very interesting is that I notice that crossings (fords especially) already work like this, with multiple cars able to enter the tile and queue in the tile without overlapping. I wonder whether we could re-use this code?

[Ranran(retired)]

Whether they can overlap depends on whether can_enter_tile returns true.
The water way and road have never intersected at the same height before, but when they do intersect at ford, can_enter_tile may always return true even for road vehicles as a result of the tile being considered a water way.
That means it's possible that road vehicle is temporarily being treated like a ship on fords ...

[jamespetts]

Whether they can overlap depends on whether can_enter_tile returns true.
The water way and road have never intersected at the same height before, but when they do intersect at ford, can_enter_tile may always return true even for road vehicles as a result of the tile being considered a water way.
That means it's possible that road vehicle is temporarily being treated like a ship on fords ...

The interesting thing, however, is that they do not act like ships: they do not all bunch up in the same place, but form an orderly queue, never overlapping with the vehicles in front of them, but always stopping a short distance behind.