Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. But that should have been okay. The FSUIPC installer checks to see if there is a "SimConnect.xml" file, and if there is it checks to ensure there's a "local" section. If there isn't it adds that minimal one I showed you. The problem with the xml file you made was that it said it was "local" but had non-local settings in it. It isn't easy to design an installer to cater for every possible error folks might make. This is why I'd hope those products which use SimConnect.xml would either come with decent installers for it, or at least with documentation adequate to get the file made correctly. Okay. That's good then. Regards Pete
  2. This section: False IPv4 local BRUNO-PC 64 500 4096 False says it is "local" but then gives PC name (address) and a port, neither of which work for local clients. Change local to global. That is NOT a local section. When you run FSUIPC4 install again it will add a basic minimal local section, which looks more like this: False Auto local Or you can add that yourself if you like, before the final Doesn't ASX support help with the installation at all? Regards Pete
  3. Departure airport of what? Your own plane? Sorry, but I don't think there's any way of getting any information about your own aircraft's routing unless you've filed a Plan, and then it is only what might be obtained from the GPS data, which is a bit iffy as far as I've seen. Most programs which deal with this sort of thing do so by checking the nearest airport in a data base, using the aircraft Latitude/Longitude which you can read quite accurately. Again, from the Lat/Lon, and using a database of Gates created from a scan of the BGLs containing AFD information. You are most welcome to use my MakeRunways utility which creates such databases. See the Downloads announcements above. Regards Pete
  4. You don't say what versions of Windows you are using, but possibly the Client isn't Windows XP or later? Either that or they aren't both in the same Workgroup. You should add the ServerName= and Protocol= parameters to the WideClient.INI file, as described in the documentation, because the client evidently cannot see the broadcasts from the Server. All that stuff is only possible automatically on later Windows operating systems with all PCs in the same workgroup. Really you should have found this out by reading just a few pages of the WideFS User guide. In the section "Configure your Network" you will see this quite clearly stated: Incidentally the current, supported, version of FSUIPC3 is 3.75, not 3.74. There's also a version 6.75 of WideFS out. Neither will make any difference here, but you should really keep up to date as far as possible and certainly before asking for help, just in case. Regards Pete
  5. From the Log it is obvious FSUIPC has started, but Simconnect is not connecting to FSX. That is because FSUIPC is trying to get SimConnect to connect again every 5 seconds. There's the problem then -- you've got an incorrect SimConnect.xml, one which probably enables "global" connections to Simconnect (the "global" in that file actually means "remote"), and stops all local connections. Maybe re-installing FSUIPC will fix it. If not you will have to edit your SimConnect.xml file. To reinstall FSUIPC you will first need to delete version 4.115 from the FSX Modules folder, as it is later than the one the Installer currently provides. You can put 4.115 back afterwards (or 4.116 which will rpobably be up by then). I would hope that programs like ASX come with documentation for remote connection which explain this properly. Did you check? Regards Pete
  6. Hmmm. Very nice of them to get me more sales, but you'll need to ask them why. Have you tried without? Maybe they are just being good to me? :-) Regards Pete
  7. I don't have the program so I don't know. That is certainly one way of doing it -- a complex install, but certainly achievable. There are examples about in C or C++. I have heard of folks doing it in Delphi. but C#? Seems very unlikely to me. As a hint, FS Gauge files (when programmed in C/C++) are DLL's in all but name. I've no idea about these new-fangled XML ones though. For FS9 and before, the only real difference between a loadable DLL in the modules folder and a GAU file loaded via a PANEL.CFG declaration is its name and position. The rest is mere detail. Those of us that have written DLLs have started from that viewpoint. FSX is different. You need the FSX SDK. Check the SimConnect SDK section. Regards Pete
  8. Which it is by default with a registered FSUIPC. It just means all axes pass through FSUIPC before they get to FS, just as happened with FS2000 through to FS2004. If LevelD doesn't like this it must mean they are capturing the same controls but at some intermediate priority between the one FSUIPC captures them at and re-transmits them at. Which would be a bit weird if you ask me. I'm afraid to sort this out properly, the appropriate developer in Level D will need to contact me and discuss SimConnect details. Regards Pete
  9. If your application is not part of the FS process, which it is not, then you can only do what you want if you run FS in Windowed mode. You simply use one of the standard Windows APIs to gain foreground status (bring window to top, or similar). If FS is running as a full window application it effectively "owns" the screen, and there is really no way you can get Wnidows space short of minimizing it (sending its Window a minimise command). The other programs you mention are written as FS components, DLLs, like FSUIPC, so they are inside the FS process and can get Wnidows displayed. However, it is still very difficult to get anything displayed with FS still running -- you get flashing whilst FS displays new frames. I'm not sure how some manage. If your display involves 128 characters or less you can use the Messages facilities in FSUIPC (see offsets 32FA and 3380). Radar Contact uses these facilities for its menus. For FSX SimConnect does offer a fuller menu facility if you use it directly instead of going via FSUIPC. Regards Pete
  10. Just so I understand a little of this, you have "NoAxisIntercepts=Yes" set as well, still? If so, if that is omitted, even though you are calibrating axes directly, does the problem still exist? I'd like to understand why, though. I wonder what is special about their implementation which would cause such problems. Regards Pete
  11. Yes, that's fine. SimConnect doesn't look to be playing up. Are you calibrating the Throttles via FSUIPC? I seem to remember in the FS2004 versions of some add-on aircraft (e.g. FeelThere ERJ145) you had to select the "exclude THROTTLEn_SET" option on the 4 throttles page when using that for calibration. Otherwise I can't imagine how there'd be any conflict. If you don't calibrate through FSUIPC is there still a problem? If so, you could further see if is still the same if you close FSX and add "NoAxisIntercepts=Yes" to the [General] section of FSUIPC4.INI before reloading? As it says in the FSUIPC4 Advanced User's guide: Mind you, if you had delay problems with axes you'd surely have noticed these before you added the LevelD 767? I'm really not able to go any further with this without knowing what the LevelD aircraft is doing. I don't suppose it is even using FSUIPC these days, is it? Is there any answer on the Level D support forum, which I assume they have (still locked to others by the look of it?). Or do they do support by private email now? Regards Pete
  12. What does the FSUIPC4.LOG file (in the FSX Modules folder) show? If SimConnect is playing up t may be installed incorrectly, so possibly a SimConnect log would be useful too. Please see the FSX Help announcement above. And what do LevelD say about it? Regards Pete
  13. Thanks, but I think it will be the "Shortcut" and "Advanced" tabs which might help. Pete
  14. Sorry, you are really confusing me now. I don't understand any of that. I replied this to you in an earlier message when you referred to "the slot": For any use of any slot it needs to be free first, otherwise it is not free! Isn't that plain? A slot which is used is not free for other use. But why ignore the statement "find a free slot", which is step 1 in the instructions for implementing the Menu part? And it also clearly says "The application must search through to find an empty slot" early in the section on hot keys. I really don't see how much clearer it could be. State what things? That "the menu facility is not the same facility as the hot key facility, this is why they have different names and different sections and different methods, and in fact do different things"? Sorry, I really think that since they are different in every way EXCEPT using a slot (a FREE slot), there should be no reason to point out that they are different. Surely you can see that? Pete
  15. Aha. There must be something about your Icon then, some property it has which causes the entry to be suppressed! Could you right-click on it and select "Properties" and tell me what it says. It is a short-cut to FSX.EXE I hope? You first need the FSUIPC SDK from http://www.schiratti.com/dowson. there are examples there for several languages. The supplement for FSX is in the FSX downloads Annonucement above, but to do what you want to do would be the same for any version of FS. For FSX only you could of course also consider writing directly to the SimConnect interface. For that you need the FSX Deluxe edition, install the SDK and check the SimConnect documentation. Note that if you have installed the FSX SP1 update you also need to get the SDK SP1A update. Regards Pete
  16. Why are you mixing hot keys and menu entries in one slot? You can't operate the Menu and a hot key from the same slot! There are many slots. You have to find an empty one for each hot key and each menu entry! They are separate things! The FF tells FSUIPC it's a menu reference, otherwise it's a Hot Key reference! The two facilities are even described in separate sections. I cannot understand how you are misreading it all so strangely. Pete
  17. The FSX icon, or the FSX.EXE. FSX has to be "run as administrator", as documented. Really, there's no Run As option when you right clcik on the FSX icon? Try the actual FSX.EXE in the FSX folder. I have Vista Home Premium and that certainly always shows this option. Are you running as the PCs ordinary administrator, or have you created another user and running as that? They are okay, nothing wrong with them. Regards Pete
  18. Try the User Guide. There's a boxed section specifically covering these, in the Buttons section. Just try searching for Increment or Decrement. There won't be that many matches. Regards Pete
  19. Yes. Not "the slot". You need to search the array of slots to find a free one first. Read the whole block in, search for a free one (zero), and use that. This avoids trampling over other program's settings. Oh dear. The FSUIPC Advanced Users guide is part of the standard documentation Users get when they download FSUIPC. It always has been. Do you have FSUIPC? That's why it mentions "users" -- all users get it. There's an "easy" User Guide and an "Advanced Users" guide. The latter documents keypresses, INI parameters etc etc. Regards Pete
  20. Good. Thanks for confirming. Regards Pete
  21. Hi Dave, Thanks for the clarification. Not sure where the message comes from, though, because FSUIPC3 would never get loaded by FSX. Best Regards Pete
  22. How strange. I don't understand that. Maybe the low level keyboard driver only handles the synchronous keyboard requests (which FS may use for the flight controls) the the main keyboard. Hmmm. Interesting. When the ATC window is open, nothing happens but if you close the window, press any of the buttons & then open the window again the function is actioned. That'll be because of the Windows message queue processing -- the ATC Menu control will be sent and sit in the queue. I'm assuming it is a bug, because it seems a pretty serious drawback for a keyboard flyer (yes, there are still some who prefer the keyboard for flying!). I'm asking questions now via my contacts. If I hear anything useful I'll let you know. Meanwhile it would be a god idea to report it yourself, as I suggested. Regards Pete
  23. Since the author confirms that FDC doesn't produce such a message, you need to be more precise about EXACTLY what the message looks like and WHEN it actually occurs. Please write down what you are doing, step by step, and exactly what you see. Maybe a picture would help. Pete
  24. I think the SDK installer installs the SDK in a fixed standard place. There's a utility someplace in the package which you run to fix the paths. The Modules folder is inside the FSX path, so that part can be omitted -- FSX assumes that bit if a complete path isn't given. Strange though. Having the path wrong shouldn't have made SimConnect fail locally, it should simply result in the incorrectly pathed modules not being loaded. They are optional in any case. What is much more likely is that the paths were/are valid, and point to older versions of the Modules, from the original FSX release. But then I thought those wouldl actually crash FSX if loaded. So when you were testing with and without FSUIPC4, you weren't doing it the 'easy' way, renaming or moving the DLL itself, but by doing something with the DLL.XML file? Anyway, glad you got it fixed in the end. 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.