Pete Dowson

The virtual button range can only be set by software designed to set the bits in those offsets. Any regularly recognised joystick device will be seen by FSUIPC and is assignable, but can only have the joystick numbers 0-15. These are the IDs assigned normally by Windows and found in the Registry. There's no way such a device can also appear in the virtual joystick range unless there's some driver or other software (like your Lua plug-in) actually writing to the offsets for those virtual buttons. In the case you are citing, the C.V.P. Joydtick had the ID 11. That's why you have "11=C.V.P Joystick". Because it has been assigned the letter T it will appear in the FSUIPC option tabs as Joystick T. T and 64 are absolutely distinct as far as FSUIPC are concerned. One is a DirectInput device, the other merely a set of bits in an offset. You have something else going on. There's no way anything in FSUIPC can invent an input on a regular joystick which it is reading in the usual way via DirectInput. So the CVT joystick button inputs to the PC itself are being triggered by your other device. I can't really speculate further than that. All I can say that this is all happening outside of FSUIPC, and probably outside of Windows too. It would be a driver or a hardware or a hub problem. Pete

Well, there's nothing there I can see which could possibly affect mouse operations. This worried me though: You appear to have gone through virtually all the Calibration pages clicking the "Set" button. So FSUIPC is trying to process every single analogue control which it can possibly calibrate, even though there is no way you have that many axes assigned or even installed. All of them, even the ones you are using, have default values, so even though you've done this you've not actually tried to calibrate. I suggest that, as a start, you delete all those lines above before loading FS. THEN, for the axes you do have assigned (probably aileron, elevator, rudder and throttle) go back into the Calibration tab, and calibrate them properly (there are numbered steps in the FSUIPC User Guide). [LATER] Just for clarification, assuming you have disabled controllers in P3D as you should when assigning in FSUIPC, you have these assignments: 0=0X,256,D,1,0,0,0 Ailerons (direct to FSUIPC) 1=0Y,256,F,65694,0,0,0 Elevator (via P3D) 2=0S,256,D,4,0,0,0 Throttle (direct to FSUIPC) 3=1X,256,F,66387,0,0,0 Left Brake (through P3D) 4=1Y,256,F,66388,0,0,0 Right Brake (through P3D) 5=1R,256,F,65696,0,0,0 Rudder (through P3D) Oddly you have chosen the old FS98-compatible FS controls for Elevator and Rudder, but the modern AXIS_ controls, the same ones FSX and P3D use, for the left and right brakes. Really you'd be better off being consistent. Either use "direct to FSUIPC calibration" controls for all of them, or "AXIS ..." FS controls for all of them. Pete

Where are you seeing those values, please? I don't know of any normal joystick type device which behaves like that, at least not after proper setting up in Windows. Have you checked that it is set up and calibrated in Windows? Please show me the Logfile then, so I can see. I don't know what all this stuff is below. It looks like it is out of any context. Can you explain? Then this, which is even more puzzling: This makes no sense. If the throttle is only providing positive values, as you stated above, WHY do you think you need to do more to make it give only positive values? Don't you see, you aren't making any sense? This is all to do with internal FS values, it is nothnig at all to do with joystick inputs or calibration. A normal single throttle input to FS runs from -16384 (idle) to +16383 (full thrust), so your 32% would be around -5898 from the throttle axis. That's if you assign to the normal throttle axis control, whether in FS or in FSUIPC (makes no difference). The positions of various detentes on your throttle range would have to be determined and marked after you have the main full range working. You are using an analogue input with values which change as you move the lever. You would need to find the positions which give you the values you appear to "require" (which I don't understand, incidentally).. It you want the lever to act more like a multi-way selector, without worrying about increasing or decreasing values, you can use the Right-Hand side of the axis assignment tab instead of the left. Don't assign to the normal throttle axis, but assign specific positions to "ThrottleN_Set" controls with the parameter set to the precise value you seem to think you need. The N is the engine number. The ThrottleN_Set controls do run from 0-16383, so your percentage points will be okay for such controls. Pete

Excellent! That was easy, then! ;-) Thanks for reporting back. Pete

No, sorry. I can't see any useful data from here. In your position I would be using a USB monitoring program to log the actual data being received at the PC, and trying ot work out what that looks like to the Lua HID functions, and compare the results to those logged by the Trace/Debug facility in Lua. Haven't you tried debugging the Lua using the facilities available to you? That would be the first step. If you add: Debug=Please LogExtras=x200 to the [General] section of the FSUIPC4.INI file before running FS you will get a lot more logging regarding what the HID code for Lua is doing. On the hardware/firmware side, for USB devices I use the "Device Monitoring Studio" USB package by HHD. There is a free (limited) version If you do find anything which you think may be due to something wrong in FSUIPC do let me know. I've never had any opportunity to test with anything more than PFC, GoFlight, Saitek, and Leo Bodnar boards. Never anything with 256 button capabilities! Pete

This means they are not assigned! The calibration tab (which must be what you mean by "controllers tab"), only provides calibration for axes already properly assigned to the function you want to use them for. That is performed in the axes tab (or, for anything other than the current P3Dv3) in the sim).! Of course. That's what you should have done anyway. But if, in FSX, you had the control axes assigned in FSX, not in FSUIPC, that still won't work, because P3Dv3 currently has serious faults with its assignments. PLEASE please do read the pinned thread at the top of this Forum about this very subject! Pete

Sorry, I don't know what the number associated with "Stackhash_" is intended to convey. You can of course use FSUIPC Monitoring to monitor the rudder trim value. 0C04 as type S16, or more accurately 2EC0 at type FLT64. The latter is the actual trim angle in radians. And you could try stopping whatever it is which is trying to change the rudder trim. Normally rudder trip is kept perfectly centred or neutral. Pete

Have you assigned any? If so, where and what to? Sorry, This part makes no sense in relation to the first part. In fact t doesn't make a lot of sense to me anyway. Care to explain what you mean by such conflicting statements? What was the 'previous version' you used, and which worked "rerfectly", the rudder pedals and brakes you say run normally? Why are you re-calibrating in any case? Why on Earth did you delete your settings in the first place? I can't really give any without any useful information. I'd need to see your FSUIPC4 log and INI files to start with, and a clearer explanation of what you mean without the contradictions, please. And PLEASE don't try to hijack threads which are about something completely different and even pinned at the top for general reference. I didn't think I'd have to lock them to prevent this! :-( Pete

You mean it doesn't see them in the assignments tab (Axes or Buttons & Switches)? Does it list them in the Log file or the INI file at all? Does JoyIDs show them (see the Download Links subforum, useful programs). Using P3Dv3 as it is at present, FSUIPC won't see anything in the calibrations tab unless it is assigned in the axis assignments tab -- see the pinned thread at the top of this frum. Pete

No, they look completely unrelated. Unless, that is, you hasve some sort of general corruption going on because of bad memory or something similar. But then you could get almost any symptoms trashed data is unpredictable. Keys assigned in FSUIPC will override any in FS, same as for any program taking keystrokes. And unwanted inputs cannot cause crashes unless something else is wrong. Pete

Sorry, I don't know. What you get is simply what SimConnect provides. FSUIPC just reflects the values provided by FS or P3D. You'd need to test every aircraft if you really needed to know. I would have thought it applied to all default aircraft, but whether add-on makers can bypass it, avoid it, or do their own icing I've no idea -- they do find ways of doing a lot of their own systems. For instance PMDG aircraft use hardly any of FS systems. Pete

Or it worked in one of the 4 FSX releases. I don't test all these things -- I don't even understand them all. They are simply exposing values of the given description in FS. If it says "OK" it is because it was reported to me to be okay. All I can do now is add a ? against it. I've already changed my master copy to show 0B69 works because of your report. Maybe now someone will report to me that it is an error because it doesn't work in FSX? I really don't know how to proceed. Probably best to put in a general warning saying "nothing here is guaranteed to work". ;-) All bugs need reporting in their Forums please. Pete

You posted before with a similar title. You keep posting in SubForums! Unless you are actually helping in a particular thread there, PLEASE DO NOT. All support requests must be placedhere, in the Support Forum. The message you pictured is already pictured with an explanation in this thread, not far from where you posted yours. fsx-fails-to-run-after-fsuipc4-first-installed. Please do look at useful postings! It does NOT ask you to reinstall. Just answer Yes (or Si in your case). Is is an occasional bug in FSX;s Simconnect. Pete

Offset 0E86 is cloud icing, as set in the FS weather for clouds at the aircraft altitude (if you are in them, which it can't tell), and is a value from 0-4 according to the setting. Offset 0348 is 0-16384, and is a structural ice build-up. It is read from SimConnect's variable "STRUCTURAL ICE PCT" As usual with all "percentage" variables mapped to offsets, 16384 = 100%, 0 = 0%. Please don't post SIOC code or scripts, whatever. They are meaningless to me. Just state the offset and the query please. Pete

Something you are using outside of the Sim is using FSUIPC. It is asking FSUIPC to change the Rudder Trim, which FSUIPC then attempts by sending the new trim value to the SimConnect variable "RUDDER TRIM PCT".. It is this which is then making P3Dv3 crash. I think it is probably part of the overall problems Version 3 has with controls. Please send this complete report including my analysis to L-M on their support forum. Pete

MOVED FROM FAQ SUBFORUM SO IT CAN BE ANSWERED! Please ALWAYS post support questions to the Support Forum or they may be ignored or deleted. I don't see any attached warning, and there's never any need to reinstall FSUIPC or reconfigure all your settings. Sounds like someone is joking with you. There is no such warning in FSUIPC itself. Pete

That sounds EXACTLY as if you are assigning in FSUIPC but have not disabled controllers in FSX. When you attach a new controller (or at least when FSX thinks it is new) it will make automatic assignments. BTW it is FSUIPC not FSUIPX. There's really no such thing as "activated". If the device is connected it is "active" in the sense its buttons and so forth are ready for use. But untouched buttons (unless faulty of course) do not send button changes to the PC, and only button changes (on-off or off-on) are noticed. Pete

No, sorry, I do not know it. I hasve seen it mentioned. The only joysticks I've ever has are the CH FlightStick, the SAitek throttle quadrant, and the Microsoft Sidewinder, and I only keep the latter two for testing of my DirectInput joystick code. All the stuff I really use is by PFC using serial port connections and my own drivers. I can't. I am simply not reading or understanding any specific problem I can reply to, sorry. You say L:Vars are too complex (?) for you, but what you are messing about with there is beyond me altogether. I just don't understand what it is you are trying to do nor why.:-( Pete

Sorry, no. G3D crashes are generally a result of errors in scenery or textures. FSUIPC cannot help. I did implement a trap and work-around for one very specific G3D crash, but there have always been many others. I can only suggests eliminating your add-on scenery layers one by one, and maybe trying different aircraft (because it might be an aircraft or gauge texture). You could also check in the CTD section of the AVSIM FSX Forums, as it may be one reported and known there. Pete

No, I wasn't asking for the whole thing. This part: 1466 ------------------------------------------------------------------- 1466 ------ Setting the hooks and direct calls into the simulator ------ 1466 --- CONTROLS timer memory location obtained ok 1466 --- SIM1 Frictions access gained 1466 --- FS Controls Table located ok 1466 --- Installed Mouse Macro hooks ok. 1466 --- Wind smoothing fix is installed 1466 --- All links checked okay 1466 ------------------------------------------------------------------- shows all the "hooks" put in place, during initialisation, as they should be. The "HOOK ERRORS" recorded later can't happen according to normal logic because the hooks are already done in this item: 1466 --- Wind smoothing fix is installed So, I think something really must have gone rather weird and somehow some part "jumped" to the wrong address in the wrong module. that implies some sort of corruption, or execution of data as code. Those often give "BEX" (butter overflow exception) errors. You haven't followed some of the bad advice on the Web which suggests turning the data execution protection off to avoid getting such errors, have you? Going back, this intrigues me: What sort of "crash" was it? I don't know of any crash which doesn't provide some information. yu don't really mean a hang, or freeze, do you? All my software, including interim updates, is available in the Download Links subforum here. The Schiratti site is not actualy mine. I think there's some other problem or corruption in your system which is causing this "crash" (or whatever it actually is -- I think you need to go into more details). You might need to start on a process of elimination -- stop all add-ons running then add them back one at a time, testing between each. Pete

Ah, thanks for letting me know! Pete

Okay. Thank you. The variable, being read directly from SimConnect, is "PARTIAL PANEL ADF". If you Monitor 0B64 on the right-hand side of FSUIPC's logging tab it would show the actual variable being read and the value supplied. If that isn't working it needs reporting to L-M. Please check. This variable is actually the same one written to when you write to the offset. Well I suppose they were confirmed as working fine in FSX, which is all the Offsets Status document actually deals with. I expect with so much development going on by L-M that another few columns might be needed for versions of P3D. (Ouch! But who's got time to test them all? :sad: ) Pete

You've cut out the most important parts of the log!!! :sad:. After the Joystick scanning there's a sections which confirms all the hooks are placed correctly. I need to see at least that -- in fact all the way to where it should say "starting everything" or similar. You seem to have enabled some extortionate amount of logging there! I'd disable most of the logging options unless you are really looking for something specific amongst it all. Those two Hook Error's should not actually be possible after the initialisation part (which you omitted), as they only get done the once when fSUIPC is doing the hooking. If they occurred hours into a flight I don't know what to make of it. Also, please update to the current version, 4.947c (or better 4,947d). Pete

So you have some setting, or maybe a Lua plug-in, which is doing it. With Lua plug-ins you can do whatever you want with the Mouse, but those are user options and need user action to install and enable. If you like, past your (now) renamed INI file into a reply here. Pete

Run the Installer, of course. Use the same name, email and registration code as on the other. If you don't have access to it and didn't bother to take a backup, you can retrieve the details from your SimMarket account! Pete