Pete Dowson

Unless you've written one you want to use there won't be one. What is concerning you? And where exactly are all these posts about a missing initial.lua? If I've seen one and replied I've said exactly the same as here. If you haven't written one there isn't one. It's an optional file to do whatever you need doing in the client before FS is connected -- unlike other Lua files which are only loaded AFTER FS connects. Whast is it you want INITIAL.Lua to do for you? If you are interested in what Lua plug-ins can do for you, please refer to the Lua documentation installed for you in the FSUIPC Documents folder in the FS Modules folder. If you have a problem please state what it is -- over in the Support Forum. A progress message telling you things for information is not an error and is not a problem. If you are reading the WideClient log file to find a solution to a problem, please tell me what the problem is, because latching onto normal progress messages won't help. But please please post questions in the Support Forum! Pete

If you want a Lua plug-in to run when Wideclient starts up, you write your Lua program and place it into the same folder as WideClient. There's no such file provided for you! It is not an error message! It is only telling you in case you had such a plug-in and it wasn't operating. Lua facilities in both WideClient and FSUIPc are described in the Lua documentation installed for you in your FSUIPC Documents folder, which is in the FS Modules folder on your Server PC. Pete

No. In the Modules folder, next to FSUIPC etc. FSUIPC will list ALL lua programs for assignment. In fact if you placed a file called "idle1.lua" in the FS Modules folder, next time you load FS, or if you got into the assignments tab in options and press the "reload" button, you'll get all these added to the assignments list: Lua idle1 Luaclear idle1 Luadebug idle1 Luakill idle1 Luaset idle1 Luatoggle idle1 Luavalue idle1 If you aren't seeing these then either you've not saved the file in the Modules folder, or you've not named it correctly with a ".lua" suffix. Pete

The FSUIPC4 installer always checks for FSX, ESP and Prepar3D. The FSUIPC3 installer checks for FS2000, FS2002, FS2004, CFS1 and CFS2. It shouldn't be a problem. If, however, it is prompting you to locate the folder then it is finding a Registry entry which indicates P3D is still installed -- in that case the uninstall didn't work fully, as that entry should have been removed. Regards Pete

This is the second time you posted the same question! You just changed the thread title slightly. :sad: Why not read my previous reply in your original thread from yesterday? See below a few messages. No. Your settings aren't touched, ever, by any FSUIPC installer.. Pete

Depends on the data. If it is only a flag showing whether a switch is on or off, it only really needs one bit, let alone a whole byte. If the program you are using for the displays doesn't tell you -- i.e. if it allows you to use what you like, then just use the type which can hold numbers as big as they are going to be. The range of values possible in an 8 bit byte is 2^8 = 256 values. In a 16 bit word is is 256 x 256, or 65536 vaslues, and so on. If the value you need is a real number with a fractional part, such as 3.142, you'd need a Float (32-bit floating point) or a double (64 bit floating point). If it's a string of characters (i.e. text) you'd need enough bytes to accommodate the number of characters in the string. There's nothing mystical or complex about it. It is just a straightforward storage decision. Use a big a box as you need for whatever it is you want to hold in it! Pete

Sounds like you are reading it incorrectly then, maybe as 2 bytes (16bits) instead of 4 (32 bits)? Try using the facilities provided to see your error -- ie.g. ipc.read logging, or easier, just monitor the offset as type S32 using the right-hand side of the logging tab and selecting "Advdisplay" or "FS window" below. You'll see it changing in real time then. Also a tool called FSInterrogate is provided in the SDK which will display values even more intelligently. There are lots of ways to check your work. Regards Pete

That override can only happen if FS is receiving signals from that axis. So the problem is that your lever is jittering. You need to calibrate in FSUIPC with a sufficiently wide "Arm" zone that any jitter with the lever positioned in the Arm zone is not transmitted on to FS -- FSUIPC doesn't send unchanged data. You can do that sort of thing with a Lua plug in. Easier than what you suggest would be to have the button release to execute a Lua plug-in which simply did a loop of "throttle 1 incr" controls until the throttle value read "0", e.g: while true do throttle1 = ipc.readSW(0x088c) if throttle1 >= 0 then break --exit when no more reverse end ipc.control(65964) --65964 = throttle1 incr. Use 65965 for smaller increment ipc.sleep(10) -- adjust for speed of increase. 10mSecs = 100 per second end[/CODE] Just save thatas, say "Idle1.lua" and assign the button release to "Lua idle1". Throttle2 is similar. The Offset is 0x0924 for throttle2 and the controls, as per the list in your FSUIPC documents folder, are 65969 or 65970. Regards Pete

Well, to be honest, i don't really agree with the need. Reponsiveness is programmed into the aircraft, and decent add-ons like those from Level D and PMDG seem to me to be spot on in any case. They are tested by real pilots. Maybe you are a real 747 pilot and think otherwise? If so you should really argue with the PMDG folks about their modelling. There's already a fitering option. which does prevent sudden changes. But the point of that was to deal with unrealistically jittery controls, usually due to a bad power supply. And I've no idea what sort of algorithm would actually give the results you want. You'd need to experiment. I don't really understand the reason -- surely with most aircraft the delay between moving a control and having the surface move is negligible in any case (there's a direct link in most small aircraft), and on stunt and fighter aircraft the response is as fast as the pilot movements. It has to be. So, I would be the worst person possibly to implement anything like this. As you seem to know what you want to achieve why not try to program it yourself? That is exactly why the Lua plug-in facility was provided -- for individuals to do things for themselves. I can help you implement it, code-wise, but I can't tell you how the output should depend on the input (or not?). You obviously have your own ideas for that otherwise you wouldn't have proposed it. Why not just work them out and write them down? The steps to a working plug-in are then trivial. For example, for a simple linear movement:at a speed which is a fixed proportion of the pilots movement speed: lastvaluesent = 0 targetvalue = 0 X = 0.5 -- Linear speed. 0.5 = half control movement speed Y = ? -- Set this to the axis control being manipulated while true do targetvalue = ipcPARAM --ipcPARAM contains the value sent by the assigned axis control if targetvalue ~= lastvaluesent then -- Here replace X by some fraction experimentally to achieve desired result lastvaluesent = lastvaluesent + ((targetvalue - lastvaluesent) * X) -- Here replace Y by the FS or FSUIPC control number for the control being manipulated ipc.control(Y, lastvaluesent) end ipc.sleep(10) --experiment with different delays here, 1 to 100 mSecs end[/CODE] The control number Y needs setting for each control -- see the list in your FSUIPC documents folder, or use one of 64100-64144 for the "direct to FSUIPC calibration" controls. The save this in the Modules folder as, say "ailerons.lua" or "elevators.lua". In the FSUIPC INI file add sections like this: [Auto.<name>] 1=Lua ailerons 2=Lua elevators where the <name> is the Aircraft or Profile name. Then, in FSUIPC axis assignments, assign the relevant control to "luavalue ailerons" or "luavalue elevators" as appropriate. All you then need to do is experiment with the value of X, or change the formula -- that's a linear formula moving the surface proportionally to the speed of the control movement. You might want it exponential or something. You can make it a fixed speed independent of the control speed by simply changing [CODE] lastvaluesent = lastvaluesent + ((targetvalue - lastvaluesent) * X)[/CODE] to [CODE] if (lastvaluesent - lastvaluesent) >= N then lastvaluesent = lastvaluesent + N elseif (lastvaluesent - lastvaluesent) <= -N then lastvaluesent = lastvaluesent - N end[/CODE] where N is some small fixed increment, like 64 or 128 or 256 (the whole range is 32768 so 256 gives 128 steps, etc). See? The possibilities are endless! Have fun! Regards Pete

Ah. Sorry. It was my error! In older versions of FSUIPC ( I don't recall eexactly when it chaged -- 4.7??) this defaulted to "No". In the current versions it defaults to "Substring". But when I was testing the changes to stop FSUIPC crashing wihen reading those section headings with missing ] vharacters, I did change it to "Yes" as part of testing. I now see I forgot to change it back to "Substring" afterwards, so it was wrong in the INI is upplied in this thread earlier! Sorry! Regards Pete

I moved your support question to the Support Forum. Please post here in future, not in one of the subforums which aren't for general support but helpful information and links. Download the Install package, unpack the contents, read the documents, run the installer as instructed. The separate DLL packages are only for those updating incrementatlly within the same version. If you don't use the installer your documentation and all the other goodies won't get updated. Pete

But only the first line, 1=B767-300ER is needed to match ALL of those because they ALL contain that substring. Or have you changed "ShortAircraftNameOk=substring" again? Pete

There's no way FSUIPC can fix it for you then. You'll need to seek help from the quadrant makers or whoever did the driver. Regards Pete

The delay feature in FSUIPC's axis assignments can be set in milliseconds. Please see the Axis Assignments section of the Advanced User's guide to see how to add it by editing the INI file. FS does something like that, but not very well, by default, if you assign there instead of in FSUIPC. If you want to do it in FSUIPC you'd need to assign the axis to a Lua plug-in and process the value there before sending it back as the appropriate axis control. You could apply whatever algorithm you liked that way. All assignments can be made Profile or aircraft specific. Regards Pete

Sorry, I've no idea because I don't know how you've programmed it. If you are loading, compiling, running and discarding a Lua program for every click of a rotary, it will obviously be rather slower than if you were to do it with a permanently loaded plug-in. Maybe more information might help me help you? For instance, relevant things like the Lua program, and how you are invoking it? Oh, and the FSUIPC version number of course. Pete

"fac throttles"? What's that? There are assignable controls in the FSUIPC assignment dropdowns called "Throttles off", "Throttles on" and "Throttles toggle". They can be used to disconnect the throttles from FS when you don't want them to interfere. Isn't that what we've been talking about all this time? You have be worried now. Isn't that your problem? You want to use the reversers but you cannot without pulling the quadrant out. This is investigating a possible alternative! Pete

That's okay. It was just really frustrating not being able to reach you. The problem with the missing ] character on the headings will no longer crash FS with FSUIPC 4.81 or later, available now from the Download Links subforum. In fact it fixes them by adding the missing ]. I hope you like the Profiles i set for you in the INI. I simply used the shorter form of the aircraft names. Regards Pete

Okay. Couple of points: Version 4.7xx was replaced by 4.8xx a few weeks ago and isn't supported now. 4.81 was released today. It seems the driver for your quadrant is sending THROTTLEn_SET controls with a zero (idle) setting continuously and very very frequently, so preventing anything getting in and changing the throttles. The only think I can think of trying. Go into FSUIPC's Axis Calibrations, to the 4 throttles page, UNCHECK the "exclude ThrottleN_set" option at the bottom, and see if the quadrant is detected there. It could be, depending how their driver is sending these controls. If it is, go ahead and calibrate them there, as you would any other axes. THEN, if you can do that, you should be able to swtch the throttles off by assigning a button or keypress to FSUIPC's "throttles off" or "throttles toggle" control. But please do update to 4.81. Regards Pete

Yes, of course. It is the malfunction of those, not the originals on the quadrant, that you wish to rectify, is it not? Therefore we have to see what is happening to their inputs. Pete

Sorry, I'm rather confused by your terms. By "code" what do you mean? Is it a list of FS variables and the FSUIPC offsets you need? If so, the complete lists are provided in documents included in the FSUIPC SDK. Regards Pete

I don't know these I'm afraid. Are they programs interfacing to FSUIPC running outside of FS, or are they Gauge files added to FS panel definitions? If the latter then they will only run inside FS, because they depend completely on the support of the FS panel and gauge system. If they are separate programs which use FSUIPC for their access to FS, then they should run via WideFS as well, though they may also want normal explorer-style access to shared folders on the FS PC for some data. Their documentation should clarify this. Regards Pete

That was only a reference back to the alternative idea I suggested, that of providing values to Lua plug-ins (or anything else for that matter) by posting them in offsets, rather than the original idea you had of executing a receiving Lua program. I wouldn't think too much on that side of things though. If we can get a reasonable understanding on the EULA with PMDG then I'm sure Nico and/or I will sort the offset method out fine. We need PMDG to recognise that utility programs providing transparency for the data made available via their SDK do not in any way constitute "End Use" and are therefore not subject to the EULA. As Nico has pointed out over in the MyCockpits thread, one clause in particular is worrying in that regard. Yes, that would be the sort of application I would envisage. Regards Pete

I backup all my work on a separate PC. And every now and then, usually before going away for a weekend or on holiday, i write it to DVDs and store them safely in an outbuilding (in case my house falls down or something!). A lot of folks sem to be using on-line storage these days. The magazines have even been comparing the different services available. But with many gigabytes it is not only more expensive, but VERY slow with UK upload speeds. Download's not a lot better, yet. If you only mean FSUIPC configuration, just back up the INI file and any macros and Lua files you've created. Regards Pete

This was a problem introduced in a release a few months ago (not sure which one), and fixed recently. Can you please re-check with the latest version (4.81 or 3.999f). Let me know. I'm pretty sure it is fixed, but it isn't easy to test all configurations. Regards Pete

Some ipc calls in Lua threads are explicitly subjected, in FSUIPC, to a "sleep" of 0 or 1 millisecond. This is in order to make sure other threads, and FS's own main thread, gets enough time. In fact the vast majority of the time needs to be spent in the FS executing threads. I'm not sure why you are using ipc.set, which stores values in another (permanent) Lua threads's stack so that they can be retrieved by other threads using ipc.get, but obviously there's a process switch involved each time you do that. Alternatively I would assume that if you are updating FSUIPC offsets from your DLL you'd be doing that directly via the FSUIPC DLL module interface, not via Lua programmed code. There is really no need for FSUIPC to provide Lua plug-ins with ultra-fast execution speeds. The application here is merely the updating of displays or whatever with read-ots from the NGX. FSUIPC + Lua can easily meet the needs of displays at any rate needed smooth to the eye. The prime aim of FSUIPC in these matters is the provision of useful plug-in facilities which don't detract from or impinge upon the performance of FS in any noticeable, or even, hopefully, measurable way. Regards Pete