-
Posts
38,265 -
Joined
-
Days Won
170
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by Pete Dowson
-
WideFS6 (FS9) connection problem
Pete Dowson replied to camaflight's topic in FSUIPC Support Pete Dowson Modules
No errors there either. Same abysmal performance: No, not a "cross" cable -- that's only for PC to PC connections. All the connections from router to PCs are normal straight ones. Well, unlimited seems to give you better fps but can make things more, er, choppy. What you are really after is a good consistent rate. And it varies how to achieve that. Try both -- a limit of 30 or 35 would be good in any case (though actually something like 28 is recommended by some experts -- it is related to the screen refresh rate of 60 with a little leeway. 58 would seem closer but not attainable all the time, whereas 28 would be, 2x30=60). Regards Pete -
UTTERLY LOST WITH CONTROL ASSIGNMENTS
Pete Dowson replied to SimSamurai's topic in FSUIPC Support Pete Dowson Modules
The names FS gives things in the dialogues hardly ever looks the same as their internal names for them. FSUIPC doesn't know the names or the numbers by itself, it just gets the complete table, names and numbers, from FS's "CONTROLS.DLL", where they are defined. The names in the dialogues will of course be different in different language versions -- the internal names don't change, and mostly haven't changed (except for many additions) since FS98 days. This is with FS9, isn't it? I forget now. If so, yes, unfortunately the FSUIPC treatment of the POV devices is now different from FS's. (POV = "point of view", the Microsoft name. "Hat" is the name I think first used by Thrustmaster -- or possibly by an Air Force somewhere ). In FS9 FSUIPC uses the original Windows API for joysticks, which is nice and simply and very efficient. When FSUIPC was written, FS also used this interface -- and both treated the Hat as a set of 8 buttons, with the result you see. For looking out of different windows etc it is fine -- that's what it was intended for really, at that time, and that is what still suits a lot of cockpit builders where they relate things to their built cockpit windows. "Smooth panning" has become more significant with virtual cockpits, which are of course relatively new. FS now uses DirectInput, and this allows POVs to be used as Axes as well as or instead of a set of buttons. When re-writing FSUIPC for FSX I changed over the axis scanning to use DirectInput (ugh! what a horrible interface) -- but left the buttons scanning as it was, for better efficiency. So, in FSUIPC4, for FSX, you can assign a Hat as an axis or as a set of 8 buttons (or even both). When assigned as an axis, you can assign it to "PAN VIEW", which is what FS does. And that's smoother. Okay. Thanks. Regards Pete -
WideFS6 (FS9) connection problem
Pete Dowson replied to camaflight's topic in FSUIPC Support Pete Dowson Modules
Well, possibly. I would certainly not use a wireless connection in my cockpit as there are too many metal objects in the vicinity and wireless tech does NOT like them. I get poorer transfer successes at 6-8 foot distances in my cockpit room than I do between complete rooms, through walls, in the rest of the house -- bar the kitchen where again there's a hulking great metal fridge-freezer, microwave, ovens etc to ruin it all. All those application messages really mean is that they are timing out when waiting for responses from the Server, in the FS PC. No errors reported there -- just abysmal performance: The reception average should be close to your FS frame rate, up to a limit. The log does show that Active Sky made 44 requests, though many of those might have been retries, if it was timing out the responses. The Client log only gives half of the story. Have you looked at the WideServer log to see if that has any problems to report? Regards Pete -
Looking for FPA adjustment control
Pete Dowson replied to rwebb616's topic in FSUIPC Support Pete Dowson Modules
Oh, right. I understand now. Quite different from Boeing then. I had a copy of X-Plane sitting here for months. One idle moment I decided to install it and take a look. I'm afraid I don't like it. As far as I could tell this version 9.xx is pretty much still as bad, graphically and scenery-wise, as when I first looked at it back in version 6 or 7 days (when it was about four times the price). And, to me, the flight models still suck. But each to his own! ;-) Regards Pete -
Looking for FPA adjustment control
Pete Dowson replied to rwebb616's topic in FSUIPC Support Pete Dowson Modules
I don't know VASfmc, but if it is simulating a proper FMC then the FPA value is set in the descent page of the CDU. I don't think any FMC implementation would provide controls for all of the CDU functions, there's too much and mostly it has to be done using the CDU keyboard and buttons. And I don't know how VasFMC uses its offsets if it has any (I don't recall if it has an allotment offhand, sorry). Regards Pete -
Combine Lua Vals in Macros?
Pete Dowson replied to guenseli's topic in FSUIPC Support Pete Dowson Modules
I need an example for this, please. Okay. Why not what you wanted, above? You wanted to do this: So, write a Lua program with only these lines: ipc.control(66587, ipcPARAM) lbat = ipc.readLvar("L:LeftBatSwitch") ipc.writeLvar("L:LeftBatSwitch", 1 - lbat) Then assign a button to this Lua program, entering 8028 in the Parameter field. The 8028 is the value then in ipcPARAM. You can have as many buttons calling this one Lua program as you like, each with a different parameter. No, no ,no. A line like "ipcPARAM = 1" sets the value 1 to the variable ipcPARAM. So it does no good for you at all. You need to test the value already in ipcPARAM, thus: if ipcPARAM == 1 then ipc.writeLvar("L:pmdg_hide_yoke", 0) ipc.writeLvar("L:pmdg_hide_yoke", 0) ipc.writeLvar("L:pmdg_hide_yoke", 0) elseif ipcPARAM == 2 then ipc.writeLvar("L:pmdg_hide_yoke", 1) ipc.writeLvar("L:pmdg_hide_yoke", 2) ipc.writeLvar("L:pmdg_hide_yoke", 3) end Take a look at the Lua website. There's lots of help there. I cannot teach folks Lua, there are better sources! If you are really interested I'd recommend the book "Programming in Lua". Regards Pete -
Combine Lua Vals in Macros?
Pete Dowson replied to guenseli's topic in FSUIPC Support Pete Dowson Modules
Why not just have a macro for the L:var setting and make two assignments to the same button or switch? Multiple assignments to buttons is the usual method, the one that preceded Macros and Lua files for many years. Lua commands can already be combined like that, because Lua files are referenced by number via the Lua Files reference list built up in the INI file. You are mixing up "L:vars", the local gauge variable, with Lua -- two completely different subjects. The problem with L:vars is that you most certainly need the name, and building up an index for every possible L:var which might occur on any user system is a forbidding prospect. Some add-on airliners have hundreds. Worse, they may use similar or the same names for different functions, so you need an index per plane. Ugh! As described in the FSUIPC Lua documentation, Lua programs are started with the value of "ipcPARAM" pre-set to the parameter value you enter into the Parameter field for the calling Key or Button press assignment, and you can use that parameter for whatever you like -- maybe an FS control number, or maybe just an index to switch to different parts in your Lua program. FS controls are sent to FS by the "ipc.control(...)" command. Please scan down the list of facilities in the Lua Library documentation. Regards Pete -
UTTERLY LOST WITH CONTROL ASSIGNMENTS
Pete Dowson replied to SimSamurai's topic in FSUIPC Support Pete Dowson Modules
But you've assigned them now, right? Not really, though FSUIPC won't let you set the minimum to a higher value than the maximum and of course the centre values must be in between. The normal thing to do is assign the minimum (the most negative), then the centre values, then the maximum (most positive) -- but only because this is the most logical. It isn't a "left" or "right" business as which is left and right numerically speaking is arbitrarily chosen by the simulator. Just look at the INput number so you can see which way it is changing. The manual gives numbered steps for the most logical order. It sounds like you've not looked at it yet! :-( . Surely I don't have to reproduce it all here? Please please PLEASE go to the Joystick Calibration chapter: it tells you all this stuff there! I don't understand how you can be so critical of my work when you obviously haven't even looked at it! The numbered steps follow the statement "Now, to calibrate any axis, just do this:". :-( My last reply for the first, and the FSUIPC User Guide, evidently, for the second. Pete -
UTTERLY LOST WITH CONTROL ASSIGNMENTS
Pete Dowson replied to SimSamurai's topic in FSUIPC Support Pete Dowson Modules
Is that the document for which there's a link provided in the "sticky" thread entitled "FSUIPC Guide for CH Users" near the top of this Forum? If so, then, sorry, but I thought that would be the first place you'd go if you had specific CH questions. That's why it was made "sticky". If that isn't the one, can you clarify, please? That's very kind of you. Yes. If you like I could host in on the same server as the Updates and Goodies (the top Announcement in the Forum), and then I could actually list it in the Goodies section, or, if you like, you could do the same as the "FSUIPC Guide for CH Users" -- post a message with some explanatory words and provide the link I shall give you, and I would then make the post sticky. You can send the PDF for me to upload to petedowson@btconnect.com. Which keystroke are they? You can always assign keystrokes, of course, but there are these FS controls which are better and avoid possible problems should a user reassign keys or have a program which needs them: Normally 'S' in FS9 = VIEW MODE Normally "shift S" in FS9 = VIEW MODE REV Normally "W" in FS9 = PANEL HUD TOGGLE For future reference, if you ever want to know the name of an FS control but do know how to activate it via the keyboard or an existing button assignment, just go to FSUIPC's Logging tab and enable Event logging (or Axis logging if it is an axis control). Then activate the control, and look in the Log file (FSUIPC.LOG, in the Modules folder, for FS9). There will be a line in there which gives the control number (from the reference list) plus the parameter (normally zero) and the Name, at the end, like this: *** EVENT: Ctrl=, PARAM = , The FS name is the one used, with _ replaced by spaces and mostly changed to lower case, in the FSUIPC assignment drop-downs. Yes, you can edit the INI file by hand. You can get changes reloaded by FSUIPC without restarting FS -- just go to the relevant options tab and click the "Reload" button. In fact it is best if you have the relevant options page in view whilst you are looking for the parameters and editing them, so you can match things properly. Many of the parameter sections are documented in the Advanced User's guide. In particular there's a lot of space in there given to the Buttons assignments, because you can do a lot of clever things of a programming nature with those -- conditional actions on buttons, and so on. There's an example provided by a user of how to use the same set of buttons several times according to a state set by other buttons, and so on. There's currently no special explanation of the joystick calibration section as really the method of using the buttons in the dialogue is good enough. I've never seen anyone have a need to mess in there, though you can -- the parameters should be easy enough to understand, relating them to the values you see on screen. They are all in the one INI file -- there's only one! ALL your FSUIPC settings are in the one file. However, I think you are still misunderstanding something. If you make the numbers match it is very likely then that the levers will not be calibrated to work together. Every axis is slightly different -- I'd be most surprised if they are identical in the values they give for the same positions. The whole point of calibrating each separately, and by actual physical position, is to use the actual numbers that the actual hardware is providing! If everything always provided the same numbers for the same relative positions, calibration would never be needed and the software (FS or FSUIPC) could assume fixed values for all the numbers. Real life isn't like that. Regards Pete -
UTTERLY LOST WITH CONTROL ASSIGNMENTS
Pete Dowson replied to SimSamurai's topic in FSUIPC Support Pete Dowson Modules
Which one is that? On this Forum, do you mean? There is no difference in the way the facilities for calibrating work between FSUIPC3 and FSUIPC4. Basically, if you only have one lever of each (throttle, prop pitch, mixture), then to enable a reverse range you check the "4 to 4 xxxx" on the first calibration page, then go to the pages dedicated to each class of control (each has 4 slots, for up to 4 engines), and simply calibrate the first one, at top left. With one lever and the mapping selected, the other three will mimic that first one in any case. You would see that if you bothered to try it. The process for calibrating with a forward, centre/idle and reverse range is in fact just following the simple numbered steps provided in the FSUIPC user Guide, in the section about calibration. I think also that you are currently mixing up "assignment" with the other things you want to do. If you get that straightened out in your mind perhaps you will be less confused. How you assign your axes is not directly related to how you then use them -- the latter is to do with calibrating them to achieve your desires. To start with simply use the normal FS assignment and go straight to the Joysticks tab in FSUIPC. Sorry, i know nothing whatsoever about CHCM, but judging by other posts here folks either like it and use it or discard it and use FSUIPC instead. I suspect it makes matters far too complicated to use both, and maybe inefficient too. What's a "code file"? Do you mean INI file settings, for cutting and pasting? Sorry, everyone's needs are different. FSUIPC is like a Swiss Army knife, a multi-tool for use as you wish. And there are nearly as many ways of doing things, with almost as many hardware configurations, as there are users. I cannot see how anyone's settings can simply be transferred to anyone else's setup. Even the calibration points won't be consistent -- I've been told that even two identical throttle quadrants calibrate differently (these were from Saitek, but i don't think CH are any more consistent). In my opinion trying to understand and apply rather weird looking parameters made for one system to a different one would cause more headaches and confusion and questions than just following the really simple instructions and doing it yourself. The parameters are made for efficient understanding by computer program, not by humans. The human interface is represented by the on-screen options dialogues, and they are clearly explained in the User Guide, with pictures and numbered steps. Okay, there are lots of options, but the reader can select the ones which apply to him. They've all grown out of user requests after all. And many thousands of users seem to be able to understand things. In the end, if you were getting on fine with CHCM and don't understand FSUIPC at all, as you seem to be saying, why on Earth are you bothering to even try? I don't understand. If you like it, use it, if not don't. Regards Pete -
Oh, I'm sorry. I just thought that, now you are getting into Lua type plug-in use, you might appreciate facilities in Lua for connecting to a Network and/or the Internet -- that's what "sockets" is all about! ;-) Regards Pete
-
UTTERLY LOST WITH CONTROL ASSIGNMENTS
Pete Dowson replied to SimSamurai's topic in FSUIPC Support Pete Dowson Modules
Well, please, if you try following the steps or try to understand a section, and reach a point where you are stuck, please do ask. I like specific questions as it helps make warranted improvements to the documentation. This is how it got to where it is now. If you think it is bad now, you should have seen it ten years ago, with the early versions! The fact that it has reached such a ridiculous size is not just because of the addition of facilities but much more as a result of folks asking questions I didn't realise would be asked, and then me adding those answers into the document. Maybe that isn't the best way to write documentation, but it is a practical one for a technically oriented person. Regards Pete -
FSUIPC & LuaSocket
Pete Dowson replied to manuelgonzales's topic in FSUIPC Support Pete Dowson Modules
Hi Manuel, Sorry about the delay, but it took me longer than I thought. The problem with LuaSockets in FS was that the precompiled parts, the socket and mime core DLLs, contained actions which conflicted with things in FS. However, I am about to release updates of FSUIPC3 and FSUIPC4 with LuaSockets support included. These are the changes: 1. The "print" function in Lua now acts like the ipc.log function, and using the io library for writing to the "stdout" and "stderr" devices also writes the results to the log. This enables ready-made Lua programs which do produce their results with those functions to be used without modification. 2. Lua library modules called for by Require are now looked for in the FS modules folder, but also, and preferably, in a subfolder modules\lua. This enables Lua programs not meant to be run direct from FSUIPC to be kept separate, and also allows code DLLs to be used on FS9 without crashing FS when it tries to load them as modules of itself. 3. Full support has been added for the LuaSockets package (see http://www.tecgraf.puc-rio.br/~diego/prluasocket/ ). In fact it is made a lot easier than the package suggests, as these main modules are built in as "preloaded modules" (still needing "Require", but not files): The two C/C++ core modules: socket.core and mime.core The three main Lua modules: socket.lua, mime.lua and ltn12.lua There are a load of little utility Lua programs provided in the LuaSockets package too, but I've not built those in. They are best placed, if required, into a Lua folder, within the FS Modules folder. I will include versions of the "testclnt" and "testsvr" Lua plug-ins, which are acceptance tests for the validity of the implementation, and also two plug-ins "MasterClient" and "SlaveServer" which can link two copies of FS with one slaved to the other as far as user aircraft position and attitude is concerned. It runs quite nicely even in the crude unoptimised Lua code I've used in the examples. I hope to release the updates tomorrow or Friday (25th October). Regards Pete -
:wink: :wink: Well, in the next updated FSUIPC versions you will be able to add DontResetAxes=Yes to the [General] section of the INI file. This may help, I don't know, but probably not if 0 really is being returned as it seems to be. More interesting changesin the next updates are in the Lua facility: 1. The "print" function in Lua now acts like the ipc.log function, and using the io library for writing to the "stdout" and "stderr" devices also writes the results to the log. This enables ready-made Lua programs which do produce their results with those functions to be used without modification. 2. Lua libray modules called for by Require are now looked for in the FS modules folder, but also, and preferably, in a subfolder modules\lua. This enables Lua programs not meant to be run direct from FSUIPC to be kept separate, and also allows code DLLs to be used on FS9 without crashing FS when it tries to load them as modules of itself. 3. Full support has been added for the LuaSockets package (see http://www.tecgraf.puc-rio.br/~diego/prluasocket/ ). In fact it is made a lot easier than the package suggests, as these main modules are built in as "preloaded modules" (still needing "Require", but not files): The two C/C++ core modules: socket.core and mime.core The three main Lua modules: socket.lua, mime.lua and ltn12.lua There are a load of little utility Lua programs provided in the LuaSockets package too, but I've not built those in. They are best placed, if required, into a Lua folder, within the FS Modules folder. I will include versions of the "testclnt" and "testsvr" Lua plug-ins, which are acceptance tests for the validity of the implementation, and also two plug-ins "MasterClient" and "SlaveServer" which can link two copies of FS with one slaved to the other as far as user aircraft position and attitude is concerned. It runs quite nicely even in the crude unoptimised Lua code I've used in the examples. I hope to release the updates tomorrow or Friday. Regards Pete
-
But if you close DIView and start it again, does it repeat the 50%? I suspect so. When you enter and leave the Axis assignments, in FSUIPC4 (but not FSUIPC3), it has to close and reopen the DirectInput API in Windows. This is why FSUIPC4 can detect new devices without restarting FSX, whereas FS cannot. I consider it an essential and beneficial feature. It isn't needed in FSUIPC3 because it doesn't use DirectInput. It seems the driver for your devices does not provide initial DI readings when opened, only after the axes are moved. I cannot reproduce anything like that here, but then the only DirectInput devices I have are an old Saitek game paddle thing and a Microsoft wing sort of controller, two things I keep for these tests as they are typical examples. They are both using default Windows drivers in any case. I'm afraid there's really nothing more I can do. I'd advise you to resist continually visiting the Axis Assignments dialogue whilst using your simulator for its real purpose! ;-) Regards Pete
-
The example was showing how a button screen could look, with parameters to label the buttons. But they are still only buttons -- buttons with labels, yes, but just the same as if you connected loads of buttons to FS and didn't assign them to do anything. You can label them all you like, but labelling something doesn't make them functional, it is only a reminder of what you have or should have programmed the buttons to do. The interaction in FS will be seen in FSUIPC's Buttons and Switches options. When you click on a button, whether labelled or not, then (provided that button square is not disabled or assigned a special function like go to next page), you will see the button number come up in FSUIPC, and you can program it as you would any real button. Regards Pete
-
Those are not "raw" values -- you don't have "raw" selected. Actually, when you first enter the Axis assignment tab, it should show nothing -- if it shows something, then you have an axis movement detected and in this case "0" is what it read. The value will show only if it is different from the last one read and acted on. At present (without the option I can implement to bypass it), when you exit from the Axis tab, FSUIPC resets all of the "previous values" to an impossible value, so that any value it then reads will be different enough to register an input. I think this is correct behaviour, but i can allow a bypass option. The fact that they all went to 50% must mean that it read values from your axis which told it those were the places to do (after your calibration, of course). Probably the values of zero it seemed to get were correctly 50% (the range usually being, ideally, -16383 to +16383 with 0 central, so 50%). It sounds exactly like your levers are going to sleep, or the drivers are strange, and giving zero until moved. Have you disabled power management on your USB sockets, in Windows? The removal of power by Windows is the most usual reason, but it could also be a driver or device function. Try "diview", attached, to see the behaviour of your devices (independently of FS and FSUIPC). What you are seeing most certainly is not FSUIPC behaviour. Try letting the devices rest for a while, then check them with diview without moving anything. Regards Pete DIView.zip
-
UTTERLY LOST WITH CONTROL ASSIGNMENTS
Pete Dowson replied to SimSamurai's topic in FSUIPC Support Pete Dowson Modules
Until and unless you actually use FSUIPC to make assignments, calibrations, and so on, it isn't doing anything. merely installing it will install it with default settings anyway -- all pressing set Defaults does is return all the weather and miscellaneous options to default, it doesn't touch any controls and anyway if you've only just installed and registered it it won't have any. It is most certainly nothing whatsoever to do with FSUIPC that FS (or more likely Windows) wanted you to unplug and replug your controllers. I suspect that is related to Windows power management on the USB sockets -- unless you turn that off, Windows removes power from USB devices which haven't been used for a while. It depends what you want to do. You can assign everything in FS and merely calibrate the axes in FSUIPC. You can assign buttons in FSUIPC, but then make sure you don't have the same buttons assigned in FS -- else they'll do both things. Or you can opt to use FSUIPC for everything, in which can you disable all (or selected) controllers in FS altogether, and assign both buttons and axes in FSUIPC. You still do the calibrations in the same way. It is a little more efficient doing it all through FSUIPC, and more flexible too as there are more options, but it is a big step. Perhaps try just calibration first. Pontification? It states facts, and provides pictures and even gives a step -by-step guide to exactly how to do the things you want to do. I'm sorry if you don't understand anything, but it really sounds as if you are simply not applying any patience. I cannot explain things here in greater detail than in the manual. There is MUCH MUCH more room in the manual for the help you need, and it is ALL there, believe me! I see no point in reproducing parts here. Perhaps you should have read it and made sure you understood it at least a little before you purchased it? All the information was available to you beforehand, after all. I don't mind helping out with specific questions, and I have always done so, but coming here and asking for a complete new manual written the way you want it is just not on. Sorry. Try a little harder, please, and ask specific questions when you have some. If you want to do clever things you need to be a little bit clever. If you want to do easy things, it is easy. Pete -
Me too. What I see happening is this: If I go into FSUIPC options and open any TAB other than the Axis assignments tab, then OK out, there is no re-scan of the axes and nothing is logged by that LogExtras=8. If I do into the Axis assignments and OK out any time later, the axes are scanned like an initial scan and their current values are actioned. This is deliberate and normal and should do no harm because all it is doing is re-using the values already set. Sending the same value to FS merely ensures that the levers and controls are where they should be and where they were last. If they have been moved whilst in the Axis tab (for instance just to identify them), then their new positions should be reflected in the aircraft settings too, on exit. Now, actions on the right-hand side of the assignment might be more of a problem with this: the action is only supposed to be triggered when the axis passes over certain set threshold values, not when it merely stays in the zone it was in before. Probably it is this which explains the original symptom you complained of, with the Flaps Dial -- though it seems to me that if the axis controlling that was in the position for the flaps dial, sending it again should have done no harm. Can you explain why it was/is a problem? If really necessary, I will certainly look to see what I can do to avoid the actioning of right-hand side zone triggers on exit from the Axis assignments options, but that may well pose a little problem as it has to record where the axis is now so it can still detect the transition across to another zone. Additionally, if the axis was moved whilst in the axis tab, even though no changes might have been made there, then FSUIPC ought to action the reslut on exit -- otherwise the result doesn't match the axis position. None of this, however, explains why you are seeing axis triggering on ANY entry and exit from the FSUIPC options. I cannot see how that can happen, because nothing in the axis scan is changed by that. It is only when the axis assignments tab has been visited. And it has to reflect the current axis positions on exit in case you moved any. I should probably really do so with the calibrations tab, for the same reason. It also doesn't explain weird sequences of axis changing such as you show in your logs. Look at your latest one: The "LogExtras=8" facility logs every actionable axis scan reading which FSUIPC detects. So, in your case, these are the detections and actions by FSUIPC, presumably on exit from the Axes tab in options: 451748 Axis AZ=0: Action=48 (direct to calib) 451748 Direct Axis 4, Ctrl 65765=0 : in calibration ... 451748 ###JOY### Event seen, ID=65765 (0x000100E5), Joy=3(D), value=0 (Direct) 451748 Direct Axis Control 65765=0 (cal=0): sent as Event 451779 *** AXIS: Cntrl= 65765 (0x000100e5), Param= 0 (0x00000000) AXIS_THROTTLE_SET =================== 451779 Axis AV=0: Action=33 (direct to calib) 451779 Direct Axis 33, Ctrl 66504=0 : in calibration ... 451779 ###JOY### Event seen, ID=66504 (0x000103C8), Joy=32, value=0 (Direct) 451779Gone for filtering as axis 32, ctrl 66504=0 451779 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 3778 (0x00000ec2) AXIS_PAN_HEADING =================== 451779 Axis DX=0: Action=5 (direct to calib) 451779 Direct Axis 5, Ctrl 66291=0 : in calibration ... 451779 ###JOY### Event seen, ID=66291 (0x000102F3), Joy=4, value=0 (Direct) 451779 Direct Axis Control 66291=0 (cal=0): sent as Event 451810 *** AXIS: Cntrl= 66291 (0x000102f3), Param= 0 (0x00000000) AXIS_PROPELLER_SET =================== 451810 Axis DY=0: Action=9 (direct to calib) 451810 Direct Axis 9, Ctrl 66420=0 : in calibration ... 451810 ###JOY### Event seen, ID=65820 (0x0001011C), Joy=8, value=0 (Direct) 451810 Direct Axis Control 65820=0 (cal=8223): sent as Event 451810 *** AXIS: Cntrl= 65820 (0x0001011c), Param= 8223 (0x0000201f) THROTTLE1_SET ==================== 451810 Axis DZ=0: Action=10 (direct to calib) 451810 Direct Axis 10, Ctrl 66423=0 : in calibration ... 451810 ###JOY### Event seen, ID=65821 (0x0001011D), Joy=9, value=0 (Direct) 451810 Direct Axis Control 65821=0 (cal=8224): sent as Event 451857 *** AXIS: Cntrl= 65821 (0x0001011d), Param= 8224 (0x00002020) THROTTLE2_SET ===================== Now all those should not have caused any change as the values read now should be identical, or close to, the values sent for the same things last time. The rest of the Axis events detected and logged by FSUIPC: 451857 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 2007 (0x000007d7) AXIS_PAN_HEADING 451904 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 1192 (0x000004a8) AXIS_PAN_HEADING 451997 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 818 (0x00000332) AXIS_PAN_HEADING 452060 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 645 (0x00000285) AXIS_PAN_HEADING 452107 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 567 (0x00000237) AXIS_PAN_HEADING 452169 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 530 (0x00000212) AXIS_PAN_HEADING 452216 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 513 (0x00000201) AXIS_PAN_HEADING 452325 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 506 (0x000001fa) AXIS_PAN_HEADING 452372 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 502 (0x000001f6) AXIS_PAN_HEADING 452419 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 500 (0x000001f4) AXIS_PAN_HEADING 452528 *** AXIS: Cntrl= 66504 (0x000103c8), Param= 499 (0x000001f3) AXIS_PAN_HEADING are most certainly NOT caused by FSUIPC detecting any axis changes. This is something else you have going on. I'm sorry, but I don't know how to help with those. What I might do is provide an INI file [General] option to not trigger any axis refreshers after exit from the Axis assignments tab. I won't have that on default, as I think that would be wrong for the reasons I've stated. but it may enable you to at least diagnose the other problems which you seem to get as a possible consequence. Regards Pete
-
Yes, thats it. Well, in that case, if it were a fault of FSUIPC, surely everyone would see it -- myself included? I don't understand how it only affects you, and you are not a new user to FSUIPC are you? Nor I. It makes no sense at all I'm afraid. I've just checked my code. There is some extra logging you can add, please. Fiirst, before running FSX, add Debug=Please LogExtras=8 to the [General] section of FSUIPC4.INI. (You may laready have a LogExtras line -- if so, replace it). Note that you can edit the Extras number in FSUIPC logging tab once 2Debug=Please" is set. This will do a lot of exctra logging in the Axis assignment and scanning routines, so please don't fly with it like this, just do the short tests. Thanks you. Pete
-
Ooops. Of course it is. I knew that! :oops: Okay. The axis logging, for your throttle axis, obviously doesn't happen when all of the action is via the range assignments on the right-hand side. I'll try to set up a similar arrangement here (not with the MD-11 though) and see if I can reproduce it. If not i shall have to add some more logging and get you to rerun the tests. [FROM YOUR LATER POST] Let me get this straight, please -- you have it happening with axes which are assigned normally, with no ranges defined on the right-hand side with specific controls? If this was a general problem with normal axis assignments then there'd be a lot more folks reporting it, including myself since all my axes are always assigned in FSUIPC, not in FSX. If it is completely independent of anything set in FSUIPC's INI file, then it is looking like a hardware problem, a lot of unwanted axis jitter. Though why that should only occur on exit from the FSUIPC menu is odd -- except perhaps that would be where the joysticks are re-scanned for identity. I'll wait for your reply before I try any experiments with range assignments. Regards Pete
-
Whenever you make changes to any part of the INI file (other than the [General] section, which does require a reload of FS), all you need to do is use the appropriate "Reload" button on the options screen -- there's one for each of Buttons, Keys, Calibrations and Axes. They operate on their sections only. Regards Pete
-
Extracting gauge informations from FSX
Pete Dowson replied to marios's topic in FSUIPC Support Pete Dowson Modules
For gauges in FS panels you need the FSX SDK which is on the DeLuxe FSX DVD (with SP1 and SP2/acceleration updates on-line). For external software, maybe driving hardware, you can either use the built-in interface (SimConnect), or FSUIPC. That's your choice. For SimConnect again you need the FSX SDK. For FSUIPC you need the FSUIPC SDK. Well, i'm not sure about that. FSUIPC has the advantage of compatibility with older versions of FS, but FSUIPC4, the version which runs in FSX, uses SimConnect itself for almost everything. Lots of folks do that sort of thing. There's an excellent book about it, with help on the software side too. It is by Mike Powell -- see http://www.mikesflightdeckbooks.com Regards Pete -
Buying FS Wide when e-mail adresse is changed
Pete Dowson replied to camaflight's topic in FSUIPC Support Pete Dowson Modules
I think you can tell them the email address you need it to be registered for, perhaps referring to your earlier purchase. Is there a place to provide extra information like that? If not perhaps raise a Problem Ticket about it beforehand? If none of that works, then after purchasing you can raise a Problem Ticket and they will deal with it, and I can also deal with it -- but they are usually quicker (and I might be away or something ;-) ). If you have to come back to me, just raise the matter first. Don't post your details or keys. Regards Pete -
Strange issue with WideFS
Pete Dowson replied to rwebb616's topic in FSUIPC Support Pete Dowson Modules
You keep making extracts from the logs, which prevents me checking version numbers. If you do that please be sure to tell me exactly what the numbers are recorded at the start of each log. That is important for me, because I don't want to waste time on older versions, and at least the logs are proof of what you are using. In the Server log, this occurs again, and it is very strange: So it isn't coincidence that just after it connects, the server decides to restart its service. Weird. I have not seen anything like that before. You haven't changed any of the client or Server INI file settings, have you? (The Server ones are in a section of the FSUIPC4.INI file). Well, it is not a real problem in that once it starts properly it stays okay. But still, I'd like to know why it is happening -- but first, version numbers please. And have you tried giving WideClient the explicit server details -- i.e. setting the ServerName (or ServerIPaddr) and Protocol parameters in its INI file? I'm wondering if it is related to the Broadcasting on your setup. Regards Pete