[dennisat]

There seems to be a problem resuming a saved game in X2157 -

Error: System.ArgumentException: An item with the same key has already been added.

This has occurred on all my attempts to resume from saves made from X2157 in two routes so far. The OR log is attached:

 OpenRailsLog.txt (9.02K)
Number of downloads: 231

[roeter]

I couldn't reproduce the error (restore went fine without problems), but version X2158 should prevent whatever it was that caused the crash.

Regards,
Rob Roeterdink

[dennisat]

I have just tested the fix and the saves have resumed OK. However, the Player Train both before the save and after the resume is Train 1. Has this changed recently, the Player Train always used to be Train 0.

Dennis

[roeter]

Yes, I noticed that as well.
I don't know what is causing this - as far as I can tell, it wasn't brought on by the changes I made as these did not concern the working of the activities, and also I noticed it when I started to make the changes, so it was in there allready. It does not seem to make any difference, though.

Regards,
Rob Roeterdink

[dennisat]

roeter, on 08 April 2014 - 06:43 AM, said:

I couldn't reproduce the error (restore went fine without problems), but version X2158 should prevent whatever it was that caused the crash.

I did a little more research on what was happening here and the error is caused by trying to add more than one train with the same service name to a list. The fix now ignores trains which have the same name as one already added to the list. This means the list does not contain all AI trains. Does this matter? I haven't really studied what the timetable logic you're building up is all about.

Using the same service name for multiple AI services is commonplace. If you have 2 trains per hour from Waterloo to Woking, for instance, you just make up one service and add it multiple times to the traffic list starting at 09:30, 10:00, 10:30,... or whatever. This saves a lot of time building an AI pattern and reduces the number of service files required for an activity. An example of this was the reason for the crash.


Dennis

PS:
I tracked down where the Player Train changed from being Train 0 to Train 1. This occurred in X2073. I haven't been able to work out why it was changed yet.

[roeter]

For activities, the name of a train does not matter, it is not used as there is no active interaction directly between trains.

The train name is specifically intended for use in the new timetable control which is under development. In that mode, there is active interaction between trains which are referenced by name, but checks for duplicate names are performed when the timetable is read.

Version 2073 is the first version where the train class was altered to prepare for the timetable mode.
I think I can figure out what happened : in timetable mode, train numbering starts at 1 as the player train is allocated later. Changing the initial value of the Number variable in the train class also apparantly accidently changed the number of the player train in activity mode.
I will have a look if I can change the numbering sequence for the timetable mode such that I can restore the use of 0 for player train in activity mode.

Regards,
Rob Roeterdink