Pete Dowson

No, I support here, in the Forum, not by telephone!! Make sure you are using the current version (4.939n), and show me the Install log, which is saved next to the Installer so it is easy to find. Pete

No. You get no user options, except Logging (which is included to help debug applications). The free mode offers the basic original purpose of FSUIPC, as an interface to FSUIPC for third party applications. Please do take a look at the User Guide, which tells you exactly what you get and what you don't get, fairly early on. As you will know if you read the Installation guide, all the documentation is installed for you in the FSUIPC Documents folder. I think that is simply because the NGX saves so much information in several files, all of which must be precise at the time of saving, that it freezes the simulation why it assembles it all. It isn't just "autosave", it's any type of flight save. That isn't an "autosave", it is a correction to an omission in FSX -- FS9 and earlier always created this by itself. FSUIPC just makes it right again. Pete

You can either use event.offsetmask, with the mask picking out the bit (or bits) to test -- this would allow you to have a separate function called for each bit -- or use event.offset for any changes in 0D0C and test individual bits using the logic.And function, within the one function. The former is probably easiest. For a single bit the mask is the value of that bit -- 1 for bit 0, 2 for bit 1, 4 for bit 2 and so on, up to 32768 for bit 15. If you don't understand about bits and bytes please refer to the FAQ subforum where there's a thread to help. WideClient automatically runs any Lua it finds in its folder. You'd need to have a signal sent to an already running Lua program to activate it. One way would be to use one or more of the User offsets (66C0-66FF), For example, assign your button to the Offset ubyte set control, setting it non-zero, and in the already-running Lua just have the one event, event.offset, on that byte. So nothing happens in the Lua program til the byte is set. The function it calls could contain the other event functions you might need for it to then carry on normally. You could also turn it off the same way, with a function then deeting all the other events. If you want a lot of such WideFS plug-ins, it might be best to use a bit for each, using Offset byte setbits, or maybe Offset byte togglebits, depending on your button or switch, and event.offsetmask in the plug-in.. Pete

There is no way version 4.09 knows anythng about Prepar3D. That is about 9 years old!!! The currently supported version is 4.939n, and it is the only one available! Pete

Yes, good! Otherwise you would either not have the devices connected, or you would have a problem in your registry! It shows that it is relating the numerical IDs (0,1,2) to the letters you've assigned, both by name and unique GUID. That's how ir works to make sure it keeps track of your devices if they get plugged in differently! Pete

By not asllowing the use of a Lua plug-in you are making it more difficult. The only other way I can think of doing it would be to assign the throttle on the right-hand side of the Axis Assignment tab. This allows assignment of controls to specific ranges instead of direct to an analogue axis. You could have three ranges set there, one operating the throttle axis from 0 to 21%, one keeping it at 21% over a sufficient range for you to be sure to make that work, and the other allowing it to increase normally. The problem with that approach is that you still really need to use the input from the axis as the parameter to send on. Therefore the part of the range you want to fix is lost. For example, if you needed a 5% zone of freedom at 21% you'd need to lose, say, an area from 19-23%. Whether this would notice would need testing, but you might notice a sudden jump. If your throttle axis is smoothly behaving, not varying very much from time to time, then there's really no reason why simply making your "notch" at the point where good calibration puts the 21% -- providing it predictably gives such a figure, why do anything complicated at all? Just assign and calibrate as normal! There would be no need for an limit or zone. Pete

It would be easy enough for me to add a facility to use the function SimConnect_CameraSetRelative6DOF via a set of offsets in FSUIPC. I'd only need to find the offset space for the 6 floats (24 bytes). I'm not sure this function does exactly what you want it to do. It looks like it controls a (defined?) user camera, it has no addressing capability for any of the defined cameras. Let me know -- best to send me an email -- and if you want, I'll add it to an interim test version for you to try before I make it firm. Email is petedowson@btconnect.com. Pete

Well, USB and COM ports using a standard serial cable wiring are always bi-directional. I didn't know Bluetooth was not. So, sorry, if your created COM port is one way TO the PC, then obviously any data FSUIPC sends to it gets nowhere. Pete

Sorry, "incoming" to which, the PC or the Device? Obviously if there's no ability for the PC to send data out then it can't send data out. Pete

You'd need to know the type of GPS data is wants to receive -- eg which NMEA sentences, or maybe it is Aviation format, etc? Also the speed being set may be important, even though it may be translated into USB signals lower down. If a COM port has been set in FSUIPC, and one or more data formats selected, data will be going to that port. The rest is up to whatever is on the other end. Pete

You now have those 3 lines twice. It won't do any harm, but you only need them once! Pete

No, add those lines -- i.e. duplicate the existing GUID lines and replace the 0, 1, 2 by the correct letters, as you did already for the name lines. Pete

Good. I'll make it a formal release tomorrow. I think the 'bug' was an event priority clash. In 4.939m I rearranged the way I scan for events to signal to Lua plug-ins, in order to try to give them all an equal chance (rather than having a very frequent one preventing some less frequent ones ever being signalled). Such behaviour could be worked around in the Lua code by ordering the events requested so that the lesser ones come first, but you shouldn't need to do that. The bug was that there were circumstances in which the event scanning didn't actually complete. That is fixed now, as well as the proper sharing. It was a devil of a job to nail down, and I wasn't really sure it was related to the Linda problems at all. It just seemed likely as not much else was changed in 4.939m. Pete

I'm pretty sure any changes wil be activated if you use the "reload aircraft" FS control to reload. There's nothing in FSUIPC or SimConnect to edit CFG files for you, so I don't think that's relevant. You just need to be able to send the Reload Aircraft control after you've edited the file. You can do that with FSUIPC or SimConnect, or even directly by sending the FS98Main class window the control in a WM_COMMAND message. HOWEVER, you can manipulate a user camera directly in SimConnect, using this function: Have you investigated this? It isn't supported through FSUIPC, though, you have to interface to SimConnect. Pete

Good. Thanks for letting me know. Did they ever work with the VRInsight device? Pete

So what are the results with 4.939n? Pete

What makes you think it is FSUIPC doing this? If it has "stopped working" it means it has crashed, so why do you need to re-boot the computer? Windows has obviously detected a crash and you will have the option of getting more information AND closing the program! Even if a program hangs instead of crashing, Task Manager will always close it. Never any need to re-boot. I also need the actual version number of FSUIPC, the LOG file from the Modules folder, details of other programs -- especially any programs actually using FSUIPC, AND, of course, the crash details from the Windows event viewer. Pete

Which version of FSUIPC are you using? I always need such data! Pete

Please try 4.939n and let me know. Pete

Thank you!! ;-) Pete

No one has helped me nail down the reason for the problems with Linda and 4.939m, seeming to have preferred just to retreat to an older, unsupported and never to be developed version. :-( But please now see this thread: http://forum.simflight.com/topic/79274-fsuipc-old-versions/ Pete

I have not received any information to help me definitively solve the Linda problems,, which I presume are the ones you are referencing, but I have re-vamped the code around the Lua event system again -- in version 4.939n, and I have hopes that this will fix it properly! I've been waiting for some reply in the other thread, but seeing as folks seem to have retreated to the k version and don't want it actually fixed properly, I've been unable to get it tested yet. So, now you are here, please try it and let me know. Here's the download link: FSUIPC4939n_Test.zip. Thanks, Pete

What problems? I'd really rather solve the problems than allow folks to go backwards. Pete

I think the way that's being done in FS must be by-passing the normal message queue, reading the keyboard state instead. FSUIPC doesn't have enough privilege to hook that low in the Windows system I'm afraid. Sorry. Pete

You'd have to program it as a toggle, Press and Release separately. Pete