Pete Dowson

I may have found a better work-around! My first tests look good, but it's late here now so I'm going to bed. I'll try some more in the morning, and maybe send you a test version of FSUIPC4. What I did was remove almost EVERY call upon SimConnect to be executed AFTER I receive the first SimStart event. After the Open I'm only requesting the SimStart and SimEnd events (didn't see any point in the first without the second, even if it isn't needed yet). On my first test with that and your TEST.DLL (still not loading of course), no errors! No crashes. More tomorrow. Regards Pete

Yes, it doesn't work for me at all. See my last message above (please see it again if you viewed it before as I've edited it a couple of times). I'm trying direct contacts, but I won't hold my breath. I think the whole team must be up to their proverbials. With a manifest resource now? It won't load without in any case, though that seems irrelevant to this problem. Regards Pete

You might be interested to view thread http://forums.simflight.com/viewtopic.php?t=57105 where it seems some nasty bug has been found in Simconnect. It has been reported, but a reliable work-around hasn't been found yet. The address you get for your 'memory error' is the same as the one I can indfuce by running the TEST.DLL supplied in that thread. Unless we can find a work-around this is certainly going to need a Simconnect fix. Regards Pete

That doesn't runthe SimConnect log shows: 9.96803 DLL Failed to load. Check for missing dependencies. 9.96808 DLL Load Failed: Error=-3 Path="Modules\Test.dll" I assume this is because you've got no manifest resource in the DLL? Anyway I tried it with FSUIPC4.023 and FSX continued to load for quite some time after that, before it crashed with a normal error box. I didn't get the location**, but I'll try again. Is that what you get, even with the other DLL not being loaded? [** LATER: got it! It is 20C6A07E, in Terrain.dll! This is the same as the crash reported in http://forums.simflight.com/posting.phpe&p=352008] I then tried it with the change to not RequestData till after the first SimStart event, and loaded okay, up to the point where I expected to see the flight screen, and then .... FSX just disappeard. CTD'd with no error at all. SoI don't think the work-around is quite right yet. If it appeared to work for you I think that may just be luck. I ran it in debug mode to see if I could trap the error. I get an access violation in API.DLL at location 200E7DA9. It is using EAX as a pointer and that is zero. Additionally, before this, on every "1sec" event, instead of the event reaching my code it is giving two identical Exception 23's" (failure to load flight plan) -- something completely spurious. From where I'm sitting it looks like something is getting corrupted really badly early on, but what I cannot say. I'm not sure what other experiments I can try for a work-around, but first I'll try my modified version in a non-debug version (in the debug version it too with bring up the non-approved dialogue). Regards Pete

Okay. Thanks. I'll try it with and without my change. Pete

Okay, so it should be okay after the first SimStart, provided it is only on the RequestData calls that the problem occurs, and providing no AI traffic starts up before that first Simstart. All my calls to SubscribeToSystemEvent first, then the Menu addition, then some RequestSystemState, then a heap of AddToDatadefinition followed by a bigger heap of MapClientEvent/AddClientEvent pairs are done. The RequestData cals are done after, but certainly before the first "SimStart" event at present. But I can change that, as I said. Regards Pete

I cannot make anything go wrong with GPSout in 4.023. I've tested it both via a COM port and via WideFS. So, can you tell me more, please? Are you sure it is set up correctly? Please show me the [GPSout] section of your FSUIPC4.INI file. Regards Pete

Yes, because FS9 uses FSUIPC3 and WideFS6, whereas for FSX you use the new products FSUIPC4 and WideFS7. Regards Pete

The value in offset 030C wasn't added till version 3.53, in January this year, in response to a request. It isn't an FS value, but one provided by FSUIPC. Regards Pete

Ernot just support, the whole development has been a full time job now for over seven years. I was supporting myself and my family with other funds until nearly four years ago, and then it became a simple choice -- not develop my software for FS any more, and do something else, or make it pay. I was persuaded to do the latter. Maybe that was a bad decision, and I'm sorry you don't like it, but without doing that there would have been no FSUIPC or WideFS for FS2004, let alone FSX. I really do not know how you are reading such things into my words. You must surely be reading something I've not written? Regards Pete

I've looked at this, and in fact a SimStart event occurs very early on, before or early during the progress bar showing the progress or loading of scenery, textures etc. Are you sure delaying the requests for a few seconds it takes to get to that point works? It looks like a SimStop event follows (about 40 seconds later in my case) and then, a lot later, after all the loading, another SimStart. That's what is happening here with my FSX configuration anyway. Trouble is I don't know if I dare ignore the first SimStart in case the sequence varies according to configuration. Regards Pete

ErI did check it and forgot which thread it was to report back in. I never got it to go wrong here -- the code is very simple, it just makes a direct copy of 02C8 except when the on-ground flag is set. There's really nothing in it to go wrong. Have you checked it with FSInterrogate, or only your program? Please use the Monitoring facilities (logging tab, right-hand side) to monitor 02C8 and 030C both as S32 types and 0366 as U16. You can see them on screen with the "FS display" or "AdvDisplay" option, and put them in the Log for me with the Log option. Regards Pete

Really? How odd. I'll re-check it here. Thanks. Pete

Ouchthis needs to be notified to MS immediately, as I think they are trying to work out what to do about the problems imposed by firewall things at present. Currently FSUIPC4 issues its main series of RequestDataOnSimObject after it gets a user aircraft ID. Before that it would have issued a RequestDataOnSimObjectType to get the user aircraft ID. It issues that as soon as it gets any System State return including a UserObjectID indicating the OBJECT_ID_USER. I thought that was safe enough, but possibly it is getting that when the default aircraft or flight is being loaded. I could try moving that code specifically into the case statement for the "SimStart" state. I don't have a second one to experiment with, although I could use a second copy of FSUIPC with a different name I suppose. How about if I make a modification, as above, and email a version to you for you to test? Oh, I also call RequestDataOnSimObject for each AI aircraft object addded, as I receive notifications for aircraft being added (OBJECT_ADDREMOVE event). Are these ever likely to occur too early or doesn't the traffic generation start till after "SimStart"? I don't want to have to stockpile AI object IDs ready to request their data later on. Regards Pete

No, because it only keeps a handle to the processes it started itself. Sorry. And it isn't simply a matter of adding it to the existing facilties. I can consider it for future addition, but it isn't trivial so it would have to wait its turn. Regards Pete

Yes, sorry. it was a typo in my code. I think it is fixed in 3.709 which has been available here for some time, but let me know if it isn't. I had intended to do a formal release before now of 3.71 but the work on FSX delayed it and now FSX support is getting in the way. But I will get to it. Regards Pete

Don't go to that tab. The FSUIPC axis assignments are for clever folks wanting to do clever things not supported by FS itself. Spoilers are supported on an axis in FS itself. Go to FS's Options-Controls-Assignments. Assign your spoiler to your axis there, following normal FS methods. There's really no need for you to bypass all of that. Make sure FS's sensitivity slider is full right (max) and the null zone full left (off). Get it all working in FS without using FSUIPC first. Only then go to FSUIPC's Joystick Calibration tab and calibrate both end points (making sure to leave a little dead zone either end), and then set the two centre values to give you an "ARM" zone wherever you want. There are simple numbered steps for calibration given in the User Guide. Regards Pete

Hi Thomas, I don't understand. It works the same way in FSX here. I simply copied over the same INI file sections to my FSX installation. Can you tell me what you are doing, exactly, and I'll try to follow it here to see why it isn't working for you? Regards Pete

Hmmm. I did delve into DirectSound way back when I did my Esound package. Although I did get it working it was quite a lot of programming to do a simple thing and it put me off for life! ;-) Certainly that's possible. I suspect the enormous VB libraries provide wrappers for you to make it much easier. I'm not going to use VB in an FS module. I expect it is also made easy using MFC, but again it relies on wrappers in large libraries. And compared to the extremely simple (and fast) way I currently do it (one "joyGetPosEx" call for each device, and that's it) I still think it will be a messy and larger job. I'll make a note to look for an example in plain C or C++ when I have time. Thank you for the suggestion. Regards Pete

Actually a way was discovered quite recently. I've not been able to do it in FSX yet, but in FS2002 and FS2004 the currently selected view can be changed by directly writing a value to a particular location. This would involve using the "Offset byte set" control which you will find in the dropdowns for both Key and Button assignments. When you've selected that, fill in the Offset field that appears with "x8320", and the Parameter with one of these values: 1 = cockpit 2 = virtual cockpit 3 = tower 4 = spot plane 5 = top down Five assignments to five keys or buttons and your done. Regards Pete

I think you can open your account (user name/password?) and create a "problem ticket". Or something like that. Regards Pete

I think you misunderstand something quite fundamental here. Just because PMDG aircraft make some use of FSUIPC doesn't mean they ONLY use FSUIPC to interface to FS! The PMDG747 is an aircraft. Aircraft, scenery, other DLLs, Gauges, are all examples of bits that although classed as "add-ons" are really made part of FS -- they have to be made to fit into the version of FS they are intended for, and they are dependent upon the features in FS itself much more than whatever little they ever used FSUIPC for, if anything. Almost no scenery, few gauges and fewer add-in DLLs use FSUIPC. With the few aircraft and gauges the predominant use of FSUIPC was to obtain AI aircraft positions for TCAS radar displays. That started with FS2002 -- but Microsoft provided a direct way in FS2004 so many used that. PMDG used FSUIPC for quite a few more things, and, indeed, during FSUIPC4 development they were a great help in testing it as their code used a lot of things in FSUIPC which I would not have otherwise even understood fully yet alone been able to test. They most certainly could still use FSUIPC in their updates for FSX, if they so desired, though I think that there will be so many other changes that they will want to (and in some areas need to) make that I think they will be moving over to drive SimConnect directly rather than indirectly. I hope that clarifies things for you. Incidentally, there are add-ons, such as FSNavigator, which have never used FSUIPC. Obviously any compatibility FSUIPC4 might provide to FSUIPC3 clients cannot apply to those at all. FSNavigator for FSX is predicted to be available mid-2007 I understand. Regards Pete

What does your receipt say? It should be clearly marked as FSUIPC3 or FSUIPC4. Keys for one won't work in the other. I don't have anything to do with the issue of Keys so you may need to take it up with SimMarket if you thing they got it wrong. Regards Pete

It isn't (cannot be) caused directly by FSUIPC4. The instruction address is actually in FS's TERRAIN.DLL. Unlike previous versions of FSUIPC, this one doesn't hack about inside FSX itself, it uses SimConnect. It is quite possible there are still bugs in the SimConnect interface, but, again, a crash in the Terrain DLL is not likely to be due to that either. Have you by any chance been applying any of the "go faster" tweaks for FSX, involving replacement texture and other files? Possibly one of those isn't right? I see you've also got Ivap (and maybe other) add-ins running -- have you reproduced the problem without those? Just adding in more things for FSX to do subtly changes memory arrangements, timings and so on, and can often show up problems which may otherwise pass unnoticed. Please submit full details of the crash to Microsoft. Emailing them to tell_fs@microsoft.com should be enough. Regards Pete

Ah .. I replied to your email before seeing this here. Sorry, some things conflict in that case. Please read this, not that: Done. I'm afraid it wasn't in the INI you sent and the Server Log therefore doesn't show any extra information. Done. Okaythat's useful. There are now two other tests that we can do: First please add the Log=DebugAll line to the [WideServer] section of the FSUIPC4.INI file. And remove the "AdvertiseService=No" line now -- we know now that this isn't responsible one way or the other. Then the two tests are: 1. Run as it is, no change to Client end. Send me both Server and Client logs. I want to be 100% sure the mailslots aren't arriving -- because if they are and the Client is not acting on them, or acting incorrectly, I have a problem in the Client code. On the other hand if the mailslots are simply not arriving, then (seeing that both your systems are WinXP I see now) there's something amiss, something stopping them. More about that below. 2. Second test. Add the line "Protocol=TCP" to the client's INI file (in the [Config] section). Re-test. If it works, it works despite lack of mailslots. If it doesn't, please send me both logs again. Okay, good. Now, are they both in the same WORKGROUP? I seem to remember that someone had a problem, only with the Mailslots, and it turned out that WinXP may not be sending these messages to other workgroups, only the PCs within the one. You can read (and I think change) your workgroup name by right-clicking "My Computer", selecting Properties then the Computer Name tab. I'd like to know this, please, even if you did get it working in (2) above. If different work group names do stop the broadcasting I will have to document the correct work-around. If they are different it would be even nicer of you if you could try making the two the same and retesting without the "ServerName" and "Protocol" parameters in the Client INI, just to prove whether that was the reason or not, but I realise that may be inconvenient. Regards Pete