Pete Dowson

All these examples in the package installed by the FSUIPC installer use events: GFDdisplay.lua TripleUse.lua VRI_SetMach.lua VRI_SetrBaro.lua The concept is easy. Istead of having a Lua program loaded, compiled, run and discarded on every use of a control, you have it loaded once, at the beginning (perhaps by a "runlua" call in the ipcReady.lua, or by using the Auto facility for aircraft specific applications), and it stays loaded and always ready to act upon events signalled in FS. Your type of events would be the parameters you have already assigned, using "event.param" to direct them to your processing finction. The whole decode of the parameter value would be in a function declared in the event.param call. You could still split things into smaller Luas if you wanted to, but there's far less need when the program remains loaded. The only advantage then of several smaller ones is that several could be doing things at the same time. With only one, it can only process one of your inputs at a time, and there's no queuing except that if the parameter is changed whilst processing the previous change the function will be re-entered when it exits. However, this isn't any 'worse' than your current arrangement -- in fact it is much better because execution is a lot faster. The presence of an event to be processed in the Lua stops the Lua from being discarded. It is only removed in one of four circumstances: 1) if you re-execute it (as when testing, or perhaps when reloading the aircraft with [auto loading) 2) all the events it is "catching" are cancelled (by the event.cancel function). 3) it is explicitly terminated by the ipc.exit function. 4) an unrecovered error occurs (eg bad Lua) -- the Log would show this. Note that the event.param function and the accompanying LuaValue assignable control have only been added quite recently, so this method would not have been applicable to your Lua programs originally. Most event-using plug-ins react to things like offset changes -- needed to keep GoFlight displasys up to date, for instance -- and the VRI Baro and Mach displays, the examples made specifically for the VRI MCP Combi and M-panel devices. Regards Pete

"SP mode" being what .. single player instead of multiplayer? I've not seen the term before. Why did you never mention it? I thought we solved all the Lua re-entry crashes way back, over a year ago. There's been no reports at all since then! I see you still have not discovered events? Much more sensible to use events, and now you can use the LuaValue controls to send them ipcPARAM values your method of having lots of functions in one Lua plug-in would work much tidier. No constant Killing, Reloading, Recompiling all the time. That's all very well, but I would need to reproduce the problem here, and I don't have the aircraft. Do you have anything which will do it on a default FSX aircraft? Maybe. The safety valve is the re-run delay, the parameter LuaRerunDelay=66 It was this mechanism that fixed the crashes. If your Lua is too long, taking over 66 mSecs to load, compile, and execute each time, then that would be the reason. You can test that by increasing the delay. This will of course slow your dial repeat rates. Try it and see. Double it first. If that fixes it, zero in on a good value. If not, double again. If it still doesn't fix it let me know because at that sort of delay it must be something else. It certainly could. But i also notice other long sections in your script: Like these: for n=1, 10, 1 do ipc.control(66587,3921) end ipc.control(66587,8031) ipc.sleep(40) That alone is going to bring the time for execution perilously close to the 66 limit, more maybe when adding the load and compile time. Why all the sleep(40)'s? That surely makes things worse when trying to re-execute fast? Yes. Typical of a stack overflow. The better method is to use event.param to receive the parameter values and program the buttons to send LuaValue controls instead. You'd just need to get the Lua started at the beginning of the session, or maybe make it load with the aircraft. In the latter case you should make it also monitor the aircraft name offset (via event.offset of course) and terminate itself when that isn't the right one (or doesn't contain the substring "J41", say). Let me know how you get on, and if you have any more questions. Regards Pete

You do know that if you press a letter on the keyboard (or several, fast enough) after the list drops, Windows will move you to that position in the list? It's the method I always use to get to items, even if they are not that far down. It's the same Windows action as in Explorer, when you've sorted a file list into order you can do the same. Much faster than scrolling when you know roughly what you are looking for. Regards Pete

If your WideFS User guide does not have this: section then I don't know what version you downloaded, because that's been there a long time now! If you can't work out how to make your two PCs belong to the same workgroup, yes, you can do that, but you'd be better off having computers properly networked in the same group. Right click the "Computer" or "My Computer" icon on the desktop and look for the Computer Name section. On XP it's a tab, and in there you can change the WorkGroup name. In Vista and Win7 the Properties show it part way down and you can edit it by clicking the 'change settings' option to the right. Pete

You must have had something else wrong, then, because I'm pretty sure that's all that can be needed -- you are the only one reporting here with a problem like this which isn't solved immediately by such steps. No, they certainly need not be the same unless both levers were identical in their electrical response. The whole point of calibration is to deal with such variations. Anyway, except for the max value set for Throttle1, those values are all either default or idealistic values. Values like that are NEVER really 100% applicable to any real world axis. It shows, in fact, that you never actually properly calibrated them! If you do not want to calibrate them, following the instructions in the User Guide, there is really little point in using FSUIPC for axes at all. It is unwise to leave the minimum and maximum values to -16384 and +16383, with no zones beyond either extreme, as it means you cannot always actually attain the FS extreme values because the input from the hardware will not always reach those values. All analogue hardware varies slightly with voltages, temperature and humidity. The ennumerated steps for calibration outlined in the FSUIPC user guide are meant to be followed to give you the best possible reliable results and include the instructions to leave small areas at either extreme. With NRZ use, as here, the minimum value should certainly be well above -16384 to ensure you can always reach idle. Regards Pete

No. Apart from their throttle quadrant, the GoFlight modules don't get seen as joysticks at all, just other types of "HID" (Human Interface Devices). In general they should remain fairly constant in assignment as it's done with their own software -- all FSUIPC assignment does is read them via their driver (GFDev.dll). No. The numbered ones tell you and FSUIPC what the current Windows ID numbers are for each device. They are what actually has to be used. You need both numbered and lettered lines in so that FSUIPC can match letters to numbers by matching the names and, if they are ambiguous, the GUIDs. I don't know how you are misreading the example lines in the document -- it shows the original [JoyNames] section, and then the additional lines when the letters are used. It certainly does not imply those replace the originals -- to start with, where's the [JoyNames] section title in the latter? That's because it isn't relevant till you start using the letters. Regards Pete

Well something else has changed too, then. But by all means try the latest update -- 3.989w from the Download Links subforum. Regards Pete

If you are doing your own pmSystems logic then you can re-use any of the ones in the pmSystems-assigned range that you aren't using. There are huge numbers there which are specific to particular aircraft LGC files. Few are used in all of them. There are also many gaps in the used areas. Have you checked? Yes, but that's only if you are intending to distribute your work, as then it is necessary to assign distinct areas to distinct products so there's no clashing. It isn't really worthwhile reserving areas for individual projects for use on one setup only, otherwise I'd run out very fast. If I ever have to go beyond the 16 bit addressing it would be a nightmare! If you truly can't find enough in the existing pmSystems area (and I'd be surprised, because PM manages with several wildly different aircraft types supported), then, also assuming you'd never use SimAvionics (as you are using pmSystems) there's 5300-53FF, and similarly there's Flight Deck Software's 6E00-6EFF. Regards Pete

Well of the ones you mark as duplicate, the "elev trim dn" and "elev trim up" are evidently different, not the same. The others are a result of some existing controls which were originally missing in FS's tables yet still operational being added by FSUIPC. Then in one of the FSX updates I think they got re-instated. So the list is a composite of those in the CONTROLS.DLL list from Microsoft and those in FSUIPC's "additional;" list. As far as I can recall this has happened since SP1 was released, though it might have been SP2. I suppose when adding them to the list I could search right through to see if they're already there, but with several hundreds in the list and quite a few being added I would be worried about the noticeable delay every single time you drop the list down (these dialogue lists are generated "on the fly" and it is the Windows API for them which sorts them -- if it was me sorting I could obviously eliminate duplicates easily). I may look to see if there's another way, like deleting duplicates from my add-on list during initialisation of FSUIPC, but meanwhile no one's noticed in several years and it actually does no harm. Those with identical names are in fact identical. Thanks for pointing it out though. I may do something about it if it is easy and doesn't slow anything down. [LATER] On checking I see there is one-time code to eliminate the duplicates, but it didn't work. Interesting, because as far as I can tell it's always been like that. Anyway, it's fixed in the next update. Regards Pete

:oops::oops::oops: I feel like a right dummy. There's a very good reason why it doesn't work, and can't work without a bit of a re-design internally. In the normal one-line macro: 1=CMD L=R1:X32c0*X6a90 the name of the macro, as seen in the assignments, is "CMD L". The rest, after the = is the 'action'. When you make a multiline macro, the name is split from the line and the actions are listed: 1=CMD L 1.1=R1:X32c0*X6a90 BUT when the L:var facility was 'shoehorned' into this arrangement: 2=L:apleft_clicked=Tog the name, that you see in the assignments, is "L:apleft_clicked", and the action follows the = after it, BUT now the name is actually also very relevant to the action, because it gives that vital information, the name of the L:var to be changed! A multiline L:var macro could theoretically exist, like say: 2=L:apleft_clicked 2.1=Tog 2.2=Cyc,5 but it probably would never really make sense. The only way I could get the combination you wanted to work would be to add more structures to the internal tables. I don't think I want to complicate it further really. Especially when the same things can be accomplished via either multiple assignments to buttons, or, perhaps much more flexibly, with Lua plug-ins. I am more interested in expanding plug-in facilities than the rather arcane and less user-friendly formats of assignments in the INI files. I hope you understand, and sorry for being so forgetful about my own designs. I put is down to senility and too much good wine! ;-) Regards Pete

An axis on a joystick assigned letter "A" will show as being on joystick "A". Of course. What else? Sorry, I've no idea what that sentence actually means. What do you find so confusing in the documentation? I don't think I can explain it any better. It uses letters instead of numbers. The letters equate to number by the names and GUIDs from the Registry as listed in the INI. How more specific can it be? Pete

If the programmers who create the aircraft don't want to expose such values, you are unlikely to find them. They may have used Local panel variables (L:vars) so just use the logging facilities provided for those in FSUIPC (via an assignable control), or the supplied Lua plug-in, to find out. No idea. Aren't there? I've always found it best to use entirely external systems simulations for any cokcpit. no FS panels at all. I use Project Magenta for everything. FS only supplies the flight model and scenery. There are other packages as well which can provide all the instrumentation and subsystems. Though whether there are any supporting ATR72 exactly I don't know. Sorry, I've no idea. Certainly not via FSUIPC offsets if they don't use FSUIPC. in any case. If the panels are written in XML and you can read their XML you might find out that way. Else perhaps ask the authors? Regards Pete

There are at least two interfaces defined in FSUIPC which include a Clear Weather facility: The "Advanced Weather Interface" (AWI), and the "New Weather Interface" (NWI). Each is dealt with in separate ZIPs within the SDK (UIPCAWI and New Weather Interface for FS2004). The NWI is better and is based on normal offset reads and writes. The older AWI uses offset type values but is a command and response system which is now rather superseded, though still supported for older existing programs. 3324 is the altimeter reading, in feet or in metres according to user selection. It won't be the aircraft altitude unless the pressure is set to the current QNH on the main pilot's altimeter. 0570 is the actual aircraft altitude AMSL, as defined. It is not dependent on pressure setting unlike the altimeter. I don't know what you mean by "that feeling XDDDD". If you want the pressure altitude (PA), that's available too, in offset 34B0. Stabilizer trim is elevator trim. There are three control surfaces, aileron, rudder and elevator, and trims for all three. It you look them up you'll find them. Pete

Offset 3128-312C are not supported in FSUIPC4. Please check the FSUIPC4 Offset status document. Why are you calling FSUIPC_Process for ever action? It is very very inefficient. Every time you do that there is a process change. Just do all the writes and reads you want in one batch at a time with one Process cal! Pete

It sounds like you might have Windows set to hide the real file extensions from you. Go intoExplorer's folder options and uncheck the options to "hide file extensions for known file types". Then you'be able to see the real extension. It doesn't matter what it is called in the Modules folder, but only files of type "lua" are recognised as Luas plug-ins, and the rest of the name must be 12 characters or less excluding the . before lua. Pete

Save it with the Lua extension instead of the txt extension. If you don't know how, just rename the file after you saved it. Pete

But that procedure is IN YOUR PROGRAM. It isn't part of FSUIPC! FSUIPC runs inside FS, and there will be, somewhere in that procedure, a call to "SendMessageTimeout", which is the Windows API call which communicates to FSUIPC. That's it. The rest is yours. Your problem will be in that specific procedure, which presumably is compiled by your compiler? You need to find out why it doesn't work with your later software. I can't do that. I don't know Delphi and i don't have either of the compilers. As I keep saying. Since the code is ALL in your program, you can debug it! Pete

Try the chapter entitled "Keeping track of multiple control devices". in the user guide. it's listed in the contents list too, as the front nearly. Pete

That's odd. It should work. It must be a bug. I'll do some tests here. Can't do it till tomorrow though. Sorry. Pete

Yes, find all the USB hubs in the Device Manage, right click and select Properties, and make sure Windows isn't allowed to switch them off to conserve power. If you use FSUIPC for button and axis assignments, then, with so many devices it would be a good idea to use the Joy Letters facilities, where FSUIPC uses letters (A-Z) instead of Windows ID nmubers. Then it matches devices up if they move owing to reconnection. Regards Pete

Did you read the part of the WideFS user guide about configuring the network, especially the part with a RED banner suggesting that it is important to read some of it? There's no such thing as 'protocol adjustments' for WideFS. You either name your workgroup consistently across all your computers, which is the most sensible thing to do, or you tell WideClient the name of your server which it otherwise cannot find when its not in the same workgroup. Win7 and Vista have different default workgroup names to XP. Pete

It means the part of the code in your program cannot decode the data it read. Probably you have the structural byte alignment set wrong. But you need to debug our program. I cannot stress that enough. You cannot expect to develop programs which work first time. You must use the debugging tools your compiling system is sure to have. If you do not understand Delphi, why choose it? Why not try Visual Basic, for example? Pete

How are you developing software in Delphi if you don't know it and don't even know if you can debug your code? That doesn't make sense to me. Shouldn't you find a language you can debug? Regards Pete

Please check the section called "Message Window Options" in the FSUIPC User Guide. Regards Pete

Ah. I don't know without going through the code. I suppose it is possible -- it may abandon the attempt to execute this if that module check fails. Does it work if you swap them round? If so I might be able to change it. But why would this happen? Wouldn't you be using different macros for different aircraft? Regards Pete