Changing Air File

[rana]

Hi Pete,

sorry to bug you regarding this - I am writing a new feature for my freeware software FlightSim Manager, where one can use a network PC for a different view (like WideView, but free)

I have the structure done, and it seems to be working fine. The only problem I have is, initially the client receives some information such as location, time, aircraft etc. Now, I am reading the location from H3C00 (Path of the current Air File) - I assumed if I set the same value on the client (also assuming that the client FS also has the same aircraft in the same location), it would change the aircraft. I did the test with default mooney bravo, and that failed to work.

I just wanted to know if I am missing something :?: I guess if all fails, I can load up a FLT file to confirm that the right aircraft is selected, but wouldn't be as elegant.

thanks in advance.

[Pete Dowson]

Now, I am reading the location from H3C00 (Path of the current Air File) - I assumed if I set the same value on the client (also assuming that the client FS also has the same aircraft in the same location), it would change the aircraft. I did the test with default mooney bravo, and that failed to work.

No, as the documentation says, that is the pathname of the current air file. There is no facility to load an aircraft except by loading a FLT. Sorry.

Regards,

Pete

[CATIII]

rana,

to load a new airplane from external software my program does the following:

1) Save the current situation as "tempflight"

2) Change the 'old' aircraft name to the new one in the just created .flt-file. I'm using Delphi5 which has a unit called 'Inifiles' that has facilities for changing this type of files.

3) Load the "tempflight" via FSUIPC

This takes only 2 seconds including FS' time to load the new flight. Works well.

Best regards,

Michael

[CATIII]

[Double-post deleted]

[rana]

Thanks Pete for your reply.

I would also like to point something out I just came across. This is mainly for other programmers:

If you try to set an engine throttle for any of the 4 engines, and the aircraft currently loaded does not have that engine, it will crash Flight Simulator. Check the number of engines (&HAEC) before setting any such values.

Thanks CATIII..

I guess a FLT file is the way to go... however, I was hoping I could get it a bit more elegant than that :(

thanks again..

[Pete Dowson]

If you try to set an engine throttle for any of the 4 engines, and the aircraft currently loaded does not have that engine, it will crash Flight Simulator. Check the number of engines (&HAEC) before setting any such values.

That shouldn't happen, as FSUIPC checks, not for the number of engines, but for a valid ultimate destination.

It wasn't until FS2004 that FS separated all the engine stuff into up to 4 separate structures, and didn't bother to allocate the structures if they weren't needed. In FS2002 and before the setup for all 4 engines was in one bigger structure with other stuff. Same for helo instrumentation and other stuff not always present.

Please tell me EXACTLY what you do that crashes FS so I can investigate. As I say, it should be covered.

Regards,

Pete

[rana]

Hi Pete,

I read the engine throttle lever position (I think I didn't mention that on the last reply) from &H3AE8, &H3A28, &H3968, &H38A8 - to simulate the throttle, I sent these four values back to the client.

Both machines are running FS9 - I was testing with Cessna 172 when this crash occured. I rem'd out writing 2,3, and 4 engine - and then it worked fine. Then I added the line for the 2nd engine only, and the same crash at the same place.

I should add that with the throttle, I am also sending the aircraft location and some other controls... I think the crash occured after writing the engines, and the location, but I am not too sure. If you want, I can test it out to see exactly when it crashes.

[Pete Dowson]

I read the engine throttle lever position (I think I didn't mention that on the last reply) from &H3AE8, &H3A28, &H3968, &H38A8 - to simulate the throttle, I sent these four values back to the client.

Those locations may not be so well checked -- I think they are directly mapped and intended for reading only, but I'll check that. Writing to them has never been tested, I'm surprised that this works at all.

The supported Engine variables, compatible from FS98 through FS2000, FS2002, and FS2004, are those at 088C onwards. These are the ones almost universally used by third party programs.

If FS crashes, e.g. with access violation, whilst FSUIPC is doing anything, like writing to such locations, it will not crash FS but the crash will be trapped in FSUIPC and logged, then things carry on. The log would show the error, but nothing else.

But that's by the way. I've just loaded up the Cessna (as the default, just to be sure) and tried to replicate your crash by writing values to the Engine 2 throttle with no problems at all. In fact the values "stick" and can be read back, which is odd when you think about it.

I think the crash occured after writing the engines, and the location, but I am not too sure. If you want, I can test it out to see exactly when it crashes.

Yes, please, because at present it is not looking like FSUIPC's doing. BTW I assume you are using FSUIPC 3.30? If not please try it with the latest version, I don't care to try to track back to older code.

Thanks & Regards,

Pete

[rana]

Hi Pete,

yep, I can replicate the error. A breif info on the systems in question - Server is XP-pro with my joystick connected. My software os reading the values from this PC - the Client PC is on Win2000 (an old P2 laptop) without any joystick.

As soon I write to the location and process the write, FS2004 screen goes black - checking the process I see dxdiag has started. I have to kill the FS process to end it.

PS. I am using FSUIPC 3.3 on both PC, using the Key you issued me.

here is a bit of the log:

190104 WRITE0 0BBE, 2 bytes: 00 00

190104 GetRealAddr(2200001C)=6106165C (orig 0BC0)

190104 WRITE0 0BC0, 2 bytes: FF FF

190104 WRITE0 0BC2, 6 bytes: FF FF 00 00 00 00

190104 GetRealAddr(2200001E)=6106165E (orig 0BC8)

190104 WRITE0 0BC8, 2 bytes: 00 00

190104 WRITE0 0BCA, 2 bytes: 00 00

190104 GetRealAddr(22000020)=61061660 (orig 0BCC)

190104 WRITE0 0BCC, 8 bytes: 00 00 00 00 00 00 00 00

190104 WRITE0 0BD4, 8 bytes: 00 00 00 00 00 00 00 00

190104 GetRealAddr(22000028)=61061668 (orig 0BDC)

190104 WRITE0 0BDC, 4 bytes: 00 00 00 00

190104 WRITE0 0BE0, 8 bytes: 00 00 00 00 00 00 00 00

190104 GetRealAddr(2200002C)=6106166C (orig 0BE8)

190104 WRITE0 0BE8, 4 bytes: FF 3F 00 00

190104 WRITE0 0BEC, 10 bytes: FF 3F 00 00 FF 3F 00 00 FF 3F

190104 WRITE0 0BBE, 2 bytes: 00 00

190104 GetRealAddr(2200001C)=6106165C (orig 0BC0)

190104 WRITE0 0BC0, 2 bytes: FF FF

190104 WRITE0 0BC2, 6 bytes: FF FF 00 00 00 00

190104 GetRealAddr(2200001E)=6106165E (orig 0BC8)

190104 WRITE0 0BC8, 2 bytes: 00 00

190104 WRITE0 0BCA, 2 bytes: 00 00

190104 GetRealAddr(22000020)=61061660 (orig 0BCC)

190104 WRITE0 0BCC, 8 bytes: 00 00 00 00 00 00 00 00

190104 WRITE0 0BD4, 8 bytes: 00 00 00 00 00 00 00 00

190104 GetRealAddr(22000028)=61061668 (orig 0BDC)

190104 WRITE0 0BDC, 4 bytes: 00 00 00 00

190104 WRITE0 0BE0, 8 bytes: 00 00 00 00 00 00 00 00

190104 GetRealAddr(2200002C)=6106166C (orig 0BE8)

190104 WRITE0 0BE8, 4 bytes: FF 3F 00 00

190104 WRITE0 0BEC, 10 bytes: FF 3F 00 00 FF 3F 00 00 FF 3F

this is the end of the log...

hope that helps.

[Pete Dowson]

yep, I can replicate the error. ...

As soon I write to the location and process the write, FS2004 screen goes black - checking the process I see dxdiag has started. I have to kill the FS process to end it.

Hmmm. Not sure where DxDiag comes into it -- how does that start to run? I thought that was a user utility to check for problems in DirectX.

I've tried all sorts of tests here to make this crash occur, and I cannot. However, really you should be using the well defined and well established throttle controls in the lower areas. Most all of those upper areas are non-writeable or unpredictable if written. In fact now you've told me there is a problem with those I will be blocking writes to them, making them read-only, so please change your program.

You may have noted that those were only recently "promoted" from the 2nd, unsupported table in the Programmer's Guide, to the first table, but I should really have marked most of those "read only". Many of them will certainly crash FS. The problem I have is time to test every location in every version of FS with every aircraft type.

BTW the fact that you are getting FS crashing rather than a mere error being trapped by FSUIPC does indicate that in fact it isn't a memory access problem, it is just that whatever you are writing to is actually part of something else and causes the crash later.

Thanks for the details!

Regards,

Pete

[rana]

Hi Pete,

thanks for the tip... I will change the code to read from 088C.

my personal guess is, after setting the throttle for these engines, FS tries to draw something that obviously doesn't exists, and directX fails - thus running the DXDiag.

another possibility can also be that the Video ram on the laptop is only 64MB - so perhaps FS is doing a memory leak while drawing.

I will confirm what happens after I changed the code, and tried to write to the 2nd engine...

[rana]

Hi pete,

brilliant... after using the lower offsets 088C, I can pass throttle settings to invalid engines without FS crashing. However, I will be checking the engine count beforehand just in case.

[Pete Dowson]

my personal guess is, after setting the throttle for these engines, FS tries to draw something that obviously doesn't exists, and directX fails - thus running the DXDiag.

Possibly. I'm not sure how DxDiag gets involved, but I think that the reason you get a crash and I don't is simply that there are different things in the memory which FSUIPC is assuming will contain the Engine 2/3/4 stuff. If something critical gets overwritten, you get to know sooner or later. If not, you don't.

The problem in FSUIPC at present is that I only check whether the pointer I derive points to valid accessible memory, which it does.

Before I prevent writing to these things altogether, I'll look to see how easy it is for me to derive separate pointers for each engine so I can nullify those which don't apply.

Regards,

Pete