jr2mey Posted February 17, 2022 Report Share Posted February 17, 2022 Hello all, Is there anyone who is using Project Magenta 738 with MSFS2020? I am trying to find out how I can write a script to bleed start my engines. This is the only hickup so far in trying to get my simulator up and running in MSFS2020. I have included a lua script that is my attempt at trying to get my Project Magenta 738 started by way of APU... Why have a simulator if all you can do is press Ctrl-E.. LOL I have used all of the offset settings for offset 0B50 and none of them get my engines turning. I see that there is some working but not yet added event controls associated with engine bleed and APU bleed. BLEED AIR APU BLEED AIR ENGINE APU BLEED PRESSURE RECEIVED BY ENGINE DO I need to have these events working for my 737 to start up? Also, when looking at my script, please know that I am learning how to write LUA. Kind Regards, James A_engStarts.lua Link to comment Share on other sites More sharing options...
John Dowson Posted February 17, 2022 Report Share Posted February 17, 2022 13 hours ago, jr2mey said: Is there anyone who is using Project Magenta 738 with MSFS2020? Not me...! I have added Project Magenta to the tile of your post to (hopefully) attract any other PM users... Have you tried asking on PM support? 13 hours ago, jr2mey said: I have used all of the offset settings for offset 0B50 and none of them get my engines turning. Writing to this offset sends the Bleed Air Source Control Inc/Dec controls - maybe that is not working in the PM 738? 13 hours ago, jr2mey said: I see that there is some working but not yet added event controls associated with engine bleed and APU bleed. BLEED AIR APU BLEED AIR ENGINE APU BLEED PRESSURE RECEIVED BY ENGINE DO I need to have these events working for my 737 to start up? I don't know.... Where do you see these controls? Do you know the associated control/event numbers? I could look into adding them if needed...Probably best to talk to Project Magenta / Enrico and get them to contact me for adding any new controls. 13 hours ago, jr2mey said: Also, when looking at my script, please know that I am learning how to write LUA. I can't really comment on your lua script as I don't know much about the PM offset areas (0x5400 -5FFF) - I have no information on what these hold. However, it does seem a little strange that you are only using event.offsetmask and event.offset functions, all calling the same function. So the function is only called when something triggers one of those offset to change - what is doing this? John Link to comment Share on other sites More sharing options...
jr2mey Posted February 17, 2022 Author Report Share Posted February 17, 2022 48 minutes ago, John Dowson said: I can't really comment on your lua script as I don't know much about the PM offset areas (0x5400 -5FFF) - I have no information on what these hold. However, it does seem a little strange that you are only using event.offsetmask and event.offset functions, all calling the same function. So the function is only called when something triggers one of those offset to change - what is doing this? John Good Morning John... What I am attempting to do with my LUA script is to take the triggering of the overhead switches from PM and translate them over to MSFS2020 starting sequence. Apparently the PM aircraft operates under legacy. So I have learned that I was having an issue at how the 0B50 offset differs if your calling an airbus apu start or another jet aircraft apu start. I guess airbus is special.. LOL Great news though, I got her to start correctly via the APU bleed. After I sorted out the 0B50 offset issue, I just needed to, for what ever reason, use IPC.Control (66300,2) then follow up with IPC.control (66301) to command the engine (2) to start. I don't know why Microsoft has me do this, but it works! For the last ten years, I have always been use to working with FSUICP and offsets without an issue. Now I am looking at having to learn HTLM, Lua and what the darnation LVARS and HVARS are... LOL Thank you for continuing to develop FSUICP... great great product! James Link to comment Share on other sites More sharing options...
jr2mey Posted February 17, 2022 Author Report Share Posted February 17, 2022 1 hour ago, John Dowson said: I don't know.... Where do you see these controls? Do you know the associated control/event numbers? I could look into adding them if needed...Probably best to talk to Project Magenta / Enrico and get them to contact me for adding any new controls. Sorry John, I forgot to tell you that where I got those bleed control was in your FSUICP7 Offset status, page 118. James Link to comment Share on other sites More sharing options...
John Dowson Posted February 17, 2022 Report Share Posted February 17, 2022 39 minutes ago, jr2mey said: Great news though, I got her to start correctly via the APU bleed. After I sorted out the 0B50 offset issue, I just needed to, for what ever reason, use IPC.Control (66300,2) then follow up with IPC.control (66301) to command the engine (2) to start. I don't know why Microsoft has me do this, but it works! Ok, glad you got it working. Strange that you need a parameter of 2 to the 66300 control though, which is Toggle Starter1 - doesn't this work without that parameter? 34 minutes ago, jr2mey said: Sorry John, I forgot to tell you that where I got those bleed control was in your FSUICP7 Offset status, page 118. Ah! Then they are MSFS simvars (or A type variables), not controls, and nothing to do with PM. I could add those to FSUIPC7 offsets. However, I am currently working on functionality to let the user add any of these additional simvars to a free (for user use) offset. This should be available in the next FSUIPC7 release, hopefully sometime next week. John Link to comment Share on other sites More sharing options...
jr2mey Posted February 17, 2022 Author Report Share Posted February 17, 2022 45 minutes ago, John Dowson said: Ok, glad you got it working. Strange that you need a parameter of 2 to the 66300 control though, which is Toggle Starter1 - doesn't this work without that parameter? So, what I found when I use just the (66301) to attempt starting engine (2) all I get is a spin up and no N2 nor fuel flow. I get the audible sound of an engine spinning up but no actual engine start is occurring. I found the event (66300,2) from the FSUICP event logging console when having the auto start start the engines. Now, when I put in the ipc.control (66300,2) before the ipc.control (66301), she fires off like a wild banshee. I am sure it is my plane having issues with the start procedure. LOL 50 minutes ago, John Dowson said: However, I am currently working on functionality to let the user add any of these additional simvars to a free (for user use) offset. This should be available in the next FSUIPC7 release, hopefully sometime next week. That is outstanding sir! Look forward to it. Thank you again, James Link to comment Share on other sites More sharing options...
John Dowson Posted February 24, 2022 Report Share Posted February 24, 2022 On 2/17/2022 at 7:05 PM, jr2mey said: On 2/17/2022 at 6:09 PM, John Dowson said: However, I am currently working on functionality to let the user add any of these additional simvars to a free (for user use) offset. This should be available in the next FSUIPC7 release, hopefully sometime next week. That is outstanding sir! Look forward to it. This is now implemented in the attached beta version if you would like to try. No documentation yet - I'll add that and release officially sometime next week. To add a simvar to a free offset, create a file called myOffsets.txt in your FSUIPC7 installation folder. The format of each entry is: offset, size, simvar, type, units [, w] (where w signifies it is also writeable and is optional). For the units, check the MSFS documentation (use what the documentation states for that simvar, or any compatible unit if you want it converted). The type should be one of the following: I32 - 32-bit integer I64 - 64-bit integer F32 - 32-bit floating point number F64 - 64-bit floating point number S8,S32,S64,S128,S256,S260 - strings with the number indicating length LLA - 3* 32-bit floats (Latitude/Longitude/Altitude) XYZ - 3 * 64-bit doubles (values representing x,y,z positions) (NB. I could extend these if needed). The size should match the type/units, and will be the size used by the offsets. This can be smaller than the type, e.g. an I32/Bool ot I32/Enum can fit in 1 byte - you don't need 4 bytes (32 bits). Note also that the offset needs to be bound to the size. This means that if the size is 8, the last offset digit needs to be 0 or 8, if the size is 4, the last offset digit needs to be 0, 4, 8 or C, etc (but not for string types). Lines starting '//' are ignored. Here is an example myOffsets.txt file: Quote // offset, size, simvar, type, units [, w] 0x66C0, 1, ELECTRICAL MASTER BATTERY:2,I32, Bool, w 0x66C1, 1, ATC HEAVY, I32, Bool, w 0x66C2, 2, COM VOLUME, I32, Percent 0x66C4, 1, COM SPACING MODE, I32, Enum, w 0x66C6, 2, TRANSPONDER CODE:1, I32, BCO16, w 0x66C8, 2, TRANSPONDER STATE, I32, Enum, w Check your FSUIPC7.log file when using this, it should report any errors. John FSUIPC7.exe Link to comment Share on other sites More sharing options...
Scotfleiger Posted February 24, 2022 Report Share Posted February 24, 2022 Hi John This is great. I tried a simple boolean example for the FBW A32NX. // offsets, size, simvar, type, units [, w] 0x66C0, 1, EXTERNAL POWER AVAILABLE, I32, Bool 0x66C1, 1, EXTERNAL POWER ON, I32, Bool I would be useful to be able to use the UB and UW sizes in addition to the I32 (UD). One reason is that the EXTERNAL POWER AVAILABLE is defined as a 0 or 1 but when power is available and turned on FBW set bit 17 to give 257 (0x101). When power is not available but it is turned on the same bit is set = 256 (0x100). Link to comment Share on other sites More sharing options...
John Dowson Posted February 25, 2022 Report Share Posted February 25, 2022 11 hours ago, Scotfleiger said: I would be useful to be able to use the UB and UW sizes in addition to the I32 (UD). One reason is that the EXTERNAL POWER AVAILABLE is defined as a 0 or 1 but when power is available and turned on FBW set bit 17 to give 257 (0x101). When power is not available but it is turned on the same bit is set = 256 (0x100). It is the size if the simvar as held in the offset table, the second number, that you need to change, i.e. // offsets, size, simvar, type, units [, w] 0x66C0, 2, EXTERNAL POWER AVAILABLE, I32, Bool 0x66C2, 1, EXTERNAL POWER ON, I32, Bool I32 is the type of the simvar as received from simconnect and maps to the simconnect datatype SIMCONNECT_DATATYPE_INT32, so is actually 4 bytes. It is up to you to determine what values the simvar holds, and size the offset accordingly. John 1 Link to comment Share on other sites More sharing options...
Scotfleiger Posted March 4, 2022 Report Share Posted March 4, 2022 Hi John With the test build 7.2.17c I am seeing some random alphanumeric Lvars listed with the FBW A32NX (see attached). I have checked with FBW on Discord and they say they are not theirs. This is with a clean start of MSFS and FBW Experimental build. These are seen with FSUIPC7 List Lvars and my scan with LINDA using ipc.GetlvarName(). Link to comment Share on other sites More sharing options...
John Dowson Posted March 4, 2022 Report Share Posted March 4, 2022 What do you see when you list the lvars from the FSUIPC Add-ons->WASM->List Lvars menu item? 1 hour ago, Scotfleiger said: These are seen with FSUIPC7 List Lvars and my scan with LINDA using ipc.GetlvarName(). What ids are you using when using that function? Maybe they are out of range? Of course, if out of range then nil should be returned... Maybe you can log the id with the name, and compare to the list from FSUIPC. Link to comment Share on other sites More sharing options...
John Dowson Posted March 4, 2022 Report Share Posted March 4, 2022 Also, please try with the latest build, attached. This is the next version I will be releasing, hopefully over the weekend. Just need to do a bit more testing and update the documentation. This version is built against the latest MSFS SDK, v0.17.0.0. John FSUIPC7.exe Link to comment Share on other sites More sharing options...
Scotfleiger Posted March 4, 2022 Report Share Posted March 4, 2022 Hi John I retested with 7.2.17d as requested. I am receiving the same alphanumeric Lvars (see attached of all Lvars found). FSUIPC WASM/List Lvars is returning the same items all set to zero (0.000000). In addition to the 13 at the start of the list, there are others scattered throughout the list. The LINDA code used to search for the Lvars looks for the all non-Nil values returned by ipc.getLvarName(): local vars = {} -- generate list i = 0 while i < 65536 do name = ipc.getLvarName(i) if name == nil then break end i = i + 1 if name ~= '' then vars[i] = name end end This code has not changed from previously and it is the first time it has returned odd looking Lvars. STOP PRESS: Looking at the FSUIPC7.log these odd Lvars are bracketed by Lvars for the Ambitious Pilots Toolbar Push Back add-on. I will investigate after I find a way to uninstall the add-on. Test conditions: Started MSFS with FBW 32NX Experimental, started LINDA 4.1.4a and then started FSUIPC7. lvars.lst FSUIPC7.log Link to comment Share on other sites More sharing options...
Scotfleiger Posted March 5, 2022 Report Share Posted March 5, 2022 Morning John I hit some problems with the new build 7.2.17d last night and confirmed this morning. The inter-process communication between FSUIPC7 and LINDA has been broken. I am no longer able to reload Lvars and some other status information (FSUIPC Ready) is no longer working. Unfortunately, I won't be able to investigate further until after the weekend due to other commitments. Link to comment Share on other sites More sharing options...
John Dowson Posted March 5, 2022 Report Share Posted March 5, 2022 3 hours ago, Scotfleiger said: I hit some problems with the new build 7.2.17d last night and confirmed this morning. The inter-process communication between FSUIPC7 and LINDA has been broken. I am no longer able to reload Lvars and some other status information (FSUIPC Ready) is no longer working. Not sure what you mean by this, but there is a change in this version with the ipcReady.lua. In this version, the ipcReady.lua is not started until lvars/hvars have been received by FSUIPC. I made this change as lua scripts that depend on hvars/lvars wouldn't have them available when starting. The ipcInit.lua is started earlier, as soon as the simconnect connection is obtained, but the lvars/hvars will not be available at this time. I will make this clear in the documentation. As for those strange lvars, they are the same in the FSUIPC log file as you get when scanning via lua, so they seem to be valid lvars. Maybe they are related to that plugin you mentioned... John Link to comment Share on other sites More sharing options...
Scotfleiger Posted March 5, 2022 Report Share Posted March 5, 2022 5 hours ago, John Dowson said: Not sure what you mean by this, but there is a change in this version with the ipcReady.lua. In this version, the ipcReady.lua is not started until lvars/hvars have been received by FSUIPC. Hi John Something has definitively been broken. LINDA uses the reserved offsets 0x7320 to 0x735F to communicate between its 2 parts - the GUI linda.exe and the LUA code (see initialisation snippet below). This is achieved by the GUI relaying instructions via the x_EXEC 60-byte block which triggers an offset event. The LUA acknowledges by resetting the x_QUEUE flag. A reload command restarts the LUA code boot via x_RELOAD. Neither of the event.offsets are being triggered with 7.2.17d from what I can see. This is what I mean when I say the inter-process communications (IPC) has been broken. The event.timer is working. The LUA code is starting via ipcReady.lua and running correctly but I cannot control it from the GUI. I did try the ipcInit.lua. -- communication offsets x_RELOAD = 0x7320 -- I/0 reload configs x_EXEC = 0x7321 -- action string max 60 bytes x_LUARDY = 0x735D -- LUA ready 1:busy, 0:ready x_LUAEVT = 0x735E -- LUA events initialised 1:busy, 0:done x_QUEUE = 0x735F -- queue flag - 1:busy, 0:ready to receive -- set up timer events event.offset(x_RELOAD, "UB", 1, 'offset_reloadConfigs') event.offset(x_EXEC, "STR", 60, 'offset_executeCommand') event.timer(20, "hidPoll") -- main timer event 50Hz LINDA cannot use this update as is. PS. I agree that the odd Lvars were a result of the add-on. FSUIPC7.log Link to comment Share on other sites More sharing options...
John Dowson Posted March 5, 2022 Report Share Posted March 5, 2022 17 minutes ago, Scotfleiger said: Something has definitively been broken. There was a correction to what I assumed was dodgy code when offsets not in the internal FSUIPC offset table (such as the ones allocated to Linda) were written to, which is most probably the cause. Can you try the attached. John FSUIPC7.exe Link to comment Share on other sites More sharing options...
Scotfleiger Posted March 5, 2022 Report Share Posted March 5, 2022 Hi John Thank you for the quick response. 7.2.17e is still not allowing any IPC with LINDA. Switching back to 7.2.17c restores correct operation. Link to comment Share on other sites More sharing options...
John Dowson Posted March 5, 2022 Report Share Posted March 5, 2022 Strange...can you try the attached (haven't changed the version): FSUIPC7.exe Link to comment Share on other sites More sharing options...
Scotfleiger Posted March 5, 2022 Report Share Posted March 5, 2022 5 minutes ago, John Dowson said: can you try the attached (haven't changed the version) That's working again. Thank you. Link to comment Share on other sites More sharing options...
John Dowson Posted March 5, 2022 Report Share Posted March 5, 2022 Ah, ok. Interesting.... John Link to comment Share on other sites More sharing options...
John Dowson Posted March 5, 2022 Report Share Posted March 5, 2022 Can you verify the attached please. This is the version I will release tomorrow, v7.3.0 John FSUIPC7.exe Link to comment Share on other sites More sharing options...
Scotfleiger Posted March 5, 2022 Report Share Posted March 5, 2022 3 minutes ago, John Dowson said: Can you verify the attached please. This is the version I will release tomorrow, v7.3.0 This version is working fine. The interface is behaving as expected. Link to comment Share on other sites More sharing options...
John Dowson Posted March 5, 2022 Report Share Posted March 5, 2022 👍 Thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now