Pete Dowson

Hmm. Strange. I've never been able to. What happened in your example above, then? Ah, so it will have been the XML gauge which got them created! And does that variable exist beforehand? And if so, does the gauge concerned allow this? And is the button being held long enough? Try using some separate LVar logging, like the Lua plug-in supplied with FSUIPC, to see what's happening. I'm not sure how this later comment really relates to your earlier need to communicating values between plug-ins, which is definitiely a facility explicitly implemented in the library. Pete

Seems doubtful to me. In the example you give it is evident that the LVar you are trying to read and write does not exist. You can't create LVars, only access whatever LVars the gauges you are using themselves create. It does say quite clearly in the Lua library documentation: "If the variable is not currently available, nothing happens" and the nil return to the read also shows that it doesn't exist. Even if you did it with an already existing LVar, the gauge decides what happens to that LVar, not you. The value could be changed after you try to write it. After all, they tend to represent things controlled by or supplied by the gauges themselves. To transfer data between Lua threads use ipc.set and ipc.get. That's what they are for! And with the most recent FSUIPC versions this even works over a Network between FSUIPC and WideFS clients, and between the clients themselves! Pete

Both the PMDG 737NGX and the 777X have facilities to control everything through added controls, which can be assigned in FSUIPC as "<custom controls>". The number of the control is needed and can be calculated from the data given in the PMDG 777 SDK -- look for the file of type .h. The list is near the end, after all the data (read-only) values (which are all mapped to FSUIPC offsets if the SDK option is enabled in PMDG). However, I don't know if even those controls provide a way to set the MCP values directly. I think they operate in the same way as using the mouse -- ie by incrementing or decrementing the value. You could do that in a loop, reading the relevant offset, until you get the value you want. The offsets are listed in a document provided in your FSUIPC Documents subfolder, in the Modules folder. Pete

Further to my last message here, in FSUIPC version 4.959, being released soon (certainly before tomorrow evening (Monday 19th), I've added an option in the [General] section of the INI file: WideLuaGlobals=Yes If this facility is not needed in a WideFS setup, the this can be changed to 'No' to make the ipc.set function exactly as before. Making the timing the same even with it enabled is a much bigger job, and I'll look at that in January. Pete

To make other PCs on the network aware of a change in a Global Variable a "broadcast" has to be sent, to all PCs in the same WorkGroup. Tht does involve several extra calls into Windows (CreateFile, WriteFile, CloseFile to be exact -- not disk files, just packets for transfer). This might take a few milliseconds I suppose. I don't fully understand what is going wrong for you. Is the small extra time causing the problem, and if so, why? Wouldn't other plug-ins be just as happy to see the values a little later? Have you actually measure the difference in times using the mSec count from ipc.elasedtime? I can look at creating another thread just to do this, but this wouldn't be a trivial job and I don't have time before Christmas. I have to make a new release of FSUIPC (4.959) tomorrow, but then I'm away till January 5th. I can look then to see what I can do, but I'd like to understand how rthe problem arises first. Can you remind me in January, please, so I can take a look? Pete

First off, your plug-in will still be running all the time after it is first invoked. The "event" system keeps it running, waiting for that even to occur again. That will happen any time the "on ground" flag changes. You should, instead, simply assign the axis itself to the Lua plug-in (as well as to the elevator). There's no reason and little point in using the range assignments on the right-hand side. But you would have to assign the elevator using the FS control method, not "direct to FSUIPC". But that should be okay. Next, you want to be sending a value based on the axis value rather than just using the Brakes ON/OFF system. That's why the value is provided. Don't use any "event". Just use ipc.readUB to read offset 0366 to decide what to do, then use the Axis controls (not "Brakes Left/Right", but the ones you'd assign to real toe brakes). Since you only want the brakes to come on when you push the stick forward a ways, test also that the "value" is over 8000, else do nothing. In all the two ipc.control calls you do, use the relevant Axis control numbers and put a number derived from the "value" from your joystick as the parameter. For a "value" of 8192 to 16383, say, just use 2*(value - 8192). That will give the correct full range for the brake axes, assuming you only do this when value >= 8192 of course. Pete

Something amiss in the Registry. Glad it is now all sorted! Thanks for letting me know. Now use Windows backup (or better) to save a snapshot with everything working. You can then get that back later if needed rather than having to reinstall! Pete

But are they seen in calibration still, not in assignments? That was the point. If not now, then sorry. It makes no sense to me at all. There's never been an issue like that before. If I had more time I'd work out some extra logging and send you a test version to give me information to see what is going on, but I'm desperately short of time before leaving to visit my son for Xmas, and then I'm not back till Jan 5th. If you still want help then please post a reminder and I'll get to it. Pete

But you should have controllers disabled in FSX if you are assigning in FSUIPC! Then the stick axes are assigned in FSX, or the stick is being controlled by other software. FSUIPC calibration operates on the values inside FS, not on the joystick inputs directly. Ensure controllers are disabled in FSX. If they are and you still get the movement in the calibrations screen then you most certainly have got some other driver or software running which its taking the inputs from the stick and passing them to FSX. That could certainly explain why FSUIPC doesn't see them. Pete

The GUIDS come from Windows, so apparently it sees three devices. Either that or there's some corruption in your Registry. FSUIPC's ID numbers count from 0. JoyIDs and FS's from 1, so when you moved the throttle from 3 to 2 evidently the 3 one stuck. So what does FSUIPC see gor these in its assignments tab now? Is the throttle still seen correctly and if so as 1 or 2? Id jy 0 not seen at all? Yes, it is. there have been 4.958a - 4.958f versions supplied to folks who needed to try things, and 4.959 is being released tomorrow. That's why I always say "or later". Pete

Ah, so, it just isn't seeing the Stick at all. Is it listed in the Scan at the beginning of the FSUIPC4.LOG file? Is it listed in the FSUIPC4.INI file? And, probably more to the point, are you using the correct version of FSUIPC? At present, for FSX, FSX-SE or P3D it should be version 4.958 or later. If not update first and retry. Also see the FAQ subforum. There's a thread there entitled "Fixing joystick connections not seen by FSUIPC"

Does FS recognise those buttons? If so, what numbers does it show for them? FSUIPC can only support 32 buttonds per joystick, which FS numbers 1-32. FSUIPC would number them 0-31 (as they are numbered internally, in windows, as well). I know many others use the X-52 and I don't recall others reporting a problem. But maybe you have some X-52 driver of other sftware installed which intercepts those buttons and assigns them itself, maybe to keystrokes? Check that also. Pete

When you say you've put it into the "fsx file", where exactly do you mean? It goes into the FSX folder, where FSX.EXE is run from. It sounds like you have either put it into the wrong place, or you have not actually run FSX itself yet so there's no SCENERY.CFG file for it to read. It does produce a log file called "Runways.txt" which will help me help you. Show me the contents of that. Pete

Even simply unplugging controllers and plugging them into a new socket on the same PC will often change its Windows-assigned ID number. You needed to enable joystick letters in FSUIPC first, so it could renumber all the assignments automatically. If it is too late for that you could try to change the ID number directly. There's a program called JoyIDs which can do that. It's available in one of the sub forums here--probably in Download Links, but otherwise in FAQ. Pete

You probably have controllers still enabled in FS/P3D. It will make automatic assignments. You must use FS assignments OR FSUIPC, do not try to mix them! Pete

I think that can only be caused by a faulty controller, or worse a faulty USB hub or chip. When you say do you mean that this still happens when the relevant joystick (joy 0) is unplugged? If so it must surely be the USB side of things. If it was plugged into an external hub try plugging instead into the PC directly. If already direct, try a different socket. Note that the joystick number (ID) might change if you move it to a different socket. If you want to avoid that happening (now or in the future) you should first get FSUIPC to use joystick letters. There's a chapter about that in the User Guide. It's easy enough to do -- a one line change in the INI file before running FS will accomplish it the simplest way. Pete

Sorry, then, I haven't a clue. I really don't know anything about the frictions tables in FS/P3D. someone else discovered them, inside SIM1.DLL. He used to provide patched versions of the DLL, but that is really not a good idea and can mess things up, so I just programmed the same patch at run time, and later added a way to change it dynamically via a Lua plug-in. Maybe you need to park facing into wind (as I think most light aircraft tend to do also, if I remember from my pilot training days)? Pete

It's available on the main FSUIPC download site over in Schiratti.com/dowson, and also in the Download Links subforum here. Where did you get FSUIPC from and not find MakeRunwats? Pete

What are you actually trying to o? If you want all 737's to use the same settings, you can simply have one line in the [Profile. ...] section sayin "1=737". Then any aircraft with 737 in the name will use that profile. i.e. exactly what it says in tthe instructions you quoted, 'such as "737" ' Only the [Profile ...] sections define which aircraft fit that profile. the [Axes ... ] are axis assignments made in the named profile, same for Buttons, Keys and JoystickCalibrations. For all 737s and all 777s you'd need two lines 1=737 2=777 It seems you think it is more complicated than it really is. it is actually quite simple. if an aircraft contains the text you give in the [Profiles. ...] section, anywhere in its name, then that named profile will be used for it. It it doesn't it won't. Simple as that. Pete

Can't you find the section in the Advanced User's guide? Just put the CLOSE or KILL word in, much as you did the READY keyword before. How did you do that if you don't know how to put parameters into a line? Pete

No, no! How are you reading that? The name of the L:Var is a string and could be quite long, so it will never fit into the 4-bye 0D6C location! As it says, it's the number of the user offset where the value is written from or read to which goes there -- the name goes into the 40 byte area at 0D70. Please read whht it says more carefully. it is explicit! It's just writing values and strings, as for any other FSUIPC interfacing task. I'm sorry, but i don't use the .Net DLL, my only languages are C and ASM> Pete

I don't really know. Is that covered by the frictions table which can be altered? If not I guess you'd need some sort of program to manipulate the ground speed and angular velocities in the appropriate circumstances. Have you tried using the changed frictions offered in the Lua plug-ins supplied? Pete

If you know the names of the L:vars you need, with any recent version of FSUIPC you can read L:Var values through offsets -- see offset 0D70 in the Offsets Status List document. If you first need to discover the names, there's a Lua plug-in provided which monitors L:Vars and logs/displays them as they change, and an assignable FSUIPC control which lists the names and values at any time you invoke it. Pete

Perhaps those A2A aircraft implement their own subsystems rather than using FS's built in ones. A lot of add-on aircraft do that (PMDG, some Aerosoft ones, FSL), primarily because they cannot get the model accurate enough or realistic enough using FS's own code. The values in the standard FSUIPC offsets are those provided by SimConnect and they are the ones FS knows about. If they disagree with whatever is shown on the add-ons gauges then either the relevant system is being simulated separately, or, in order to get the desired performance, they are being "fiddled" internally and the gauge values adjusted to show what the values should be rather than what they really are. I guess the only way you'll find out which and why would be to ask A2A. They should know the answers! Pete

You don't need to reach it!! I only mentioned it to explain that with the "KILL" keyword in your Run command, instead of "CLOSE", it would act like terminating the process with Task manager! Mind you, I now notice you didn't even bother to use the CLOSE keyword either, in the Run= line. Maybe that will do the trick in any case. Why didn't you try it? (You don't close followme.exe either). Pete