Skip to main content ↑ ↓
Topic: r2848 win pak128 Stops - Destination changed after reloading savegames (Read 3416 times) previous topic - next topic

r2848 win pak128 Stops - Destination changed after reloading savegames

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

Re: r2848 win pak128 Stops - Destination changed after reloading savegames

Reply #1 –
Did those stops overlap?

Re: r2848 win pak128 Stops - Destination changed after reloading savegames

Reply #3 –
I have similar problem.
After loading old savegames, p****engers change their destination.
They are completely different place. Not overlap.

Tested in r2848 and r2849.
[edit]
simware.cc
Quote
   else {
      ziel = haltestelle_t::get_halt( welt, zielpos, NULL );
   }

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

Re: r2848 win pak128 Stops - Destination changed after reloading savegames

Reply #4 –
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]
	if(ziel.is_bound()) {
		halthandle_t new_ziel = welt->lookup(ziel->get_init_pos())->get_halt();
		if( ziel != new_ziel ) {
			****ert(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 ) {
			****ert(false);
		}
	}

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

Re: r2848 win pak128 Stops - Destination changed after reloading savegames

Reply #5 –
Maybe get_halt() returned halthandle_t() and they made a big group.

Re: r2848 win pak128 Stops - Destination changed after reloading savegames

Reply #6 –
Quote from: z9999+ – on
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.

Re: r2848 win pak128 Stops - Destination changed after reloading savegames

Reply #7 –
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.
 

Re: r2848 win pak128 Stops - Destination changed after reloading savegames

Reply #8 –
Quote from: prissi – on
Btw, formerly bound handles could be treated easily as not equal, since their ids differ!
Yes.
Quote
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).