John Dowson

Yes it is - everything in the FSUIPC lua library document is specific to FSUIPC. - it is the FSUIPC lua library after all!

First, can you try just assigning (a key or button) to the available presets (that I mentioned earlier) for glareshield and/or o/h integ lights inc/dec (if you haven't already) - do they work for you? Also make sure that you are also using the latest version of FSUIPC7, v7.3.23. I will switch to the dev version and check this tomorrow and let you know if they work here. If they work, it should be straightforward to use something similar on an axis/potentiometer, or to send/set a fixed value.

I have checked and there is no SDK for the DC-6. Take a look at the available lvars (Add-ons -> WASM -> List Lvars) and the available presets (https://hubhop.mobiflight.com/presets/). John

You need to also install the PFC driver (PFC.dll) - see fsuipc.com. This topic is for a trial license for MSFS2020, not FSX. I do not provide trial licenses for FSUIPC4 (for FSX).. Do you want a trial license for FSUIPC7 for MSFS2020?

No they don't, as I have explained several times. Offsets will be written starting from the offset specified and to the number of offsets required by the type and size of the data you are writing, and when you read from an offset it will read that offset and the consecutive ones up to the size if the data type you are reading. Everything works as it should, and nothing "leaks". You just need to understand how memory addresses work. Of course not, as that would just call the getnumbersfromtext function each time the offset changed - that is obviously not what you want.... Whatever you like - you have to wrap your script in a function, e.g. based upon the last script you posted function getnumbersfromtext(spdstate) return tonumber(spdstate:match"%d+[%d.,]*") end funcyion decodeString(offset, spdstate) if (string.find(spdstate, "%-") and string.find(spdstate, "%*")) then ipc.writeUB(0x66C5,1) ipc.writeUB(0x66C6,1) elseif string.find(spdstate, "%-") then ipc.writeUB(0x66C5,1) ipc.writeUB(0x66C6,0) elseif string.find(spdstate, "%*") then ipc.writeUB(0x66C5,0) ipc.writeUB(0x66C6,1) else ipc.writeUB(0x66C5,0) ipc.writeUB(0x66C6,0) end if string.find(spdstate, "SPD") then ipc.writeUB(0x66C7,1) else ipc.writeUB(0x66C7,0) end if string.find(spdstate, "MACH") then ipc.writeUB(0x66C8,1) else ipc.writeUB(0x66C8,0) end if string.find(spdstate, "%-") then ipc.writeSW(0x66C1, 0) -- speed hast to be forced to 0, when the dashes appear in managed mode, otherwise there will be interferences with the dashes else speed = getnumbersfromtext(spdstate) speed100 = speed*100 ipc.writeUW(0x66C1, speed100) -- logging "speed100" with U16 in the simulator and a 2 byte integer in MobiFlight end end -- of function decodeString event.offset (0xABCD, "STR", 9, "decodeString") If you are planning to use lua, you should look at some on-line lua tutorials. Also take a look at the example lua scripts provided, which are located in your FSUIPC documents folders. There are also plenty of examples in these forums. John

I have moved your comment to a new topic. What do you mean by this? What values are you looking for? Does the DC6 have an SDK, similar to the PMDG 737? If it provides an sdk with additional data that I can use, then I can add this to offsets, as I do with the PMDG 737. Otherwise, maybe check the available lvars. Looks like the DC-6 also uses custom controls in the same way as the PMDG 737 - check the FAQ section on how to use these (although the FAQ refers to the PMDG 737, it should also apply to the DC-6). There are also > 100 presets available for this aircraft, so check them out. Also check-out other posts in this forum on using the DC-6. John

@salsero_at Do you still have this issue? If you want me/us to help you, please supply the required files (see my last comment), otherwise I will close this support request. John

I understand this, but do understand what you mean when you say it isn't working...how do you know this? What errors are you getting? Are you using FSUIPC7, and if so what does that report for the WAPI? Try also setting Debug level logging for the WAPI, and show me/attach your FSUIPC7.log file first, as this will tell me if FSUIPC7 is connecting to the WASM or not. Doesn't matter - you can still download and re-install, as this will also re-install the WASM module. John

What do you mean by "no longer work"? Is it still in your Community folder? What does the FSUIPC_WASM.log say? Have you tried re-installing it? Later: note that you should NOT be using the version of FSUIPC7 posted above - that is now over a year old. Please download and install the latest version, 7.3.23. The installer will also install the WASM for you.

@chickster25 I have just taken a look at this in more detail. The preset works reasonably ok here but only moves the lever between the discreet 4 or 5 positions. However, I can fully control the lever by assigning with Send to FS as normal axis using the Axis Spoiler Set control. Make sure there is no calibration being performed - go to page 6 of the calibration tab and remove any calibration by clicking Reset in the spoilers.

I am very surprised that works... If you remove the general button section from your FSUIPC7.ini file, it will get added back with the default values. The ButtonRepeat rate is not read from a profile button section..... John

License sent. John

But, as I keep saying, ypu shouldn't do this.... If you are storing a number in an offset as a 2-byte word, you should store it starting on a 2-byte offset, e.g. at 66C0 or 66C2. It way seem to work, but you can get problems if you don't do this, depending on how the offset is accessed... Rather than have it run in an endless loop, you can use the event.offset function, using offset 0xABCD, so that you update each time that offset changes value - this would be more efficient.

What version of the A320 are you using? The MF presets for the glareshield lights are for the dev version only - did you try in that version?

License sent. John

You should add your own presets to the myevents.txt file, not the events.txt file, as that will get replaced the next time you update. Executing a preset is EXACTLY the same as executing the calculator code associated to the preset, so you can use either ipc.execPreset("A32NX_OH_INTEG_LIGHT_25") or ipc.execCalcCode("(A:LIGHT POTENTIOMETER:86,percent) 25 (>K:2:LIGHT_POTENTIOMETER_SET)") Note also that the '(A:LIGHT POTENTIOMETER:86,percent)' part is redundant, as this just reads the value and then that value is ignored. it is the same as just ipc.execCalcCode("25 (>K:2:LIGHT_POTENTIOMETER_SET)") as I wrote in my previous comment, and you have said that this doesn't work... if you need calculator code for a specific function, you can ask about this on the MSFS2020 channel of the MobiFlight discord server. That is the community resource you should use for asking the community for the calculator code needed to implement a specific function.

The key press to repeat while held applies to the key sent on button press, not release. As you have nothing assigned to the press, only on release, the repeat option doesn't matter and so is not saved. Try assigning to the press instead of the release. John

But you should not do his... a float is 4 bytes/32-bits, and so you should write on a 4-byte boundary. This will also overwrite offsets 66C2, CC63 & 66C4 This is how floating point numbers work - they are not exact. If you only want to store to 2 decimal places, store the value * 100 as an int, and just remember to divide by 100 when you read it. The size of the offset that you need to store the number depends on the range - you can use 2-bytes if its always between -32,768 to 32,767 (signed) or 0-65,535 (signed), and 4-bytes for the full int range (-2,147,483,648 to 2,147,483,647 signed, 0 to 4,294,967,295 unsigned). And 1-byte if its between 0-255 (unsigned) or -128 - + 127 (signed). Remember to always read the same size as writing, don't overlap your offsets (i.e. make sure you leave enough space for the offset to hold the data before assigning the next offset value), and respect offset boundaries depending on the size of the data the offset holds (as I explained in the other post!). John

Ok, thats interesting. So it takes the profile settings if there are no general ones. I can check the code to see what the actual detail is, just can't remember off-hand...! John

Not really...just think about it. If you write one bye to offset 66C1, it will occupy that byte. If you write 2 bytes, it will occupy 66C1 and 66C2. And the same when you read them, so if you are reading 2-bytes, starting at 66C1, then you are reading 66C1 and 66C2. Similarly, if you were reading it as 4-bytes, you would be reading 66C1, 66C2, 66C3 & 66C4. When you are using offsets for your own needs, remember also to respect byte-boundaries. This means that a 2-byte word must start on a 2-byte boundary (offset address ending in 0,2,4,6,8,A,C or E), a 4-byte double-word must start on a 4-byte boundary (offset address ending in 0, 4, 8 or C), etc. It should be ok if you send it as a single-byte. if you are sending it as a 16-bit word (2-bytes) you shoul move it to a 2-byte boundary. You should space them as needed, and respect the boundaries when using more than one byte (strings excepted, they don't need to be aligned).

Probably yes. FSUIPC4 and above uses SimConnect in the background for most things. @John Dowson will be able to confirm. Yes - everything goes via SimConnect anyway, either to the FS or the WASM. But you can also send "legacy" events via calculator code, using them as k-type variables.

If you are reading 66C1 as a 16-bit/2-byte value, you are also reading offset 66C2, which is changing.

As I said, not all simvars (a-type variables) are settable directly. The MSFS SDK lists the available simvars and their settable status, but this one is not documented, so is probably settable. This is why the presets only read this simvar and use the k-type variable, which is an event or control, to update. As simvars can also be updated by sending the appropriate event. instead of updating directly, why not use: ipc.execCalcCode("50 (>K:2:LIGHT_POTENTIOMETER_SET)") John

In the first ini you posted, you had this: This will run SerialFP2 straight away which will grab the port and prevent FSUIPC from opening it - although I no longer see this in your latest ini. Please read the Appendix Handling VRInsight serial devices in FSUIPC in the Advanced User guide for details on setting up your VRInsight device. Ok, great - what was the issue? John

I think such buttons can cause issues when assigned in MSFS as you would get continual button press events, but this shouldn't be a problem when assigned in FSUIPC as it handles repeat button presses differently - it will only repeat the press when asked and will repeat at the rate configured until a button release is seen. John