Pete Dowson

I didn't ask whether Windows recognised them, but whether FS recognises them. In other words can you assign them in FS? FSUIPC uses the same windows routines as FS. Pete

Sorry, no. I think Jouni Tormanen was developing this, using the iFly SDK, but i have no other details at present. I don't know if it's ready yet. I suggest you ask at the iFly support forum. Yes, though you won't know if "value == 1" is right until you know how the switch settings are stored. You might need to test bits instead using logic.And. Well, more than the SDK. Someone would need to use the SDK to provide data via offsets. Regards Pete

You need to specify the aircraft because FS itself has no VNAV option. You mention "iFly". do you mean the recent iFly 737NG? I understand that needs another free program to interface it to FSUIPC offsets. The information you need should be included in the details for that program. For other aircraft it will vary. Very few add-on aircraft for FSX use FSUIPC offsets, so you have to seek other ways. Regards Pete

Lua is another programming language, but one designed for things like scripting and configuring other programs. It can be quite powerfiul in terms of scope, mainly because of the libraries of functions also provided. There's a Lua compiler / interpreter built into FSUIPC (and WideClient) to allow all sorts of applications to be "plugged in" to FSUIPC and WideFS. If you look in the FSUIPC Documents folder (in your FS Modules folder) you'll find documentation and examples provided for you. Supporting Lua in FSUIPC/WideFS is a way of allowing the power of FSUIPC to be expanded indefinitely, as folks find more interesting and useful things to do. Regards Pete

You can if you ZIP it first, same for any executables. Regards Pete

Good. That's always going to be a better way. But I will see if I can repro your original problem to see if it is preventable. If it is due to any code I have control over I should be able to fix it. If it is deep in the Lua code I wouldn't want to fiddle with it too much. I don't really understand enough of it, yet. [LATER] I've spent a good half hour almost continuously and quickly pressing and releasing buttons assigned to FSXviews.lua with press parameters 1 or 2 and release parameters 3, and seeing that the Lua is continually killed and restarted, and at no time was there any problem. How often was your original 'crash' occurring? I have got Bufferpools set to 0 to encourage the problem. Maybe it's because I have 8 Gb memory on this PC? Or maybe it's because it's a very fast PC? Does it only happen in full screen mode or both full screen and windowed? What is your typical FSX frame rate? (Ah, I see 27-29 fps in the Log you included. Mine is nearer 50-60 when flying, away from the detailed airports). I'm wondering if this is really more of a video driver problem than a corruption caused by killing and resurrecting threads. Except for the very odd "eof expected at line 6" error, your symptoms certainly seem very much more video related than anything i've encountered before due to Lua thread killing -- the latter problems have always been a case of stack overflow due to too many resources associated with the threads piling up. That certainly crashes FSX completely, or hangs it irrevocably with no responses at all. I'm reasonably sure I have all cases where that can occur sewn up now (though maybe thee's always another! ;-) ).. Unless I can reproduce it I'm going to have to assume its video driver related and suggest a possible update in that area. Regards Pete

Nothing is shown until it sees an axis changing. I assume you are actually moving the axes to see? You don't say. If nothing is shown when you move things then either you've disabled joystick scanning in the INI file or the joystick isn't working in Windows. Try deleting the FSUIPC4.INI file before loading FSX, as a test. Save a copy first if it contains a lot of your settings. What about FSX's assignments dialogue? If FSX itself sees the axes then so will FSUIPC4. It uses the exact same routines. Also, please ensure you are using a supported version of FSUIPC4. Current is 4.751a. Regards Pete

But if not edited, it is truncated. If that's all there is of it then it is corrupt. Perhaps you should post the whole thing so we can see what other DLLs are supposed to be loaded. Maybe the missing one is also listed there somewhere? You might like to refer to this entry in the changes list: The order of initialisation actions in FSUIPC4 has been changed substantially in an attempt to try to avert the possibility of causing a loading problem with SimConnect, whether or not this is caused by Trust checking timing bugs. Furthermore, in order to allow changes to the timing to be tried, to avoid clashes with other competing SimConnect clients being loaded at the same time, a new parameter is added to the FSUIPC4.INI [General] section: InitDelay=0 This can be set to a value from 0 to 120 to delay the actual linking to SimConnect by that number of seconds. Whether this actually helps is unknown at this time. Perhaps this 'missing DLL' isn't really so much missing as not running (in fact hanging) because of something odd it is doing with SimConnect at the same time as FSUIPC is intitialising its connection too. You could try setting a value for Initdelay to move FSUIPC's activities to a later point. if the DLL XML is loading that other DLL you could also, or instead, try swapping the order. I'm not sure why FSUIPC4 is the first in the DL.XML list -- the installer adds it to the end -- but possibly that's bacuse it was originally installed before you added whatever else is in there. No. And why, when you were comparing 4.60a with 4.751a? (you said "The previous/current version would be 4.6x."). Going backwards is never a good solution in any case, and if you do so you are without further support. The problem needs fixing, maybe in FSUIPC or its INI, or by RXP. Let me know what RXP says, but do try the above ideas as well. Regards Pete

Hats don't normally need any calibration. All they signal is the direction you are pushing it in -- 4 or 8 or many points, sent as either a button combination (CH did this in their game port devices) or as a value in degrees or multiples of degrees. If your hat is calibratable it isn't a hat but a mini joystick. When you say your X. Y axes from the proper joystick 'hit maximum' half way, what do you actually mean? A joystick has zero at the centre and diverges positively and negatively in both directions from there, so "half way into the throw' is rather ambiguous. Half way both ways? In terms of the angle or what? And where are you reading the numbers to verify this? If the joystick is not sending any changing values after "half way", then no software can do anything because it cannot detect further positions as being different. Isn't that reasonably obvious? If changing values are seen then you should be calibrating your min and max positions to accommodate them. That's nothing to do with the range of the axes, but to do with the sort of response, the feel, you prefer. Flattening the centre of the slope will just make the aircraft less twitchy. You'd want a steeper slope for fighter and stunt aircraft and a flatter one for most airliners and light aircraft. The main use of a centre dead zone is to prevent jitter or other small changes affecting the aircraft control surfaces when you don't want them to. No, if they provide no further inputs for any of their 'throw' they are faulty. The pot or optical reader should detect the position and supply proper values over the whole range of movement. If you want any further advice you'll need to tell more, like how you assign and where, and minor things like which version of FS and FSUIPC. Regards Pete

Quite honestly, I've no idea. I don't think the dialogues are trustworthy -- you need to find some way of actually checking the weather which is truly implemented in the simulation, not what the dialogues tell you. Digging into the internals of the WEATHER.DLL is very difficult, and a real mess is facing you if you want to try it. Things were much cleaner and straightforward in FS2002 and before. The things wrong with the FS9 version were also, unfortunately, carried forward into FSX. But by then I gave up trying to figure it out and used SimConnect instead, which is even more mystifying when it comes to trying to read and write weather. Crafting a good weather control program for FS9 or FSX is more of an art form than a science, and folks like HiFi Simulation should be congratulated on doing as well as they do with Active Sky. Incidentally, in the example I quoted earlier, with the two Lua plug-ins, the difference between the results of writing Global and Local weather disappear if you first write Global and then, without clearing all the weather again, write the local weather the same. You then get identical results. What is happening is that because, after clearing the weather, there are no wind layers at all at all the surrounding stations, when a lone one is set the weather there is immediately 'tempered' by the influence of all around. Naturally multiple layers of wind cannot be sustained in isolation at one point on the globe. By setting all of the as-yet-unset stations to something similar to what you want locally, when you do set the local weather it looks more correctly what you ask for. This is actually how it is written up in the little Read Me document on the NWI. You just cannot get away with writing local weather only. The best way is to write the global default first, then stations at say 40 miles away and getting closer to local is a sequence. An alternative which works well is to set them all 'Pending', and then Activate them when done. That method was added specifically for the weather control programs. Regards Pete

Sorry, but you need to check with whatever support forum supports RXPG1AE about this. Merely replacing one version of the FSUIPC4.DLL with another should in no way affect anything else, and certainly it cannot possibly result in a sudden disappearance of a DLL from your computer then a miraculous reappearance of that same DLL simply by changing versions again. Something else is evidently wrong, and since the errors you are getting are from RXPG1AE, whatever that is (and I'm sorry but I've no idea at all what that is), that is surely the place to go for more help. Have you tried reinstalling it, whatever it is, as it suggests? That looks fine as far as it goes. If it is #2, where is the entry for #1? Why have you removed it? I assume you posted it for a reason, so why edit it? And what follows? Pete

Instead of using ipcPARAM and Lua SetValue, you could use the Lua flags. You can set and clear those from FS and in your script. Pete

Ah. Two things there: First, the dialogues for weather settings do not do what you think they do -- as you can see in fact, from the wind speeds and altitudes you get. Second, the weather changes as soon as you exit the dialogues. You can't do much about that. Global weather is more predictable because it isn't influenced by other weather stations. However, unlike FSX, FS9 has no global weather mode, and the weather soon localises in any case. In any case, if you are simply reading the details from FSUIPC then you are reading what FSUIPC gets from the FS internal structures which are created by FS, not by FSUIPC. You wouldn't want FSUIPC to lie to you would you? For actually using the NWI, as a test, I've just made two small Lua plug-ins which use the NWI to set 5 wind layers only, one for "GLOB" and the other for, in my case, EGCC. Just change EGCC to wherever you are -- make sure it is a weather station, though, AND that you are positioned actually AT the station. Often the weather station is off the airport a mile or more. Try these plug-ins yourself. Just put them into the Modules folder and assign two keypresses or buttons to them. You'll see they are identical, an attempt to set 5 layers with increasing speeds, directions and turbulence. All get set fine excepting turbulence which is adjusted differently in the two cases: Global 0,1,2,3,4 becomes 0,0,1,2,4 Local 0,1,2,3,4 becomes 0,0,0,1,3 Interesting, true. But I'm afraid there's nothing I can do about it. Especially not after 8 years when it is used by so many applications. WthrGLOB.lua NW_SETEXACT = 2 -- Set weather bypassing user filters NW_CLEAR = 3 -- Clear all weather, but leave dynamic setting alone NW_DYNAMICS = 4 -- Set weather dynamics (from uDynamics value) -- Set dynamics to zero, then clear all weather ipc.writeUW(0xC80C, 0) ipc.writeUW(0xC800, NW_DYNAMICS) ipc.sleep(1000) ipc.writeUW(0xC800, NW_CLEAR) ipc.sleep(1000) offs = 0xc8fc turb = 0 alt = 3000 spd = 10 dir = 30 while turb < 5 do ipc.writeStruct(offs, "4UW", alt / 3.28084, spd, 0, dir * 65536 / 360, "2UB", turb, 0, "3UW", 0, 0, 0) offs = offs + 16 alt = alt + 3000 spd = spd + 10 dir = dir + 10 turb = turb + 1 end ipc.writeUD(0xc8f8, 5) -- 5 layers ipc.writeStruct(0xc800, "2UW", NW_SETEXACT, 0, "1UD", 0, "4STR", "GLOB")[/CODE] [u][b]WthrEGCC.lua[/b][/u] [CODE] NW_SETEXACT = 2 -- Set weather bypassing user filters NW_CLEAR = 3 -- Clear all weather, but leave dynamic setting alone NW_DYNAMICS = 4 -- Set weather dynamics (from uDynamics value) -- Set dynamics to zero, then clear all weather ipc.writeUW(0xC80C, 0) ipc.writeUW(0xC800, NW_DYNAMICS) ipc.sleep(1000) ipc.writeUW(0xC800, NW_CLEAR) ipc.sleep(1000) offs = 0xc8fc turb = 0 alt = 3000 spd = 10 dir = 30 while turb < 5 do ipc.writeStruct(offs, "4UW", alt / 3.28084, spd, 0, dir * 65536 / 360, "2UB", turb, 0, "3UW", 0, 0, 0) offs = offs + 16 alt = alt + 3000 spd = spd + 10 dir = dir + 10 turb = turb + 1 end ipc.writeUD(0xc8f8, 5) -- 5 layers ipc.writeStruct(0xc800, "2UW", NW_SETEXACT, 0, "1UD", 0, "4STR", "EGCC") [/CODE]Have fun! Pete

But it is kept sorted and you don't need to scroll through, just open the drop-down then enter the first letter or two or three of the commands you are looking for. It is very quick that way. No idea really, though you could try pre-compiling it as a test (you'd need the luac component from the Lua website I think). In order to investigate I'd need to be able to reproduce the problem. In all cases I've managed so far to cause repetitive Lua execution hangs (never seen any other result) I've found a solution. Your problem, not being a hang, surprises me. I just have no idea how it might occur. Regards Pete

By the time the installer has reached that stage it has finished everything, completely. All the registration options do are check, rewrite or ignore the registration held in your KEY file. You just press Cancel if already registered okay, as it tells you in the document included in the ZIP. Okay, so you needed to first run the 4.7xx installer in any case, in order to get the documentation and other files (in the FSUIPC documents subfolder) updated. You'll find no difference if the version you drop in is identical to the one you just installed. Replacing a program with it's exact equal makes no change occur. If there was any corruption the file couldn't load as the signature would be wrong. No, they are already in your FSUIPC documents folder, as clearly explained in the Installation document which you really should have read. If you want to know exactly what the Installer did for you, read its Log, in the Modules folder. Pete

I thought you said the only thing different was the turbulence? Seems that the wind speed is also different. I think I need to see exactly what you are writing. Could you also enable IPC write logging, and cut out the sections where you write those wind layers each timer, please? Meanwhile you should note that localised weather is almost impossible to control exactly. There are all sorts of terrible bugs in the FS9 and FSX weather system. This is why the better weather programs like Active Sky provide a global mode facility (and in fact default to that mode in latest releases). Regards Pete

Lua is unfortunately woefully short on logical bit-oriented facilities, so I added them in the logic library. To test a bit you need to logically AND the value with a mask containing only that bit and test the result to be zero or non-zero. For example, function MCP(off, val) if logic.And(val, 0x0008) ~= 0 then -- do what you want for bit 3 end ... [/CODE] If you aren't clear on bits, numbers and masks look in the [b]FAQ [/b]subforum for a short tutorial. Regards Pete

Hmmm. Those are a very strange selection of symptoms! The problems in the past of fast forced termination and re-execution of Lua plug-ins were all due to stack overflow and caused FS to hang completely. I can't imagine what causes only parts to hang. I'm not sure what you mean by "any actions which affect the screen mode", though -- only dialogues, not views in FS, changing scenery, gauges etc? I always use BufferPools=0 since I got a GTX 580 video card with 3Gb memory on board. Before, with a GTX 480 with 1.5Gb it created problems including video hangs. The best thing then was to use the RejectThreshold instead.. Do you mean forcibly terminating, or re-execution which does the same thing? Unless your plug-ins are really short, and preferably only re-executed by Repeat actions on button assignments, you should really consider using the Event system.instead, because with longer complex plug-ins you really have no idea what state things are in when their threads are forcibly terminated. Hmm. Never seen that error before. Expecting the end-of-file at line 6 seems odd. I assume there was nothing wrong with the file at that line? That's a very long Lua to expect to forcibly terminate and restart quickly. Have you considered splitting into three separate Lua's, one for each of the three parameters? Or keeping them together but use a timer event or a continuous loop and use LuaValue to change the ipcParam which it can act upon? You would then have the plug-in startup with an ipcReady.lua call or using the [Auto] option in the INI file. I'll see if I can reproduce the problem here with what you've supplied, but I don't know when I can get to it. It might not be till I return after Christmas & NY -- after January 6th. As a simple change to test initially you could instead send that 3 value by LuaValue and test for it in the loop so you can tidy up and terminate normally. That would be a far preferable method in any case. Certainly, if it is so affected by that tweak, it is suggestive of corruption outside of my control. Regards Pete

Don't send anything -- a weather log will be huge and I'm not ploughing through it all. Just find the entries showing the weather you are setting and reading for Global and that you are setting and reading for the specific weather station you are at. Then paste both extracts into a message here. I think you should also compare what you get when trying to set the same things via the FS weather dialogues. That is how I derived all this stuff in the first place. Pete

FSUIPC options (in the Modules menu -- take a look one day), Logging tab, log weather. Have you never seen the FSUIPC options? The logging facilities are normally an essential part of developing FSUIPC applications, especially the logging of IPC reads and writes to check that your program is reading / writing the right things. I'm amazed you've never heard of them. There is a Chapter in the user guide about the facilities too. Please update to the latest 3.998 version so you are using the same as I. 3.998n is available in the Download Links subforum. Pete

Ah. FS9. You should say. And which version of FSUIPC? That code is 8 years old. I've no idea. I can delve into it but I'm reluctant to change anything that folks have been using and depending on for all that time. Nevertheless the logging is still important. Please do the log and show me what it says it is setting. Pete

The encoding in FSUIPC is identical for GLOB or a real ICAO. It knows no difference, they are just ICAO codes to FSUIPC and are treated the same. So I suspect it is FSX. Have you checked the logging? Compare the wind blocks in the METAR being sent, see if there are differences between the GLOB one and the local one for EDFH. Regards Pete

You posted twice, and both in the wrong place. I deleted the extra and moved your post to the Support Forum. Such applications aren't really things I want to have built into FSUIPC, but it would be reasonably easy to do that as a small Lua plug-in. Regards Pete

Sure it isn't 4.751a? That's the latest. You NEVER need to re-register, unless you deleted your Key file or moved to another PC or reinstalled Windows. The FSUIPC installer touches nothing except it's own files so I've no idea what messed up your RXP DLL. And the FSUIPC4 installer hasn't changed for FSX in well over a year. The only changes have been for Prepar3D. What version was that? There are no EXE's to drop into the Modules folder, but if you were using FSUIPC 4.70 or later before, all you need to do to update is download the FSUIPC4.DLL itself and copy that in, as always. Both the installer version and the separate DLL package are available in the same place, in the Download Links subforum. But since the only program item the Installer will install is the same FSUIPC4.DLL (the rest of the stuff is only documents and Lua examples, Zipped), it won't make any difference. Pete

You don't get replacements, but you can retrieve the original key. See the thread entitled "READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys" in the FAQ subforum. Pete