intercept fsuipc calls

[xettera]

Hi Peter,

I have multiple pieces of software all using fsuipc (fs9) to do various things. I'm have trouble with overlapping and conflicting functionality, in particular autopilot functions like stab trim, repositioning and weather.

Long story short, I want to be able to intercept writes to certain offsets and either redirect them to other offsets or discard them depending on the value they are trying to write.

I tried writing a wrapper dll for fsuipc.dll but have only managed to crash fs9.exe with my attempts.

I know you have ceased fs9 fsuipc development, but is there any chance I could send you a simple little block of code you could compile into your dll for me. Or can you suggest any other way of achieving the desired effect - which is something like:

if (pOffset == STABTRIM && pValue == 16000)

{

// ignore

}

else

{

doWhatFSUIPCDoes ();

}

[Pete Dowson]

 

I've moved your post to the Support Forum -- you posted in Paul Henty's subforum where support for his .Net client DLL is provided. Please take care where you post.

 

Long story short, I want to be able to intercept writes to certain offsets and either redirect them to other offsets or discard them depending on the value they are trying to write.

 

Best, then you update to FSX, because that's a facility provided in FSUIPC4.

 

I tried writing a wrapper dll for fsuipc.dll but have only managed to crash fs9.exe with my attempts.

 

Since most FSUIPC requests from programs route through FS's message procedure, the one for class "FS98MAIN", you'd need to hook into that procedure (subclass it) and process the FSUIPC requests before they get to FSUIPC.

 

You'd probably also need to do that with the class "UIPCMAIN" which is specifically added by FSUIPC and used by some programs too, depending what library they used, if any.

 

I've no idea how you'd "wrap" FSUIPC.

 

Or can you suggest any other way of achieving the desired effect - which is something like:
if (pOffset == STABTRIM && pValue == 16000)
{
// ignore
}
else
{
doWhatFSUIPCDoes ();

}

 

 

Which offset is "STABTRIM" and how is it being written? If this is from an assigned axis why not use a Lua plug-in to intercept it?

 

Pete

[xettera]

Thanks for the reply. It didn't make a whole lot of sense to me (yet) but I'm sure it will after I do some more digging.

By stabtrim I meant offset 0BC0 for elevator input control. I will try again with the info you've given me and let you know how I get on. Thanks again, you're a legend!

[Pete Dowson]

By stabtrim I meant offset 0BC0 for elevator input control.

 

0BC0 is elevator trim, not elevator. Isn't that being set by an input axis from a joystick? If so you can just assign that to a Lua plug-in which tests for your 16000 and otherwise sends it on using the appropriate FS control (Axis elev trim set most probably)..

 

Pete

[xettera]

Yes I meant trim.

Ok it looks like the LUA event.intercept is exactly what I'm after. Many thanks!

[Pete Dowson]

Yes I meant trim.

Ok it looks like the LUA event.intercept is exactly what I'm after. Many thanks!

 

I'm still wondering, though. is it a program which is writing to 0BC0 and you want to change what it is doing?

 

It's always more interesting to know what the problem is for which a proposed solution is available, rather than simply the solution. It leaves one trying to guess the problem! ;-)

 

Pete

[xettera]

Works perfectly. Thanks again.

 

function interceptStabTrim(offset, value)

  if value == 16000 then

    -- do nothing

  else

    ipc.writeSW(0x0BC0, value)

  end

end

 

event.intercept(0x0BC0, "SW", "interceptStabTrim")

 

 

It's not a single problem I was trying to solve.

I work on multiple simulator setups, each with an array of external applications (over which i have no control) mostly using fsuipc.

One example of what I can now fix, is a hardware interface constantly setting elevator trim in the game to match the physical trim wheel position - blissfully unaware of another application trying to control the games trim for autopilot. I can trick the hardware into thinking it is trimmed to a certain point eg 16,000. I know that an autopilot won't trim to that extent and can therefore distinguish between the conflicting writes to 0BC0 and ignore the hardware value, but allow the autopilot writes to occur.

[xettera]

Whilst that solves my problem, using specific values is perhaps not as elegant as it could be. Is there any way at the LUA level to determine the source (process or thread) of the write request?

[Pete Dowson]

function interceptStabTrim(offset, value)

  if value == 16000 then

    -- do nothing

  else

    ipc.writeSW(0x0BC0, value)

  end

end

 

Or slightly more efficiently:

function interceptStabTrim(offset, value)
   if value ~= 16000 then
      ipc.writeSW(0x0BC0, value)
   end
end

 

Whilst that solves my problem, using specific values is perhaps not as elegant as it could be. Is there any way at the LUA level to determine the source (process or thread) of the write request?

 

No, sorry. Even FSUIPC doesn't decode that now. It used to, because originally each FSUIPC application had to be registered with a Key. But it became too inefficient, and most program makers were pretty honest and if they were making money paid their dues.

 

Pete