Pete Dowson

Shows the same -- just nothing reaching it from Wideclient. It does show you are using FSX though, which may have been useful information in the first place? ;-) I notice the Server name is spelled HOME-SERVER is the Server but home-Server in the client. Not sure if that makes any difference 9it does get the IP address -- is that correct), but I have been told of one case, in Windows Vista, where the case of the letters in the names was relevant. Can I see the Wideclient.INI file please? Regards Pete

You've only shown the client log. That's only half the story. Does the WideServer Log show anything useful? The client seems to be just hitting a brick wall. Maybe a firewall problem in the Server? Possibly something you've updated, or automatic windows updates? There's no errors logged, but I've noticed that with firewall problems. Rather than return anything , which I assume might lead an attacker to think there's something there, you just getnothing. No response, nothing. But look at the server log. then check your firewall. Regards, Pete

In that case the main change for you in FSUIPC, in 4.02, is that it doesn't touch the axes -- like the other controls it monitors them for logging, but it doesn't intercept them. Before 4.02 they were being stopped in FSUIPC and then re-issued, after possibly being calibrated or re-shaped. All that is now not invoked for unregistered users. It uses FSUIPC? do you know what for? I'll be needing information from PSS then. You say it works better WITHOUT FSUIPC, so what is it using it for? Oh, right. But with FSUIPC you can move ailerons etc in other aircraft? The very first release, 4.00, was only available for a few hours. The only two official user releases have been 4.01 and 4.02. The 4.023 you are using is an interim version. I need the Logs in any case, please, as described. And some information really about what PSS is doing with those controls. It is presumably part of their "fly-by-wire" system, but I need to know what so I can see what'sc changed. Could you also try with the official 4.02 release please in case it is only a side-effect of something in the streamlining I did, for better frame rates? Oh, one more thing -- could you enable IPC Write logging as well, when you try the Airbus. I have an idea what is might be, but i need to see where they are writing. I've also a strong feeling that, if my idea is correct, you'd actually have no such trouble if FSUIPC4 were registeredif you can send me the logs this evening so I can check, I may be able to email you a test version later tonight. Regards Pete

Any log for me to look at? I know of no issues with any axes in this version. The only possible problems I know of with SAimconnect at present are: 1) FSUIPC cannot run at all -- no Add-Ons menu, nothing. In this case there would obviously be no effect of having it there. 2) Intercepted controls, like axes is intercpeted by a Registered install of FSUIPC for joystick calibrations, can, on a very few systems (so far) appear to be delayed, with a delay increasing from a few seconds up to 30, as has been reported. I've not managed to reproduce this on any system so far, but it has been reported to MS. You don't say whether either of these things are happening, nor even if your FSUIPC is registered. Can you give some more information, please? If you have registered it, have you been calibrating your controls in FSUIPC or not? The main change is that in an unregistered FSUIPC none of the axes are now intercepted by FSUIPC, so that it has no influence at all. Only if you register FSUIPC do you get an interception, but then you can still add a parameter to the INI file to stop it if your system suffers delays because of the Simconnect problems. In other words, the change (which actually occurred in 4.02, the current official user release) is to avoid problems with axes, not to create them! ;-) The current official version is 4.02, but that will be replaced by 4.03 when I am sure there are no known problems with 4.023 etcHowever, to make any progress I need information when folks do get problems. So, could you please tell me: 1. Is there an Add-Ons menu containing the FSUIPC entry? 2. Have you registered your copy of FSUIPC4? If yes to those: 3. Have you been calibrating your joysticks using FSUIPC4? 4. Can I see your FSUIPC4.INI file please? 5. Can you, briefly, enable Axis logging (in the Logging tab of FSUIPC options), and use your axes a little, first with a default aircraft, and then with the PSS aircraft, seeing it not respond whilst the default one does? If any of the files are too long to show here, ZIP then up and send to petedowson@btconnect.com. Also, could you tell me, is this PSS aircraft actually one converted to work correctly in FSX, or just one transposed from FS9? I may need help from PSS to get to the bottom of this in any case, so have you also posted on their site -- you can point out that you have me looking too. Regards Pete

That is really weird. Well, I'm glad you have a work-around, but I wonder what on Earth it could be? I don't even know how to detect which mode FS is in! Unless they come up with a Window you have to respond to, and that is hidden in full screen modecould that be it? I get one when I try the driver, but then I've got no Elite equipment, so it is bound not to like it. Regards Pete

First, I don't understand why you included the picture. What are you trying to show with that? Second, all the "Offset" controls are in among the 'O's" in the dropdown controls list, which shows all of the FS controls and all of the FSUIPC added controls. They are sorted in alphabetic order. There are hundreds of controls -- just hit the drop down button then enter "o" in the box to get to the O's quickly, and then scroll to find the right one. Drop-down lists are a standard type of Windows control. You've surely had cause to use one before? Otherwise get back and I'll try to find the appropriate Windows help. Regards Pete

Ah, I've checked. I think they may be getting cleared if it doesn't get a connection. I'll fix that if so. Possibly, as you are using a USB device, it was asleep or not connected one time. Thanks, Pete

Erthere are TWO values for the middle "Set" button. Don't you see them, one under the other? They define the RANGE for the Arm position. You cannot expect to find an exact position which always gives an exact value, and even if you could find it, values vary very slightly all on their own. This is why I carefully prepared numbered steps in the document for you to follow. Please just follow them exactly. This is the relevant one: Regards Pete

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