Anyways, thanks for fixing this.
There might be anothr issue in the code, though I could not come up with a case where this actually is an issue. I guess it's simply a missleading naming, but the logic is fine.
The variable can_be_at_front is always true, except from the case where there is an "any" constraint defined.
In fact, a vehicle that has a list of vehicles defined as a constraint, but not "none", also cannot be at the front. Should consider renaming this to something like "prev_has_any"/"next_has_any", obviously swapping true/false in that case.
Further, I am not sure if that's just a weird, but intended definition of can_lead_from_rear=1; bidirectional=1; prev "none", or a bug.
A vehicle that has these three things assigned will have a cab at both sides. Note that it does not matter if there further is a list of vehicles assigned to prev or not.
This is due to the following code:
if (!bidirectional || can_lead_from_rear || has_front_cab) {
basic_constraint_prev |= vehicle_desc_t::can_be_head;
}
Later on, there is the "//auto setting" code that will remove the flag again, if the vehicle is
- unpowered and
- bidirectional and
- cannot lead from rear
Which in our case effectively means never. (as we observe the case can_lead_from_rear=1)
I had just blindly taken this over, but it doesn't seem to make much sense to me. Might be one of the weird but intended implications of can_lead_from_rear, which led to its deprecation.
This time, I'm not working on these things. Just my thoughts I couldn't get out of my head, so I wrote these down.
If you think it's worth fixing, let me know or simply fix it by yourself.