Spoofing sim variables with FSUIPC possible?

[Simon853]

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

[Pete Dowson]

... 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.

Ouch. What a horrible thought! So nothing would ever be able to read the real values, at least whilst you were doing something somewhere?

Is this possible with FSUIPC as it stands, or is it something you would consider doing?

Well, it certainly isn't possible at present with FSUIPC alone. Of course, if your program were running in-process in FS, as a DLL or Gauge, it could subclass the FS98MAIN and UIPCMAIN windows (either or both might be used by clients), and alter data in the memory-mapped area on its way back to clients. That's messy but certainly possible and would give complete control to the program doing it -- but it wouldn't work for WideFS clients of course as WideServer gets its stuff directly.

To actually provide a general facility, controlled via offsets, for this wouldn't really be on, simply because those offsets would be included in the general class of things to be spoofed. On the other hand, maybe a limited set -- say a defined subset or range -- might be reasonably feasible. Or maybe a specified list of pre-defined definitely limited size.

Would you care to expand on your idea more fully, bearing this in mind? And can you limit it to, say, FSX and ESP rather than have to go back to FS9 and so on? It is far more difficult with the way the memory for offsets is re-mapped in FSUIPC3. In FSUIPC4 it is made a lot easier by the way things are implemented internally.

It is still problematic for WideServer, even though it is built in, and my other direct-loaded drivers (PFCFSX, EPICINFO, GA28R) because of the direct access techniques they employ, but even there it is infinitely easier on FSUIPC4 than FSUIPC3.

What's meant by "A vars" BTW? Is that an XML gauge term?

Regards,

Pete

[Pete Dowson]

And can you limit it to, say, FSX and ESP rather than have to go back to FS9 and so on? It is far more difficult with the way the memory for offsets is re-mapped in FSUIPC3. In FSUIPC4 it is made a lot easier by the way things are implemented internally.

Further to this, I've thought of a nice easy and neat way to do spoofing of any offset or group of offsets for FSUIPC4 / ESPIPC, and could implement this for you very quickly if you need it. And it would work for WideFS and other direct-accessing programs too. But it will not work for FSUIPC3 and, to be honest, I cannot see a way of doing it in FSUIPC3 which I would at all be happy about.

If you want to proceed, please write to me at petedowson@btconnect.com and I'll explain the details and soon provide a Beta version for you to test with.

Regards

Pete

[Simon853]

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

[Pete Dowson]

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.

I experimented with execute_calculator_code() but couldn't get it to return anything recognisable for any of the variables I tried. I was particularly interested in getting the aircraft's LLAPBH that way so that synchronisation with other things could be made more precise.

Since my code is FSX/ESP specific (because of SimConnect) any FSUIPC dependency would be limited to FSUIPC4.

In that case the method I thought of (well, I woke up this morning with the solution in my head) will be fine.

Regards

Pete

[Simon853]

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

[Pete Dowson]

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..

I've implemented a "spoofing" or "override" facility for most offsets FSUIPC reads from FSX -- by no means all. Those which involve some substantial re-working by FSUIPC have been avoided. The ocde is rather complex and i don't want to mess it up or slow it down.

But I think it will handle all the stuff you want.

FSUIPC4 is still reading the originals, but when they are being overridden then the 2real" values are being stored, ready to restore to the offsets when your program relinqishes control of the offset or times out.

There are some uses that still get the originals:

1. GPSout still sees the "real" FSX values for the stuff it needs.

2. A Lua plug in which applies overrides can still read the originals.

#2 has a special use. You can write a Lua plug in to read a value, manipulate it, and make it available in the original offset just as if it had come from FS. and being internal (an FSX thread) it can do this almost as fast as FSX is running (it simply isn't given such a high priority).

I'll email to you the interim FSUIPC4 update, plus details of how to apply the facility, and the Lua example of changing values on the fly.

Regards

Pete