Pete Dowson

Oky. that definitely has the runways and the log entries there do indicate that they've gone to the data files. Are they missing in all the files, XML, R5, R4? I think I need the resposible BGL so i can take a look and run the test here,. C:\Prepar3D v4\Flightbeam\Flightbeam - SEQM\scenery\SEQM_ADEP4_DS_04_W_STATICS.bgl Pete

Why is that an "rtf" file. A simple text file would be far easier for me to deal with. Trying ot open is brings up Microsoft Word which then says it can't open it. Perhaps you could send again, as a Zipped TXT file lease. Is the SEQM data in a separate BGL, like "SEQM.BGL"? Perhaps to save time you could include that -- it will be identified in the Runways.txt section you upload. Additionally can you confirm the exact version nmuber of the MakeRunways you are using please? Pete

If the runways for SEQM are not appearing in the resulting database files then the scenery files are in error somewhere. Do the runways appear in the drop-down position list for "go to airport" in the Sim? If they do, please show me the relevant section of Runways.txt (which is only a log of what the program finds, not a database). No need. If the airport itself is appearing in the MakeRunways log file, then it is being included in the scan list. It must be something wrong or very non-standard in the AFD BGL for the aiport. Pete

Do you have your Sim installed in your Program Files folder? Because if so that's protected from writing. I wouldn't have thought you'd get any files written by MakeRunways withoutadmin privileges. Otherwise i can only think it's the Lorby-Si program used to make that CFG file which needs this level on your systems. I'm not sure why. Pete

This is now sounding like you have a corrupted P3D install. Either that, or there's a new bug in 4.5 as this was definitely fixed in 4.4. There's nothing FSUIPC can do. All it is doing is recording the value sent to it by P3D. Could yo possibly (temporarily) go back to 4.4 (just the Client, no need to change anything else). A few minute job, uninstall the Client saying you want to keep your activation, then install the 4.4 client. If this proves that it's a regression in 4.5 then I would suggest we both report it to L-M, myself on the Beta Forum and you in the main client forum. Pete

This is the support forum for FSUIPC and WideFS. I think you need to ask in the FSPAssenger forum, if it has one. Personally I've never heard of that product. Sorry. Pete

It was a bug in P3D4 which was fixed in 4.4. See this pinned notice at the top of the forum: IMPORTANT NOTE for Mouse Macro users updating to P3D version 4.4 The numbers assigned by P3D4 before version 4.4 were different on each load UNLESS the order of loading aircrat and their cockpit configuration is kept exactly the same. Updating to 4.4 or 4.5 will stop that, but they will all change because of the update. After that they'll be constant into the future. Pete

Not easily. The standard way is by checking your Lat/Lon/Alt against the database of airports (e.g one of those generated by MakeRunways). Or you could check the surface type (there's an offset for that). Tarmac or concrete or other hard-standings might be a clue, unless you've landed on a road. But this won't tell you which airport it is. Maybe others can help here. Possibly there are other ways. Ask on the AVSIM forums. Pete

But you are still reading offset 11BA, as as an UNSIGNED integer (UInteger). Why haven't you switched to offset 1140, which is already a Double, and doesn't need the /625. Pete

Maybe your ipcReady.lua runs other things? You should really report the LINDA problem, with your crash info, to the LINDA folks. Pete

The offsets list actually suggests dividing by 625. And by dividing an integer by an integer you will get an integer, losing the fractional part, so even if it is 1.99 you will be getting 1. Copy to a floating point variable before dividing, to retain the fractional part. But offset 11BA is the original one dating from FS98 days (I think). If you are using FSX or later try the double floating point value at offset 1140. You won't get any better, and that needs no conversion. Pete

Please try without LINDA running (rename ipcREADY.lua). LINDA may be using a driver which has a problem with your system. If you then don't get the crash, seek help on LINDA support. I don't know. They are your lines. Maybe the LINDA log line at 202848 contained some sequence which the display options here interpreted as "strikethrough". Check the original. Pete

Just that they mostly seem to be arranged to give their max output at the opposite end of the movement to their minimum output. Not always, though, i know. The fact that there's an interim detente on yours won't change that, it is just an interim value. The fact that you've been happily using yours as they are calibrated must mean that my question doesn't apply in this case. Yes, that's what you want for the OUTPUT, so that's okay. You misunderstand the meanings of the calibration values. The left most one, marked "minimum" means the minimum input value, not the minimum result. You must always calibrate with each box to the right higher than the one to the left -- i.e. in order -- because FSUIPC cann't correct for out-of-order values. The two centre values, denoting the idle zone usually, can be either way around -- it is their difference that matters. But both must be lower of equal to the Maximum, and greater or equal to the Minimum. The beep just means you have the order wrong, not obeying these rules. You normally need to Reset and reset when selecting REV to avoid this. Pete

Do you perhaps have the CH manager software running, because the logs indicate that FSUIPC isn't sending this. To prove this perhaps you can unassign it in FSUIPC, for the Profile you are using. Another check, to see if it is something your quadrant is doing, got into the FSUIPC Axis Assignments tab and see if Throttle2 is registered as changing there when you press those buttons assigned to trim. If any axis is jittering a little use to button at the top to ignore it, until you either have none indicated on only throttle 2. The INI you supplied shows: Throttle2=-16253,-11665,-6947,12570 Have you re-calibrated? Shouldn't you reverse the throttles (REV checkbox) -- full forward is full thrust, but most quadrants produce the max value when pulled back. I'm pretty sure the CH one isn't any different. Pete

If those are the real values in your INI then since they are out of 100, you are effectively stopping most of the ways it offers of deleting traffic set them to 0 to only delete furthest traffic. Otherwise use much higher values for all except NP, PAP and AP which could be kept low (0 for NP). It tries to avoid deleting ground traffic nearer than about 0.5 nm in any case. But if it has to because of tge limit, then it certainly will. And there's still a random chance. I've experimented with all this myself, and cannot recommend any specific settings. The defaults are all at 50% for a reason! These days, now i have a much faster PC and P3D4 performance is so much better, I just try to set the limit high enough for there rarely to be any need for deletions. Pete

Can you do the same logging in both FSUIPC4 and FSUIPC5, go through the same Transponder sequences, and let me see the logs. I want to see what the difference is that you are getting, because the code is the same in the 64-bit version. the 32/64 bit difference in P3d itself may also be a fsctor dependening what the Ivap module or program is doing. you didn't say whether it's a DLL which is running inside P3D or an external EXE. Have you confirmation that the P3D4 version is using this still? Pete

I'm surprised it does thgat even after a / character. I thought the re-direction parameter had to be space delineated just like parameters in general. Maybe I should implement an alternative form like /G ? I'm also surprised this problem has never arisen before. Pete

With the FSUIPC limiter it is the furthest which are deleted first, at least in the air. The parameters provided mainly deal with ground aircraft, though there is one option which can be used to favour airborne aircraft which are due to arrive at or depart from your current airport. but if you are airborne yourself then the airborne AI deleted first are the furthest from you. So I don't know why you actually saw one disappear. That is more likely to be one of those cases where the sim deletes them if they've run into a conflict or have somehow no where to go, though I don't know how either could happen in the air. Pete

Did you check whether the assignment had the desired effect on the aircraft, though? It might simply be that the model doesn't reflect the actual value back on the screen graphic, i.e the picture of the lever. check your dials or readouts or whatever else it is you expect to change. Pete

In that case you need to change your Arduino program to use the different offsets if you have to change those. Ah, I see spokes2112 has replied with a solution. Right. So the offsets used are defined in the Arduino program. Is "mobiflight" another software driver? I don't think I know it. I have an Arduino (used with an add-on board to control my 737 magnetically held Starter switches). I don't remember how i programmed the Arduino -- I think I used their software. Ouch! I think you mesn "double word" (DWORD). A "double" is an 8-byte floating point number,. 😉 Wow! That's a lot of work! I've never seen so many events in one plug-in! 😉 Thank you so much for jumping in and helping Simone so comprehensively. He did have me at a loss, not knowing what he was doing. Oh, just noticed. According to your Log, I see you are using FSX. will the P3D4 version of the Maddog still be the same? Most aircraft add-ons need serious changes to work in the 64-bit world. Pete

It confuses the issues very much. It runs many of its own plug-ins AND external hardware drivers modules. So is there a driver they supply which uses those original offsets you had? That's what I'm still asking, all these times. What is reading those offsets and sending them to your hardware? I've no record of ever assigning any to Skalarki -- they never applied for an assignment. Looking through my records IU see you are encroaching on offsets assigned to others: 6700-67FF = Jean-Michael Biston ("Michael") for Airbus gauges 6800-6BFF = Robert Fischer, FS-Communicator Your last script has a mix of event-driven LVar reading, and a set before it which only execute once, when the script is first started. I think you need to work out what it is you want to do. Just saying you "want it to work" is no use. You need to say exactly what you are trying to do and why. If you have some hardware driver which is using the original offsets you showed, albeit "illegally", then you will need to stick to those and using the formats it requires. But you still say nothing about what is supposed to happen to the offsets you are writing despite my repeated questions about this. In your last effort you changed to proper user offsets but you don't say you changed the hardware driver to match. Sorry, but you are continuing to provide too little detail. Oh, and before you provide another log, make sure Linda isn't running, and enable the Lua logging.option. Pete

Test them first. You need to determine which is which of the two identical units. Pete

I see you are using LINDA. I think you may need to ask their support. You are constantly writing zero to those offsets, the ones you will or cannot say why you chose. You still haven't said what it is driving your displays. How can you expect help? The other thing I note is that your Lua plug-in is headed: -- MD80 Interface BY sKALARKI -- LUA Script V 1.0 -- 20.10.2011 2011? That must surely pre-date the MD80 aircraft you are using? What makes you think it is in any way still relevant? Maybe this "sKALARKI" can offer something for your P3D4 version? BTW, the Lua is a bit of a mess. All the part till "--GLARESHIELD" only gets run once, when the plug-in is first loaded. Is that what you really intended? Then, at the end of your Lua plug-in you have "ipc.sleep(50)" which is really unnecessary and is only excuted the once too. and the "end" right at the end is invalide -- there's nothing for it to complete. Pete

I've no idea what that means1 This is probably because the offsets are being read by something else, which oyu haven't identified, and changing them won't work without changing that too1 WHAT is reading the offsets? Is it the MadDog directly? does it use FSUIPC? Does it say it needs FSUIPC? Pete

The GUID and name of the device go hand in hand. They are read from your system as it is now. it is only the IDs which need sorting out. To do this just look as your assignments. Button assignments will bt P, R or U (for Press, repeat or Up) followed by the axis name (X, Y, Z etc). You can see the joystick IDs on screen in the assignments tabs, at the top. Yes, sorry. So, you get the hang of it now? Pete