Luke Kolin

What's the faulting module in FSX? Look in the Windows Event Viewer to find the crash report. Cheers! Luke

Since FSUIPC isn't a flight recorder or logger, it's like not the cause of your problem. What are you using to record your flights? Let's focus on the symptoms rather than assigning blame. Cheers! Luke

No, Gunnar mis-spelled it. It's flyawaysimulation.com Cheers! Luke

I tried to respond but your e-mail provider is blocking my response. You can export your data from simFDR in a variety of formats. Cheers! Luke

I have a wrinkle with some of my LVAR reading in that some aircraft use the LVARs as a toggle for state, rather than the state itself (looking at you, PMDG MD-11). I need to therefore keep my own internal state and make sure I can detect the LVAR changes before the panel switches them back. Here's a log excerpt: 4630593 LUA.0: L:FCP_PROF_Switch_var=1 4630983 LUA.0: L:FCP_PROF_Switch_var=0 4635273 LUA.0: L:FCP_NAV_Switch_var=1 4635632 LUA.0: L:FCP_NAV_Switch_var=0 4645616 LUA.0: L:FCP_FMS_SPD_Switch_var=1 4645975 LUA.0: L:FCP_FMS_SPD_Switch_var=0 Can I safely assume that the timestamps on the left are milliseconds since FSUIPC started? If so, I probably have enough time to detect them since my timer is between 125 and 250ms. Cheers! Luke

The network error is a shame - although it is going half-way around the world from Oregon. I suspect the virus alert is a false alarm, but what specifically is it warning about? It's a relatively straight NSIS installer. Cheers! Luke

Joachim, I've built a product similar to what you are looking at doing. Right now it's still in a free beta - https://www.simfdr.com/ Apologies in advance for the plug, Pete. Cheers! Luke

Works like a charm! Thanks! Cheers! Luke

Pete, how do LVAR writes work? I started looking at doing writes, and I'm assuming that nothing has changed and that they are all FLT64 values When running the LUA log lvar script, when I write to LVAR foo I see a "foo_value" and a "foo_set", but the variable doesn't appear to change. Cheers! Luke

Just tried 4.952 - seems to work great once I got my bitmaps right. Thanks again! Cheers! Luke

Thank you! I've tweaked my code to use the encoded data size and I'll test things out in a little bit. You are correct, by the way, I just need a single byte per call. I'm not too worried about performance; I already did a test with the PMDG 747 reading a dozen LVARs regularly without any noticeable performance impact, and that was using multiple Process() calls since I could only read LVARs at a time, but I'll confirm. Thanks again! Luke

That would be wonderful! All of my values are currently 8-bit values but this would be a handy feature for down the road. Cheers! Luke

I'd forgotten about that - so I can do multiple write/write operations to D6C and D70 before a single Process()? That would be ideal because it means that I can read everything in a single Process() call like I do with everything else (I read different offsets with the PMDG737, PMDG737X and PMDG777X). I'm wrapping up a trans-Atlantic leg in the 744 but I'll see if I can test this out later today. I guess I'll need to find 96 free bytes. :) Thanks again Pete! Cheers! Luke

Update - when in doubt, assume the programmer is missing something important. Pete, it looks like you definitely are enforcing some limitations on the output offset, just like your documentation suggests! :) Once I started using 0x66C8 rather than 0x6D88, I started getting back some data. The form ":MCP_AT_ARM_Switch_var" seems to work fine. Hope this helps someone else down the line - now to see what the performance impact is! Cheers! Luke

Enjoy your weekend! So I don't forget, here's where I've gotten thus far. I think I'm making an error in the format of the LVar name. I've tried several different options, with the resulting offset being 0x6D88. Here's the logging: 7758523 WRITE0[7296] 0D6C, 4 bytes: 88 6D 00 00 .m.. 7758523 WRITE0[7296] 0D70, 23 bytes: 3A 4D 43 50 5F 41 54 5F 41 52 4D 5F 53 77 69 74 :MCP_AT_ARM_Swit 7758523 63 68 5F 76 61 72 00 ch_var. I've tried the following strings for the LVar name: ":L:MCP_AT_ARM_Switch_var" "L:MCP_AT_ARM_Switch_var" ":MCP_AT_ARM_Switch_var" "L:MCP_AT_ARM_Switch" ":L:MCP_AT_ARM_Switch" And they all seem to return 0. Is there an example snippet for the use of this offset for reading LVars? FWIW, it seems like every write/write/read/process iteration (to read the LVar) is around 5-10ms on my i4770K using FSX. Cheers! Luke

Out of curiosity, what is the format of the string going into 0xD70? I'm passing in ":MCP_CMD_L_Switch" as ASCII bytes and null-terminated, but I'm consistently getting back a zero. Is there something obvious I'm missing? This is what the LUA logging returns: 776012 LUA.0: L:MCP_CMD_L_Switch_var=1 776292 LUA.0: L:MCP_CMD_L_Switch_var=2 Cheers! Luke

It's around a dozen, but it depends -- all on the PMDG747X MCP. I'm trying to be somewhat intelligent in my reading to only check autopilot and auto-throttle states when the AT is armed and one of the CMD buttons is selected, but that means between 2 and 4 reads at a minimum. I've thrown together a prototype that should give me some ideas as to what the performance penalty is like; I'll take a look and see what the performance penalty is. Cheers! Luke

Thanks to the thread today, I started poking into FSUIPC's capability for reading local panel variables, and I think it's going to solve a long-standing problem I've had about reading payware autopilot states. Pete, what is the best practice for reading several LVARs continuously (say, every 100-500ms)? Right now I'm doing a three-step shuffle of writes to 0xD6C and 0xD70 followed by a read from my specified offset, all wrapped around a single FSUIPC_Process() call. However, if I need to do a Process() for every LVAR, that strikes me as rather inefficient and problematic. Ideally, I'd like to register an LVAR->offset mapping and then have FSUIPC handle it all in the background when it changes. That way I can batch my Reads like I already do. Is there a way to do this? Cheers! Luke

Have you cleaned out your saved weather files, like Pete suggested in the other thread? Cheers! Luke

They're all PDF documents, IIRC. Cheers! Luke

What are you trying to do? Pro 2016 isn't Pete's software. Cheers! Luke

Are you referring to this? http://www.pcaviator.com/store/product.php?productid=20700 Cheers! Luke

It might be an idea for the installer to avoid displaying that option if it doesn't detect an FSUIPC.KEY file in any of the installation folders. If Pete is poking around in the installer, it might also be a good idea for "Check Existing Registration" to provide some feedback if the registration is valid - I always found it a little counter-intuitive that no feedback at all was success. Cheers! Luke

If you want to write an installer, look at a package for that purpose like NSIS. It has functions that do a lot of the work you need for you without messing with the API directly. Cheers! Luke

Faulting module name: sim1.dll, version: 10.0.61637.0, time stamp: 0x46fadb59 Cheers! Luke