Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. FSInterrogate is a useful tool for experimenting with known offsets, but it isn't the reference for what is available. You should be referring to the FSUIPC4 Offsets Status document for that. I do try to keep the FSI file for FSInterrogate up to date, but it certainly isn't guaranteed, and hasn't got anywhere near as much infirmation in it as the offset documentation. As it happens, the values actually called "Ignition switches" are not currently available through FSUIPC -- they never were and they've never been requested before. Things like that tend to be added by request. I've looked at the SimConnect interface, and there are separate ignition switches numbered 1 through 4, with 1 and 2 corresponding to your Left and Right, so I'll add them in the interim FSUIPC4 update planned for later today. I'll add these to the TURB ENG set of values, as follows: 208C (4 bytes) Turb eng 1 ignition switch, 1=on 0=off 218C (4 bytes) Turb eng 2 ignition switch, 1=on 0=off 228C (4 bytes) Turb eng 3 ignition switch, 1=on 0=off 238C (4 bytes) Turb eng 4 ignition switch, 1=on 0=off Currently the latest version is 4.305 -- look out for 4.306 later today or maybe tomorrow. (In case you hadn't noticed, interim releases and updated information are always provided via the Announcements above). Regards Pete
  2. No point in that. All your client arrangements can stay the same, no matter which FS version is running on the server. Didn't you ever notice that you were downloading the same client EXE twice? Regards Pete
  3. There's only one version of WideClient. It has always been completely FS version independent. You will note that the current incremental release of WideClient is version 6.767 in both the FSX and Other downloads Announcement above. They are identical. You never need to change the Clients at all when changing FS versions, from FS98 through to and including FSX and ESP. Look out for the next incremental release in one of the Downloads Announcements above. Probably in the next day or three. Regards Pete
  4. I don't have such an option in WideClient at present, but it wouldn't be hard to add it as an INI file option. Maybe "Visible=OnTop", and "Visible=MaxOnTop"? Pete
  5. I decided against allowing that directly because the macro file references are not fixed -- the names are assigned in the FSUIPC.INI file, so the control numbers to instigate the macros within would vary from installation to installation. For instance, many folks still run FS9 and FSX. I didn't want unpredictable things happening because the macro files just happened to have different reference numbers in the two installations. But it can be done. The best way, and one which overcomes the above problem altogether, is to use the virtual button facilities -- offsets 3340 and following. Instead of sending a control via 3110, toggle a bit representing a virtual button, and program that to operate your macro. in the normal Buttons way. Regards Pete
  6. What does that mean? You need to explain what happens, what you see, not terms like "takes out" which means only something like "murdered" or "removed from" depending what sort of films you watch. And how is an install incomplete? Does it say "i am not complete"? Else how do you tell? And has this anything to do with anything I deal with here? I'm pretty sure FDC uses FSUIPC, so that makes sense. Why would you want to try it without FSUIPC in any case? Nothing you say makes sense. Can you explain why you are trying FDC without FSUIPC? Corrupt? What does that mean? What does the FSUIPC log file say (you'll find it in the Modules folder)? Why are you even talking about FSUIPC in the first place? Why do you arrive here instead of at FDC or PMDG support? Regards Pete
  7. Okay, so that change is by "Offset Word Togglebits" with a parameter of x0188. Ah, not something we can do just by fiddling with bits once -- unless setting it to x0148 or x00C8 "triggers" the panel code to start the sequence? I assume this is programmed in the Gauge based on the switch position. So you probably need to operate the switches. Does the mouse macro facility operate on that at all? Well, at least not in the way you thought.you have to get the add-on panel code to do the work. Yes, assuming that you cannot operate the cockpit switch to make it happen. If you did need to actually do that bit flipping continuously yourself, you could actually do that with a new programming interface I'm adding at present -- a LUA interpreter, in fact. But at present I'm only doing it for FSX, i.e. in FSUIPC4. I may add it to FSUIPC3 later depending on the response I get. Regards Pete
  8. I think MixW virtual ports do show up under the Ports section in the device manager. Are you sure the COM5 and COM6 ports you are assigning aren't some USB devices? Ah, Vista. I don't think MixW works in Vista -- at least according to other reports in this Forum. You could try searching for a Vista update, but as it is freeware I wouldn't put out too much hope for that. I was going to suggest getting "PortMon" from sysinternals.com, so you could check port activity, but i don't think that works in Vista either. All my Client PCs run Win XP, I only use Vista (64) on my main FSX PCs. I think there are some commercial virtual serial port programs with Vista support. Not cheap though. Regards Pete
  9. Where does it "read 3.7.4.0"? There are several ways of determining the version: 1. Right-click on the FSUIPC.DLL file itself, in Explorer, and select Properties, then Version. 2. Install it into the Modules folder of FS, run FS, then go to the Modules menu and read the version number on screen. 3. After or whilst running FS with FSUIPC installed, find the FSUIPC.LOG file in the Modules folder and read the version number in the first line. Regards Pete
  10. Okay. I'll add it in an increment in the FSX downloads announcement first -- check there over the next few days -- maybe by the end of the weekend with any luck. I am in the middle of something rather bigger but I can probably release it for testing and development anyway, just not a full user release for a couple of weeks (lots more testing and documentation needed for the new stuff I'm doing). Best Regards Pete
  11. I use FliteMap regularly via WideFS and MixW virtual serial ports, but I'm afraid I don't know "fliteDeck" at all. Maybe someone who has got it working will help here. And they are listed as okay in device manager, are they? Don't you have to give it the Port? i.e. COM6? Or perhaps it only scans ports COM1 and COM2. Some badly written programs assume an ancient PC architecture which never allowed more. Though if FliteDeck is later than FliteMap it should be okay because FliteMap is okay. Isn't there a test mode? There is in Flitemap. It shows the data it is receiving. Maybe it is receiving data but doesn't like it. And 4800 baud seems very slow -- that's the default speed for standard NMEA devices, but I suspect with a one-second update you might get clashes -- you are asking for 4 sentences (RMC,GGA,GSA,PGRMZ) which could amount to nearly the 480 characters maximum per second at 4800 baud. Either use a higher speed (I use 38400 as a rule, but you should be able to go up to 115200) or slow the rate down to 2 seconds or worse. And check that you are setting the same speed in FliteDeck. In Flitemap neither the speed nor port were automatic -- you have to set both. What error are you referring to? 15257 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 15257 Failed to start IPX/SPX Server This one is ignorable. It just means you've not installed IPX/SPX, so it isn't going to be supported. 349941 Error 10053: client socket disconnected at Client: removing (skt=8424) TCP Those look like you closed WideClient down, that's all. These lines: 1624641 Client capabilities: 04 (GPSout=Y) (skt=8180) TCP show that the Client is requesting GPS data. You might want to update to the latest WideClient from the Announcements above. There have been a few improvements in this area. This shows that WideClient is opening the selected COM port okay, so it will certainly be sending the data. Regards Pete
  12. And what about when it is off? That's important to know too as all those bits are totally unrelated to any strobes in FS. 0x0C8 means wing, recognition and taxi lights are on, all others off. 0x1C8 merely adds the Logo light. The FS strobe light switch is bit 4 (0x010), which isn't being touched!! Seems that your aircraft does not use FS strobes at all, but steals the Logo light for steadying one of the others it is also 'stealing' (but we don't know which one from the above). Weird. Sorry, I don't really want to go into any of that (and the ZIpped "manual" is in fact only a Zipped Link of some kind, which I'm certainly not following!) I only offered to advise you on how to edit the parameters in the INI. ;-) Oh, I thought it was an either/or. It could get mightily more complicated to do combinations. It can't really be done with a user offset with Keys. You'd have to make the Key toggle a virtual button (see offset 3340) and program the button instead. Is the keypress acting like a toggle switch? i.e. can the "press" and "release" be programmed separately for "on" and "off" states? Or is is a real keypress and release like a normal keyboard? It makes a lot of difference. You might want to wait until I've finished adding the Lua programming interpreter to FSUIPC. Are you using FSX or FS9? The FSX version of Lua programming facilities will be reading in a couple of weeks or so, I hope. FS9 much later if at all. See http://www.lua.org Things never happen on their own no matter how you program them. The instigation of anything happening is a change of button or key state, nothing else. Why not do that then -- if you know the changes in the 0D0C offset you can program the key to change 0d0C based on the appropriate 0D0C bits! I could tell you the actual sequence, the paramters to use, if I know what 0D0C looked like with the strobes off. Regards Pete
  13. Ah, yes. There are some variables that were added. These in fact: REALISM CRASH WITH OTHERS True indicates crashing with other aircraft is possible. REALISM CRASH DETECTION True indicates crash detection is turned on CRASH SEQUENCE One of: 0: off 1: complete 3: reset 4: pause 11: start CRASH FLAG One of: 0: None 2: Mountain 4: General 6: Building 8: Splash 10: Gear up 12: Overstress 14: Building 16: Aircraft 18: Fuel Truck I could add offsets for these to FSUIPC4, in the next interim update if you like. They aren't really compatible with the older offset 0830, so i'd probably prefer to find some place else to put them. Looks like 4 byte values would do. And, in fact, make the "crashed flag" at offset 0840 give more information, as above. Currently it is driven by an Event, not a Variable. Regards Pete
  14. Easier than changing two lines in the INI? How much easier could it be? One parameter change and one section title change! It sounds like you haven't actually referred to the documentation on this at all! Regards Pete
  15. Only by the menu I think. Hardly any of the menu items have been exposed via SimConnect I'm afraid. Pete
  16. If it is disabled it doesn't matter, though for tidiness, or to avoid later confusion, I suppose you could delete everything in FS assignments. There's a slight worry though that it might reassign them automatically, as if it is detecting them afresh -- though obviously it shouldn't do this if they are disabled ... I think you can be sure. I've only ever disabled the joysticks, I've never bothered going through deleting anything. Regards Pete
  17. Sorry, even 'what' when controls are disabled in FS? Not to assign in FS and in FSUIPC the same axis / control? I don't understand what you are now asking: If you don't assign in FS (ie. they are disabled) how can there be a conflict with assignments in FS? "It does not compute" as Spock would say! Pete
  18. Probably. Fly-by-wire for Airbus, perhpas. Never unintentionally have multiple assignments to the same FS axes -- they will certainly conflict as each will send different values according to their different processing. Assigning them in one place cannot stop them also being read elsewhere, it is the nature of the joystick interface in Windows. However, if you mean axes and FS controls you aren't using with a specific aircraft, then they don't matter. Regards Pete
  19. Do it for one and then edit the FSUIPC INI file. Please refer to the Appendix on this subject in the recent editions of the Advanced User's Guide. There's an easy guide there thanks to Peter Hayes. Regards Pete
  20. Ah, yes! Mea culpe! I was thinking of the button conditions or "compund button" actions. Sorry. I clean forgot about that offset testing facility. No, there are offsets for flaps position and on ground indications. Really, to use these things, you need to Offsets list, which is supplied only as part of the FSUIPC SDK (on the Schiratti Dowson page). Flaps are at Word offset 0BE0, with zero for flaps up and other values for different flap positions. The "on ground" indicator is the Word at offset 0366, non-zero when on ground, zero when airborne. If you want help in editing the keypress entries in FSUIPC INI, let me know exactly what you want done. Regards Pete
  21. As it says in the User Guide, the "direct" method bypasses FS altogether until the value has been calibrated. In FSX it also bypasses SimConnect altogether. It is more efficient, smoother, better in every wayEXCEPT that, as also stated in the User Guide, there are some add-ons which intercept the FS control and do things with it, and this method bypasses that possibility. That's why it says (with an emboldened NOTE) to try it first, make sure it doesn't mess your add-on up. The only other reason for using FS controls, not direct to FS calibration, is that there are a lot of assignable controls for FS which are not subject to FSUIPC calibration and which therefore cannot be sent direct in this way. Regards Pete
  22. Keypress? I don't provide any programming facilities for conditions on keypresses, only buttons. You vould conceivably do it by programming a keypress to operate a "virtual button" and then programming that, with conditions, but it gets pretty weird and complicated. Same as a 737's strobes switch. How is the switch operated? Only by mouse? I assume the normal Strobes control from FS only selects off and one of the on states? Well, you can do that with buttons, or for a keypress programmed to operate a virtual button, but since there's no shortage of keypress combinations I don't understand why you don't simply use a separate keypress for each requirement. After all, in the real aircraft you would have to think about this and do it correctly, it isn't automatically going to change, is it? The virtual button could be programmed to do your bidding, including mess things up if you wanted it to. ;-) 0D0C deals with FS supported lights, not any add-on ones. Without monitoring 0D0C (which you can do in the right-hand side of the Logging page -- offset 0D0C, type U16) there's no way of knowing what the aircraft uses. I doubt it uses any FSUIPC offsets at all for his extra values -- add-on programs only use extra FSUIPC offsets to communicate with external modules, and then they need to apply to me for an allocation. Oh, did I publish my birthday someplace? Thank you. Yes, I am 65 today. But I'm not counting any more! ;-) Oh, thanks. That's odd. I'll just try it here ... ... Ugh! So it does. That's not very nice! Thanks for letting me know! Regards Pete
  23. This worried me, so, despite having no information to start with, I persisted and finally got it to happen here. It is a bug in the Installer which only had any adverse effect after I added facilities in FSUIPC4 to allow for changed INI file names based on changed FSX.EXE file names. Thanks for reporting it. It'll be fixed in the next Installer release, in a week or two. Regards Pete
  24. Ah, yes, you are correct -- it is an Appendix to the Advanced User's guide. I put it there because everything to do with editing the INI file is there. Sorry, but that is not true. The Installer ALWAYS installs both manuals and the list of FSX controls -- check your FSX Modules folder. The confirmation of what the Installer installs is provided in the Installer's Log, also in your FSX Modules folder, thus: There's actually no way, in fact, that you can install version 4.30 without the Advanced User's guide also being installed. And the latest copy of "FSUIPC4 for Advanced Users.pdf" is subtitled "for version 4.30, July 2008. I don't know where you are looking, bt if it is in the Modules folders, where everything is installed, it can only mean you never actually ran the 4.30 installer. Yes, thanks. Best Regards Pete
  25. Not good. There are facilities for making that much shorter and simpler, and "Idiot's Guide" level instructions on how to do this were posted here by one kind user a while back. Those now form one of the Appendices to the User Guide for FSUIPC. Have you looked at the documentation recently? Yes, of course, and there always has been. Please scan the Contents list in the current User Guide -- you'll spot some documentation on exactly this subject. 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.