Pete Dowson

I only wanted to know why you did what you did, and in fact I still want to know. Mapping folders and fiddling with registries in not something many users do. It is quite advanced. I wouldn't venture into such things. Yet you say i'm clever and you are not? How do you work that out? I think you must have seriously misread my reply. I simply don't understand what you'd done nor why you'd done it. I don't see any relevance in what you did to your problem, which is why I asked -- many times now. And you still won't even bother to do me the courtesy of actually replying to any of my questions! Why? Well, please yourself, but i still don't understand why you are being like this. If you really want to simply give up, then do so, but i strongly suggest you undo the things you've done. I wouldn't have thought it would have been so much trouble to look at the FSUIPC log file from Prepar3D to see what path it was telling applications like IYP. If the path was not a UNC path, i.e. one starting "\\<name of computer> ..." then the problem is probably smply that you've not shared the folder. If you can't find it in the Log file, just paste it here and I'll take a look. You privided two files of no relevance, but not the one I suggested might be of assistance! It's late here now and I'm off to bed. I'm out in the morning so it'll be a few hours before I can help further, should you change your mind. Pete

Sorry, where on Earth do you see any "chewing out", whatever that means? I'm trying to help. Why such a weird retort back? Who does that help? Why ask any questions at all if you don't want any answers? I don't understand you! i was suggesting you forget all that drive mapping and registry fiddling, and instead just check that you have shared the paths in the Server correctly. You can see the paths being supplied by FSUIPC in the FSUIPC log. I don't understand why you've done all the things you listed you'd done. You didn't explain why you'd done such things,. Maybe someone told you to? I won't try to help at all if you come back again with such an unwarranted and unhelpful retort. Pete

Why are you mapping FSX to a drive of the Client? I've never had any need to do that, not ever. I run IYP and radar Contact on a client. Why? That makes no sense to me at all. Wideclient needs no path to FS at all, and nor, as far as I know, does IYP. I've never given it a path. It sounds like you are messing up registries and mapping drives for nothing. What made you start on this path? Yes, most FSUIPC applications obtain paths they need from FSUIPC. It constructs the full UNC path if it can. You can see the FS path it provides in the FSUIPC log file. Neither are relevant beyond showing things are probably okay. Check the FSUIPC4 log file. Maybe you've not shared the P3D folder but have done the FSX folder? It would be rather futile if IYP knew the path but couldn't access it because you'd not shared it. None of that drive mapping and registry fiddling should ever be needed. I don't understand how you got into such things. Regards Pete

Sorry, that makes no sense at all to me. Why is cpFlight using a different offset to everything else? How can cpFlight hope that its users can operate the Autobrake if their switch is programmed to operate via an offset which isn't used by anything else? Regards Pete

That's the first problem. i cannot possibly support such an old version. the current version for FSX is 4.823. The other serious problem is that your FSX is up to SP2/ACC level but your SimConnect installation is not, so they are incompatible. you need to install SP2 or Acceleratioin (again, if you tried already). Pete

Thanks. I looked at the reports, and the crash at offset BA66D is identical to the one which FSUIPC patches around in FSX SP1 and ACC versions of G3D.DLL. I can easily make this patch work in P3D 1.3 as well -- but as explained above, I'd rather LM fixed the problem at source, as all my patch does is force the function to exit with a "false" result if the value about to be used would give an access violation. It was pure luck in FSX that this had no evident adverse affect. I assume that something wasn't drawn on that pass which otherwise would have been (apart from the crash). If LM support agree, I will add the workaround to an interim update of FSUIPC4, but i would hope they would fix this in their next update in any case, and if they do I'd like direct confirmation so i can rmove the work-around. I added this reply to the P3D thread. Regards Pete

No. I'm not in favour of working around bugs in code which is being actively supported and developed, because then it may never be fixed, and it should be. I'd rather everyone who experiences these crashes submit the appropriate bug reports to LM. If they want to know what my workaround patch did, I can by all means tell them what i checked, though it was pure luck that it worked with no evident adverse results. Regards Pete

Thanks, but i was answering the message from BrunoAU, who has problems with 4.81. Regards Pete

If you mean Lua for FSUIPC plug-ins rather than as a free-standing program-making language, then, just that, really. A small Lua plug-in can be knocked up in no time and run inside FS using the FSUIPC facilities, and developed by editing and reloading all within the one FS session. And for things only wanting a little intimate access within FS they are efficient because they are actually in-process. C/C++ programs on the other hand are many many times faster, and are ideal for larger externally run projects. What they lose in closeness to FS they gain in the speed of their own operations. Same really for gauges or DLLs running inside FS -- those written in C/C++ will beat anything in Lua for performance. Lua plug-ins are intended to allow easy user expansion of FSUIPC facilities. I added the interpreter specifically to avoid my having to continually program new features into FSUIPC itself. Really, from that point of view you can't compare them to proper C/C++ programs. You could make use of Lua for trying ideas out, ( "prototyping") before embarking on a proper C/C++ program. I did exactly this recently, running quite an extensive Lua plug-in to drive my hardware 737 multi-USB overhead, before writing a proper C driver for it. Regards Pete

The FSUIPC offset for the autobrake switch is listed in the FSUIPC offsets list. That is for FS aircraft. I think TSR has its own autobrake system, though, so you might need to refer to its documentation. And some add-on aircraft will be different again -- e.g. PMDG. The FS one is 2F80, one byte, value 0-5, matching your strings. I don't understand why you couldn't find it. Just search on the word "autobrake".! Pete

No, the Reload facilities only reload assignments, so you can edit the INI file without closing FS. To re-execute a running Lua you simply need to restart it. What I do is assign some otherwise unusued key combination, like TAB+1, to "Lua <name of lua>". Then when to press that it will Kill the existing one and start the new one with the same name. Regards Pete

Sorry, I don't understand the question. If you want FSUIPC offsets relating to FS aircraft then these are all listed in the Offsets lists provided with the FSUIPC SDK. If you want offsets relating to an add-on, assuming the add-on even uses offsets, then you'll need the list from the add-on maker or support. I know Project magenta fully documents their offset use, Have you checked ProSim documentation? I've no idea what cpFlight has to do with it I'm afraid, nor where the string you are reading on a serial port comes into all this. Regards Pete

That's not actually binary data, it is a character string reading "MIPCOM5_0". I think you'll need a table of all the string values you receive, and look them up to determine their function. Pete

That was the main reason for the FSUIPC 4.82 release a couple of weeks ago. Please refer to the Download Links subforum. Pete

Please try the current version, FSUIPC 4.823. Pete

You can install it on all your computers and use them at the same time if you wish. The registration is for you, not your machines. Regards Pete

You cannot. You buy an FSUIPC4 key. FSUIPC4 is not the same product as FSUIPC3. It had to be completely re-written. It is as different from FSUIPC3 as FSX is from FS9. I guess you didn't buy FSX either, eh? Pete

These are comments on errors in PMDG's NGX data structure, not on any FSUIPC mapping, because all FSUIPC does is receieve the entire structure as one data block directly into where you read the offsets from. Please direct all such bug reports to PMDG but do not refer to the "offset" which is meaningless to them, but to the name of the varaible in the header file. Regards Pete

Check the FSUIPC Documents folder, "Example Lua Plugins" and see the "TripleUse.lua" example there for multiple actions on one button. that should give you the ideas you need for rotaries too. There's also an example of exactly what you want in a thread somewhere here. Er ... yes. Try reading rotary-encoder-input-speed. Regards Pete

If the plug-in is simply doing some one-off action when you press the button, yes. But that APU function is designed to monitor a condition and reflext it on an indicator, isn't it So it isn't button-instigated and needs to be running in the background all the time. Right? So start it either by a "RunLua" call in ipcReady.lua, or use the [Auto] facilities in the FSUIPC INI file to start it like a macro. The latter method allows you to start different plug-ins for different aircraft or profiles. Well, when FS is ready to fly to be more exact. But best to just start off your separate pluginns with "RunLua" calls inside ipcReady.lua -- easier for reconfigring, editing, debugging and so on. Regards Pete

This is your problem. You didn't really properly read the documentation nor even my previous reply where I pointed out that 2B00 is a 64-bit floating point number, i.e. a double. It is NOT the same as the Lat/Lon values which are 64-bit fixed point nmbers (your "currency" would work for those). Just read 2B00 directly into a double. No conversion is needed, as I told you already! :-( Pete

I use this: [b]ullAvailVirtual[/b] The amount of unreserved and uncommitted memory currently in the user-mode portion of the virtual address space of the calling process, in bytes. [/CODE] I don't think there's any way of getting only "contiguous memory above a certain size" without doing a complicated memory walking loop, which will detract from performance. I found the value I was computing good enough to predict problems -- graphics and other things started playing up at around 200 Mb left, followed by the OOM crash. The warning I set at 300 Mb seems about right to avoid these things, e.g. by saving the flight and maybe doing something like reloading memory or aircraft, to force a memory defrag. Regards Pete

The Lua Debug method is really redundant now. I shall be removing it. FSUIPC features a much superior Lua debugging feature "Lua tracing", an entry on the Logging tab. This not only logs the line numbers being executed, but also the variable values, when they change. This is in the current version FSUIPC 4.823, and will be in the next release for FSUIPC3. If you choose the othr Lua logging option, to log separately, then each Lua program will have its own log. Otherwise all the Lua logging goes to the main FSUIPC4 log file. In this case multiple Lua plug-ins have an ID number, like "Lua:N", with N starting at 0. This helps identify which log entries are for which plug-in. This method of logging is very useful when you have several separate plug-ins interacting with each other, as with projects like LINDA, as you then see the precise sequence of events. Regards Pete

Ah, clean forgot that. It was something I added a little while back to help me, personally, locate a memory leak in one of my other specific cockpit drivers -- and it did. I never took it out, but stupidly forgot to document it. It not only logs it, and sounds a warning, but also provides a continual (10 sec interval update) running value of the amount of free FSX process memory left in an offset. Let me see ... ah yes: 32-bit integer value at offset 024C, free memory left in kilobytes. You could monitor that on-screen using the Monitor facility on the Logging tab. It plays two Windows "exclamation" sounds when this gets below 300 Mb (i.e. 307200), as, in my case at least, it was soon after this that FSX was starting to play up, ending in an OOM crash. Additionaly, if you set the Log Extras option in the logging tab, it logs the memory "in use" and "available" values, in Mb, once per minute during the whole session. I'll add it to the Changes list next week. Off for the weekend in a short while ... Regards Pete

No formula needs. As stated in the documentation, 2B00 is already in degrees, as a 64 bit double floating point value. If you treat the 8-byte value you get correctly, it will read correctly. Please use the documentation (offsets lists) which tell you these things. Pete