Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Really? And to the value you expected? If so, could you tell me what weather you started with. Was it downloaded weather or a weather theme, or something else? There's so many compbinations to test I've not been through them all. But I remember getting weird results when trying to apply changes to downloaded weather ... Regards, Pete
  2. Not that I know of. You'd have to go to the Weather menu and re-request downloaded weather. I think it does it there and then. If this is with FS2004 I think you have to go into the weather menu each time and tell it to download weather, but you could try selecting that then saving a new Flight as your defalut. It should work, but I think it doesn't in FS2004 -- it works fine in FSX. Best to get everything ready before you climb into the cockpit, or maybe use ActiveSky or FSMeteo? Regards, Pete
  3. The "ARM" zone can be as large or as small as you like, but get it working in a default aircraft -- more complex aircraft may be interfering with their own control. Sorry, I don't really understand what you are doing or saying there. I cannot even envisage where you are reading these numbers, except for in an out -- the Centre number, where you seem to say you have "1" is merely a default. YOU have to calibrate that for the detente number shown above (#1 to start) -- and there are TWO numbers for centres, not one, it is a RANGE of vlues, not one value! Let's start from a known position. Calibrate your flaps axis just like any other -- don't try detente setting yet. If you already tried things, press "Reset" then "Set". Set your flaps up as "Min", full flaps as "Max". Make sure you leave a little room either end for slight variations. Put the axis back to flaps up, press the "Dt" button. You should see the #0 #1 #2 labels at the top. The entre heading indicates it is ready to set detente #1. Move the lever either side of the first detente and set the "centre range" in the column. Make sure there's enough space either side to cater for variations. Use the scroll buttons above the centre values to move to #2, and so on. Don't worry about the IN and OUT values. All you are concerned with is setting a series of "centre" values, a pair for each detente. Regards Pete
  4. Did you enable changes to FS weather (in the Miscellaneous tab)? They then may have an effect, but weather changes in FSX take timesometimes a long time. And then, the effect you get may not be what you want, and in some cases the results are awful. Even, without FSUIPC4, just doing somethnig simple like selecting a stormy overcast theme after having clear weather doesn't appear to do what you ask, for a long time, and then the clouds seem to appear left, right and rear, but never in front out of the cokcpit view. Very confusing. I've had rain when flying ABOVE all the cloud layers, and rain in a clear area with distant clouds only. And this is with the default weather facilities, no FSUIPC4 at all. Add more unpredictablility because the METAR strings sent to FSX by FSUIPC4 (or other programs) aren't interpreted properly, and it gets very hard to understand what is going on. Just like UK weather, notoriously unpredictable! They need the weather facilities in SimConnect fixing to work properly. They were broken in Beta 3 but MS didn't have time to fix them before the user release was forced on them. I was informed they had the top priority for fixing in the first SimConnect update, whenever that might be (this year I'd hope), but now that there are all these much more severe problems with SimConnect's TCP/IP usage conflicting with so many third party security programs I suspect that the weather fixes may take second place. When they do work as specified they will be better than anything we've had before, but at present the results of trying to write weather data into FSX is rather, er, experimental, as I said. Considering the problems, ActiveSky does an excellent job, and it is probably rather more reliable than trying to modify FS's own weather at present. Regards Pete
  5. Yes, Windows XP does this with ALL EXE and DLL files (and some other types too), since some recent security updates -- very recent too. A bit of a shock. Even I had to seek help to extract and install such files, but once you know you won't forget: You need to "unblock" the ZIP (in this case) -- right click on it, select Properties, and then Unblock. This will happen with all downloaded files from now on. It may even apply when copying files from one PC on your own network to another. All part of Microsoft's security improvements to protect you from yourself. I have a feeling that in Vista you'll need to ask your own permission to do anything at all! Regards Pete
  6. It is known. There are at least two other threads here about it. I was supplying an interim fix (4.021) but now I am up to 4.022 and I'll post that up in the FSX bits and bobs announcement above, later today. Please download that and install it and you'll be fine. Sorry for the inconvenience. Pete
  7. Ah. I think you needn't look any further. The chaps at TRC in their wisdom have checked the version of FS in their driver and decided you aren't allowed to use it in FSX. It would be but a moment's work for them to make the small change needed to remove such an unnecessary check. Maybe it is there for a reason? Maybe they want to charge more for FSX use of their gauges? I don't know, but if I were you I would ask them. Regards Pete
  8. If their driver doesn't work at all with FSUIPC4 then it sounds like they are doing something like checking the FS version and simply not working when they see it isn't FS9. Enable IPC Read and Write logging in FSUIPC4 and run the TRC driver. Let me see the FSUIPC4.Log file and we'll see what they are doing. Pete
  9. Do you mean me, Peter Dowson (not Dawson)? If so, then I've never done any drivers for any Simkits. They interface to FSUIPC -- they probably mean the FSUIPC Beta for FSX Beta, but FSX was released over a week ago and FSUIPC4 (non-beta) was released at the same time. Regards Pete Dowson
  10. Do you get a proper crash information dialogue, with the option to send it to Microsoft? If so, please do so. If not please report this via the tell_fs@microsoft.com email. Give them as much detail of your video hardware, drivers and settings as possible please. Then try other drivers, later ones if possible. FSUIPC4 isn't actually doing the switch you see from FSX's normal display to the black background, on which my program then draws the option dialogue. That's actually a function of SimConnect's facilities to allow dialogues to be displayed in full screen mode. It sounds as if there's a conflict with the particular video settings, card or drivers on your system. We need to get information on all these sorts of bugs to Microsoft in the hope they'll fix them soon. This is, so far, the only report I've seen of this particular bug so your information is even more vital. Until Microsoft can find a solution then I think we will have to look at work-arounds. One of them is to go into Windowed mode, as you've found. On one of my systems I have to use Windowed mode for all flights (with or without any add-ons like FSUIPC4) because otherwise after about 5 minutes of flying or less FSX zaps itself irrecoverably into the Task Bar and won't come out again. I've not got to the bottom of that yet, still trying things. If everything else is okay at present and you can use the Windowed mode on the few occasions you need to go to FSUIPC options, then I should carry on that way. Otherwise you could try different drivers and different settings (i.e. different anti-aliassing levels, filtering, etc -- options in FSX as well as in the video drivers). There may well be a good combination which doesn't cause the crash. Regards Pete
  11. Okay, so FSUIPC4 definitely hasn't run. There won't be a log file just because you install. Did you also run FSX? FSUIPC4 makes the Log file when it is started, and it records the menu addition (at least since version 4.02). Please confirm you did actually run FSX after installing FSUIPC4? There's no FSUIPC4 entry there, which is why it isn't loading. However, there is also no FSCopilot entry there, so FSCopilot can't be loading eithereither that or you are looking in the wrong folder. There's nothing in that DLL.XML file that's any use to you at all UNLESS you have installed the FSX SDK and need to use any of the SDK tools this runs. Please either delete it or rename it ("olddll.xml" say) then try installing FSUIPC4 again. If you don't see a new DLL.XML file then I think you are looking in the wrong place. Please tell me the path in that case. Regards Pete
  12. If the frame rate is too low for too long the auto-restart might be kicking in. But it should keep reconnecting then. Try changing the "RestartTime" parameter in the WideServer.INI to 0 to switch that action off. Whether this is the problem or not can easily be seen in the Server's Log. If it isn't this I'd need to see noth Server and client logs. Regards Pete
  13. Meanwhile I've done assorted tests here. With FSUIPC4.DLL specifically marked 'Read Only' I can get the error, but I cannot specifically mark the modules folder "read only" -- it has a sort of gray tick in the "read only" checkbox, which I can change, but it is always there again afterwards. I've no idea why -- this is new with recent XP securtity updates I think -- but it certainly didn't stop the Installer. So I think your original problem was something else. The pointer in the error message to "read only" is only because that seemed like the most likely reason Windows would stop the Installer overwriting the older file. One other possible reason for it to fail is that the file was in use at the time. Possibly you had terminated FSX and it didn't appear to be running, but something in it hadn't closed. That would prevent the Installer changing the file for sure. You can check for this condition by using Ctrl_Alt_Del and looking for "FSX.EXE" in the Process list. If you find it, terminate it (button bottom right). That sort of thing happened sometimes with FS9 -- certain add-ons left threads running. In FSUIPC4.022, which I may release for testing or wait and release it as 4.03 tomorrow or Friday, I am reporting the actual error text which Windows provides me. I am also detecting 'Read Only' beforehand and temporarily changing it to allow replacement, then restoring it afterwards. No, that certainly isn't necessary for attribute changing. It would fix an FSX.EXE still running condition though. Regards, Pete
  14. The FSUIPC4.LOG file in the FSX Modules folder. It sounds like FSUIPC4 isn't being run. There may be no LOG file there -- proof positive. Did you install FSCopilot after FSUIPC4? Would you know if you or it copied a file called "DLL.XML" into the same folder where FSX.CFG is? If so then the install of FSCopilot has overwritten the install data for FSUIPC4 -- that's very naughty of it if so. Let me know so I can write to the authors. To recover, re-install FSUIPC4. The FSUIPC4 installer ADDS itself to the DLL.XML file, it doesn't replace the file, so it retains any other installed DLLs. Pete
  15. All of the changes in FSUIPC have always been published in the History document. For FSX this is iinstalled for you when you install the update. For advanced information see the appropriate Announcement above -- the one about FSX stuff tells you about the changes from 4.01 to 4.02. Pete
  16. I've checked tihs, and it is still as I thought in FS2004. As far as I can tell the code in FSUIPC is correct. I tested writes to 0C3E with the Cessna loaded, and using only FSInterrogate. All the writes had the desired effect, directly and with no problem. Certainly no alternating of values as we see in the log you sent. Please check it yourself using FSInterrogate. In order to take this further, if you should still think it is not your program, please supply the log with not just the monitoring but also the IPC reads and writes, so I can see what you are doing in FSUIPC. Regards Pete
  17. Good. Thanks for letting me know. Meanwhile I have streamlined a few internal parts of FSUIPC4, I hope without messing anything up. It may or may not help a little -- here, where I had about a 15% drop using FSUIPC4 I get hardly any difference, just slightly more variation. After some more testing I'll probably release it as 4.03, certainly this week, maybe before the weekend this time. I know MS are working on it, at least to find the more serious problems like lack of Add-Ons menu and so on. I hope they will be able to address the perfomance issues too, but I won't be holding my breath on that! Regards Pete
  18. Can you show me the FSUIPC4.Log please? You didn't see this note in the Announcement above then? Also, temporarily try removing the FSCopilot DLL and see then if the FSUIPC entry appears. Show both FSUIPC4 Logs please. This is sounding like a bug in Simconnect's menu handling -- there was a report in the other "No Add-Ons" thread about the FSUIPC entry sometimes disappearing when FSCopilot was loaded. The gentleman changed the order of the two in the DLL.XML file and it was okay then -- but that shouldn't be needed. I did download FSCopilot, and even FSInn, but I couldn't reproduce this problem here. Maybe you actually have to use them as well. I'll need info so I can report it to Microsoft. Please als oreport it via tell_fs@microsoft.com when we've done a couple more tests. Regards, Pete
  19. There's no option. FSUIPC4 will only install in FSX. It won't see FS9 and cannot be installed into it. FS9 and FSX will not interact. You just cannot run them both ast the same time on the same PC. WideFS clients will connect with whichever is running at the time. You need no changes that end. Regards, Pete
  20. Unfortunately, whilst you did correctly Monitor 0C3E for me (and very odd it certainly looks), you forgot to enable IPC read and write logging as requested. I wanted to see the relationships between what you wrote and what was happening to 0C3E. So, could you do that, please? Whilst you are at it, please enable Event logging too. Looking in the code I see that there is no direct way to set the drift, or at least I couldn't find one. The code I have actually uses the FS control GYRO DRIFT SET. [Later ....] Hmmm it isn't just a matter of using this control to set the absolute value of the drift amount. It looks like the value which has to be set is the DIFFERENCE between the current value and the one required. Or at least it looks that way from the code I have. It is quite possible that this was true in FS2002 but fixed in FS2004. No one has mentioned any problem for the past 3 years, but maybe you are the first one to actually write to this offset in FS2004! Looking through my History document, I see that the last change in this area was this: That was in FSUIPC 2.96, one of the later versions for FS2002. Looking at the Monitored values it does seem plausible that this was changed in FS2004 -- if so then I'll need to change FSUIPC as well. I'm out tonight. Meanwhile, do you think you could assign a Key to the GYRO DRIFT SET control, with a non-zero parameter, and see if it changes it correctly? If so then I'll change FSUIPC to do the same. I'll try it myself later, but it will be in the wee hours or tomorrow morning now. Regards Pete
  21. I don't have a Server, and in any case FSUIPC doesn't go on-line. The email address you used when you purchased the Key is irrevocably tied with your name to the Key. The three go together as a totally unique tracable identification. The actual email address doesn't matter as it isn't used for email, only to identiy you. Folks with no internet connection would use the first line of their address, for instance. You must ALWAYS use exactly the same details as notified to you when you got the Key. Not just the email address but your name too, to the letter. It does say this someplace. Regards Pete
  22. Now you explain it, yes. It is the same problem as reported in another thread. I fixed it and am trying to put a release together this week. It is only a problem with unregistered installs of FSUIPC. See your email. Pete
  23. Yes. It's exactly the same as in FSUIPC 3.709. I have no idea what is going on there and I cannot even picture it. Can you show me your starting settings in the INI file please (only the JoystickCalibration sections), and then ennumerate step-by-step what you do and what you see so I can try to replicate it? I'll also need to know your "ShortAircraftNameOk" parameter setting. SimConnect itself won't be able to mess up the way the dialogue works. It is needed to supply the aircraft name, though, and of course forward the joystick values for calibration -- unless you are assigning those directly via the FSUIPC4 axis assignments. Let me have the info and I'll try to work out what is going on. Regards Pete
  24. I am sorry but there is no way I can or will support such an old version! The current version is 3.70 (or you can get 3.709 in the Announcements above -- that will be released as 3.71 soon). Answers: - No - Don't know - Don't know - Only if you use the currently supported version. Please re-test with that. If you think there is still some problem I'll want a suitable Log file with IPC reading/writing and 0C3E monitored, please. Regards Pete
  25. Yes, I get that too. Not always, but most of the time. I've not yet found a solution, and I'm afraid with all the Simconnect support I'm having to do at present for Microsoft (it seems :-() it isn't high on my priority list. It's something to do with the way FSX closes down much faster. PFCFSX is certainly still tyring to send the code sequences out to the device (there's a whole sequence of them, for each display part), but it's getting killed. With my connection to FS via Simconnect now being asynchronous, it looks like by the time I get told that FSX is closing there isn't enough time -- the serial buffers are purged when the process disappears, and that's that. Similar problems will occur with WideFS's "shutdown" facilities for Clients. It isn't a "PROBLEM" in capitals as you maintain, just an annoyance. Until I can find a way around it I suggest you switch the aircraft's battery off before closing FSX. I may have to create a special thread which doesn't die for several seconds after the rest of FS, but, I'm sorry, there are more urgent things to do first. I have a similar problem in trying to find a way of rectifying FSX's omission of a "Previous Flight" facility. I like to pick up my aircraft from where I parked it at the end of the previous session. In FS9 and before it was easy -- just set "Previous Flight" as the default. FSX doesn't save one. I would like to save one automatically from FSUIPC4, but, just as for PFCFSX, by the time I can detect that FSX is closing, it is too late! I have a request in with Microsoft for an earlier notrification. Regards Pete
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.