r2848 win pak128 Stops - Destination changed after reloading savegames

[Diegote]

As shown in the picture below, after reloading savegames, all passenger's destinations from one stop are merged into a single destination.

[prissi]

Did those stops overlap?

[Diegote]

Did those stops overlap?

Do you ask me if in each one of this 4 cities I use overlapping coverage? The answer is Yes.

[z9999+]

I have similar problem.
After loading old savegames, passengers change their destination.
They are completely different place. Not overlap.

Tested in r2848 and r2849.

[edit]
simware.cc

   else {
      ziel = haltestelle_t::get_halt( welt, zielpos, NULL );
   }

What is this ? I commented out this code, and seems working well again.

[gerw]

Imho, this is a bug in simhalt_t::suche_route, since the connections are calculated correctly - or at least displayed correctly

Edit:I don't even understand the lines arround. My modified code

Code Select Expand

if(ziel.is_bound()) {
halthandle_t new_ziel = welt->lookup(ziel->get_init_pos())->get_halt();
if( ziel != new_ziel ) {
assert(false);
}
}
else {
ziel = haltestelle_t::get_halt( welt, zielpos, NULL );
}
if(zwischenziel.is_bound()) {
halthandle_t new_zwischenziel = welt->lookup(zwischenziel->get_init_pos())->get_halt();
if( zwischenziel != new_zwischenziel ) {
assert(false);
}
}

And indeed, if I delete the line you mentioned, all things are normal again. But I don't understand this...

[z9999+]

Maybe get_halt() returned halthandle_t() and they made a big group.

[gerw]

Maybe get_halt() returned halthandle_t() and they made a big group.

Oh, yes. This is it: On loading, all ware_t gets a unique halthandle_t (this can get unbound after loading). But, if get_halt return halthandle_t(), all those ware_t have a handle with entry=0. And then the ==operator returns true. And then pax and mail gets joined...

Maybe we should think of halthandle_t()!=halthandle_t()? Matlab (a program for numerics), e.g., has NotANumber!=NotANumber. Maybe this is also usefull here.

[prissi]

This was introduced to avoid the initial "Error_in_routing" display reported. But then the cause was found at another place and this line was overlooked.

Btw, formerly bound handles could be treated easily as not equal, since their ids differ! However this would break code in some places, I fear. And I see no gain, unbound should be unbound.

[gerw]

Btw, formerly bound handles could be treated easily as not equal, since their ids differ!

Yes.

However this would break code in some places, I fear. And I see no gain, unbound should be unbound.

Mmh. My idea was, that two unbound handles are always unequal (even if they have the same "entry"). Currently, unbound handles are "sometimes" equal and sometimes not. This is somehow inconsistent, but equality of unbound handles isn't tested often in the game, I think. And since the bug is fixed in r2850, we don't have to touch this (yet).