Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Maybe different levels of WinXP SP2 security updates represent the differences? I notice that these have been trickling through on my auto-updating systems regularly. I'm not sure how to compare update levels between two systems. Maybe only by looking at the list in the Control Panel "Add or Remove Programs" table? If you check the box "Show Updates" it seems to include a whole load of Security and other updates. Alternatively, maybe you could try invoking the Windows Update mechanism manually and make sure your WinXP SP2 is fully up to date -- my main PCs are all on "automatic update" settings, with installation being done at switch-off, so I know they are pretty much bang up to date. Regards Pete
  2. 127 not 27, yes. Pete
  3. Nor me! A peek at some typical lines in a Log would help. But I think to detect negative you just need to check the top bit (0x8000) in the 16-bit value from bytes 2-3 (or the 0x80 bit in byte 3). To do you could either use AND or TEST (if those instructions are supported -- see I just don't remember!) or, considering EPL doesn't have negative numbers, see if the 16-bit value is greater than 32767 (0x7FFF) or the high byte greater than 127 (0x7F). Or do the whole job in reverse by testing if the 16-bit value is either Less than 25 (i.e. 0 - 24) or between 32768 and 32793 (representing -1 to -24). Regards Pete
  4. Where does this "+K" condition come from. there's nothing in the docs like that. The button scanner doesn't scan the keyboard too, they are separate facilities. Well, closer. But there are several problems there: First the button 2,0 will operate your line 24 whether control is held or not, AND line 26 when the Flag is set. Simlarly for 2,1. You need conditions on those too to stop that: 24=CR(F-10,1)2,0,C65879,0 ;Heading_Inc 25=CR(F-10,1)2,1,C65880,0 ;Heading_Dec Next, in the lines 26=CR(F+10,1)2,0,1024,0 ;Heading_Inc_Fast 27=CR(F+10,1)2,1,1025,0 ;Heading_Dec_Fast you need the 'C' still before the control number, thus: 26=CR(F+10,1)2,0,C1024,0 ;Heading_Inc_Fast 27=CR(F+10,1)2,1,C1025,0 ;Heading_Dec_Fast Finally, and this is mainly my fault for not thinking through what I documented: 0=0,10,1003,2561,1004,2561 won't work because, although 0 (null) is listed as a valid code, this is only for key values being sent to FS (from a button push). It's my error for not spotting that the same table is used both for Buttons converting to Keys to be pressed and for Keys being detected. There are some additional KeyCodes which can be used. I'll need to add these to the table: 16 Shift 17 Control 18 Menu Now you still need the shift codes to match, because what will happen is that FSUIPC sees the shift so sets the shift code, ready for matching, then checks both the keycode and shift code against your list of Keys. Thus, to use Shift you need 16,9 Control you need 17,10 Menu you need 18,72 So, if you have: [buttons] 24=CR(F-10,1)2,0,C65879,0 ;Heading_Inc 25=CR(F-10,1)2,1,C65880,0 ;Heading_Dec 26=CR(F+10,1)2,0,C1024,0 ;Heading_Inc_Fast 27=CR(F+10,1)2,1,C1025,0 ;Heading_Dec_Fast [Keys] 0=17,10,1003,2561,1004,2561 then it should all work as you wanted! Regards Pete
  5. I don't think the install path makes any difference, provided you got the installer to do it, not moved it after installation. I never use the default path, it's too long! My FS's are all in places like D:\FSX, G:\FS9 etc. AND shared on the Network. Don't think so. Whilst developing I don't bother to sign my code, and of course each recompile makes a different version in FSX's eyes, so I always have you explicitly tell it to Run this module from this "unknown publisher". I'm still hoping to get some answers or at least some help from Microaoft. Regards Pete
  6. Advdisplay is not supplied for FSX. It isn't even supported or developed now on FS2004. There are new facilities built into FSUIPC and FSUIPC4 for menu displays from the likes of Radar Contact, and ShowText can be used on Clients as before. What are you trying to use Advdisplay for? Pete
  7. I've enabled the Windows XP firewall here, and nothing got blocked in FSX at all. So it isn't simply a matter of "on" or "off". There's evidently more to it somewhere ... Pete
  8. In order to try to find out what this "FSCopilot.dll" is doing to lose the FSUIPC menu entry, I downloaded and installed both FSCopilot and FSInn. Now I have both FSUIPC and FSCopilot in the Add-Ons menu. Interestingly, although FSCopilot put itself at the top of the list in the DLL.XML file, the FSUIPC menu entry is still first in Add-Ons. Whatever I do I cannot either get the order to change, nor make either disappear. I'd be grateful for some more help here, please. How do you do it? Regards, Pete
  9. Yes. There is one. Haven't you looked? Pete
  10. Read data on a Windows WM_TIMER message, or in a TIMERPROC routine established by the Widows API "SetTimer". As for matching it to FS's frame rate, that isn't really possible to do exactly, buty you can get close by doing something like limiting FS's frame rate to, e.g. 20 (in the Options-Settings-Display menu) and having your reads timed to happen every 50 mSecs (probably every 55 mSecs actually, as I think that's the default granularity of the Timers, or at least it used to be in Win98. Maybe it is better now). An "internal user" is one which is running insdide the FS process, so doesn't need the complexity of the inter process communication (IPC) nor the process switching. Internal users are panel Gauges and other DLLs running inside FS. Nothing has to put FS in pause mode -- there's an option in FS to stop it going into pause mode on task switch. Regards Pete
  11. Just one clarification, in case you misunderstand. The same WideFS key will not enable both WideServer 6 and WideServer 7. You'd need to register both. Regards, Pete
  12. Well, all the symptoms reported so far point to some sort of TCP/IP blocking going on, so it will depend on what settings folks have, what third party protection programs they've added, and so on. I've put in a request for clarification to the Microsoft FSX Team. It has to be sorted because, as time goes on, there will be more and more Simconnect client programs and DLLs and there's going to be a lot of unhappy people if there's not a way to plough through the blockages. I'll post here, and probably in an announcement, as soon as I have a decent solution back from MS. Meanwhile, all I can suggest is checking through all the possible things that may block access. Regards Pete
  13. Somewhere way back in this thread I gave a very long folder name, so that's one way to start looking, but if I were you I'd simply use Explorer's Search facility. Search the Windows folder for "simconnect.dll". Pete
  14. Shucks! But then I did give up smoking about 20 years ago, in any case. ;-) I have a sense of Deja Vu here, but for all my other readers, here goes ... Ah, sorry. It just looked SO unlikely. The "My Documents" bin gets so full of junk all the time anyway. Ugh. I always install in its own top-level folder: C:\FSX, or more usually D:\FSX etc -- more efficient if possible to get Windows and FS on separate hard drives, but even separate partitions on the one drive makes regular defragging much more expeditious! And then you can always share it on the Network, no probs. Must be something to do with its location (and a change in the SimConnect loader checker) then, as it all works fine in the sort of install folders I use. Certainly worth reporting, and if it is a restriction it should really be detected by the FSX installer so that you get a "can't install there" message before it does so. Regards Pete
  15. Yes of course. That's the whole point of keeping WideFS 100% compatible! No. Why should there be? Just don't run both FS9 and FSX at the same time! Not that you'd want to (and I doubt that you can). Regards Pete
  16. So what is the problem? Of course. Else it will just sit there looking pretty! ;-) That's what it is for. Sorry, please use RC support for that. You'll need to tell JD a little more than "it simply doesn't work" too. Not sure why you are posting that here anyway -- if you offered to test it for JD, shouldn't you be talking to him? I've run my old RC4.0 or something on FSX, but I really haven't had time to keep it up to date for weeks, if not months. When I am over this "FSX Release Rush" I wll try to get someone to put all the latest stuff on a DVD so I can get up to date. ;-) Regards, Pete
  17. Eryou mean the FSUIPC4 option for AutoSave? Not sure what that's got to do with anything? It's dormant most of the time. Was the first one in the DLL.XML file the FSCopilot.dll? If so I'd like to find out what it is actually doing that can remove the FSUIPC menu entry. SimConnect is supposed to treat each client separately and equally, and it is SimConnect which manages the Menus. I hope FSCopilot.dll is obeying the rules and not trying to fiddle the menus directly as we had to in FS2004 and before. Is FSCopilot freely available? If so where? Maybe I could try it here. If not, could you do me a favour? Somewhere further back in this long intertwining thread I explain to someone how to get a SimConnect LOG. Could you do that, put the DLL.XML back as it was, then try and reproduce the phenomenon of the FSUIPC entry disappearing? ZIP up the SimConnect log you get and send it to petedowson@btconnect.com. Thanks! Pete
  18. Well, it seems very strange that you have exactly the same symptoms as someone with a firewall blocking access, who fixed it by removing that block, yet yours is caused by something else. Anyway, it is certainly now a matter for Microsoft, being a problem between one part of FSX and another. There is no way I can actually debug it. I have written to the appropriate authority in the FSX team requesting assistance on this, and I hope he is returning from holiday this week. I'll get back to you as soon as I know more. Meanwhile please help by reporting your problems by email to tell_fs@microsoft.com. Provide all the details you have provided me. It all helps to get things fixed. On the other question i asked, which is probably not relevant really: Your DLL.XML contains loading instructions for the Object Placement and TrafficToolBox parts of the FSX SDK. You must have installed these. They add menu items in FSX. Are you programming for FSX, that's why you installed the SDK? It is getting very confusing here. there are about three intertwined threads! Regards, Pete
  19. Ah, and I'm afraid I only speak English and C (well ASM too, but less and less). ;-) The settings are the same in both FS9 and FSX cases, yet you say FS9 works fine. The logs show absolutely no communication from the Client to the Server, so all I can think it can be is a firewall preventing access by the Client to FSX. It seems likely that you have given permission for access to FS9 but not FSX. So, can you check that, please? Regards Pete
  20. What about WinXPs? Are the mission_placement and TrafficToolBox facilities working? Mind you, I don't think they actually USE SimConnect, they are simply loaded by it, so it probably isn't a good check. Yes, the log shows FSUIPC4 is running, but there simply is no communication between SimConnect and FSX. There's not even anything I can do in the program to check and report these conditions. All that happens is that it never does what i ask and I see no responses -- even errors are returned using TCP/IP, so if they're blocked, nothing at all happens. Ugh. Me too. I've written to the MS chap in charge of SimConnect to see what the best thing to do is -- if I can program a way around it I will, but it seems unlikely. Meanwhile, I think it simply MUST be some sort of firewall protection which you've not actually managed to disable yet. Please look further, see what you can find. Regards Pete
  21. Hmm. Odd. I've no trouble with the relative path to my FSUIPC4 installed in \Modules. I don't think the path used for this is the SDK install path, it will be FSX's install path. But in Beta2 and Beta3 the SDK was automatically installed into the FSX folder, so the relative path will be correct. In the RTM version, you can install the SDK anywhere. If you didn't install it into the usual place, the FSX folder, then obviously the relative path won't work. Ahthere's your answer. Surely you haven't installed all 8 Gb of FSX into C:\Documents and Settings\Bill\My Documents\Flight Simulator X? Relative paths for FSX are relative to where the FSX.EXE is placed, which is the folder listed in the registry as "InstalledTo" for Flight Simulator\10.0. Regards Pete
  22. I don't really know. Certainly FSX needs to talk to SimConnect and vice versa. Bt what puzzles me is that these are, of ocurse, actually part of the same process. simconnect uses TCP/IP to talk to FSX, even though it is in the same process (for a DLL in any case). I think Microsoft did it this way because it then works with external EXE programs, and across Networks, without any extra interfaces. However, it is confusing when one part of FSX cannot talk to another. I really know nothing at all about firewalls. I use a router for the Internet and leave it all to that. Every time i've tried using any type of firewall I get into all sorts of difficulties on my Network, and it really isn't worth the hassle to me. Please see the message above from Splodge, who had the exact same symptoms and fixed it. Regards Pete
  23. Is there an FSUIPC4.LOG? Does it look a bit like the one shown earlier here? If so, can you disable your firewall? For most of this stuff I am most likely going to have to pass the problems over to Microsoft. It is all to do with their SimConnect interface and its use of TCP/IP. Pete
  24. Ahmaybe the "trusted" block was the only one needing allowing. SimConnect doesn't need the Internet, but it does talk to "trusted" programs like FSUIPC4.DLL via TCP/IP. The thing you'll block on the Internet connection will be the weather. Regards Pete
  25. Correct, which is why I asked for the WideServer section of the FSUIPC4.INI file. Take a look, -- I said The main files I needed to see, which you forgot, are the WideClient LOG (after all, it is the WideClient which isn't connecting, is it not?), and of course the FS9 WideSever INI so I can compare like with like. After all, the same code should behave the same given the same parameters. Please show me the files as I asked, then I'll look and try to work out what the problem is. 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.