Instrument submission guidelines question

Working on a instrument project or just finished a project? Show it to others!

Moderators: russ, Ralph

Message
Author
Detlef
Posts: 304
Joined: Mon Nov 16, 2020 9:43 am
Location: Bavaria

Instrument submission guidelines question

#1 Post by Detlef »

Hi,

I have put a lot of work in AM instruments for the FS2020 PMDG B737-700. I would like to submit the instruments in the librariy so everyone can find and use it easily. For 5 or so of the 30 or so instruments I made, I rely on FSUIPC. I need FSUIPC to generate the needed Lvars. Airmanager then functions with the Lvars as with all other sim variables. The submission guidelines say: "Operation of Instrument should not rely on third party software or plugin.".

So still, would the submission be accepted here?

Thank you
Detlef

User avatar
jph
Posts: 2846
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: Instrument submission guidelines question

#2 Post by jph »

Hello Detlef and congrats on the most amazing work,
When using FSUIPC along with Air Manager, can you give an example of how something that would be FSUIPC specific would be controlled from AM ?
I am presuming here of course that the user has FSUIPC paid version installed appropriately.
This is something I have been looking at recently myself as it seems that without FSUIPC any meaningful and comprehensive development in MSFS is not going to be possible as it is definitely becoming the de-facto standard whilst Asobo stumble over their coat tails :)
Nice work - as always.
Joe
Joe. CISSP, MSc.

Detlef
Posts: 304
Joined: Mon Nov 16, 2020 9:43 am
Location: Bavaria

Re: Instrument submission guidelines question

#3 Post by Detlef »

jph wrote: Wed Nov 09, 2022 12:13 pm Hello Detlef and congrats on the most amazing work,
Joe
Joe,
thank you. Regarding an example where I use FSUIPC7. I use this lua code:

Code: Select all

-- Detlef von Reusner
-- FSUIPC7 lua script for PMDG 737-700
-- Oct 23 2022

-- Put 1=Lua PmdgOk in [Auto] section of fsuipc.ini file for automatic start. 


local gVar = {}

function AddVariable(lvar, vtype, len, offset)
  -- create Lvar with prefix
  -- call Lvar func per event when the associated offest changes
  -- len is optional. If len is not given the third parameter is assumed to be the offset.
  if offset == nil then offset = len end
  gVar[offset] = {}
  local var = gVar[offset]
  var.lvar = "ipcpmdg_"..lvar
  var.type = vtype
  var.len = len
  var.offset = offset
  
  ipc.log("creating Lvar "..var.lvar)
  ipc.createLvar(var.lvar, 0)
  ipc.sleep(1000) -- needed as of Sep 5 2022
end

function OffsetChanged(offset, value)
  -- ipc.log("OffsetChanged called, params: "..offset.." "..value)
  -- ipc.log("type of value is "..type(value))
  if gVar[offset].type == "STR" then
    -- ipc.writeLvarSTR(gVar[offset].lvar, value)  -- not working
    if offset == 0x656c or offset == 0x6572 then -- process dashes
      if string.find(value, "--", 1, true) ~= nil then
        ipc.writeLvar(gVar[offset].lvar, 99000.)
      else
        ipc.writeLvar(gVar[offset].lvar, tonumber(value))
      end
    else
      ipc.writeLvar(gVar[offset].lvar, tonumber(value))
    end
  else
    ipc.writeLvar(gVar[offset].lvar, value)
  end
end

function StartEventWatching()
  for offset, var in pairs(gVar) do
    if var.type == "STR" then
      event.offset(offset, "STR", var.len, "OffsetChanged")
    else
      event.offset(offset, var.type, "OffsetChanged")
    end
    ipc.sleep(200) -- not sure if needed
  end
end

AddVariable("AIR_DisplayLandAlt", "STR", 6, 0x6572)
AddVariable("AIR_DisplayFltAlt", "STR", 6, 0x656c)

AddVariable("MAIN_annunAP", "UW", 0x65f1)
AddVariable("MAIN_annunAP_Amber", "UW", 0x65f3)
AddVariable("MAIN_annunAT", "UW", 0x65f5)
AddVariable("MAIN_annunAT_Amber", "UW", 0x65f7)
AddVariable("MAIN_annunFMC", "UW", 0x65f9)

AddVariable("MCP_IASMach", "FLT32", 1, 0x65c4)
AddVariable("MCP_IASBlank", "UB", 1, 0x65c8)
AddVariable("MCP_IASOverspeedFlash", "UB", 1, 0x65c9)
AddVariable("MCP_IASUnderspeedFlash", "UB", 1, 0x65ca)
AddVariable("MCP_VertSpeedBlank", "UB", 0x65D2)
AddVariable("MCP_VertSpeed", "SW", 0x65d0)
AddVariable("MCP_indication_powered", "UB", 0x65e9)

StartEventWatching()

-- ==============================
The above is part of the lua code that needs to be running inside FSUIPC7. For example:

Offset 0x65c8 holds an unsigned byte, saying if the IAS speed display on the mode control panel instrument of the 737 is blank or not.
The FSUIPC7 script generates the Lvar L:ipcpmdg_MCP_IASBlank and waits for changes on that offset. If the offset changes, it writes the information to the Lvar.
When the Lvar changes, Airmanager sees the change if it subscribes to that Lvar.

The function AddVariable() does that in one call for the parameters given, which are
- the Lvar name (without prefix),
- the type of the offset variable (in FSUIPC "language"),
- the number of bytes (only in case of string variables), and
- the offset.

StartEventWatching() must be called once after the AddVariable() calls.

I have had trouble with string variables because Airmanager always seems to see "number" variables if the Lvar is generated in FSUIPC7. But I found a way to manage arround that.

I hope that explains it a bit. The table of offsets for the PMDG aircraft is part of the FSUIPC7 documentation. By now, at least part of the PMDG SDK is available also, and it includes a .h file with the variables. But I don't know how to make use of that information. The only way I found, is with FSUIPC7.

Regards
Detlef

User avatar
Ralph
Posts: 7878
Joined: Tue Oct 27, 2015 7:02 pm
Location: De Steeg
Contact:

Re: Instrument submission guidelines question

#4 Post by Ralph »

Sorry to say that no, we cannot have it rely on FSUIPC.
But what can FSUIPC do what we can't?

User avatar
Crunchmeister
Posts: 222
Joined: Tue Aug 10, 2021 2:06 pm

Re: Instrument submission guidelines question

#5 Post by Crunchmeister »

My 2 cents on this...

I'm not quite sure I follow what FSUIPC is being used for in this context. I only have the freeware version of it so that I can use Pilot2ATC and know little about it. I know some of what it does, but I'm not experienced enough with it to have a direct opinion on it.

But if there really is something FSUIPC can do to talk to a plane that AM can't do natively, I think it would be better to open up dialogue with Ralph and / or Corjan to see if this missing functionality can be added to AM natively. In the end, I think it would be a much better solution than having to have end users rely on a 3rd party app to make AM instruments work. And would prevent support tickets from people that can't get their FSUIPC instruments to work because they didn't read instructions first and didn't know this extra add-on was required.
- Ryzen 5950x, 64GB 3600MHz RAM, RTX3070Ti

Simstrumentation Instrument dev
Free Air Manager instruments for MSFS available at http://www.simstrumentation.com

Detlef
Posts: 304
Joined: Mon Nov 16, 2020 9:43 am
Location: Bavaria

Re: Instrument submission guidelines question

#6 Post by Detlef »

Ralph wrote: Wed Nov 09, 2022 4:22 pm Sorry to say that no, we cannot have it rely on FSUIPC.
But what can FSUIPC do what we can't?
The 737 is from PMDG. The aircraft comes with an XML file that controls the behavior within MSFS. Normal users of the aircraft dont know nothing about that and there is no need for that. But I have found all Lvars and event codes that I need in that XML file. Except some.

And for those I use FSUIPC. FSUIPC maps information from the aircrafts internal MSFS state to memory, that FSUIPC users can access via so called offsets. John Dowson, who makes and supports the FSUIPC software is obviously in contact with the PMDG developers. I dont know details about that. But those contacts have resulted in a working list of offsets for many if not all sim variables that the aircraft uses.
With FSUIPC (but not the freeware version) I can generate Lvars, that I can then just use in Airmanager.

I dont see what Siminnovations could do here, other then ask PMDG directly why some aircraft states are not being provided as variables when all others are.

I will try to get in contact again with PMDG myself. I was some time ago, but the answer then was very short, basically "we are working on the documentation and on the SDK". Now the SDK, at least some of it is available, but it does not help with building AM instruments.

PMDG is just one example here. I think for more than this aircraft, Lvars could be generated in FSUIPC and then be used in Airmanager. I see your point of course @Ralph and @Crunchmeister. (I dont like it though ;-) since it might block users from the benefit of AM instruments)

Detlef

User avatar
jph
Posts: 2846
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: Instrument submission guidelines question

#7 Post by jph »

Great 8nfo Detlef. The approach of PMDG is also just one example of the way things are moving with msfs quality addon development both now and in the future. The common denominator is the use of FSUIPC. It is the enabler. It is of great interest as to how AM can offer easy access.?
Joe
Joe. CISSP, MSc.

User avatar
Sling
Posts: 5237
Joined: Mon Sep 11, 2017 2:37 pm
Contact:

Re: Instrument submission guidelines question

#8 Post by Sling »

Hi Detlef,

This particular guideline was introduced because several submissions were made that relied on using the Mobiflight wasm for access to LVAR’s back in the early days of MSFS. The good news is AM doesn’t require that now. AM community instruments can’t be reliant on other software for various reasons. I don’t know if there is a way for AM to better interface with this type of arrangement. I do not have the PMDG 737 and so I have no way of looking at this in any detail but if those vars you are accessing fall into the BIO var group then there is hope that Asobo may improve access to those because they affect not just the PMDG but also every other aircraft. PMDG are unfortunately not helpful towards cockpit builders and have so far not made it easy to interface to their aircraft. Even prior to FS2020. If it is related to the BIO vars the aircraft dev can easily provide LVAR hooks that we can use and many devs provide this but sadly many of these var types are hidden away from external control. There is a votable wishlist item on the MSFS forum that covers a lot of the BIO var stuff. Please vote if you haven’t already.

User avatar
jph
Posts: 2846
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: Instrument submission guidelines question

#9 Post by jph »

Sling wrote: Thu Nov 10, 2022 1:26 am Hi Detlef,

This particular guideline was introduced because several submissions were made that relied on using the Mobiflight wasm for access to LVAR’s back in the early days of MSFS. The good news is AM doesn’t require that now. AM community instruments can’t be reliant on other software for various reasons. I don’t know if there is a way for AM to better interface with this type of arrangement. I do not have the PMDG 737 and so I have no way of looking at this in any detail but if those vars you are accessing fall into the BIO var group then there is hope that Asobo may improve access to those because they affect not just the PMDG but also every other aircraft. PMDG are unfortunately not helpful towards cockpit builders and have so far not made it easy to interface to their aircraft. Even prior to FS2020. If it is related to the BIO vars the aircraft dev can easily provide LVAR hooks that we can use and many devs provide this but sadly many of these var types are hidden away from external control. There is a votable wishlist item on the MSFS forum that covers a lot of the BIO var stuff. Please vote if you haven’t already.
Incorrect. PMDG have released an SDK. They have an issue with their displays not being available as pop-outs, that is the main restriction for cockpit builders. As for items available via FSUIPC, it is a sensible approach for them.

The SDK is available to anyone who purchases the program, it is also available to companies who may request it that want to support it so if SI want to know more of what they are doing and to see if there is a way to access their vars then I am sure they will send a copy of the sdk on request.

FSUIPC is a standard in the flight sim community and will remain that way. The Dowson's products offer a far far more stable offering for msfs and remain a constant no matter what mess asobo make. Little votes on a wishlist on the msfs forum make no tangible difference as asobo have dug themselves into a hole. The way forward for developers is via fsuipc and that is what is happening. I expect more and more of the better quality releases will definitely opt for fsuipc. Don't hold out false 'hope' for asobo :roll: It will be a matter of fact that soon anyone using msfs and addons will have fsuipc already installed.
Joe. CISSP, MSc.

User avatar
Ralph
Posts: 7878
Joined: Tue Oct 27, 2015 7:02 pm
Location: De Steeg
Contact:

Re: Instrument submission guidelines question

#10 Post by Ralph »

They indeed have an SDK, and we support the PMDG 737 for FSX and Prepar3D. But their data set is very limited. In the past I have contacted them multiple times, asking if this can be expanded, but they always said no. Their replies were short, if I even got a reply. They didn't feel very cooperative.

Post Reply