[James Ross]

So running RunActivity from the debugger/directly requires a little extra step to normal: you need to configure the command-line options, telling it what to load. Luckily we have a really handy option in Open Rails: "/resume". This option tells RunActivity to find the most recent save and load it, so what I typically do is this:

• Load up the latest Open Rails build.
  
• Select a route, activity, etc. for demoing the bug and start it.
  
• Get the game in to a position where the bug is demonstrated or easily triggerable.
  
• Save (F2) and quit.
  
• Go in to Visual Studio, and open the RunActivity project properties (Right-click "RunActivity" in Solution Explorer and select "Properties").
  
• In "Debug", under "Start Options" enter "/resume" in to "Command line arguments".
  
• Run the project (F5).
  
• Check that the bug is fixed.

Steps 5 and 6 only need to be performed once for each copy of the code you have, since VS remembers the setting.

You can repeatedly run the project with F5 after each tweak and see how things look; unless you make a new save, you'll keep resuming from the same place each time.

[markus_GE]

:) for the reply. I read it just after closing down VS for the day, trying to get acquainted to it (after all, when I start studying, this should be one of my main tools to work with :) ) I´ll put it to use tomorrow :)

Cheers, Markus

[markus_GE]

I did what you said, James, and everything worked out, on the first try, except for one thing: I got English text, even though I switched to German when doing the save to be resumed. ORTS, when started from my Desktop shortcut, also loads in German, just the VS build doesn´t...

So I went looking for where the compiled RunActivity.exe was locate, found it in "Program" in my local source copy, made a backup of my regular installation of ORTS, and copied all contents of Program over to the regular installation. I switched ORTS to run the non-64-bit RunActivity, tried it, and everything was fine (I changed the 12 to 19 later on, because 18 was still a little small).

My solution, however, is a bit cumbersome... is there a way to get it to work the way you described?

Cheers, Markus

[James Ross]

markus_GE, on 17 March 2015 - 03:51 AM, said:

My solution, however, is a bit cumbersome... is there a way to get it to work the way you described?

Ah yes, I did forget a step. Inside the \Source\Locales directory there is an "Update.bat" file. If you double-click to run that, you should be good. What I believe was happening was that your copy of the code (as is expected) didn't have the localised files so it defaulted back to English.

[markus_GE]

Ah, the update.bat... why didn´t I think of that myself, after all, I use it every time I check my translations... :) :)

:) again, the changes are committed already :)


BTW, what about the idea of showing the states in the extended car ops window, as was originally suggested by Eugen (and is, as per the title, the original request of this thread)?

Cheers, Markus

[James Ross]

markus_GE, on 17 March 2015 - 04:28 AM, said:

BTW, what about the idea of showing the states in the extended car ops window, as was originally suggested by Eugen (and is, as per the title, the original request of this thread)?

Ideally we should display them in the train operations window, for some at least, but yeah, they should be shown. Someone could start this by simply setting the background or foreground colour of the clickable labels. We do need better UI controls though. It's on my list. :)

[markus_GE]

Do you mean displaying them outside the menu that I changed? That would be better still. :)

Cheers, Markus

[James Ross]

markus_GE, on 17 March 2015 - 07:06 AM, said:

Do you mean displaying them outside the menu that I changed? That would be better still. :)

Yeah, the train operations window (F9) is the best place for some of them to be shown - but they can all be shown in the car operations windows (the popup you changed).

[markus_GE]

Ah, now I understand what you mean.

Cheers, Markus