Pete Dowson

Sorry, but more information is needed than just "doesn't start"! (And what are you doing trying an unsupported version like 4.69?) Please see the FAQ subforum. There's a thread there with lots of helpful hints. You can't miss it, it is pinned right at the top. Regards Pete

Level-D doesn't use FSUIPC as it stands, but there's an interface to FSUIPC made for it by Nico Kaan. See LekSeeCon Regards Pete

That is correct, exactly what happens in a real aircraft. As I understand it, the "red zone" is not actually part of the axis movement detectable by the computer, it is merely where a button is pressed. The only way you can do this is to use the lever as a switch -- just program the forward zone as "MixtureN rich" (where N is the engine number) using the right-hand side of FSUIPC's axis assignments tab. Don't assign it on the left at all. (This should be only for jets -- you want it the way you currently have it for props ad turbos). Then program the button pressed in the red zone as "MixtureN lean". That won't matter with props and turbos. These two FS controls are those sent to all engines by key presses Ctrl+Shift+F4 and Ctrl+Shift+F1, respectively. Regards Pete

Install and register as normal and then copy over the INI files. If you are using FSUIPC button or axis assignments, best to make sure you use the Joystick Letter facilities first so you don't get any problems with control devices change IDs in Windows. Pete

Looking at the ipcReady file provided, it only runs the Mustang lua if this line is true: Since ipcReady.lua is only run at the start, it will only run the Mustang lua if you load a flight initially with the aircraft named (exactly) "F1_Cessna_Mustang1". No others will do. Thereafter you can only run that Lua by assigning a button or key to it and running it that way. I think when the Mustang files were contributed it was probably before the "Auto" facilities were available. Now it would be far better to add this to your FSUIPC INI file: [Auto.F1 Cessna Mustang] 1=Lua F1MustangSwCtl and delete the ipcReady.lua file altogether. Regards Pete

There's really nothing in FSUIPC which can cause crashes in NTDLL. Those are almost always video or other driver problems, or even memory problems. And there really have been no serious changes since 4.747 except for the specific G3D crash prevention addition and big improvements in WideServer by the addition of BroadcastMode. With NTDLL crashes I don't have a chance in hell of doing anything remotely. Whenever I've had such errors I've eventually sorted them by changing drivers, and once replacing a memory stick. By the time NTDLL crashes it is about 10-20 layers below FS and the stack is usually so corrupted there's no clue whatsoever about where it all started. My most recent occurrence was when I installed UK2000's EGLC extreme scenery. When both that and their EGLL sceneries were both enabled, one or the other would invariably crash in NTDLL. I only overcame that by updating the video driver AND reducing the graphics anti-aliassing settings a notch. Sorry, I can't help other than by such advice. Regards Pete

There are 4 separate crash reports there, not one. Two of them are as you reported in the Avsim FSX Forum -- at 4384B. I had a look at that and I'm afraid it is not in a place I can do anything with. It looks like it is processing data in a file, lots of different values, and in the middle of a very large routine from which there's no easy way out of. I'm pretty sure these errors must be due to bad files. I'll have a look at the other two locations, 437D0 and 114D5, of which the former is suspiciously close to the one I cannot deal with, so I don't have high hopes for that. You then said meaning what? Loads of other, different, G3D.DLL crashes? [LATER] I had a look at the other two. Sorry, but I can't see any way out of those either. I was lucky with the FSX case I dealt with, a small function with a simple TRUE or FALSE exit. no such luck in these cases, and too many different ones in any case. Regards Pete

As listed in the 4.749d changes document, I did find a bug in the signed and cyclic decrement controls, see here: 23. The Offset signed decrement and Offset cyclic decrement had minor bugs affecting how they operated. These are now fixed. I'll re-check them here, but I've not touched the INCREMENT controls, only the DECREMENT ones. [LATER] Of these: 139=B66C0=7 RA,0,Cx310066C3,x00640001 ;//ELEVATOR UP <-------- Not working in 4749d 140=B66C0=7 RA,1,Cx410066C3,xFF9C0001 ;//ELEVATOR DOWN <-------- Not working in 4749d 141=B66C0=7 RA,2,Cx310066C4,x00640001 ;//TURN RIGHT <-------- Not working in 4749d 142=B66C0=7 RA,3,Cx410066C4,xFF9C0001 ;//TURN LEFT <-------- Not working in 4749d I get both increments working fine. It only appears to be the decrements I messed up. Sorry. I had an incorrect - sign in one line which made the decrement immediately jump to -limit. The increment would then not work, of course, because the value was at the limit already. Fixed in 4.749e, up within the next half hour. Regards Pete

Well, I wish you had. Now I no longer have the source for that version and cannot see how or why it changed I'll never understand how it could have been wrong. I have a set of test Luas I use to check things and I'm sure I would (should) have spotted it if wrong, and if I didn't, how did it correct itself? Seems it will remain a mystery forever. Regards Pete

Hmm. Well, I'd like to know what actually changed other than the documentation. In that I clarified where it said "x = ipc.testflag" which implied X was a number to "boolean = ipc.testflag", as it should really have been documented in the first place. Anyone who programmed Lua expected a cleared flag to be TRUE when tested would surely have incorrect logic in the first place! It simply wouldn't make any sense. Regards Pete

It's wrong. The wind smoothing fix is installed -- the incorrect message is fixed in the current release (4.749). It went wrong when I altered the order of things being initialised in FSUIPC when it is loaded, and the message unfortunately came before the fix installation. I fixed it as soon as I noticed it. No one actually reported it until recently, oddly just after I fixed it! Pete

But in Lua all values are TRUE except "false" and "nil". strings are true, all numbers are true. Functions are true. Arrays are true. Only false and nil are false. For me it is probably the most annoying thing about Lua, but there you are. it is what it is. No, that could never have been correct. If it returned a number and you compared it to "true" or "false" it would be "true" no matter whether you cleared or set the false, because in Lua all numbers are true! As far as I know it was always a BOOLEAN, but I only recently corrected the documentation to make that explicit. I've not changed the code, only the documentation. Regards Pete

Sorry, I've never seen that. What part is relevant? I'm not sure what point you are making. Surely if a flag is set then testing it should return "TRUE" and vice versa. Correct. You have to test whether the result is "true" or "false". All numbers and all strings and all other things other than "nil" and "false" are TRUE in Lua. I don't like it, being used to C, but there it is. That doesn't work in Lua, and is opposite of correct in C. "As originally described"? You mean it is described incorrectly somewhere? Please tell me where. Pete

Hmm. if the flag is clear it should certainly return a FALSE. If 4.745 did the opposite it was most certainly wrong and you should really have reported it. TRUE = set = non-zero FALSE = clear = zero This convention holds throughout everything. not only my code, but all programs everywhere. I've not deliberately changed anything here in FSUIPC, and I would never ever deliberately return a "TRUE" for a clear flag. So I honestly don't know what happened. In any case it is correct now from what you say. Regards Pete

All of a sudden without any changes made to your system at all? First off, your WideClient is out of date. Minimum supported is 6.86, and there's a 6.90 available which gives much improved UDP performance with FSUIPC 4.749 if you use BroadcastMode. Second, the IP address being returned by Windows for your Server looks wrong: According to an IP search that turns out to be: Hostname: 72.3.199.16 ISP: Rackspace Hosting Country: United States State/Region: California City: San Francisco Postal Code: 94103 Seems like your router is doing this? There are mentions of this sort of behaviour in the FAQ subforum thread "WideFS Server names translating into incorrect IP addresses". I assume you are either using an old version of Windows on your client, or for some reason are using differently named Workgroups, because otherwise you'd be better off removing bother ServerName and Protocol out of your WideClient INI file and letting WideFS sort itself out automatically. Regards Pete

Oh, sorry. When you said "take-off and landing distances" I thought you meant what those terms usually mean -- the predicted amount of runway needed for either operation, so you know whether it is a suitable runway. Yes, of course. Regards Pete

What is it you do not understand? Have you EVER used FSUIPC to assign anything to a button before? If not just try it first on something easy, and do take a look in the User Guide. There's a whole chapter on assigning buttons, even with a picture or two. Regards Pete

Not that I'm aware of. Compared to which version, 4.749c or something earlier? It returns true or false. How are you testing the result? Pete

You are entering something incorrectly, then. The registration system has never been changed. That's not relevant. You must use the original address, the one tied to the key. It isn't used for email in any case, it is just a form of extra identification because names alone aren't unique. It could be a street address or an National Insurance number for all it matters, providing it belongs or did belong to you. The key, name and address are all inextricably related and if that relationship fails its checks, the key is invalid. BTW if you were already using a registered copy, you should not have needed to re-enter your registration in any case. If you did have to do this you must have deleted your KEY file. When installing updates for FSUIPC you do not have to delete anything or re-register, unless it is for a new PC. Regards Pete

Really? no mention of what version of FSUIPC you are talking about, nor even what version of FS? Sorry, I can't help with no information, and I'm certainly not aware of any problems or bugs affecting any aircraft with current versions of FSUIPC. The thread you added to was successfully concluded some time back and concerned the VRS Superbug. It turned out that this aircraft was making use of incorrect information in FSUIPC which when corrected made it go wrong. The author of that aircraft is fixing it in an update (or rather has probably fixed it by now I'm sure -- it has been a few weeks) and in the interim, to help users, I added a special parameter to make FSUIPC revert to the wrong data -- purely as a temporary manner. Evidently you've not actually read the thread you added to or you'd see it has no relevance to whatever it is you are complaining about with no information provided. Sorry, I'm the "administrator", programmer, helper and general dogsbody here, I've been very busy and I've only just seen your post -- mainly because it was buried at the end of an older, finished and resolved thread. If you want faster attention and less confusion you should kindly start your own thread and give more information! Pete

If you know how to compute it then I'm sure you could do it in any sort of small program, whether a Lua plug-in or a separate program. Not sure where FSUIPC comes into it. You need weather data, certainly, but you'd input that from the METAR reports you'd need during planning in any case. You need aircraft weight, but you need that too to compute your fuel. And you need airport altitude and runway length to compute your V1 speeds. Landing distances are probably more complicated but there will surely be tables for that stuff in the AOM. If you know how to put all this together then any programming language, including Lua, could be used, or possibly even a series of equations in a programmable calculator or smartphone app. I'm afraid I'm not the person to tell you how to do this. I'm a programmer, yes, but not an aviation expert. But the data should be accessible quite readily I should think. Regards Pete

I've never had Win2000. I seriously expect problems on that too. After all it was released four years before FS9 and 12 years before my currently supported releases. What's wrong with Windows XP or Windows 7 as I suggested? Pete

Well, I just tried to do this -- I generate the document automatically from the tables in FSX's "Controls.DLL". And guess what -- that control is not there! It appears to be one of many I found which aren't even catalogued in FSX's internals, yet do work. I'll have to add those manually! Meanwhile, here's a list of those which perhaps you'd like to print out for reference (sorry about the format -- the list is extracted directly from my module in C): {"adf needle set", 66481}, {"adf outside source", 66480}, {"adf sound set", 66476}, {"adf sound toggle", 66475}, {"adf1 radio fract dec carry", 66453}, {"adf1 radio fract inc carry", 66454}, {"aileron center", 65686}, {"aileron left", 65685}, {"aileron right", 65687}, {"atc menu exit", 66171}, {"autopilot panel airspeed set", 66355}, {"bail out", 66203}, {"bomb view", 66208}, {"chase view", 66206}, {"dme sound set", 66474}, {"dme sound toggle", 66473}, {"dme1 sound set", 66470}, {"dme1 sound toggle", 66469}, {"elevator down", 65683}, {"elevator up", 65684}, {"engine fuel flow bug position 1", 66349}, {"engine fuel flow bug position 2", 66350}, {"engine fuel flow bug position 3", 66351}, {"engine fuel flow bug position 4", 66352}, {"fire all guns", 66156}, {"fire primary guns", 66157}, {"fire secondary guns", 66158}, {"flaps detents set", 65760}, {"force end", 66234}, {"gunsight set", 66135}, {"gunsight toggle", 66136}, {"hud units", 66209}, {"keyboard overlay", 66205}, {"low height warning gauge will set", 66324}, {"low height warning set", 66323}, {"magneto set new", 66399}, {"magneto1 set new", 66400}, {"magneto2 set new", 66401}, {"magneto3 set new", 66402}, {"magneto4 set new", 66403}, {"map zoom set", 65713}, {"marker sound set", 66478}, {"nav1 sound set", 66468}, {"nav1 sound toggle", 66467}, {"nav2 sound set", 66472}, {"nav2 sound toggle", 66471}, {"other aircraft view", 66207}, {"overlaymenu", 66267}, {"Radio comm1 autoswitch toggle", 66282 }, {"Radio comm2 autoswitch toggle", 66284}, {"Radio commnav1 test toggle", 66280}, {"Radio commnav2 test toggle", 66281}, {"Radio nav1 autoswitch toggle", 66283}, {"Radio nav2 autoswitch toggle", 66285}, {"select next target", 66196}, {"select prev target", 66269}, {"skip action", 66146}, {"sp multiplayer score display", 66273}, {"stop all guns", 66272}, {"stop primary guns", 66270}, {"stop secondary guns", 66271}, {"toggle damage text", 66200}, {"toggle enemy indicator", 66201}, {"toggle padlock", 66197}, {"toggle radar", 66170}, {"toggle radio", 66204}, {"tooltip units set", 66405}, {"unlock target", 66198}, {"view snap forward", 66274}, {"view snap panel reset", 66414}, {"view snap rear", 66275}, {"view type set", 65831}, {"view1 mode set", 65691}, {"view1 zoom set", 65701}, {"view2 direction set", 65711}, {"view2 mode set", 65710}, {"view2 zoom set", 65712}, Note that I don't know if these all work. Many may have been left out of Controls.dll because they don't! But many of those certainly do work! [LATER] I've made the revised list available in PDF form in Download Links - Documentation Regards Pete

No. 65693 is "View1 direction set". The View1 mode set control is 65691. Hmm. I don't think it'll be in the FSX menu. But it is in FSUIPC4's assignments drop-down. That's where I assign things for testing. FSUIPC4's drop down lists are always the most complete because they are built up from the internal tables of FS (and then added to with all of the FSUIPC added controls, of course). I see that the List of FSX controls which I published when FSX was released is actually out of date -- Microsoft must have added more controls in the SP1 or SP2 updates. This obviously explains why you never found it, though for future reference I would advise you to try FSUIPC's assignments drop-down lists, just in case. When I get time I'll try to update the document. Regards Pete

That message has not existed in FSUIPC for many years. You are evidently using a very much out of date and unsupported version. Install a current one - 3.998 or later. Pete