Simon853

Thanks Pete. There's lots of things I've got to work on and my workaround is sufficient for now. If and when I get the time to try out your suggested Lua approach then I'll be sure to let you know how I get on. Thanks, Simon

Pete, I have a SimConnect client running inside my .gau file that does lots of wonderful things for me. I use FSUIPC (not from within the aircraft .gau) to extend the list of map-able input events using the .evt custom user event file support in FSUIPC that you implemented at my suggestion a few years ago. This allows me to create new event bindings for custom switches that aren't natively supported within FSX/P3D. (Wind-screen wipers, circuit breakers, etc.) These custom events are then mapped in FSUIPC to hardware switches interfacing as joystick buttons. The problem is that my aircraft's simconnect client does not know the state of these switches when the aircraft loads and can only infer their position when their state changes and I receive an event. Ideally simconnect would have a facility to query the actual position at any time, but it doesn't. I wondered whether in FSUIPC you get this information from the DirectInput driver yourself. So therefore, if the simconnect client in FSUIPC could receive an event from another client (in this case my aircraft) and then fire off the custom events as defined in the .evt and mapped to inputs in simconnect according to the current switch states. But if FSUIPC itself only receives notification of switch/button states from the driver when they actually change, then this isn't possible anyway. (Edit: I should add that I don't know whether FSUIPC is trapping input events via Simconnect, or interfacing with the DirectInput driver and causing these events to be generated. If the former, then this idea won't work obviously as you're subject to the same notification-on-change limitations as all simconenct clients.) Resetting everything to cold and dark every time is one solution, but then doesn't permit flights to be loaded in a running, in-air state. This limits the flexibility for setting up training scenarios. My current workaround solution is to present the pilot with a dialog immediately upon aircraft initialisation listing the states of all switches saved within the flight file so they can ensure all their hardware switches are set accordingly before starting the flight. (I trap and discard these events during that phase.) (By the way, there are actually some things for which FSUIPC is useful for even if the aircraft's .gau contains a simconnect client. For example, you cannot subscribe to and receive the FlightLoad and FlightSave system events in a client dll (.gau file) that gets unloaded and reloaded during a flight load/save process. Because FSUIPC's simconenct client is outside of that process, I can use it's facilities within my .gau code to determine when a flight is loaded or saved in order to load/save corresponding config files for additional aircraft systems not native to P3D.) Regards, Simon

Pete, There's a currently unavoidable issue with switches in custom hardware cockpits getting out of sync with the associated settings in the sim when flights are reloaded if the switches have been moved since the flight was saved. Is there a way to get the state of a current button input without switching it to cause FSUIPC to send an event to the sim's simconnect server? If not, here's an idea for a solution: I'm using custom simconnect event definitions within an .evt file to send on/off custom switch events to my aircraft's simconnect client. What would be ideal is if I could send a custom event that FSUIPC could trap and in response send all the custom events listed in the .evt file and mapped in FSUIPC to buttons/switches with their current position as read from the DirectInput interface. This would allow my aircraft to synchronise itself with cockpit switches when it loads. Is this feasable? Regards, Simon

Pete, if you PM me your email address I can send you over the test example, exe and source. Regards, Simon

Developers duplicating event names could certainly cause clashes, but each developer could isolate themselves from that risk by using their name in the event string, I.e. "MEGA_ADDONS_INC__WHIZBOX.POWER_SWITCH_TOGGLE". I like the .evt file idea. Simple yet elegant and removes the likelihood of user typos also. Edit: remember that if simconnect is running as a client in a gauge then there is no client app running, other than FSX itself. Si

Pete, I can certainly make a small gauge project with an embedded client to trap and action some test custom events. It'll just take me a day or so to pull it together and then I'll email it to you. FSUIPC wouldn't need to know whether the aircraft is loaded or not because simply mapping the client event should then make it available to other clients. (i.e. It shouldn't matter which client maps the event first.) However, since you already have aircraft specific mapping profiles in FSUIPC you could take advantage of that. However, there is one potential problem: If a developer build a complex avionics package, like an MFD that was not aircraft specific and could be placed into existing or other aircraft by the user, then FSUIPC wouldn't know that those events were available to be used. There is one other potentially very useful ability you could consider via custom events: When users map events to persistent (i.e. non-momentary switches), as in home cockpits, when the aircraft is reloaded the client has no idea what state the hardware switch is actually in, so the user has to reset all the switches without triggering toggle events and getting the sim switch positions out of step with the hardware. What I did in my experiment was to create a custom event in my gauge client to poll the switch interface client (which would be then FSUIPC in this instance), with something like WHIZZBOX.GET_ALL_POSITIONS event (posted as at normal priority level.) The interface client then sends the current state of all custom event switches, like "WHIZZBOX_POWER_SET, 1", etc. By doing this the hardware cockpit switches are always synced with the sim switch positions whenever the aircraft reloads. (In the gauge I trap all events at highest maskable, so FSUIPC would need to send the custom events at normal for them to be intercepted.) As far as how you would mod FSUIPC to support it, you obviously know the architecture of your software better than I, but I assume you could add a push button to the event mapping tab called "Add custom event" or suchlike, which would then open a text dialog so the user could type it in and you could then store all such custom event names in the FSUIPC.ini. Developers could then just publish a list of all these events and their usage, (toggles, value ranges, etc.) in their aircraft/panel documentation. Si

Custom events are visible globally. I've tested it myself by writing a stand-alone SimConnect client exe and sending them to my client in my gauge dll. They don't even need to use matching event ids, as when you use MapClientEventToSimEvent() with your custom event name, i.e. "WHIZZBOX.POWER_TOGGLE", the SimConnect server handles the translation to the client specific event ids. The only thing you need to be careful of is reletive event priorities and masking of in the two clients to ensure that the client actioning the event is a higher priority than all those capable of sending it. I started writing a utility myself to handle all event and joystick mappings so people could do this without the confusing and awkward need to map new switches to obscure events in the FSX settings like Concorder nose visor events, but then I realised that since almost everyone uses FSUIPC already that if it supported this then I could save myself a lot of work and users the confusion of having two similar utilities operating simultaneously and potentially clashing on priorities and SimConnect bandwidth. Si

I've an idea for a useful feature: Say I create a wholly new system for an aircraft in a C gauge file, let's call it "WhizzBox", that has a power switch on it. In order for the user to map a key or button to operate the switch (if they don't want to use the mouse) I have to identify an existing aircraft system event that isn't in use in that aircraft, (like a arrestor hook on a helicopter for example), and trap those key events to operate the switch. Explaining this to new users especially can be confusing for them and I quickly run out of unused standard events implementing complex systems. As my gauge files often include a SimConnect client, I can map custom events to be trapped and operated on by the embedded client, for example "WHIZZBOX.POWER_TOGGLE" or "WHIZZBOX.POWER_SET". It would be incredibly useful if it were possible for FSUIPC4 to support these custome events, so they can be selected in the key/button mapping action drop-down list. An implementation could then save and load them from the FSUIPC.ini file. I could then distribute a list of custom events with my gauges for users to add themselves for saving in their aircraft specific FSUIPC settings. Is this possible? Would you consider implementing such a feature? Regards, Si

Yes, both those offsets look okay now with 4.424. Thanks Pete. Si

349078 SimRead: 2400="GENERAL ENG RPM:1" [also 0898] [also 08C8] FLT64: 394.900097939 [i]<<<<<< offsets 0898, 08C8 and 2400 populated from the same SimVar "GENERAL ENG RPM"[/i] 349078 SimRead: 2408="GENERAL ENG PCT MAX RPM:1" [also 0896] [also 0898] FLT64: 0.999853181016 [i]<<<<<< offsets 0896, 0898 and 2408 populated from the same SimVar "GENERAL ENG PCT MAX RPM"[/i] If "GENERAL ENG RPM:1" returns 394 for the 206 then it's reporting the down-geared output shaft RPM, not the engine RPM (which is about 29,000 RPM at full chat.) I assume that "GENERAL ENG PCT MAX RPM:1" is the percentage 394 of max 395. (But scaled to 1 and not 100.) So, these values shouldn't be used to effect 0898 and 0896. They come from "TURB ENG N1" and "TURB ENG N2" alone. The "ENG ROTOR RPM" also returns about 394 but it differs from the "GENERAL ENG RPM:1" value because if you roll off the throttle the rotor free-wheels (and RPM can be maintained during auto-rotation) and so the rotor RPM can be higher than the engine gearbox output shaft RPM. Si

With 4.421, 0898 now reads correctly. Simon

Pete, I just wrote this whilst you were obviously typing your reply. I'll post it anyway for your information and then try what you suggest: --- Pete, Here's a quick log, performed using FSInterrogate and FSUIPC 4.40. As you can see, the first read of 0898 returns a valid value (about 79%) but if I immediately call it again, it returns 16384 (100% N1.) Then I read 2000 and it returned 79% in 8-byte float format. Then I called 0898 again, and this is where it didn't behave exactly as I found last time because it read 100% again a couple of times. Then I went back and read 2000 and tried 0898 again at which point it read 79% again. ********* FSUIPC4, Version 4.40 by Pete Dowson ********* FSUIPC4 Key is provided WIDEFS7 not user registered, or expired [Continuation log requested by user] Running inside FSX (SimConnect Acc/SP2 Oct07) Module base=61000000 Wind smoothing fix is fully installed 628172 System time = 17:48:33, FSX time = 11:03:47 (16:03Z) 651297 READ0 0898, 2 bytes: 2B 33 +3 655844 READ0 0898, 2 bytes: 00 40 .@ 668375 READ0 2000, 8 bytes: 12 BC E2 5C 88 F9 53 40 ...\..S@ 675515 READ0 0898, 2 bytes: 00 40 .@ 679437 READ0 0898, 2 bytes: 00 40 .@ 688890 READ0 2000, 8 bytes: 93 3D 68 1C 8E F9 53 40 .=h...S@ 698234 READ0 0898, 2 bytes: 23 33 #3 711828 READ0 0898, 2 bytes: 00 40 .@ 715859 READ0 0898, 2 bytes: 00 40 .@ 725234 READ0 2000, 8 bytes: 76 B1 E9 32 97 F9 53 40 v..2..S@ 732703 READ0 0898, 2 bytes: 23 33 #3 736953 READ0 0898, 2 bytes: 00 40 .@ 741469 Sim stopped: average frame rate for last 113 secs = 19.1 fps The value in 2000 is always correct, as you are reading the correct SimConnect variable "TURB ENG N1" for it. The only reason I'm reading 0898 is that i'm trying to debug a friend's SimKits gauges which don't show N1 correctly in FSX. A scan of an FSUIPC log he recorded shows that they're reading 0898, which as demonstrated here, is unreliable. I can get around it by reading 2000 and spoofing that value into 0898, but I just thought i'd let you know there may be a problem. With regards to the helicopter turbine temperature variable, "ENG TURBINE TEMPERATURE" is the correct simulation variable, but the variables list in the FSX SDK says this is applicable to the Bell helicopter (and thus those derived from it also) only. Reading FSUIPC offset 08F0 in FS9 yields the correct value (Deg C * 16384) but in FSX it always reads around 15 * 16384. (Edit - I mean the sim var reads correctly via SimConnect, but the offset that did work in FS9 doesn't in FSX.) Regards, Si

Thanks for the reply Pete. I will try it again tonight and record a log. Si

(Using FSUIPC 4.416 in FSX) Pete, I'm trying to read the "Eng 1 N1" for the default 206 helicopter in FSX from offset 0898. This works in FS9 but FSX always returns 100. However, if I read offset 2000 "Turbine N1 %" and *then* read 0898 it reads the correct value. But if read it again it's back to 100%. I realise I can just read 2000 to get the N1 %, but i thought I'd report it since the behaviour differs from FS9. Also, 08F0 "Eng 1 Turbine Temp" does not work in FSX (again, using the Bell 206.) It just reports a static value 518 regardless of what the engine's doing. In FS9 this varies as the N1 does. Regards, Si

I was incorrect. I use aircraft_varget() to fetch data into my gauge, i.e.: ex_APlaneBankDegrees_f64 = aircraft_varget( get_aircraft_var_enum("PLANE BANK DEGREES"), get_units_enum("radians"), 0); But I have used execute_calculator_code() successfully in the past. I have a host of functions to use it with different variable types. This is one: FLOAT64 GetAVar64(char *str) { FLOAT64 val; sprintf_s(VarCommandString,VAR_STRLEN,"(A:%s)",str); execute_calculator_code((PCSTRINGZ)VarCommandString,&val,NULL,NULL); return val; } where the variable passed is a string like "ROTATION VELOCITY BODY X,radians". I have several hundred SimConenct events and data responses going on every second so I like to use the gauge functions like this to relieve some of the SimConnect burden and aid synchronicity. Si

Hi Pete. Thanks for the reply. By A vars I mean those accessible via XML using the A: prefix, i.e. aircraft specific variables, like engine speeds, etc. Actually my code is all in-process gauge dll using SimConnect so I tend to write sim variables using SetDataOnSimObject(), but I retrieve them from FSX using execute_calculator_code() as it's faster. Since my code is FSX/ESP specific (because of SimConnect) any FSUIPC dependency would be limited to FSUIPC4. Because all the variables I'd need to spoof are aircraft specific, there shouldn't be any need for other clients to get at the underlying sim variables rather than my spoofed ones anyway, (only while my aircraft is loaded obviously.) The main reason I'm looking at this is that we have a few home cockpit builders who use SimKits hardware gauges. The gauges use either SimConnect or FSUIPC (they have two versions) to get the needle positions from the sim and then their own calibration software drives the gauge device. However, their software only allows the user to select from a list of variables which it cross-references with the FSUIPC offset list. (So to display airspeed, they have to select the list entry which corresponds to the FSUIPC airspeed offset.) All my gauges display new values, calculated on the fly by my own flight dynamics which exists within the in-process dll, hence FS's own gauge values read incorrect. The variables I replace are (All engine specific values used are for engine 1 only): GENERAL ENG OIL PRESSURE GENERAL ENG OIL TEMPERATURE ENG TRANSMISSION PRESSURE ENG TRANSMISSION TEMPERATURE ENG TURBINE TEMPERATURE ENG ROTOR RPM ENG TORQUE PERCENT TURB ENG N1 TURB ENG N2 GENERAL ENG FUEL PRESSURE ELECTRICAL TOTAL LOAD AMPS The tidiest solution would be if I were able to intercept all requests for sim object data as I can events, and return thespoofed values to whatever requests them, whether it be FSUIPC or any other client. Unfortunately I don't think that's possible. What I was thinking might be possible is if FSUIPC had a function that allowed a client to "mask" an offset, so I could call a function to mask say 0908H. My client would then be able to read and write that offset (without FSUIPC ever having to read and write it to/from FSX) and any other clients reading that offset would be returned my value. It's messy for sure.. (It's also complicated further by the fact that my engine variables aren't limited to 0-100%. It's perfectly possible for the rotor to overspeed significantly , like to 120%, but via FSUIPC 16384 (max int) represents 100%. But that's another story...) Regards, Si

Hi Pete, I'm working on the DodoSim 206 FSX helicopter project (nearly finished!) and in my code I replace a lot of the inbuilt FS helicopter flight behaviours with new code and then my own variables drive the panel gauges rather than the sim A vars. However, this means that 3rd party add-ons (like SimKits gauges) acquire incorrect values when the sim variables (like rotor speed for example) are retrieved from FSUIPC. One option for me is to write my own HID device drivers but an easier solution would be if my code could somehow write data to FSUIPC that would be returned to other client applications when those default offsets are read instead of FS's own A vars. Is this possible with FSUIPC as it stands, or is it something you would consider doing? Regards, Si

Hi, I've been given the nod at work to begin developing what I have done as a demo with FSX into a commercial product using Microsoft ESP when it is available. Do you know whether it will be compatible with FSUIPC4? From what I understand so far, ESP is simply FSX with the "game" front end removed, allowing it to be more easily tailored to commercial simulations, (which is what I want it for.) (I'm still using FSUIPC4 over SimConnect as the last time I checked it still had features SimConnect did not. I've not checked whether that situation has changed with SP2.) Regards, Si

Pete, I made a lot of changes and optimisations to my code last night and the program seemed to perform properly the whole time. So whether the problem is still there and didn't raise it's ugly head, or I inadvertently fixed a bug in my code that was causing it, I'm not sure. Anyway, considering this one resolved unless I add to the thread in the future. Thanks as always for your help, Simon

No, I didn't mean that it deteriorates when running. Rather that sometimes the application works many times in a row, (i.e. application restarted and connected to FSX which is left running), typically during debug development, and then all of a sudden stops. Rather like what they said here: "At times the throttle offset (0x088c) and joystick offsets (0x310A, 0x3328, 0x332A, 0x332c, 0x332e) do not work at all. Whether these offsets will work or not, is known at startup time. Once they come up in working order, they appear to stay in working order. But it is a wild card at startup." This is what I see. In that it either works or it doesn't. Once it doesn't work, a reboot of the PC sorts it out. (Simply restarting FSX doesn't.) Note that all the other reads I'm performing continue to work, like Sim On Ground, True Airspeed, Engine Torque, etc. i.e. it's only the blocked axes in the 332x range that respond with spurious values. Anyway, I shall do as you request and get the interim version and check logs when I return home later. (I will also test it with FS9 and FSUIPC3 to see if that behaves any differently.) Thanks, Si

Pete, With reference to this thread: viewtopic.php?f=54&t=64333&p=399411&hilit=writing+joystick+axis#p399411 Do you know if you still have any outstanding issues regarding the 310A axis ignore flags and subsequent inconsistent values from the 332x registers? My program's been working well all day and then suddenly started behaving oddly. (A earlier build's exe which was ok is now playing up too.) It appears that often reading from the 332x addresses gives me inconsistent readings when I'm blocking the axes (using bit mask 0F to set 310A.) I find that if I reboot the PC and restart FSX it'll all work fine. And then suddenly at some unspecified point I'll run my program and it'll stop working again. And once it fails it never seems to run properly again. This sounds awfully familiar to the problem highlighted in the thread referenced above. I'm rewriting the 310A mask regularly. (Once a second.) FSUIPC version is 4.16, registered. Regards, Si

Thank you Pete. Much appreciated. (And yes, I was looking in the wrong place!) Si

I think I may have found enough hints to keep me going in this thread: viewtopic.php?f=54&t=64333&p=399411&hilit=writing+joystick+axis#p399411 Simon

I want to write a program that reads a joystick axis, modifies it using a bit of external logic and then writes it back so that I can add extra moments of inertia during certain flight conditions. So as not to confuse the sim, I thought I should assign my joystick to normally unused input channels, (i.e. engine 2 throttle on a single engined aircraft), read the values, mod them, then write them back into the proper (i.e. engine 1) channels. But it seems these are all read only values in FSUIPC4. Is there another way of doing it? i.e. remapping and reading and writing joystick inputs to FSUIPC rather than the FSX axis settings? Thanks, Simon

I've solved the problem Pete. It was my fault. It appears the copy of my program that I was using was an old version and had some bug in it. I ran my latest code in debug mode as I was recording the logs for you and it worked ok. Apologies for the trouble. Regards, Si