Loading a Flight using FSUIPC

[scruffyduck]

Hi Pete

I hope that you had a good holiday :D :D

I am trying to cause FS9 to load a .FLT file using offsets 3F00 and 3F04. As per the programmers guide I am writing the file name to 3F04 and 0 to 3F00.

Checking the log I can see the writes being made but the flight is not being loaded. I am wondering if I have defined the path correctly. in the guide you say to use a relative path so that if I want to load the file which is Flights\FCFlights\My First Flight.flt then I write "flights\FCFlights\My First Flight.flt" + chr(0) to 3F04 and 0 to 3F00. I am doing these in the same process with the write to 3F04 first.

The flight is not loading so I am doing something wrong. Can you confirm that I am writing the pathc correctly - should there be a \ at the front? Is this relative to the main FS9 folder for FS9 or the flight data in my documents? Is the file name case sensitive? and is there anything coming back to indicate success or why it might have failed?

thanks in advance

[Pete Dowson]

I am wondering if I have defined the path correctly. in the guide you say to use a relative path so that if I want to load the file which is Flights\FCFlights\My First Flight.flt then I write "flights\FCFlights\My First Flight.flt" + chr(0) to 3F04 and 0 to 3F00. I am doing these in the same process with the write to 3F04 first.

[\quote]

Actually the description may be wrong for FS2004, because the default saving path is now in the Flight Simulator part of My Documents, that would probably be the root of the path FS uses. After all, since all user-saved flights go there if FS assumed loading was from the FS path it would never be able to load user-saved flights.

In FS2002 and before there was never a problem -- user saved flights went into FS\flights alongside provided flights.

Possibly FS assumes the My Documents route unless you provide the complete path, drive included (D:\FS\Flights\...). First try putting your flight into the saved flights part, possibly in a subfolder, and check.

I would experiment here, but I'm still catching up from my holiday and, worse, have come down with a rotten cold (changes of climate) and a case of Delhi Belly, so I'm not very productive at the moment. Sorry.

Can you confirm that I am writing the pathc correctly - should there be a \ at the front?

No.

Is this relative to the main FS9 folder for FS9 or the flight data in my documents?

That is the question. Please let me know.

Is the file name case sensitive?

No.

and is there anything coming back to indicate success or why it might have failed?

No, the procedure I call in FS doesn't tell me.

Regards,

Pete

[scruffyduck]

Hi Pete

Sorry to hear you have come down with something :cry: :cry:

I will experiment with different path settings and see if I can get a hit - I will let you know what I find

[scruffyduck]

Hi Pete

I have done some tests and the results are puzzling. First I set 3F00 to '1' and wrote the flight name and 1. Sure enough the flight was saved in My Documents\Flight Simulator Files as we suspected. I then moved my aircraft and did no more that write the flight name again and this time '0' to 3F00. This did not load the flight and FS9 crashed. I have repeated it a couple of times with the same result.

I must be missing something here - any suggestions much appreciated

This is the relevant bit of the log:

   185172 WRITE0 [P2524]  3F04,  18 bytes: 4D 79 46 69 72 73 74 46 6C 69 67 68 74 2E 46 4C 
   185172                           54 00 
   185172 WRITE0 [P2524]  3F00,   2 bytes: 00 00 
   185390 C:\Documents and Settings\Jon\My Documents\Flight Simulator Files\MyFirstFlight.flt
   207703 System time = 12:23:34, FS2004 time = 12:23:11 (17:23Z)

That is the flight name that I am trying to load. Looks fine to me??

[Pete Dowson]

I have done some tests and the results are puzzling. First I set 3F00 to '1' and wrote the flight name and 1. Sure enough the flight was saved in My Documents\Flight Simulator Files as we suspected.

If you set 3F00 to 1 first, there would have been two flights saved -- it is the writing on something to 3F00 which triggers the action. you always need to write the string to 3F04 first.

I then moved my aircraft and did no more that write the flight name again and this time '0' to 3F00. This did not load the flight and FS9 crashed.

Er, but the log shows the flight being loaded:

This is the relevant bit of the log:

   185172 WRITE0 [P2524]  3F04,  18 bytes: 4D 79 46 69 72 73 74 46 6C 69 67 68 74 2E 46 4C 
   185172                           54 00 
   185172 WRITE0 [P2524]  3F00,   2 bytes: 00 00 
   185390 C:\Documents and Settings\Jon\My Documents\Flight Simulator Files\MyFirstFlight.flt
   207703 System time = 12:23:34, FS2004 time = 12:23:11 (17:23Z)

That is the flight name that I am trying to load. Looks fine to me??

The line at time 185390 is FSUIPC independently detecting the loading, by FS, of a new flight. This part of the code operates on all flight loading, no matter where from. Try loading it from the Flights menu, you'll get the same entry.

If FS9 then crashed it's something to do with what it loaded, as that will be some time later.

How is it that FSUIPC managed to continue and log the time etc if FS crashed? Normally if a process crashes all of its main thread crashes with it. There's no sign of a crash in the log. can you explain a bit more about what actually happened?

Pete

[scruffyduck]

If you set 3F00 to 1 first, there would have been two flights saved -- it is the writing on something to 3F00 which triggers the action. you always need to write the string to 3F04 first

Yep that is what I am doing - write the file name to 3F04 then write the action digit to 3F00 then call process.

The line at time 185390 is FSUIPC independently detecting the loading, by FS, of a new flight. This part of the code operates on all flight loading, no matter where from. Try loading it from the Flights menu, you'll get the same entry.

Thanks Pete - that is what I suspected.

How is it that FSUIPC managed to continue and log the time etc if FS crashed? Normally if a process crashes all of its main thread crashes with it. There's no sign of a crash in the log. can you explain a bit more about what actually happened?

Well the flight sim screen sat there for a few sceonds - no sign of activity via the cursor showing busy. Then MS helpful little window came up saying that FS had done something nasty and needed to be closed down and would I like to let MS know what had happened.

I am now starting to suspect that it may be related to other stuff in my FS setup - recently it has not been closing properly so perhaps I have other conflicts. Having said that I have no problem loading the flight from the FS menu so I can't see a link right now. From what you are saying FS reported that it was loading a new flight - the correct one so it is not the way I am calling it via FSUIPC but something else?

[scruffyduck]

Right just tried again with the same results - FS is opening and closing normally. If I load the flight from within FS it loads fine. If I try to load it via FSUIPC then I get the same crash and exactly the same log entries. :?

Bit more info

Fatal Error in module xpsp2res.dll Offset 00202113

It seems to be something to do with service pack 2. It is described in the properties as 'Service Pack 2 Messages' and is obvisouly being called somehow when I try the load from my program

[Pete Dowson]

Right just tried again with the same results - FS is opening and closing normally. If I load the flight from within FS it loads fine. If I try to load it via FSUIPC then I get the same crash and exactly the same log entries. :?

I've tried loading a flight through FSUIPC with no path, just the flight name, and it loads it from the default flights path successfully and carries on okay. I've tried it with all sorts of different flight names.

I'm just about to test with paths in the string too, to see if it only selects folders within the default folder, or whether I can get it to load those in the main FS flights sub-folders.

There's really nothing in FSUIPC which can cause that crash you are getting. The save and load flight actions are simple calls to the routines in FS which do those things. It sounds as if something else is conflicting with the flight loading somewhere. Is your program perhaps trying to access something before the flight is loaded? (Mind you, FSUIPC traps its own errors, so you wouldn't get FS crashing if you asked FSUIPC to do anything for you when it shouldn't).

What else do you have running? Can't you get any information about where the crash is occurring?

Incidentally, it also just occurred to me that Radar Contact version 4 (I'm in the Beta group) has been using the Flight Loading facility through FSUIPC for many months now. It certainly never seems to cause a crash either.

Regards,

Pete

[scruffyduck]

Pete

As you see I hqve found the dll which is causeing the crash but it is not much help as it seems just to be a message handler for SP2 - so I guess something else is calling it and sending it duff info - as far as I know I am not going anywhere near it myself.

I have a temporary program that does nothing except test the connection with FSUIPC. I will try everything stripped down to see if I can get it to work. There must be a conflict somewhere as you say - what I don't understand is why I can load it from within FS just fine - if my program is sending the same instructions as the internal menu then it should work . Must be my program somewhere but at the moment I have no idea where

[scruffyduck]

OK Pete it is something my program is doing. I ran my stripped down test program and it works fine. I need to get into my code and figure out what is causing the problem.

Thanks for your help :)

[Pete Dowson]

I have a temporary program that does nothing except test the connection with FSUIPC. I will try everything stripped down to see if I can get it to work.

I've now tested with paths as well.

Basically, what happens when you write zero to 3F00 is that FSUIPC checks to see if there's a path in the string provided at 3F04. If there is, it sends it to FS unchanged.

If there's no path, it pre-pends the full default path -- the one to the My Documents place for Flight files.

I tried it with the full path to FS's supplied Flights, i.e. D:\FS9\flights\ etc and that works fine too.

If you just use a partial path, like Island\FSUIPC doesn't add anything, but FS doesn't know what it means either. So you either have to provide the complete path or just the filename for the default user path. I'll clarify that in the programmer's guide.

I'm sorry I'm unable to help with whatever it is crashing your FS. I cannot seem to make anything crash here, even with bad paths and/or filenames -- in the latter cases FS simply does nothing.

Do you have any other Add-Ins in FS? i.e. other DLLs? FSUIPC posts a message via the FS window when you write to 3F00, as it must make sure FS is in a message-processing loop when it tries to call Fs's load and save routines. This also prevents FSUIPC callers timing out because of the Load taking too long. To send this message, FSUIPC uses a WM_USER+n message number. I'm wondering if something else could also be making use of such.

However, if that were the case, FS would crash in the same way when you saved a flight too.

Anyway, just to make sure that nothing I've changed in FSUIPC recently has affected things, I'll send you an interim version soon -- probably tomorrow. This is not a solution, just a "making sure we are using the same code" exercise.

Regards,

Pete

[scruffyduck]

Thanks Pete

At least this has clarified how FS9 behaves :D

Here is what I have found out. There is something that I am doing to FS with my program which will cause the load to fail with a crash. I put the call to load the flight file right at the top of my initialization routine and ti worked fine. Moving it down below other functions which make FSUIPC reads or writes started to cause the crash again. Eventually I made sure that both the call was at the top and also that there is a delay built into the loading routine to make sure the load has a chance to finish. since I am using FS9 I started with a 10 sec wait then tested the ready to fly indicator every second until it went 'green' Flight loaded fine and my program ran.

Unfortunately I am not over it because when I stop the flight and try to exit FS it crashes with the same error. What also happens is that if I stop the flight and then run the load flight routine again it crashes.

This also happens if I run a flight script which does not call a flt file. If I then try to call a flight file FS crashes. This happens even if I shut my program down and re-start it.

My conclusion at the moment is that I am leaving FS in a state which screws up loading a flight file and I am doing this whether I have previously loaded one or not. FS must be doing certain things when it starts the load and is reading data which I am leaving behind or which I am setting and abending in this obscure SP2 dll :?

I will go back and look but at the minimum I am doing a bunch of reads which are obviously not changing any data and the other thing I am doing is using hotkeys and writing messages to the screen.

I will go back to my test rig and try to build up a series of writes to try and pinpoint it.

[Pete Dowson]

Here is what I have found out. There is something that I am doing to FS with my program which will cause the load to fail with a crash. ...

...

I will go back to my test rig and try to build up a series of writes to try and pinpoint it.

Hmmm. Good luck! Try also using the interim version 3.471 of FSUIPC I sent, just in case it makes any difference. Kepp me posted.

Regards,

Pete

[scruffyduck]

Thanks Pete

got the interim and I'll put that in for further testing

[scruffyduck]

Pete

This makes no sense to me but it is repeatable 100% on my setup.

If I load a flight using offsets 3F04 and 3F00 it loads fine.

Then I write a text message using 3380 for the text and 32Fa for the time/style.

I disconnect, close my program and then start it again

I then try to repeat the flight load and the crash occurs. Clearly there does not seem to be a connection between the flight load offsets and message writing offsets - I'm not over-writing one with the other as they are far apart. Nevertheless it happens each time.

I have a bunch of 3rd party dlls in my modules folder and I will disable them one at a time to see if any one of those is the culprit. I have no add-ons running that I am aware of

[scruffyduck]

Pete

I have found the problem - mea culpa - it was nothing to do with the flight loading itself but with the writing messages. I was right padding the message string to 255 instead of 127 :oops: so overwriting the next 127 bytes with (presumably) 32. This did not show up unitl I either shut down the flight sim, or tried to load a new flight. Sorry to send you off chasing red herrings. A bunch of the offsets after the write string are read only but presumably one or more of them sets FS into an error condition which does not show up until either the flight is changed or the sim is shut down.

I knew that the string length was a max of 127 but must just have gotten 255 in my head when I wrote the padding code.

Edit:

Pete - just re-read the documentation from the SDK which suggests that either FSUIPC or FS truncate the string to 127 so maybe there is a funny in there somewhere as far as FS9 is concerned?

[Pete Dowson]

I have found the problem - mea culpa - it was nothing to do with the flight loading itself but with the writing messages. I was right padding the message string to 255 instead of 127 :oops: so overwriting the next 127 bytes with (presumably) 32.

A bunch of the offsets after the write string are read only

This is offset 3380 we're talking about, right?

Where do you find "read only" after 33FF? The offsets 3400-347F could do anything. I think only a few are marked read-only in my tables. The others either write to the listed values, or else write to weird untested as yet unknown places in SIM1.

just re-read the documentation from the SDK which suggests that either FSUIPC or FS truncate the string to 127 so maybe there is a funny in there somewhere as far as FS9 is concerned?

If you write 256 bytes to offset X, and the first field at X is 128 bytes long, then the first 128 bytes will be used for that field. The remaining 128 bytes go to whatever fields follow. The whole offset area is treated as continuous memory, although it is nothing like, to maintain that illusion, as that was indeed what was happening in the original FS6IPC with FS98.

The only truncation going on is FSUIPC putting a zero in the 128th byte, hence truncating a 128 byte non-terminated string to 127 bytes.

Your writes to offsets 3400 and following are regarded as totally separate "commands" to FSUIPC. Every separate field is a separate command, but the whole lot is simulating a contiguous expanse of "memory" (which it most certainly is not).

Regards,

Pete

[scruffyduck]

Thanks Pete

Yes I am refering to 3380 - also it is marked as 128 bytes in the programmers guide which I assumed was the space to the next offset, but seems to be 240 bytes since the next entry is at 3470 and if my maths has not failed me that is 240. I was writing 252 bytes so I filled the 240 plus another 12 which would, as I understand things, write to the ambient wind components which start at 3470.

Assuming that writing to the wind components would not casue an exit crash or crash when I try to load a flight then whatever I wrote to in the space between 3400 and 3470 was causing the problem. As you say they are untested and I will avoid them in the future :wink:

[Pete Dowson]

Yes I am refering to 3380 - also it is marked as 128 bytes in the programmers guide which I assumed was the space to the next offset, but seems to be 240 bytes since the next entry is at 3470 and if my maths has not failed me that is 240.

No, you are reading the table incorrectly. Each field has the length specified. Unlisted offsets are just that -- they may access parts of the Sim which we haven't worked out yet. You may not have noticed, but things do get filled in gradually as more useful data is identified and documented.

This applies to all unlisted offsets below 4000. From 4000 upwards it is nearly all FSUIPC-local memory, used for applications, excepting the 6000 ff area which I used to map into the GPS data owned by FLIGHTS.DLL.

I was writing 252 bytes so I filled the 240 plus another 12 which would, as I understand things, write to the ambient wind components which start at 3470.

You were writing to unknown parts of SIM1 as well, believe me.

Since this crashes FS in the end, one of the values you overwrote was very likely a pointer or a value used as an index on a pointer.

Regards

Pete