Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. ypu have a "COM3"? That's unusual. Doesn't that use a Network connection? If so, then the COM ports, if allocated to Windows as a Network will not be usable for normal serial port connections. They are "owned" by Windows. The Network connection doesn't just start when you run Instructor Console and stop when you stop, it is owned by Windows for the entire session. Seems like you either need to uninstall Windows direct cable connection network, or install another connection between two other COM ports. Regards, Pete
  2. You've assigned the axis to the spoiler in FS's assignments dialogue? did you test it worked in FS then, before going to FSUIPC? You need to at least check that it does move the spoiler, even if wrongly. All FSUIPC is doing is supplying more accurate calibration, for spoiler "ARM" position especially. Test it with thr aircraft in the air. On the ground the spoiler will probably deploy to 100% when you arm it. Pete
  3. None of them. I was addressing Jose's problem of testing his access key. That's why I quoted his comment! No!!! Doesn't Jose's new file fix your problem? If not, can I see the log please, because it should. Pete
  4. There's no way I know to do that at the moment, though when I get time I have plans to work on a joystick interface program for FSUIPC that could also work through WideFS. But really, I would certainly never recommend that your main controls (aileron, elevator, rudder) are on a separate PC from FS simply because the latency (delay) in the response can lead to over-controlling. It is a trivial job to do it the other way around -- that is send Roger Wilco PTT commands from the FS PC. Yes, that is easy. You need to register (i.e. pay for) both FSUIPC and WideFS. In FSUIPC you use the Buttons page to program your button to send KeySend 1 on pressing and KeySend 2 on releasing. In the client PC, in Wideclient.ini, you add parameters to make KeySend 1 do an "RWon" and KeySend 2 do an "RWoff". And that's it. These parameters are described in the documentation. Roger Wilco has been supported in this way for several years. Regards, Pete
  5. To test access registration from any program, sinply temporarily remove the FSUIPC.KEY file from the modules folder, or rename it. For a Beta version of FSUIPc this won't work -- you have to add "TestRegistration=Yes" to the FSUIPC.INI. Regards, Pete
  6. Yes. I should refer to my own documentation, shouldn't I! :oops: :) Check your Email. I'm sending PFC 1.65 for you to try. No updated documentation yet though. Be aware, by default the driver now restarts itself (using the restart facility I mentioned for 1.63) early on after loading so that all the switches synchronise in FS. If this is inconvenient at all you can disable it -- more about this in the documentation update which I'll do by Friday. Regards, Pete
  7. Hi again Frank, I've played around writing the the separate selector offsets on the Baron, and I'm not really sure how I should interpret the Cirrus selector switch. Does the following seem useful? Off -> both off (0) Left -> Engine 1 normal, Engine 2 crossfed from left Right -> Engine 2 normal, Engine 1 crossfed from right Both -> both on normal (selector straight up) I'll implement it this way unless you have a better idea? Regards, Pete
  8. The INI file GPSout creates will be just the defaults, which are almost guaranteed not to suit your setup. Please check that and edit it suitably, before running FS. If you still can't get it working, please tell me exactly what you have selected in FliteMap, and let me see your GPSout.ini file. When you use FliteMap's "test" facility, what do you see? There really isn't anythng complicated or difficult about any of this. If GPSout is installed, it sends stuff out regularly, unstoppably, all the time. If FliteMap doesn't see it it will be because one or more of the settings, in GPSout.INI, or in FliteMap, are wrong, or the connecting cable is wrong. This is my GPSout.ini file: [GPSout] Sentences=RMC,GGA,GSA Interval=500 Port=COM1 Speed=19200 Of course your COM port may be different. This is how my FliteMap is set: Connections menu -- External Device setup: 'Use GPS' is checked COM2, 19200 speed selected (obviously set COM port to suit) Garmin selected on left Garmin GPS 95 NMEA 0183 selected on right (but I think almost any NMEA 0183 should work) The bottom left selector (I don't know what it is) reads 'None'. You can press the "TEST" button there to see what FliteMap is making of any input it gets. If you get none then check the Ports, the Speeds and the Cable. Regards, Pete
  9. I assume you want the fuel switch to operate both selectors together? They should actually do that already, in fact I never knew it didn't work in FS2002. The PFC driver merely uses FSUIPC for this, and operates the fuel selectors via the offset which is supposed to be applied to all selectors. However, there are offsets which I can use for up to 4 separate selectors on 4 separate engines, so it will be easy enough to fix in PFC.DLL. Please look out for a new version by or over the weekend. I'm planning to release new versions of PFC, FSUIPC and WideFS, probably Friday. Regards, Pete
  10. The rain fix was for a bug in FS2002 where the rain could get stuck on, never stopping -- even with no clouds. I worked out a solution, but this was only ever a problem with FS2002 and there was no problem with "spurious rain at FL370". In some ways it was similar to the stuck zero visibility problem in FS2000. Both options are still available in the current FSUIPC, but they are not applied to FS2004. There was no rain/snow implementation in FS98 so I'm certain there was no "FS98 rain/snow bug", so I still don't understand your reference to a "damn FS98 weather issue". Sorry. Aren't you going to elaborate further? I don't understand why you'd come here with a possible problem and then not want to discuss it more fully so that it is possibly understood, and maybe even resolved. You seemed to imply it was some well-known historic bug but you evidently don't have the right reference for it? Regards, Pete
  11. Where did you send it, and what email address did you use for yourself? There's certainly nothing containing the words "Livewire Assistant" in any emails I've received this year. I think perhaps you sent it to the wrong place? There's nothing here. Unless I'm away on holiday (which times I post an announcement in the forum), I always respond to messages within a day or two, and 99% of the time within a few hours. Regards, Pete
  12. What is this "damn FS98 weather issue"? Sorry, I've never heard of it. You get rain and snow at FL370? There are rain clouds above? If so, it will be Active Sky setting this. Did you check? What does Active Sky forum say? What has Microsoft got to do with it? They didn't write Active Sky. It is more likely down to bad data from the Weather Internet sites. This is the most common reason for odd weather effects, but this is the first time anyone has ever mentioned rain at FL370, to me at least. If you can explain more about what you are complaining about, and how it relates to FS98 and Microsoft, I may be able to offer some advice? Regards, Pete
  13. Yes, I am afraid it is the same problem. the new version still has no Product Name nor File Description in the version information. It seems neither version are correct for the details Jose supplied to me for the Key. I will write direct to him, as he says he has difficulty getting here. No, leave that. it is not relevant to this. Regards, Pete
  14. What was the previous version of WideFS you were using? If it was 5.50 then you could use exactly the same WideSever.ini and WideClient.ini files as before. If you want me to help, I really need some more information, please. Like the WideServer and WideClient LOG files and the INI files you are using. Regards, Pete
  15. a) Because WideServer is not doing anything at all when you don't run WideClient to connect to it -- and you say you have problems without running WideClient too. Remember? You said this in your previous message. b) Because it has been in use for six years and never once before having any such problems. It sounds as if EITHER your WideServer DLL is corrupted, i.e. not the same as the one I released -- which you could ascertain by re-downloading it and re-installing it, as I suggested, OR something is badly wrong below, in Windows, the network card drivers, or the network card itself. When WideServer is running it is of course linked through Winsock and the network drivers to your Network card. When there is no WideClient connected it is merely listening for a connection. there is no traffic. so, if FS is crashing or stopping there must be something fundamentally wrong in that area. There is no other area for it to be wrong in. The most likely thing is some sort of IRQ conflict between your Network Card and your Video card, or bad or corrupted network drivers, or, just possibly, a Network card which is causing problems directly. I did make several suggestions for you to try before, which you seem to have ignored. I really don't think the logs will show you anything of use, especailly as almost nothing will be happening without WideClient connecting. Regards, Pete
  16. You don't get ANY menu bar? Not the standard FS menu with which you can select flights, weather, options, help and so on? If you are not able to get to this then your FS2004 installation is corrupt and you need to uninstall and re-install, though I've never heard of such a problem before. If you just mean you've started FS2004 and you are faced with the initial choices, then press "Fly Now" (bottom right corner) to enter FS proper. The menu bar may be hidde,n but should pop into view which you press the ALT key. Regards, Pete
  17. If you are using the PFC.DLL (or FSUIPC or WideFS) "Roger Wilco" PTT facilities, it makes no difference whatsoever what you program the RW PTT keystroke to be, because it doesn't use keystrokes but direct registered messages to RW. There are no facilities for simply using a CTRL key on its own. You'd need to either choose a combination (CTRL+something, for example), or a regular (non-shift) key on its own. Then you'd program that PFC button in FSUIPC's "Buttons" page, not in PFC. (For that you'll need a user-registered copy of FSUIPC). If TeamSpeak provides a pair of Registered Messages to operate its PTT on/PTT off actions, like Roger Wilco does, then I could add those to PFC, FSUIPC and WideFS, so you don't need to worry about keystrokes again. You'd need to ask the author what provisions have been made for such external control. Regards, Pete
  18. No you didn't! As I thought I explained, the Keycode I published in the Freeware list is one which is based on the information I was supplied about AIBridge's "Version Information". The log you showed tells me that the AIBridge you are trying does NOT have that Version Information and therefore that Key does not work with that version. All I need to provide the correct keys is 1. The program name, presumably AIBridge.exe 2. The Product Name from the "Version" display it its properties 3. The Company Name from the "Version" display plus, if either of 2 and 3 are missing or empty: 4. The File Description from the "Version" display. Maybe Jose will provide the correct information for me to make a new key. Jose? Regards, Pete
  19. It is sounding as if it is not really anything to do with WideFS. What prompts this "equally deadly" result? Maximum logging data is produced by setting Log=DebugAll in the [user] section of the WideClient.ini, and Log=DEbug in the [user] section of the WideServer.ini. But I'm not sure any logging will tell you anything about FS graphics changes -- all the logging is to help discover what data is being exchanged across the Server-Client link. With only a client running and no applications, this only amounts to a handshake. Pete
  20. How odd. The Network part of WideFS, which will be invoked when Wideclient connects, is totally independent of FS and runs in its own separate thread. Can you clarify -- does this happen with ONLY wideClient running, or is there a client application running as well (pmTCAS, or whatever)? If the latter, can you try things with JUST Wideclient connected, nothing else? I'd also like to see WideServer and WideClient LOG and INI files, please -- if they are long, ZIP them and attach them. If it ONLY happens with the application running (pmTCAS?) also enable IPC write logging in FSUIPC and let me see the FSUIPC Log. There is nothing WideServer "owns" which FS would want and which needs to be released. There is, in fact, nothing in WideServer that has anything to do with any operations in FS at all, certainly not graphics. Even when it needs to write FS variables it does this through FSUIPC, not directly. Let me see those files and we'll take it from there. WideFS has been going now, relatively unchanged, for about 6 years and I've never heard of anything like this before. So one thing that occurs to me is a possible corrupted WideServer.DLL, or similarly network drivers or Winsock components in Windows. Maybe you could try re-downloading and installing WideFS in any case, just in case. We may then need to proceed to uninstalling your Network card and re-installing it, and finally, if necessary, trying some Windows repairs, although there I start getting lost. Regards, Pete
  21. Sounds very strange, almost impossible in fact. 15 seconds is a VERY long time! Where can the details of all those changes be stored, waiting so long? Additionally, virtually all the PM-control areas are above offset 4000. For those, WideClient updates its local memory at the same time as sending it off to the Server. It doesn't do this with the lower areas, because reading and writing many FS and FSUIPC values are noy the same. There is a long-standing lower PM area, 04E0-0536, and certainly, as it currently stands, writes to those do go to the Server first. Maybe this is a problem for the sorts of things these two programs are doing. Can you just try a test -- move the MCP to another Client, if you have one, if not, then to the Server? If this fixes it, then it is either a problem with the 04E0-0536 locations, or it is some sort of process problem on that client. Let me know. I can then send you a version of WideClient which treats 04E0-0536 like the upper areas. If moving MCP doesn't fix it, then we'll need to investigate further -- possibly invoke some of the extensive diagnostic logging in WideFS. I must admit to never having run the Aerosoft program on the same PC as any PM module. Regards, Pete
  22. Don't you read your email? You are marine_aviation_8762@yahoo.com are you not? that's who I get replying to you by email. Pete
  23. The problem here is that the key I generated followed Jose's stated data, with a Product Name "AIBridge" -- but the version you are running has no Product Name and no Description either (which is used as an alternative input for this). I don't know if there's more than one version with different properties, so I hope Jose can help here ... Regards, Pete
  24. There is no way in FSUIPC to reduce sensitivity. The FSUIPC calibration in fact does the reverse -- it makes sure that whatever little movement you have on your stick covers the full range of control surface adjustment. The "dead zone" facility, if anything, exagerrates sensitivity, because it renders some part of your joystick movement 'dead' so leaving the remainder to cover the whole range -- less movement, greater range = greater sensitivity. If the Sensitivity adjustment in FS itself is insufficient, you could try adding "stick_sensitivity_mode=0" to the [CONTROLS] section of your FS CFG file. This works in FS2000 and FS2002, and probably in FS2004, making the stick handling mechanism in FS operate linearly, like it did in FS98. 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.