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