Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Hi Massimo, Would it be okay for me to put a link to your SPAD site in my documentation? Regards Pete
  2. I assume "error message 14" is from FS Commander? What does it mean? I don't have FS Commander and don't know it at all. You created a folder called "(x86)"? Are you sure you don't mean the Windows folder "Program Files (x86)", which is the default installation place for 32-bit programs on a 64-bit version of Windows. It is, like Program Files on both 32- and 64-bit versions, still protected by Windows against normal user changes. I've no idea what "IAW" means, but even sharing "drives" won't allow programs full access to program files unless they are run with elevated administrator privileges. It is a problem with letting FS install into Program Files folders. Ok, that's good then. Are you running both FSX and FSCommander with "run as administrator" set, or does it work fine without needing that? If so, then FSCommander does have the file access it needs. If it never connects then that is certainly a problem -- though whether that gives your "message 14" I've no idea. It is a pity it isn't documented, if it isn't as you imply. Your Wideclient log shows: 265 Trying TCP/IP host "FLIGHTSIM" port 8002 ... 265Okay, IP Address = 204.194.233.140 1451 Error on client pre-Connection Select() [Error=10061] Connection refused which isn't good. That IP address looks completely wrong to me. It looks like an Internet address, not a local Network address. It Googled it and the 204.194 group seems to be pre-allocated to a number of commercial concerns, with yours in this one: 204.194.232.0 - 204.194.239.0 Med-E-Systems Corporation (NETBLK-MEDENET) and a WhoIs I found via Google gives: 204.194.233.140 server location: San Francisco in United States 204.194.233.140 ISP: 302 Direct Media LLC In your Wideclient.INI file you've set the ServerName and Protocol parameters: [Config] ServerName=FLIGHTSIM Protocol=TCP Why? Didn't you first try without, as it comes? Provided both PC's have the same workgroup name it should connect automatically. It seems that your Windows or Router setup is somehow translating the name "FLIGHTSIM" into the IP address of "Direct Media LLC"?! Find your real FS PC's IP address on your network and try replacing the ServerName=line with "ServerIPAddr=nnn.nnn.nnn.nnn where the nnn's are replaced by the correct values. Regards Pete
  3. Sorry if I gave that impression. It wasn't so much frustration, just surprise. ;-) Regards Pete
  4. Not particularly, no. The order doesn't matter, though since ASA uses FSUIPC in FS9 it obviously shouldn't be run until FSUIPC is installed -- else it will complain. Correct. But installation order doesn't matter. Whether things are installed only becomes important when you run applications which depend on that installation. Regards Pete
  5. You need to calibrate every lever properly first, with special care with Engine 1 levers, because they won't change thereafter and are used as the "measure" for recording the equivalent positions on all the others. Naturally get them lined up for min. centre and max positions. The sync positions are only taking care of making them match correctly at the intermediate positions. Don't go overboard with too many "sync" positions -- depending how bad the alignment is you shouldn't need many. FSUIPC will replace any too close though, using the latest. Sounds like there's no real dead zone then. You could make a dead zone span half of the movement available if you wanted to. I'm sure you should be capable of making it enough so that a slight movement will be ignored -- providing you leave it in its parked position of course. With these settings: Throttle 1: -16035, -9586, 512, 15512 Throttle 2: -16203, -9542, 356, 16205 where are you "parking" the throttles whilst taxiing? In the centre idle position? If so there should surely be enough movement available with that 10,000 odd space. You certainly don't seem to have any noticeable "dead zone" at either minimum or maximum positions -- 16383 is the very limit of possibility. No, you describe it exactly. If you have predefined throttle settings, values to be sent to establish different thrust modes, as in an Airbus, then that is precisely "doing certain things under pre-defined conditions". For 4 different throttle modes you'd delineate 4 regions on the throttle and in each one assign the AXIS_THROTTLE_SET control with the one, single, fixed throttle value which will give you that setting in the aircraft's engine control system. I think some Airbus implementations actually use fixed controls or keypresses to select throttle modes, in which case those controls or keypresses would be sent instead, but it sounds like your aircraft needs the actual throttle values but interprets ranges rather than specific values. So why not send the correct specific values in the first place? Regard Pete
  6. Of course, but you don't need to "select" the altimeter first. There are separate FS controls you can assign keystrokes to in any case. Please review the List of FS2004 controls (or FSX controls) included in the FSUIPC documentation. Any of those can be assigned to joystick buttons or keypress combinations. These are the Kollsman window BARO adjustment controls: KOHLSMAN DEC KOHLSMAN INC KOHLSMAN SET The last takes a parameter which represents the number of mb (hPa) x 16 and can be used to set STD (1013.2) by using it with a parameter of 16211. That emulates pushing the BARO knob on a typical airliner EFIS panel. It is one of the examples in the FSUIPC user guide. The baro setting display on an altimeter is called the "Kollsman window" after the German company who first made such altimeters. Microsoft mis-spelled the name! ;-) You can read all the FSUIPC documents and work out whether you need it in any case. They are installed for you if you install FSUIPC (you don't need to register), or they are now available in the "Updates and other goodies" announcement here in the Forum. Regards Pete
  7. It would have been better to use the FSUIPC installer to register WideFS, just as I hope you did if/when you registered FSUIPC. Questions: 1. What does the FSUIPC.LOG file show? That is always the first place to look. You'll find it in the FS Modules folder. 2. Did you have it working BEFORE you registered WideFS? 3. Are you using Vista or Windows 7, and if so, did you allow FS2004 to install into its default place of "Program Files"? There's only the one, and it is called "WideServer.DLL". It won't have anything whatsoever to do with any of this. 3.947? That's way out of date and totally unsupportable! 3.96 is the minimum currently supported version, and there's a much later version (3.976) available here in the Updates announcement. Please do LOOK AT THE ANNOUNCEMENTS! They are VERY important. I Announce things there! I sdtill don't understand why no one ever reads them! :-( The most likely cause of your problem is that you purchased your WideFS registration in 2010, and 2010 keys only work with 3.96 or later. Please ALWAYS keep FSUIPC up to date if you want help. Tha'ts always the first thing to ask yourself, "am I using the latest version?". Download and install 3.96 from the Schiratti site. Then overwrite the DLL with 3.976 from the Announcement. Then you'll be up to date -- at least until next week when 3.98 will be released and become the only one supported. :-( Pete
  8. If they have some protection mechanism that stops them being installed on more that one PC at a time, I suppose so, but that sounds unlikely. If they aren't going to be used on the FS PC they could be left alone, surely, unless you desperately needed the disk space. Mind you, Squawkbox might be different. Doesn't that need something installed on both the FS PC and the client in order to operate effectively? I'm not sure. You'll need to consult the documentation for that. As I said, if you didn't use them on both PCs at the same time, what could go wrong? How would they cause confusion and conflict if they aren't used? But check Squawkbox. I don't know enough to say for sure how that operates over WideFS. Regards Pete
  9. So I don't understand. Is it simply that the real throttle axis is interfering with the values the Prop Pitch is setting via the AIR file "fiddle"? If so you need to have a bigger idle "dead zone" to make sure there's no input from the real throttle axes when taxiing. Neither FS nor FSUIPC actually transmit any controls or values to the Sim Engine when the readings from joysticks are stable. Any jitter will, however, send values and have the adverse effect you describe. You can also alter the "Delta" value in the FSUIPC axis assignmwents tab. A bigger value will ignore bigger changes. But take care that doesn't stop you using it normally. I thought it was, but usually it is easiest simply to cut the relevant parts of the file out and paste them into your message as text, enclosed using the "Code" option, so they don't make the message impossibly long but are enclosed in a scrollable and selectable frame. Regards Pete
  10. You are posting in the wrong Forum. I have an FSUIPC Support Forum not far from here. There are Announcements there which tell you all you need to know. FSUIPC4 and WideFS7 are new products for FSX and ESP, they had to be completely re-written for FSX because of SimConnect. You need to purchase new keys and download FSUIPC4. WideClient stays the same. You don't have to do anything with FSUIPC -- it is optional of course -- but you may calibrate with it if you have purchased it and wish to do so. You might even find that you can transfer most of your settings form FSUIPC3's INI file into FSUIPC4's, but take care because axis lettering might be different. Regards Pete
  11. Really analogue axes are not terribly suited to that sort of control. But FSUIPC does attempt to allow such "gate" systems by allowing assignments to specific, fixed, controls on the right-hand side of the Axis assignments tab -- the ability to assign controls to different ranges within the axis movement. Is this what you used? The prop pitch controls, you mean? (When I first read that I was thinking elevator, which is of course your prime aircraft pitch control! ;-) ). But if you are not using the throttles to taxi, what is the problem using pitch as you stated? I've obviously missed something Do you mean on auto-throttle? The A/P controls throttles as well? If there is no autothrottle then there should be no difference at all between the throttle with A/P on or off. If there is an auto-throttle then then your throttle setting shouldn't have anything to do with it, surely? So you aren't using the axis region facilities to assign fixed controls for your 4 modes? Wouldn't that be more precise? Perhaps that's the problem? Which parts of the file are you unsure of. most of those parts which users are expected to want to mess with are explained in the Advanced Users guide, and I can explain other parts for you if you wish. Regards Pete
  12. Ah, sorry. There are lots of changes in each set of incremental releases I place in the "Updates" Announcement, and they are detailed in the list within. If I had an Announcement for each there would be several pages of Announcements before you got to folks Forum messages! ;-) Good flying now, I hope! ;-) Best Regards Pete
  13. Please refer to the Announcements in this Forum from time to time. It will help enormously, as it is where I post ANNOUNCEMENTS. This problem was fixed with an update within a few days of it being reported, and it is described in the long list of changes made to FSUIPC since then, in the Updates announcement. I have an Announcements section here in the Forum to actually Announce things so that folks can help themselves. I just don't understand why folks would rather spend the time posting questions when they are so often already answered. It is an ongoing puzzlement to me. Can you explain it? I'd genuinely love to know. How can I make it more obvious do you think? Regards Pete
  14. THat's well out of date now. Please see the Updates announcement above. You should install 4.57 then update to the latest increment in that announcement. I don't understand how you could get in a mess in the first place. There's nothing complicated about anything there. There's no difference in these areas between FS9 and FSX versions of FSUIPC. The differences are all in the other options -- weather and miscellaneous stuff. All of the assignments and calibrations are identical. Why is that "painstaking" when all it involves is disabling the controllers -- the checkbox in FS Settings-Controls? That's all I ever do. It sdimply sounds as if you've (a) not assigned correctly and (b) not calibrated those you have assigned. If you do ever try again, and get into a mess again, please do not hesitate to paste here the [Axes] and [JoystickCalibration] sections of your FSUIPC INI file so I can see what you are doing. That would help me greatly to advise you. Yes, the User Guide supplied with FSUIPC. That has a chapter on assignments and one on calibrations, with step-by-step approaches and pictures too. If you actually follow the steps you can't go wrong. Thousands of other users make it work easily enough, so why not you? If it is just that you don't like my style, then that's why SimSamurai wrote his guide, because he thought mine was too technical. And his is no different for FSX in any detail or essential, as I've said. Please please do browse the Announcements section here in the Forum from time to time. They do actually ANNOUNCE things, like versions, bugs, fixes, etc. Regards Pete
  15. GAPanel and WideFS. And then GAPanel I can close normal but WideFS need the help of Task Manager. By "wideFS" I assume you mean WideClient? If WideServer freezes then FS freezes also! And you've shown no logs from Wideclient which show anything wrong at all, they all terminate normally after a message trelling them to do so from WideServer, a result of you closing FS and the parameters you've set to allow the close in WideClient.INI. If your application freezes then it can easily cause WideClient to freeze, but you've shown no evidence of either. Quite the contrary. If it is merely that you've never shown me the correct file, then it is sounding as if the application is buggy. If it is a graphics program, maybe it has a problem with the graphics driver. I suggest you contact the author to see if it is properly compatible with your PC. Your WideServer log shows everything is working properly as well. It perfectly matches what is happening at the Client end of the link: So, WideFS is working correctly both ends, as is FSUIPC. You have an application problem. Sorry, I cannot help with that. You'll need to check with their support. Regards Pete
  16. The "server log" is called WideServer.log, and is in the FS Modules folder. If it isn't there then you have never run WideFS. There should certainly NOT be a WideServer INI file on the client PC. WideServer only runs in the FS PC. On the Client PC you should only have WideClient files and your remote applications. No, that is a completely unrelated matter and no doubt due to the option you have set in Windows to show windows whilst moving them. As the documentation clearly states, that option prevents that checkbox facility from working. Pete
  17. Okay. Your FSUIPC log file shows that it is working well, and your WideClient log shows it is okay. That's one half of the story. You don't show me the WideServer log file, which will also be in the Modules folder. That is the Server half of the story. Why don't you check that too if you think you have a WideFS problem (which doesn't look to be so). Also, you say your client only lasts one minute then "freezes", but this is not borne out by the client logging: The client application starts here: 9375 New Client Application: "GAPanel" (Id=608) WideClient was still connected okay when you closed FS three and a half minutes later: 215406 FS closing down (param=ADBC), disconnecting 215406 ********* Interim performance summary ********* 215406 Total time connected so far = 212 seconds 215406 Reception maximum so far: 28 frames/sec, 14380 bytes/sec 215406 Reception average whilst connected so far: 22 frames/sec, 8296 bytes/sec And it maintained a good average frame rate all that time! Furthermore your application was running and exchanging data with FS all that time, too: 215406 **************** Individual client application activity **************** 215406 Client 608 requests: 898 (Ave 4/sec), Data: 1703213 bytes (8034/sec), Average 1896 bytes/Process So, the next question is: what is really "freezing"? It certainly isn't WideFS or FS. It looks like that application of yours, GAPanel, is your problem? Is that freezing? Maybe it has a video problem local to the Client PC? Why are you thinking it must be WideFS at all? Certainly, let us check the WideServer log file, at last, but I am now thinking you are looking in the wrong place, that you have a problem with the application itself. BTW there is a much later version of FSUIPC, 3.976, available in the Updates announcement in this forum. I suggest you update to that version, then you are using the same one as me. Regards Pete
  18. Have you by any chance allowed FS9 to install itself it its default location, in the windows "Program Files" folder? If so then a lot of programs will have problems, because those folders are protected by Vista and Windows 7 from being written to by anything without elevated privileges, such as installers. Windows 7 recognises FS9 as being a non-Vista aware program, written at a time where there were no such rules, so it provides it with separate, hidden, folders elsewhere, ones the program, FS9, can actually write to if it wants. And then the folders it shows you, in Explorer, are not the real folders but "aliassed" folders. This doesn't apply to folders elsewhere. For example, it is a good idea to install FS9 to, say, "C:\FS9" or "D:\FS9" which would be better if you have a separate drive. Short names also make it much easier when editing files and telling programs where FS is installed. As it is, in order to run MakeRunways successfully you'll probably need to do two things: 1. Run Explorer "as administrator" (that's a right-click option). Doing that gives it elevated privileges, like an installer, and allows you to see and write to the "real" folders instead of the aliassed ones. 2. Using the privileged Explorer, copy in MakeRunways.exe, if it isn't already there. 3. Now run MakeRunways in that folder, also right-clicking and selecting "as administator" so it can write the data back to the same folder. Note that this applies even if you ARE the administrator. That's not relevant. Confusing isn't it? Vista was the same, this isn't new in Win 7. Same problem. Many folks are told they must run FS9 "as administrator" all the time. This shouldn't be necessary, but it is made more so by having FS9 in the Program Files folder, which is the real problem. If you do run FS9 "as administrator" you must run all programs wishing to interface to it via FSUIPC "as administrator" too, because Windows 7, like Vista, prevents programs of different privilege levels talking to each othr! Regards Pete
  19. That would be the correct option if you did notwant to control the reverse thrust on a region of the levers, but if you had wanted that you could have calibrated the middle numbers to be anywhere you liked on the lever movement, not only at the 50% mark. That's just the default. At the same rate as each other, or at the same rate as those on the first TQ? If you mean the latter, I remember that someone else found that -- and we thought this was because they might have been made at different times with different components, non-matching ones. You might want Saitek to fix that, but you should note that FSUIPC does offer more advanced calibration facilities ("sync pos") for recording places on all throttles (or prop pitch or mixture controls) for which the resulting OUTput matches. This effectively makes the calibration into a curve (well a curve made of several short straight lines), and it works quite well. The more points you calibrate this way the more accurately will they line up.* Does it do that no matter what you assign it to? If so it will be the device (maybe the pot), but if it only affects the assignment to a specific finction it is more likely to be a conflict with another assignment. Regards Pete * P.S. I've just noticed that the "sync pos" facility isn't currently documented in the FSUIPC3 version of the User Guide! It is in the FSUIPC4 version, but the facility does apply equally to both. If you are using FSUIPC3, you can read the relevant but missing section here: http://fsuipc.simflight.com/beta/CALIBRES_etc.pdf
  20. Which out box where? The 4 throttles page? Have you actually calibrated in FSUIPC at all? If so it sounds like you'd done it wrong. If the output isn't -ve below the 50% mark (for reverse thrust), then maybe you are setting it for a reverse zone on an aircraft which has no reverse thrust? If you've selected the "no reverse zone" option, then the only other possibility is that you SET the minimum thrust value at the 50% mark. If it is very noticeably it will be because you've calibrated them differently. No two joystick axes are ever exactly the same, and FSUIPC has facilities to match them at a number of positions to deal with that, but it sounds like you've simply either calibrated one and not the other or done them both differently and wrongly. Please RESET both, then calibrate them step by step. You set the minimum, centre idle area (optional, only if you are using a reverse thrust zone) and maximum, in that order, left to right. There are simple numbered steps in the User Guide. Follow them. If you don't do things properly there's really no point in using FSUIPC for this at all. Regards Pete
  21. Hmm. Strange. There's been no change to cause any effects like that, and I cannot reproduce it here. Could you please first update to the very latest increment (3.976, from the Updates Announcement in this Forum) and try again. If you get the same with that I'll need some logs. Enable button and key logging in the FSUIPC logging tab, repeat the problem then Zip up the FSUIPC.LOG file and send it to me at petedowson@btconnect.com. What was your old version number, please? That was fixed a few weeks ago in the updates available here. Please do look at the Announcements now and then, they tell you about things like that. Regards Pete
  22. It should be applying the exact same valuer in both (200 scales to the max 16k). But the value starts decaying immediately, in a proper decay curve -- ie inverse exponential, so a larger value is decreasing fast. Anyway, I used FSUIPC's monitoring facilities and here are the results, FSX first, FS9 second: ********* FSUIPC4, Version 4.593 by Pete Dowson ********* ... 271453 Monitor IPC:0C00 (U8) = 137 271453 Monitor IPC:0C01 (U8) = 137 271484 Monitor IPC:0C00 (U8) = 127 271484 Monitor IPC:0C01 (U8) = 127 271484 SimRead: 0BC4="BRAKE LEFT POSITION" <<< First response from SimConnect (async operation) FLT64: 0.684978306293 271484 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.462377429008 271515 Monitor IPC:0BC4 (U16) = 11223 271515 Monitor IPC:0BC6 (U16) = 7576 271531 Monitor IPC:0C00 (U8) = 117 271531 Monitor IPC:0C01 (U8) = 117 271531 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.41038697958 271531 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.41038697958 271562 Monitor IPC:0BC4 (U16) = 6724 271562 Monitor IPC:0BC6 (U16) = 6724 271625 Monitor IPC:0C00 (U8) = 107 271625 Monitor IPC:0C01 (U8) = 107 271625 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.358396500349 271625 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.358396500349 271640 Monitor IPC:0BC4 (U16) = 5872 271640 Monitor IPC:0BC6 (U16) = 5872 271671 Monitor IPC:0C00 (U8) = 97 271671 Monitor IPC:0C01 (U8) = 97 271671 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.306342571974 271671 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.306342571974 271703 Monitor IPC:0BC4 (U16) = 5019 271703 Monitor IPC:0BC6 (U16) = 5019 271718 Monitor IPC:0C00 (U8) = 87 271718 Monitor IPC:0C01 (U8) = 87 271718 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.258564978838 271718 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.258564978838 271750 Monitor IPC:0BC4 (U16) = 4236 271750 Monitor IPC:0BC6 (U16) = 4236 271796 Monitor IPC:0C00 (U8) = 77 271796 Monitor IPC:0C01 (U8) = 77 271796 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.220571935177 271796 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.220571935177 271828 Monitor IPC:0BC4 (U16) = 3614 271828 Monitor IPC:0BC6 (U16) = 3614 271859 Monitor IPC:0C00 (U8) = 67 271859 Monitor IPC:0C01 (U8) = 67 271859 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.182578876615 271859 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.182578876615 271875 Monitor IPC:0BC4 (U16) = 2991 271875 Monitor IPC:0BC6 (U16) = 2991 271937 Monitor IPC:0C00 (U8) = 57 271937 Monitor IPC:0C01 (U8) = 57 271937 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.144585847855 271937 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.144585847855 271968 Monitor IPC:0BC4 (U16) = 2369 271968 Monitor IPC:0BC6 (U16) = 2369 272000 Monitor IPC:0C00 (U8) = 47 272000 Monitor IPC:0C01 (U8) = 47 272000 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.106592819095 272000 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.106592819095 272031 Monitor IPC:0BC4 (U16) = 1746 272046 Monitor IPC:0BC6 (U16) = 1746 272046 Monitor IPC:0C00 (U8) = 37 272046 Monitor IPC:0C01 (U8) = 37 272046 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.0751999020576 272046 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.0751999020576 272078 Monitor IPC:0BC4 (U16) = 1232 272078 Monitor IPC:0BC6 (U16) = 1232 272109 Monitor IPC:0C00 (U8) = 27 272109 Monitor IPC:0C01 (U8) = 27 272109 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.0591833032668 272109 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.0591833032668 272140 Monitor IPC:0BC4 (U16) = 970 272140 Monitor IPC:0BC6 (U16) = 970 272171 Monitor IPC:0C00 (U8) = 17 272171 Monitor IPC:0C01 (U8) = 17 272171 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.0431862324476 272187 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.0431862324476 272203 Monitor IPC:0BC4 (U16) = 708 272218 Monitor IPC:0BC6 (U16) = 708 272234 Monitor IPC:0C00 (U8) = 7 272250 Monitor IPC:0C01 (U8) = 7 272250 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.0271891597658 272250 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.0271891597658 272281 Monitor IPC:0BC4 (U16) = 445 272281 Monitor IPC:0BC6 (U16) = 445 272312 Monitor IPC:0C00 (U8) = 0 272312 Monitor IPC:0C01 (U8) = 0 272312 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0.0111920889467 272312 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0.0111920889467 272343 Monitor IPC:0BC4 (U16) = 183 272343 Monitor IPC:0BC6 (U16) = 183 272375 SimRead: 0BC4="BRAKE LEFT POSITION" FLT64: 0 272375 SimRead: 0BC6="BRAKE RIGHT POSITION" FLT64: 0 272406 Monitor IPC:0BC4 (U16) = 0 272406 Monitor IPC:0BC6 (U16) = 0 It is odd that the inital resulting values are so different. I have no idea why. The computation code for the value to be written is the same for C00 and C01 -- only a flag tells the difference. It is something happening insiode FS. As you see above things step into line immediately afterwards. Within 100 mSecs they are even reading the exact same values on each step. I really don't think anyone will be able to detect any discrepancy even assuming there is actually a real one at the brake application level. As observers through a rather circuitous route we can't really tell, you have to try it in practice. The same test on FS9 shows a similar result, though its 0BC4/6 brake readouts are based on a max of 32767, annoyingly enough. ********* FSUIPC, Version 3.976 by Pete Dowson ********* ... 312860 Monitor IPC:0C00 (U8) = 137 312860 Monitor IPC:0C01 (U8) = 137 312907 Monitor IPC:0BC4 (U16) = 22444 312907 Monitor IPC:0BC6 (U16) = 15150 312907 Monitor IPC:0C00 (U8) = 127 312907 Monitor IPC:0C01 (U8) = 127 312954 Monitor IPC:0BC4 (U16) = 13447 312954 Monitor IPC:0BC6 (U16) = 13447 312954 Monitor IPC:0C00 (U8) = 117 312954 Monitor IPC:0C01 (U8) = 117 313000 Monitor IPC:0BC4 (U16) = 11743 313000 Monitor IPC:0BC6 (U16) = 11743 313000 Monitor IPC:0C00 (U8) = 107 313000 Monitor IPC:0C01 (U8) = 107 313063 Monitor IPC:0BC4 (U16) = 10037 313063 Monitor IPC:0BC6 (U16) = 10037 313063 Monitor IPC:0C00 (U8) = 97 313063 Monitor IPC:0C01 (U8) = 97 313110 Monitor IPC:0BC4 (U16) = 8472 313110 Monitor IPC:0BC6 (U16) = 8472 313110 Monitor IPC:0C00 (U8) = 87 313110 Monitor IPC:0C01 (U8) = 87 313157 Monitor IPC:0BC4 (U16) = 7227 313157 Monitor IPC:0BC6 (U16) = 7227 313157 Monitor IPC:0C00 (U8) = 77 313157 Monitor IPC:0C01 (U8) = 77 313204 Monitor IPC:0BC4 (U16) = 5982 313204 Monitor IPC:0BC6 (U16) = 5982 313204 Monitor IPC:0C00 (U8) = 67 313204 Monitor IPC:0C01 (U8) = 67 313266 Monitor IPC:0BC4 (U16) = 4737 313266 Monitor IPC:0BC6 (U16) = 4737 313266 Monitor IPC:0C00 (U8) = 57 313266 Monitor IPC:0C01 (U8) = 57 313360 Monitor IPC:0BC4 (U16) = 3492 313360 Monitor IPC:0BC6 (U16) = 3492 313360 Monitor IPC:0C00 (U8) = 47 313360 Monitor IPC:0C01 (U8) = 47 313407 Monitor IPC:0BC4 (U16) = 2464 313407 Monitor IPC:0BC6 (U16) = 2464 313407 Monitor IPC:0C00 (U8) = 37 313407 Monitor IPC:0C01 (U8) = 37 313469 Monitor IPC:0BC4 (U16) = 1939 313469 Monitor IPC:0BC6 (U16) = 1939 313469 Monitor IPC:0C00 (U8) = 27 313469 Monitor IPC:0C01 (U8) = 27 313500 Monitor IPC:0BC4 (U16) = 1415 313500 Monitor IPC:0BC6 (U16) = 1415 313500 Monitor IPC:0C00 (U8) = 17 313500 Monitor IPC:0C01 (U8) = 17 313563 Monitor IPC:0BC4 (U16) = 890 313563 Monitor IPC:0BC6 (U16) = 890 313563 Monitor IPC:0C00 (U8) = 7 313563 Monitor IPC:0C01 (U8) = 7 313610 Monitor IPC:0BC4 (U16) = 366 313610 Monitor IPC:0BC6 (U16) = 366 313610 Monitor IPC:0C00 (U8) = 1 313610 Monitor IPC:0C01 (U8) = 1 313657 Monitor IPC:0BC4 (U16) = 0 313657 Monitor IPC:0BC6 (U16) = 0 313657 Monitor IPC:0C00 (U8) = 0 313657 Monitor IPC:0C01 (U8) = 0 Both are in line within 100 or so milliseconds, so it shouldn't be a bother? I could investigate the innards of FS to see why the same values result in different initial pressures, but I won't have time this week. Regards Pete
  23. I'm sure that would have been in some context regarding assignments in FSUIPC. If you uncheck that option in FS and don't have your controls assigned anywhere else, of course they'll be dead! Nothing will be looking at them! You should only uncheck that if you are assigning everything (controls and buttons) elsewhere, as in FSUIPC's Axes and Buttons tabs. Detects it where? In the axis assignments? Have you actually assigned it too? And if so, to what control and in what manner? If you assign "direct to FSUIPC calibration" you must calibrate in FSUIPC's Joysticks tab too, otherwise it won't do anything. Unplugging and re-plugging USB devices is not generally a good idea as it could make FS re-detect and re-assign them, and may also make Windows assign them different IDs. FSUIPC does offer a Joystick Lettering facilities, to use letters for assignments instead of the numerical IDs, and then it tries to match them up using the device name. Please always state the version number of the FSUIPC you are using when posting a question. I does help provide the correct answers. Regards Pete
  24. Yes, because that's the same as having a brake pedal axis kept pressed at that point. You need to use the 0C00, 0C01 bytes which emulate the momentary effect of the key controls and include the decay. Regards Pete
  25. Sorry, I cannot make head nor tail out of your code fragment, but I suspect you are simply writing 32 bit values to the offsets, so "destroying" the state of 32 buttons all at once? If you want to manipulate the virtual buttons directly, via the offsets, then you must READ the relevant offset first, then OR in (to set) or AND out (to clear) or XOR (to toggle) the single BIT you want to signal, and write it back. Note that is foolproof if you are the only program doing this, but if there are others then you might get conflicts -- there's bound to be a short period between your read and your write then some other program could read, then write wither before your write or after. The result could be unpredictable button changes for both. To reduce that possibility considerably you should use single byte reads and writes, thus only affecting 8 button bits at a time. If you can select a range of 8 buttons which only your program is using, that'll work well. **** STOP PRESS **** I had planned, for the next main FSUIPC release, a new facility to make this a lot easier and foolproof. I've decided to release it now, in an interim update. Please look out for FSUIPC version 3.976 or 4.593 in the Updates annoucement in this Forum a little later today (Monday). With this facility to can set, clear or toggle any of the virtual buttons without needing to read anything first. It will be like this: Write to offset 29F0 a 32-bit value (4 bytes) made up as follows: Byte 0 = Button Number on Joystick (0 - 31) Byte 1 = Virtual Joystick Number (64 - 72) Byte 2 = Action: 0 = Toggle, 1 = Set (Press/On), 2 = Clear (Release/Off). Byte 3 = 0 (Reserved) So, for example, you can send 0x00014016 to offset 29F0 to "press" button 22 (hex 16) on joy 64 (hex 40). Or you could use a 4 bytes array: BYTE mybuttons[4] = { 22, 64, 1, 0 }; 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.