There are many factors that the pax use to determine which checkpoint they choose as of my experience they mostly choose the ones with either the best effective rating or the lowest but other things are in effect that I haven’t noticed
It seems like it is a known bug that repeatedly pops up, gets solved (partially), then comes back in full force again. Not the biggest concern of the devs most of the time with all of us begging for multi-floors.
In that particular screen shot I can’t see any immediate issue. One of the security desks is having a shift change so naturally there won’t be any pax there, for the rest of the desks I can’t see that they’re filling up to the brim so from that point we’re good (i.e they don’t stack up). The only “issue” is that they probably don’t consider the number of queuers in the static part of the queue, only the dynamic. I will see if I can make some adjustments there.
Yes and no but mostly no. It’s more so that we discover new scenarios in which a certain solution don’t work. That’s the story for all of it, especially remote stands. We push out a first version, everything breaks, we push out a second version, somethings break, third version, stuff works but breaks in certain cases, fourth, new bugs, etc… etc… etc… eventually, when all is working, we have some behavioral improvements which in turn might bring in new bugs… but… in the end, we’ll finally arrive at a 1.0 that offers perfect working remote stands and perfect working queue distribution.
Found an additional issue thanks to all the reports, which also explains why you’re getting mixed results. An important positioning variable has not been either serialized or re-populated upon load causing old passengers not to get a proper request position for security check-points, while new ones easily recognized all available ones. Should be fixed in next experimental update!