Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Get a new SimConnect log please as well. Regards Pete
  2. I wasn't suggesting you did, only explaining that this is one of only two possibilities IF your FSUIPC was working without registration but not with. Regards Pete
  3. No. There is certainly no other case where SimConnect just ignores the entry in DLL.XML and doesn't even attempt to load the DLL. Well, that absolutely cannot happen here, because the code is not even getting a sniff of your computer, as proven by the fact that the SimConnect log doesn't even mention it. It has to actually be loaded into the memory in order to run, and it isn't being loaded. There's something you are not seeing there. Even if FSUIPC4.DLL was nowhere on your PC, the fact that it is called for in the DLL.XML fiel means that SimConnect should look for it, and if it cannot find it it would report it in its log. The fact that it isn't even looking for it really means to me that you are either running a different FSX (one not for the user with the DLL.XML you showed me), or you have been looking at the wrong DLL.XML file. I did suggest some further simple tests you could make, like misspelling FSCopilot in the DLL.XML file, and seeing if it still loaded, and then similarly with FSUIPC4's entry. But you never came back about any of that. If you really do think you have everything correct you really only have Microsoft to turn to now. Sorry. Unless FSUIPC4 can actually run there's no code change in the world that will do anything. And there has never been and still isn't one single other report anything like yours. Regards Pete
  4. You may want to check these past threads on the same subject, all of which were resolved: viewtopic.php?f=54&t=57969&start=0&st=0&sk=t&sd=a viewtopic.php?f=54&t=62944 viewtopic.php?f=54&t=64109 Regards Pete
  5. Ah! you are programming a button! Your last message mentioned the Key Press tab, for programming key presses! In the past this has been 100% due to drivers still installed for joysticks you don't actually have installed. This is especially true for "game port" devices, whose drivers seem to hang when asked to supply readouts for their devices. In Windows (outside of FS) go to the Control Panel (Start-Settings) and select Game Controllers. Find all of the controllers it thinks are there but which are no longer applicable, and delete them. You may have to go to Add/remove programs and uninstall instead, I'm not really sure. There's one other possibility, if you've ever used EPIC there may be remnants of an EPIC driver there. You can make FSUIPC bypass that by adding PollEpicButtons=No to the main [buttons] section of FSUIPC4.INI (add that section if you haven't already got one). Regards Pete
  6. In that case it sounds like the two PCs are not in the same Workgroup. You should put them in the same workgroup, then connection is less hassle and can be automatic. The Server broadcasting doesn't work across different workgroups. I'm not sure where you change it in Vista, but in XP right-click "My Computer", select Properties then Computer Name. You'll see the Workgroup name, which can be changed by pressing the "Change" button. You'll probably have to re-boot. Okay. I see. One or both of the keys you are using is invalid. It is either pirated, or it has expired, or it was issued AFTER the current date set in your Server PC. The last is plainly not the case because WideServer reports: Date (dmy): 28/10/07, Time 12:22:00.063: Server name is SERVER Everything else is fine. WideFS is working, but FSUIPC is refusing to cooperate with any applications because it believes it is being used with invalid keys. If you think your keys are valid, please ZIP the Key file, along with any prof of purchase you can find, and send them to me at petedowson@btconnect.com. Regards Pete
  7. Never heard of FSIP200x. But it doesn't matter. What I need to see (as always) are the Log files. There will be a WideServer.Log on the Server and a WideClient.Log on the client. I see from your WideClient.INI file you have specified these: ServerName=server ServerIPAddr=10.0.0.100 Protocol=TCP Why? Are you using Windows98, not XP? If you are using Windows XP all round you can let WideFS connect automatically. Also it is redundant to provide both the IP Address and the Server name -- the Name will be completely ignored. You are best only giving the name, in case the IP address changes. All these things are explained in the documentation provided. Additionally, I notice this in the INI: [user] Log=Debug Why are you specifying Debug logging (making a HUGE file) here, yet not even bothering to look at the Log when you have a problem? In the first instance, I don't want to see Debug logging as it is far too much data to wade through. Please change that back to "Log=Errors+", or simply delete it so that defaults. Finally, ALWAYS provide version numbers. If you are not using the currently supported version of WideFS (6.75) or later, for both Server and Client, please do so first, and test again. Oh, I need to see the FSUIPC.Log from the Server too, please. A complete one, after FS has closed. Regards Pete
  8. "Registered" version? There's only one version! You register it by entering a key you purchase from SimMarket. It doesn't "become a different version". If things work fine without the Key (remove the FSUIPC4.KEY file from the Modules folder), but not with it, then there's one of two things wrong: 1. Either your system date is earlier than the Key purchase data, making it look illegal, 2. Or is is an illegal (pirated) key. If you believe it is neither of these things I need to see a complete FSUIPC4.LOG file (i.e. run FS and close it), as well as the KEY file. Don't show them here. ZIP them and send to petedowson@btconnect.com. If the same problems exist with or without the KEY file, first try version 4.203 from the FSX Downloads Announcement above. Regards Pete
  9. Sounds like they are installed in the Program Files folder, which is protected in Vista? Or maybe they need to write to somewhere in FSX and that is installed in Program Files too? The FSUIPC4 Installer makes the Modules folder read/write by all comers, to avoid problem with FSUIPC writing its INI and LOG files. Best really to install all non-Vista aware programs outside Program Files. Regards Pete
  10. No. It's just another control, like all the others. Sorry, I'm lost. I didn't mention mapping to keys. You did. And what are WideFS form keys? Regards Pete
  11. I only just noticed, you are trying to program a BUTTON! Not a keystroke! So why on Earth are you going "to the FSUIPC Setting Key press tab"????? Pete
  12. Sorry, I cannot understand any of that. Let's take it step by step. You "go to the FSUIPC Setting Key press tab", right? So you have displayed the part where it says "Press set, then the keys you want to program". But then you say "then I click the button I want to program". What? You must press the "Set" button first! If you do that, the words "PRESS KEY" come up with a white background in the edit box, and when you press "shift+C" it displays "shft+C". Are you following this? does this happen? When you say "nothing happens", doesn't "shft+C" appear in the edit box for the keypress? Can you help me at all by describing anything in more detail? sorry, but I have never heard of anything like this before! Did you report it? I don't remember! Sorry, but I don't understand any of that last part. Can you describe things slightly more, er, understandably? Regards Pete
  13. Since both FSX and FSUIPC4 (not to mention SimConnect) are 32-bit programs, I am really at al loss to know how a 64-bit operating system can affect it so. However, I need (as always) to see the Install FSUIPC4.log and the FSUIPC4.log files, both from your FSX Modules folder. Your problem is probably nothing to do with whether it is 32 or 64 bits, but whatever it is the first steps are there. Regards Pete
  14. No problem. I wouldn't have thought of that either! ;-) Pete
  15. Could you first try using Logging and/or FSInterrogate (the tools provided to investigate such things), to check what you are reading to what is provided? BTW I've just re-checked, and both ground altitude and aircraft altitude read-outs are still fine. (There's actually no reason why they shouldn't be as it is all down to Simconnect these days! ;-)). Regards Pete
  16. Good. Glad it helps, and thanks for the feedback. Incidentally, I had to make interim releases anyway, without waiting for confirmation, so those two links I gave you are now wrong. You and others needing this fix should get 4.023 or 3.766 from the Download Announcements at the top of the Forum. Regards Pete
  17. :roll: Of course not. What would the key be used for if you are writing to FSUIPC directly? What would be the use of a key press or a button if it were never used? Who would see it and act on it anyway? Please look up offset 3110. I get the feeling there's a serious misunderstanding here of what the FSUIPC application interface is all about. Please tell me you understand a bit about it, else we'll have to go to absolute basics! ;-) Regards Pete
  18. As I said "I've managed to reduce the stuttering, but i fear it may also be less effective." In tests here I'm getting fewer severe windshifts, but they are still there. On most flights there have been none to upset the autothrottle or anything. The worst ones with the default settings were at most around 110 degrees, whereas before they were often 180 degrees or close (the worst they could be). Most I've seen have been 40-50. If, in the Logging, you enable "Extras" (or set it to 1 if you have the Edit box showing), each significant occasion of Wind Shear will be logged, like so: 2124468 **** WINDSHEAR: prev ambient wind = 345/34, new wind = 257/34 The only way to make it acceptably effective, I think, (yet still not foolproof) is to reduce the delay to zero AND maybe including the Global weather. In other words, change these two parameters in the INI file (defaults shown): WeatherRewriteDelay=10 ProcessGlobalWeather=No I've not found a Delay of 1 to be noticeably better than 10, but do please try it and let me know. The best would be 0, but then you will certainly notice stutters. And it is probably best to ignore the Global weather part -- for proper graduated visibility it seems that is definitely needed, but the stutters are unbearable. Also, seeing as the other problem is the time taken to scan and update the nearest 9 stations (one of which may have therefore updated its weather 9 x update period ago, or maybe 18 seconds), if you can make it scan and update faster it should be more effective. The problem then is the performance hit. The default period is controlled by the parameter at the bottom left of the Winds page, which is this in the INI: WeatherReadFactor=2 You can change that to 1 for the fastest scan rate, halving the possible lapse before FSUIPC picks up new WX from a station. But take care not to slow down your FS frame rates. If you install Acceleration (or SP2 when it is released)* it will be twice as fast in any case ("2" will give 1 second instead of 2), so setting it to 1 gives a maximum scan, hopefully, of about 5 seconds per station. I suspect then that a delay value of less than 5 should be about an optimum for stutters versus wind shear effectiveness. As for trying to detect the weather at a station before it is set at the station, I'm afraid that's impossible. I was hoping that, by changing the weather at stations as far away as 40 nm the weather would be under control by the time you got there. The very nearest is actually processed twice in the scan (so really making each scan 10 stations). Experiment. Let me know. I can change the defaults if you find better values. Ideally I would like to just process the 3 WX stations which are contributing to the weather at the aircraft, but at present I can't identify them. If I could I could keep them all under watch every couple of seconds. And maybe use a delay of 0 (for one small stutter?) when one of the three changed. * You said "within FSX SP2". Did you mean SP1? SP2 isn't available yet. Or do you mean Acceleration? Regards Pete
  19. Yes, of course. If is an FSUIPC-added control with a published control number. You can send any FS or FSUIPC control via offset 3110. If you want to Zap specific aircraft your own code selects from the FSUIPC TCAS tables, that facility, to do it with the aircraft ID, has been available for several years -- see the Programmers Guide. Pete
  20. So, as it works fine with all the default planes, how do you work out the specific Level-D 767 problem is "something to do with FSUIPC"? You seem to have successfully proven otherwise! Or am I misunderstanding something? Regards Pete
  21. Actually 60905 (means "5th September 2006") was the first release, last year, not SP1A. Regards Pete
  22. It won't be FSUIPC giving you a CTD. Look elsewhere. Probably video driver. If you want any further help you'll need to be a lot more specific. Details, logs, etc. Pete
  23. Aha, so there is a function for it! That's good, and I did really think there should be! Well done, Pete
  24. Yes, that will work (though you should add a zero character to the end -- if you don't any previous longer message will leave part of itself appended to yours when displayed). But: it is not very efficient. Each time you add another character you are creating another "write block" with a 16-byte header. That makes the data being transferred nearly 17 times larger than it should be. Worse, when it gets to FSUIPC, each of those writes is processed separately, taking valuable FS processor cycles. Better to formulate the string correctly in your own area first. If VB doesn't come with a way of converting its strings for normal Windows API ASCIIZ format already (which would surprise me), then declare a work area as an array of 128 bytes and do the loop for the string length preparing that array. Add the zero at the end, then do the single FSUIPC_Write from the array with a length+1. Regards Pete
  25. Further to this, I have now added code to FSUIPC4 to check that the full pathname for the SimConnect.dll I connect to contains "WinSxS" (to show it is from the Windows side-by-side folder. However, in trying to test it, I placed each of the versions of Microsoft.FlightSimulator.Simconnect.dll I can find (Original, SP1 and the new Accelerator version), one test at a time, into the Modules folder alongside FSUIPC4, and also even tried them with the name stripped to just Simconnect.dll, and in no case did Windows supply anything other than the correct WinSxS version. So I don't understand what happened in your case. Are you sure there was no other file in there, like the .manifest file or any SimConnect.xml or cfg file? [LATER] EUREKA! I managed to make it do as you did -- on Vista! It doesn't go wrong on WinXP. It is evidently a new Vista bug/deficiency! Anyway, now I can test my "check" for this. Unfortunately I cannot make FSUIPC4 actually work with this hapening, all I can do is log the incorrect SimConnect details and say it should be removed. Thanks, 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.