[11.00] bug with public cars piling up at corners

[ӔO]

the public cars just keep piling up at the S-bend between the two stops.

https://dl.dropboxusercontent.com/u/17111233/pileup_test.sve

[jamespetts]

To where are you referring? The game loads, as on the server, in Dulmead, and I can't see any traffic jams there.

[jamespetts]

Can this issue be reproduced in 11.6?

[ӔO]

yes, I still see them stacking upon each other at the corners in the S-bend.

---

of note is that player vehicles will not stack, only public cars.

[jamespetts]

Hmm - I think that this is a well-known issue in Standard, though, is it not?

[ӔO]

Is it?


okay, I tried it in standard and the same problem happens there too.

[prissi]

Ok, I fixed this. It was never checked if the direction of driving is equal to the next cars. Not sure why.

[TurfIt]

On the surface, your fix appears ok. I can't think of any desirable reason to allow entry to tiles in the same direction on a straight road. It is an extra unnecessary check for convois, hurting performance in an already slow routine, since other clauses block the movement. The problem with the citycars is their ist_weg_frei routine calling no_car_blocking with invalid (duplicated) parameters. Provide the correct required info, and no_cars_blocking works. The true fix is to bring stadtauto_t::ist_weg_frei up to the same standard as automobol_t::ist_weg_frei. There's still a lot of other undesirable citycar behaviour that would be fixed doing so... I'd planned to do that after finishing for the convois, but that turned into such a frustrating experience, further work in this area of Simutrans ended up at the bottom of my list!

[prissi]

Well in case of straight roads the next check below would just returned the same car, so this may go now. But I was not sure if this is doing something else, so I left it in.

[TurfIt]

I believe it still prevents two cars entering an intersection from different directions and trying to use the same exit. Obviously it won't trigger 50% of the time anymore, so the comment is now misleading... I had a huge table covering all possibilities at intersections, what's in the code is the reduced version to cover everything in a minimum # of checks. And the checks are ordered so the most likely blocking conditions (determined from profiling actual games) are checked first. What the routine doesn't like is being called with current==next==next90 like happens with citycars.