Pete Dowson

Your G3D error will not have been the one FSUIPC used to trap -- that one is fixed in the version of FSX-SE you are using, which is why FSUIPC doesn't attempt to trap it. You need to report your different one to DTG support. Send them the MDMP file you should find in the FSX folder. Send to dtgflightsupport@dovetailgames.com Pete

It just means that the wnd.bitmap function isn't in the version of WideClient you are using. It needs to be version 6.999g or later. Pete

I'd need to see the WideClient and FSUIPC4 log files from the server and the Wideclient log file from the client. That's what logs are for, to show what might be going on. You can paste them into a message here. Use the <> button above the edit area to enclose them neatly. The current version is 4.939n. Please update first. Pete

So, where I said this: "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.", way back when, you could have said, "yes, exactly", right? Except of course thar doing it by mere assignment is no good because above the fixed 21% mark it would suddenly jump to a higher value, depending on how wide a range at 21% you need -- as I also pointed out later. So, the only way is the way I suggested here: "You just have a Lua plug-in which uses event.param to receive values from your throttle axis. You would need to process that value and decide what to send on to the simulator -- using ipc.control with the control value for Axis throttleN set (N= engine number), or Axis throttle set for all engines. You need to work out some arithmetic to limit the result sent to FS to 21% until something happened (though what?)" except that now we know what the "something happening" is -- the incoming value being that where your "flight idle" notch is. Beyond that you'd need a formula to convert the remaining, higher, incoming values to the correct thrust range of 21-100% Pete

FSUIPC's settings can't have changed just because you install an updated aircraft. I think you might need to post on the PMDG support forum to find out what they've done. , The only currently supported version is 4.939n (the letter can be quite important). No, updating FSUIPC merely replaces the program itself and the documentation, though that doesn't change very often. It never ever touches your settings, plug-ins, profiles or macros. Your registration is not touched or changed. The installation allows you to bypass re-registration. Just click on "Not now" when it asks. Pete

You just have a Lua plug-in which uses event.param to receive values from your throttle axis. You would need to process that value and decide what to send on to the simulator -- using ipc.control with the control value for Axis throttleN set (N= engine number), or Axis throttle set for all engines. You need to work out some arithmetic to limit the result sent to FS to 21% until something happened (though what?) Maybe I don't fully understand your "problem". Have you yet tried just putting your "notch" on the position where things change? You seem to be wanting something very odd -- I don't know how much of the axis movement you want to waste! (Seems a little on the daft side to me, in fact, sorry to say).. Or do you simply want to limit it to 21% until you press a button? That would be much easier, and more sensible to me. Pete Pete

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