Still having a bizarre time with Raildriver

[Coppo]

Hi folks,
and a Happy New Year to all!

I've installed the latest (XP) version of MSTSBin, but the problems with the Raildriver still exist (Brake levers do not work and the throttle control is very flakey).
I now find that the keyboard controls for brakes, throttle and direction are not working correctly.
I've been running the German Railroads Vol 7 (Excellent add-on by the way)and now the diesels, I have not tried anything else, do not respond to the default [ ] ; ' keys.
Instead the a & d keys appear to work as a combi throttle. For the w & s keys, the s keyseems to be the only one the works.
Is anyone else having this problem?

Also, having copied over the the two files in the translated dll folder I find that the F5 key is doing the auto-rotate through all three options again. Can someone remind me how to stop this.

Cheers
John

[OTTODAD]

Hi John !

And a HAPPY NEW YEAR to you too ! ;-)

Can't check my RAILDRIVER in the U.K. with 1.6.122319XP as I am with my son in the States.

The basic drivers which are supplied with the RAILDRIVER are inadequate for working with all the variations of locos used in MSTS and unless you modify all their *.eng files to suit the RAILDRIVER's few options you will get problems !

When Microsoft updates Direct-X then it is up to the graphics cards manufacturers to update the drivers for their products so that it's improvements can be used.

George improved many of the MSTS functions with MSTSBin and continues to do so, apparently thinking of adding new ones to *.eng files and it is up to PIEngineering to supply suitable RAILDRIVER files which make use of them !

O t t o

[stresstool]

Here's a thought. I propose a new RD driver be written that uses a shared memory region. It could read parameters from this region and write current control settings into the region. George could have MSTSbin open the shared memory and copy all the stuff that is currently shown in the F5 display into the shared memory in addition to (instead of?) what it displays on the screen. The new RD driver would use the info in the shared memory region instead of having to parse the pixels in the display buffer. This would allow everyone to use AA and AF along with the RD and otherwise not care about the placement or color of the F5 display.

I don't believe there'd be a need for anything more complex than that. I.e., no DirectX interface implimentation; just a simple shared memory.

Later, if George feels like doing it, he could have MSTSbin read the control info from the shared memory and act on it directly rather than having the RD driver send keyboard commands as it does now.

I'd be willing to try writing the RD driver if I can find enough info about how to read and interpret data from the RD device. Maybe PIE keeps that secret, I don't know yet.

[Turbo Bill]

Here's the dat file from my GUI folder for the RD. I know mine works so hopefully this will get you back at the controls for your sim.

[OTTODAD]

Yes Dave, that is precisely what I have been talking to George about before ! ;-)

But this would mean adding new source code to MSTS and re-compile it which he can not do.

All he can do is read the un-assembled Binary code segments of functions and making sure that their sizes do not change, amend them, re-assemble them and save them back to where they came from. That alone requires some genius ! ;-)

That is why none of the MSTSBin patches have changed the size of the original Train.exe !

O t t o

[stresstool]

>All he can do is read the un-assembled Binary code segments of
>functions and making sure that their sizes do not change,
>amend them, re-assemble them and save them back to where they
>came from. That alone requires some genius ! ;-)
>
>That is why none of the MSTSBin patches have changed the size
>of the original Train.exe !

Yikes! That is genius.

I'm by no means an expert and I'm pretty sure George has already thought of or tried this, but if it were up to me, I'd take a shot at patching the object file headers and either increasing the size(s) of the sections or, worst case, adding a whole new section of any size I needed. Then changes to the main code would simply jmp, jsr or reference into the new section as required. I am not intimate with the workings of the Windows compilers and linkers, but I've done that in the past with other OS's. It was possible for me to use the compiler or assembler to produce new object code that I was then able to simply patch into the old object file, but it wasn't easy. It appears at first glance the .exe format would allow such a cheat. Re:

Train Simulator $ objdump -h train.exe

train.exe: file format pei-i386

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 003503a5 00401000 00401000 00001000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .rdata 0002be17 00752000 00752000 00352000 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .data 00035000 0077e000 0077e000 0037e000 2**4
CONTENTS, ALLOC, LOAD, DATA
3 .idata 00002874 0084d000 0084d000 003b3000 2**2
CONTENTS, ALLOC, LOAD, DATA
4 .rsrc 00006b20 00850000 00850000 003b6000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .reloc 00029239 00857000 00857000 003bd000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA

[Coppo]

Many Thanks Bill, the keyboard is now behaving correctly.

The raildriver is another matter, and I'll have to look in to it over the next few days.

Cheers
John

[OTTODAD]

Hi John !

I am back at home with my computers and my RAILDRIVER and can check on what your problems could be, but as I said before there are many versions of settings in *.eng files and trying to make them all work with just 4 RD driver versions is impossible !

You would have to synchronize locos *.eng files settings to match the basic 4 RAILDRIVER *.rdf parameters, or create new *.rdf files for specific locos.

O t t o

[rrc_tx]

To take your thought one step further, can a shared memory region be created for the HUD variables that could function via scripts as an Application program Interface (API)? That would provide a method of interface for those of us developing full scale cab simulators.

Does George have a memory map of the variables displayed on the basic and expanded HUD formats? If so, how can that information be obtained?

[OTTODAD]

Did you read this in my post above, Doug ?

All he can do is read the un-assembled Binary code segments of functions and making sure that their sizes do not change, amend them, re-assemble them and save them back to where they came from.

He can not add new code or functions to the MSTS source code which would necessitate a re-compile of the amended original C++ or whatever program source code he has not got.

O t t o

[rrc_tx]

Thanks for the reply.

Yes, I did read your post and realize the limitation he has creating binary patches versus compilable code which precludes adding a memory area for variables.

However, it occurred to me that in creating the additional expanded HUD he might have knowledge of where the variables are located within MSTS (i.e., relative memory addresses). If these locations were known, it should be possible to write a script to output the values to another application.

This would be a far better method of outputting variables to an external device than using an OCR of display video (similar to the RailDriver approach). But, it may be wishful thinking.

[OTTODAD]

Yes Doug, I have been pondering on similar for a while myself.

The HUD displays are controlled by their files in the GUI folders and possibly linked somehow to the *.DLL files George has amended for the MSTSBin patches, changing the size and capacity of the Object Placement window in the RE forinstance.

But although the RAILDRIVER can read the yellow HUD data displayed on screen where the HUD.dat files specifies it's location, he can not capture the MSTS output of what the locos are doing and the RAILDRIVER has to read it in Video Ram, it's location remaining constant.

For MSTSBin to read that data and store it somewhere would require new code he can not add and the RAILDRIVER programmers to re-write it's source code to access it.

O t t o

[Coppo]

Hi Otto,
I've upgraded to version 1.7xx.

Keyboard still works fine, but the raildriver levers do not work. The buttons do, however. I am also having the problem with the HUD cycling through the 4 [F5] states (includes, blank)by itself.

The engine files I use are the default plus the custom files created by protrain and german railroads for their models.

I have tried a number of routes, just in case it was a route specific problem, but they all behave the same.

I think the first problem to solve is how to stop the [F5} auto-cycle.

Is there a lsit of the files that MSTS Bin changes? I could take a look to see if I have mucked something up somewher.

Cheers
John

[Coppo]

I think the first problem to solve is how to stop the

intriguing, I used the square brackets to indicate F5 but the text did not appear.


the sentence should read
I think the first problem to solve is how to stop the F5 auto-cycling.

Cheers
John

[OTTODAD]

Hi John !

These cycling F5 HUDs have been reported by others too, which mine does not.

But to prevent it happening this is what I suggested before and in this case using my DASH-9:

Plug in your RAILDRIVER into a USB port.
Start the RAILDRIVER Manager
Select MSTSModernDieselDefault (mine is dated 26.Nov.02)
Select Play
Select Route
Select DASH-9
When in it's cab switch on the F5 HUD parts 1 and 2, showing RED text on a 1024x768 screen
Press the RAILDRIVER Run/Stop button.

All works as it should but now notice severe stuttering occurring every few metres, I was not aware of before and testing all previous versions of MSTS including the 1.2/1.4 version find that all of them do it !!! :-(

Electric locos and there many different versions have their own problems using the RAILDRIVER, as have Dual-Control ones.

Looks like my RAILDRIVER will stay in mothballs until KRS and PIEngineering provide a new interface for it !

O t t o

[ns4eva]

Sorry for getting a simi-old thread back up. Just a quick question (yes Ive read the whole thing). So in other words, RailDriver will NOT work if you have MSTSBin installed? I was thinking of purchasing a RailDriver, but now am reconsidering seeing this... *blah*


[font color="red"]My Railfan Photos
[font color="red"]http://ns4eva.rrpicturearchives.net

[font color="black"]--Drifton

[font color="black"]Clinch Valley District V.2.0 is "On The Shelf for Now"
<<There's a bit of Norfolk Southern in all of us>>

[Turbo Bill]

I'm using a a RD just fine with Bin. It's permanantly sitting next to my keyboard, will never go back to the old ways. Works like a charm.....get one!!!!

[Vince]

>>"....Works like a charm.....get one!!!!"<<

Ditto here. RD has worked from the earliest Bin patch thru and including the latest 1.7 whatever.

The only thing I have had to do differently with the Bin Patch installed is select the F5 before selecting the RD Run/Stop key on the RD console.

Thank you George for bringing MSTS alive again!

[OTTODAD]

I can confirm what Vince said !

I was only one version of MSTSBin where George for some reason changed the E-Locos F5 HUD to yellow text, the RD could not read and I provided a fix for until he restored the red text version with the next patch.

Now he does not touch them any more ! ;-)

O t t o

[ns4eva]

Awesome! Glad to hear this. Planning to order on soon then :)

[font color="red"]My Railfan Photos
[font color="red"]http://ns4eva.rrpicturearchives.net

[font color="black"]--Drifton

[font color="black"]Clinch Valley District V.2.0 is "On The Shelf for Now"
<<There's a bit of Norfolk Southern in all of us>>