Pete Dowson

The fact that it isn't receiving broadcasts does indicate that either one of your PCs is using an old version of XP (before SP1), or that the Workgroup names in the two PCs are different. Broadcasts don't work across different workgroups. Renaming is easy enough in "My Computer" properties. Regards Pete

It's a bug in SimConnect. It does recover itself if you keep trying. Please see the FAQ thread FSX fails to run after FSUIPC4 first installed. Pete

Is that your complete code? Because you need to use gfd.GetValues beforehand, as the documentation says. All "gfd.Buttons" does is decode the buttons value from all the data obtained by the last gfd.GetValues. If you want individual buttons you'd be better off using gfd.TestButton in any case. Just have a loop testing each possible button from 0 to 31. As the documentation says, each of the 32 bits in the returned value represents a button setting. You'd need to test each bit separately using the logic.And function with a mask, starting with 0x00000001 for button 0, doubling each time till you get to 0x80000000 for button 31. For a short tutorial on numbers, bits and masks see the FAQ thread entitled About bits, numbers and hexadecimal ... Regards Pete

The value from the offset is mach x 65536. But to get 3 digits you have to multiply by 100 (0.82 to 82). If you divide by 65536 and multiply by 100 you get 655.36 -- please use a little more thinking! Pete

That gives you Mach speed x 100, with no decimal point. eg. 082 for mach 0.82 For that you need to divide by 100 of course: stringMach = string.format("%01.2f", Mach/100) That will give 0.82 for mach 0.82. Pete

Correct. Sorry? This question seems to have no meaning. what offset where? Please, if you are going to ask a question, supply more relevant information. Pete

That sounds like an old version, which, like old versions of FSUIPC, had such problems when certain video Drivers installed Windows DLLs which were not compatible with the standard system font. The font metrics mismatched, causing one part of the Windows dialogue drawing code to use a different size to another. I found a work-around for that long ago -- otherwise it's a video driver or Windows reinstall job.. You are not calibrating the throttles correctly then. You must ALWAYS define a small unused zone at either extreme to allow for readout differences. That is either a hardware problem, or a USB serial port adapter problem. i had similar results with some of the cheaper USB serial port adapters and eventually invested in a BrainBoxes serial port PCI card. I've had no such problems ever since. Before that I tried a number of different adapters -- the really cheap ones are almost useless. There really is nothing as good ass a genuine serial port. Please always quote actual version numbers, both of FSUIPC and the PFC driver. As it is I've no idea whether you are even using FSUIPC4 or FSUIPC2 or PFC.DLL or PFCFSX.DLL. The numbers are easy to find, please quote them. Pete

Have you tested the reverser with a default aircraft to make sure you have it right? The reverser cannot work unless both throttles are reduced to idle first, so check that those are calibrated to give a secure idle (zero) output first. you might need a null zone to ensure this. The FSUIPC reverser at full reverse position will send the maximum reverse value defined in the AIRCRAFT.CFG file. It reads this value from FS. Check the CFG file for this line: min_throttle_limit=-0.25 //Minimum percent throttle. Generally negative for turbine reverser That's from the FSX 738. 25% would equate to an output value of -4096 (25% or -16384). Maybe the Add-Ons you are having trouble with doesn't implement reverse using the FS facilities. Regards Pete

Thank you very much. It seems the chap who originally asked for the facility has found other things to do so I never really heard back from him after his initial misunderstanding. Regards Pete

Can you point at least one out, because i do not know of any reports, for years at least, of "errors galore"! The logs show no errors whatsoever, only a lack of any connection. Can you please describe what these "errors galore" are? Have you any record of them at all? If you are getting lots of re-reads and sumcheck errors, and these have occurred suddenly without any changes made by you, then it is most likely symptomatic of a bad cable connection or failing Ethernet interface hardware. Software, on its own, does not tend to deteriorate like hardware. The logs simply show the programs loaded and no connection. This line in the Client log: 68609 Trying to locate server: Need details from Server Broadcast shows the client is simply waiting to see the broadcast from the Server. Apart from firewall blocks at either end, the most likely reason it cannot see it is because your PCs are in different workgroups, but such a situation cannot possibly occur all on its own, only by changes made by you. You say you "have tried several quickfixes ", but did you actually try the main one to get around the lack of broadcast receptions, the one where you tell WideClient your Server details in the INI file? It is one of the first things suggested in the documentation, after all, in the section on configuring your network. It's all very well searching a Forum, finding lots of (unnamed) "similar" occurrences, and trying lots of "quickfixes", but it strikes me as usually more efficient to first refer to the manual. Also, if you have all this wealth of information, on errors galore and on quickfixes you've tried, it might be actually useful to state what they are in order to elicit further help. If you do have such relevant information, please provide it so I can help further. Regards Pete

Phew! From what I've seen of the PMDG 737NGX (I assume you mean that, not the iFly?), it is extremely comprehensive. There will be hundreds if not thousands of switch and dial actions, and I doubt that all that many will be accessible for hardware interfacing. It is not PMDG's way. If they do produce an SDK for it, that may be the only way. I might get the PMDG 737NGX, not for interfacing to my cockpit (it will most certainly not be possible), but because it would probably make a good learning aid for all the ins and outs and interactions between all the switches and controls -- especially those lesser parts of the overhead which don't generally get simulated. I already have the PMDG editions of the Boeing manuals, which I purchased last year when they came out. it isn't knowledge that is the problem. That can be obtained as needed by referring to documents and asking normal questions. And that's fair. I think the only problem you and I have here is that you don't seem to use much logical thought to move from one thing to another. It is thinking about what to do which would help, rather than rushing into things without thinking. I do think you'll be fine if you slow yourself down and think more carefully about things before writing code. Regards Pete

Everything is wrong there. Please, you are still not thinking at all. Look: ipc.readUD(0X07F2) is reading the value as Unsigned! That's what the "U" stands for! The VS can be negative,, so it is Signed! You need SD not UD! also ipc.readUD(0X07F2) is reading a DWORD, 32-bits or 4 bytes for the value, but 07F2 is clearly documented as being 2 bytes, or 16 bits or a WORD. So you need SW not UD! Please do READ what it says and apply a little intelligence to the way you read it. Next: it clearly says it is supplied in feet per minute. It says nothing about metres, nor about being 65536 times the value. It is just the number you want, so you need no conversion! Why don't you see that? In the end it is simply ipc.readSW(0X07F2) why oh why do you make such simple things so complicated? Please slow down and THINK what you are doing. Having to correct every little thing you do is taking a lot of my time and I've really not got so much patience. I did say I'd not do any more -- I shall have to stick to my promise soon! Pete

Sorry, I don't understand much of that. I've no idea what you are doing with V/S. You were saying the FS AP Altitude INC/DEC controls didn't work. They certainly do here, and always have. else you have a corrpted FS and should consider reinstalling. Pete

Yes, correct, but don't forget it is metres. If you want feet you need to convert it from metres, so math.floor( (ipc.readUD(0X07D4) * 3.28084 / 65536) + 0.5) because there are 3.28084 feet in a metre. So you have something else writing the MCP altitude? Those controls work perfectly with the FS 737. What aircraft is it? What simulator? Is this the "SimCheck A300B4-200" in your title? Does that use the default FS MCP? For the FS MCP test your work with a default aircraft first. Then if it doesn't work on an add-on you know they are doing something different. Log events in FSUIPC so you can see what happens? Pete

Where are you looking? The INC and DEC controls are listed in the List of Controls installed in your FSUIPC Documents folder. They appear in the Buttons and Keys assignments dropdowns. You can send them from a Lua program by using the ipc.control function, with the control number as listed in the List of controls document. Oh, heading. Yes, but not math.floor(ipc.readUD(0X07CC) * 65536 / 360) which converts degrees into FS units, obviously (360 degrees --> 65536 units). To convert the other way around it's the reverse, math.floor(ipc.readUD(0X07CC) * 360 / 65536) Don't you see? The value is documented as being the number of degrees x 65536 / 360, so to convert it to degrees you have to do the reverse, x 360 / 65536. Please do read the documentation more carefully. You are rushing along so fast you don't read things correctly. You might want to round it to the nearest integer, not round it down, so you'd need to add a half too, so: math.floor( (ipc.readUD(0X07CC) * 360 / 65536) + 0.5) Pete

Well, since that's exactly what it says in the document, I suspect that's a good guess! ;-) The controls for AP speed can be found by clicking the airspeed up and down on the autopilot speed adjust knob whilst logging Events. I think you'll find they are named AP SPD VAR INC and AP SPD VAR DEC. Why don't you just look through the list? You already knew about AP SPD VAR SET. It wouldn't have been too hard to look for yourself, would it? Why on Earth do you want to do such computations? It says it's in knots! What sort of speed value do you want, kilometers per hour? What's wrong with knots, that's what pilots use after all! Why not just accept it? Pete

There is NOT necessarily any correspondence at all between an event and a alue in FS in any case, and they certainly won't follow the weird names that Microsoft adopted for the events, like "AP spd var set". You need to apply a bit of intelligence and think about what value it is you are looking for. In this case it is to do with the Autopilot, right? So, search for the word Autopilot. And isn't the autopilot airspeed value in knots the thing that the control "ap spd var set" would set? What else do you think it might be? How many airspeed values do you think the autopilot has? Pete

The problem there is that I've no idea why itt doesn't work, because, as you see, it simply uses the same standard setBright calls to GFDev.DLL that all other devices support too. If it doesn't work it might be a bug in GFDev.DLL, but i can't really report that without knowing for sure. Why not just knock up a little test of the gfd.setBright function on it and see what it does? Pete

Pretty much what it does say, though when it was written I couldn't have said "many" -- I really have no idea how many it works on because I don't have nor use many add-on aircraft at all. There is a thread in the User Contributions subforum that tried to make a list, but I'm not sure how far it got. See here: http://forum.simflig...le-with-macros/ Actually, you need to read my answers more carefully, because right at the beginning I answered your question clearly with It was you who chose to quote extracts from the manual, out of truly relevant context, and then continued to argue about meanings of words and such even after I clarified it and highlighted the parts you chose to omit and seemingly ignore. Whilst obviously I do like folks to check the manuals (else why write them), having parts quoted to me out of context to try to illustrate something they think is wrong, and then when corrected trying to say it is self-contradictory, is really not a good way to ask a simple question and get a simple answer, now, is it? Think about it! Why didn't you simply take the first "No" in the answer and be done? Oh, BTW, I don't do tutorials, only reference manuals. I'm sorry you don't like them, but you can read them before purchasing and also browse this Forum to see my style of support, and if you didn't like anything you would then of course be free to take your custom elsewhere. Regards Pete

I thought you were having your plug-in loaded automatically via the [Auto ...] system? For that you only need to put a line with Lua GF-ModDisp into the [Auto ...] section. There's no reason to use ipcReady as well. That's for Lua programs you want running all the time regardless of aircraft etc. Also, whilst ipc.macro("Lua GF-ModDisp") will work, it is a little easier and more efficient to use ipc.runlua("GF-ModDisp") BTW why "2B00" for one of the offsets and 0x.... for the others? Nothing wrong, just inconsistent. "2B00" is treated as 0x2B00. There's a Lua math library function called "floor" for that: math.floor(29.3456) gives 29. If you want to round to the nearest whole number add 0.5, i.e math.floor(x + 0.5) It is much easier and quicker to simply assign a temporary keypress to the Lua and use that. Whilst testing plug-ins i tend to use TAB+Q (easy being next to each other). When you start a Lua program again it kills the first incarnation and loads it again. Not nice. Why's that? It can only do that if the name changes. Regards Pete

Oh dear. No no no! Where do you get these strange ideas from? There is nothing whatsoever about offsets in that log line. That is logging an EVENT in FS -- a control. The "Ap spd var set" control is one listed in the assignments dropdowns for buttons and keys. It is number 66037 (same as hex 0x101F5), as you can see in the list of FS controls installed in your FSUIPC Documents folders. You cannot get offset details like that. You have to look them up in the offset tables which are provided in documents provided in the FSUIPC SDK, for FS, and in other documents for other add-on programs like Project Magenta and Sim-Avioincs and FlightDeck software, and so on. No, the first is the control or event number. it is absolutely nothing to do with offsets, nothing at all. How do you even think that? Microsoft called them Events in its user documentation but Controls inside, hence the "CONTROLS.DLL" which is the part of FS which deals with decoding them and passing them on to the right bit of FS. Offsets are addresses of values in memory. Events are things that should happen, sent from one place (as a result of a button or mouse click) to another (like FS's sim engine or a gauge). Offsets represent data. Events and controls represent actions. See? Even the concept is completely different. It's like comparing apples to eating. One is a thing the other is an action! Pete

If you know the offset and the format of the value, then, yes of course. There's a whole range of ipc.read and ipc.write functions for different offset types. But take case, as not all offsets can be written to. Nothing! There is no "Set" or "Get"! The offset is needed in hexadecimal (i.e. in the format 0x????, where ???? is the offset). If you do not know the offset, you cannot use it. Obviously. The word "offset" really just means "distance from" or "set off by", and represents the original number of bytes from the Global Base in FS's variables in memory, part of its "GLOBALS.DLL". So, an offset of 0x0020 (which is the same as decimal 32) is referring to some value which starts 32 bytes from the start of all the "Global" variables. So, you now understand that an offset is a number. It is almost always expressed in hexadecimal, not decimal, and the documentation lists them that way. The system of offsets for access to FS variables started in FS95 and FS98. When I introduced FSUIPC for FS2000 I continued this, although by then it was already an illusion, a fiction made to keep compatibility. These days the term is still used and they are still numbers, but there is no "Globals.DLL" in FS and the values are not really all in memory together. FSUIPC gathers them from wherever they are, on demand. Regards Pete

But it wasn't even necessary to understand that, when the operative statement was (and I'm sorry to have to repeat this yet again): in order to work they need to be able to hook into Gauge code which must be structured in the predictable way which results from using the Microsoft FS SDK for building gauges in C or C++. This unfortunately excludes most of Microsoft's own default FS aircraft, How on Earth can you misinterpret that? Whether you understand what gauges are or not, it clearly says that it doesn't work on most of Microsoft's own default aircraft. Why isn't that clear to you? Can't you even understand why your attitude is so exasperating? It says what it means in black and white! (Well and red in my emphasis!). It tells you clearly that it won't work on most of the default aircraft. You don't need to understand the word "gauges" at all, that is just part of the reason it won't work, which you don't need to understand -- though most folks questioned it before I felt bound to include that explanation! The documentation comes about like it is as a result of folks asking questions. You didn't have to ask what gauges were, but you should have seen that it wasn't likely to work because it clearly said so! It DOES work very usefully on many add-on aircraft, and that is why it still exists. Else I would have withdrawn it to avoid such timewasting. Pete

Which I did actually know! ;) By omitting the part that says "this is how" I naturally assumed you didn't realise you had to edit the INI file. Else why bother telling me about having Lua files loaded? Okay. So all of the first part of the post was really irrelevant and caused my misunderstanding of what you wanted to say! I think, then, you should have just asked that. Unfortunately it cannot detect a reload -- it does what it does now by seeing the aircraft name change. What is the problem with an aircraft reload? The Lua program shouldn't be stopping. Why does it need restarting? Maybe there's another solution to your problem? And apologies for appearing to "jump on you". If you re-read what you posted you will see why I couldn't see the question you really wanted to ask amidst what certainly looked to be a complaint against either the documentation of the Lua loading facilities or both. Regards Pete

ALL buttons and switches in FS are part of some gauge or other. They are loaded by FS using parameters in the PANELS folders which detail the gauges to be loaded and their positions and sizes. And it does clearly state, and I repeat, "in order to work they need to be able to hook into Gauge code" before going on to explain that Microsoft's code isn't susceptible. So, even if you had no idea what the word "gauge" meant, you are still clearly being told that mouse macros won't work on much of the default aircraft. Where does it say anything of the sort? That's nonsensical. If you don't actually read what is written I'm not surprised you confuse yourself. Please in future read what is written, and don't assume something else entirely. Then maybe you'll avert such confusion! Pete