Pete Dowson

As documented, the ZFW is supplied as a value in pounds multiplied by 256, so, tell me, why are you multiplying by another 256? Pete

Surely one of the L:Vars you can read will tell you which is to be used? If not, sorry, I can't help. You need support from the aircraft writer. Pete

I thought you said you were using FS9 and FSUIPC 3.99! And as I said there's nothing assigned to offset 126C in FSUIPC3! Please re-read the earlier reply! Pete

That was very useful. Thanks. it was a bug. I was using a short integer (16 bit) for a size value for internal storage based on the size of the MCRO file, and yours computed at over 32k, which made it look negative in a signed 16-bit word. That got expanded to a HUGE positive number when fed to the memory allocation routine ... bang! It'll be fixed in forthcoming updates for FSUIPC3 and FSUIPC4, probably Thursday but maybe tomorrow. Regards Pete

Yes, get the total weight, from 30C0, and subtract from that the ZFW, which you found. note that they are in different numerical forms and units. What was that business with 126C, though. What did you read to get that? Please do use the correct references. And you would be able to find all the relevant ones by simply searching on the word "weight". There aren't all that many! ;-) Regards Pete

I assume you mean FSUIPC3 with FS9 or before? FSUIPC4 does provide a specific offset for total fuel weight for FSX, ESP and Prepar3D. It's in offset 126C, as listed. If this is with FSUIPC3 I'm not surprised as 126C isn't assigned to anything useful. What do you think is there? Well, more errors. As well as 126C being an unknown quantity, you have 3BFC being treated as a "short" when it is clearly documented as being 4 bytes = 32 bits = integer, not a 2 byte 16 bit short. If you are using FSX and FSUIPC4 then the total fuel weight is already given to you in offset 126C, no computation necessary. It too is a 32-bit integer. You need to be a little more careful looking up this information. And make sure you are using a current edition of the offset lists, please. Pete

The format %01.2f means this: % means this is a value placeholder 0 means for any padding use the 0 character. You could have a space instead for spacing. 1 means include at least 1 character, even if 0. (Normally a number like 0000234 would be shown "234", but you can force "0000234" by %07 to say 7 digits. A format % 7, with a space, would give " 234" where there are 4 spaces in front of the 234. . shows you want the fraction part too 2 says show the fraction to 2 places f says the number is in floating point form (all numbers in Lua are floating point, but can be uses as integers too, losing the fraction). Regards Pete

Thanks! It might be tomorrow before I get to it. Things are piling up a bit! ;-) Ouch! Yes. No matter how much real memory you have, a 32-bit program like FSX is limited -- 3Gb. We're talking "virtual memory" in any case., the process virtual memory is 4Gb max for a 32-bit process. Other processes might still have most of theirs available even if FSX's process is stuffed. Regards Pete

You never need to access the panel whilst the Options dialogue is open. Even if you could it would do no good because FS isn't active when the dialogue is open, so there would be no way for the mouse click to be registered as doing anything! All you do in the dialogue is ENTER mouse macro creation mode and give the file which all the macros will go in a name. Then you EXIT, make all the maxros for the panel, and when finished, go back into the dialogue and switch macro making mode off! All this is explained clearly in the documentation, even with pictures. You'll see that the individual macro naming dialogue in an overlaid window, not a dialogue. Please do read a little more carefully. Regards Pete

Er, this is confusing for me, sorry. You mix too many questions in one paragraph. Yes, of course it is passible to write a value to the GF displays. That is what part of the Lua gfd library is for. But what is all that about "creating 1 for each mach number"? You just write the variable you read to the display in the correct format! What is driving the GFMCP -- do you have a complete Lua program for it, or are you mainly using the GoFlight driver for it? Because I doubt whether you can mix them successfully. Er, I'm not understanding any of this. Why only write 0.51? Why not write the value you read, call it "machval" or something? It seems totally inexplicable to me that you'd want to only write specific numbers. And it is a total waste doing "string.format("%03d", 0.51)" because all that does is give you "000" as a result, because the integer part of 0.51 is 0! If yu want the display to read 051 you'd write "051", or, if you have a "machval" variable you'd use string.format("%03d", machval * 100) You need to multiply by 100 to get mach x 100 for display. However, doesn't the GFMCP display decimal points too? If so you could use string.format("%01.2f", machval) or something like that. LVarSet = "L:MCP_MACH_DSP" LVarGet = ipc.readLvar(LVarSet) + 0.01 ipc.writeLvar(LVarSet, LVarGet) if (LVarSet ~= LVarGet) then gfd.setDisplay(GFMCPPRO,0,1,0.51) <<<<<<<<<< ??????????????? WHY? end Sorry, I don't understand a word of that bit. If you mean how do you add code into the latter, just add it in a logical place -- near the end, before the 'sleep'. Sorry, what limits for what? You've lost me again. I don't understand this either. If you want to apply limits to your mach changes, why not use the same methods as for the VS we already covered. just different values, that's all. Pete

Well, I was wrong! I have found it! I'll have a look at it later this week. [LATER] Looked at it already. 3.99 crashed because it was referring to a PANELS variable access facility which it seems was not included in CFS1, although it was in CFS2. The options were mostly disabled for CFS1. I've re-enabled them insofar as you get all the current option tabs, but I doubt if all of their contents actually work. And at present I can't guarantee than none of them crash CFS1. But if you only want to use it for calibration it should be okay. Look for an FSUIPC3 update tomorrow, or more likely Thursday. It'll be 3.997f or later. Regards Pete

That's interesting, I've never seen those messages invoked! The routine which logs that is the one used for all FSUIPC's memory allocations, and it means that when Windows was asked for more memory it said no, it couldn't supply any more! Once that happens, to avoid an infinite loop asking for memory, FSUIPC won't ask for any more. That's what it means by "Operations restricted." It's a pretty crucial error as it would stop a lot of things working properly thereafter. I wouldn't really expect to see such an error without FS also suffering from memory problems. Maybe it was a transient memory garbage problem but that sounds unlikely if you were able to reproduce it so consistently that you found out how to work-around it. Why does each variant of the same 737NG need a completely separate set of 65 macros? I don't understand things like that. A 737NG is a 737NG -- the cockpit is mostly the same across them all. The small variations you can get are usually customer options, but they are mostly ones of presentation, or the provision or absence of a particular switch or button. Having extremely large macro files isn't efficient in any case. There's a limit imposed internally of 999, but you didn't hit that. The limit would merely cause excess macros to be inaccessible because they wouldn't be tabulated. There's a maximum number of macro files, but i think that's only imposed by the size of the Macro file list itself -- up to 32k.characters. So there can be more with shorter names. Maybe, but there's an efficiency balance between larger files on the one hand and multiple files on the other. I wouldn't know how to compute it though. I must admit that most of the facilities in FSUIPC were designed with "reasonable use" in mind. These facilities probably aren't robust enough for mass industrial use. I've always striven for efficiency and performance so take the simplest most compact designs that work rather than try to cater for the ultimate and in so doing potentially wreck performance for everyone else. Anyway, I'm very curious as to how that memory error arose without any other nasty memory problems in FS too. I'd like to investigate. I could try adding extra logging in the memory allocation routine, but i think it might be quicker if I could try reproducing the error here. Do you think you could send me the file(s) which cause the problem for me to test here? ZIP and send to petedowson@btconnect.com. Thanks. Regards Pete

I've done some reading of my own historical documents, and as well as the long quotation from yo, they all seem to confirm what I am sort of remembering. CFS1 dates around the same time as the release of FSUIPC for FS2000, which was the first FS it was intended for. On FS98, and I thought CFS1too because it was based on the same code, it only ever provided the interface for applications, no user facilities at all. The quote you put into your last message seems to agree: With CFS2 it provides access to many of the things that programs enjoy on FS2000 and FS2002, including full weather control. However, it should be noted that CFS2 is not the main target, and support for 100% of the features is not guaranteed. With the original Combat Flight Simulator (“CFS1”) the features are much more restricted: for instance there are no operating weather facilities in FSUIPC for CFS1. It's a shame I cannot help further as I've not managed to find CFS1. I think it must have gone out with the garbage and FS98 some time ago. I did, surprisingly, find CFS2 and FS2000! Now CFS2 was more like FS2000 (it was basically the same code I think), and the current version, 3.99, of FSUIPC runs okay on CFS2 with most all of the user facilities intact. The only problem with CFS2 seems to be that the FSUIPC options screen is only usable in Windowed mode -- you can switch back and forth with ALT+ENTER as usual, or leave CFS2 in full screen mode and ALT TAB to get to FSUIPC options. But I think this deficiency might be down to changes in video drivers since then rather than any change in my code. The current version 3.99 is also okay in FS2002, which I just happened to have still installed, and I'm pretty sure it will be okay in FS2000 which I've also found but not bothered to install at present. If i do come across CFS1 someplace I'll certainly try it and see, but I don't hold out a lot of hope I'm afraid. I found all these others together and i would have assumed that if I still had CFS1 it would be with them. Regards Pete

Okay, Done. Please try these and let me know: FSUIPC 3.997e FSUIPC 4.715a BTW the alternative, using the event.terminate function, could simply call ipc.exit, which would do the lua_close, which should call all your __gc functions. But if that's all it was doing it would be a waste -- quicker to let this abort method do the same. Regards Pete

Sorry, I have no idea what their code is doing. Maybe they only update the value when another action is taken, like the mouse click on screen. Just because you write to an L:Var doesn't mean the panel will see that it needs to redisplay the value if it detects that by some other way. There have been lots of cases like that with other aircraft. Can't you get any help at all from the people who wrote this aircraft code? You are really asking the wrong person. Regards Pete

That makes 6 actually. ;-) I really don't know how I can at present. I would need to try and find a copy of CFS1. My old copy might be around somewhere. I'll take a look, later this week if I get time. Pete

So "lua_close" does no garbage collection? That makes no sense at all! :-( I've no idea whatsoever how to force garbage collection otherwise, and according to everything I've read it isn't necessary for me to do so. Lua tidies up after itself. Ah, if it's waiting for an event it is not processing any of the "Abort" flag settings! That is why! I never thought of that, sorry. I tested on looping plug-ins only. If it's waiting on any event it is easier. i can simply call lua_close instead of an event function! Tomorrow ... Pete

No, sorry. It was something I investigated years ago, but gave up after getting nowhere hacking away day and night for a week. I don't think it does. You, the pilot, have to select the reply by the item number in the menu. If the same number was always used for the same function you could use the words instead, but ... Pete

Right. so it is masquerading as the GF-WCP, because otherwise it certainly wouldn't see it at all. That's correct. At present I assign up to 4 WCPs from 152 to 155. However, I might change that if they only have 6 buttons -- I can accommodate up to 16 of them in the same space, as I was allowing for a lot more as I said. Yes, it looks like the changes are occurring in the data area defined for the 5-way toggles, so my computations for converting the toggle position into a button press is making a mess. The problem is simply that the information I have about the data format is wrong. they obviously changed it in the last year before releasing this WP6. I'm afraid it either means waiting till I get feedback from my contact, or you lending me your GF-WC6 to experiment on! ;-) [LATER] It's okay .. I just got the reply and have all the information I need! I'll sort it out tomorrow and you can test it for me. Okay? ;-) Regards Pete

Okay. Download FSUIPC 4.715. I've added those read-outs as follows: Offset - size - type - units - value 0334 - 4 - Float32 -- Radians - Pushback angle 0338 - 4 - Float32 -- Feet - Pushback contact X 033C - 4 - Float32 -- Feet - Pushback contact Y 0340 - 4 - Float32 -- Feet - Pushback contact Z They are read-only. I tested writing and that generates a simconnect exception. Regards Pete

Okay. try these: FSUIPC 3.997d FSUIPC 4.715 When a plug-in is being Killed, a flag is set which caused all statements to be bypassed until the end is reached, which will terminate that script (or module), thus very soon ending the execution at which time a normal Close should sort out any resources used. Of course if C-modules are called it cannot achieve that sort of result so easily, but hopefully they don't keep control for too long. I've allowed only 5 mSecs for this action to occur before forcibly throwing off the thread if it is still running. After experiments I found that 10 mSecs was sometimes just long enough to affect FS smoothness (I am controlling Lua plug-ins from FS's main thread because it makes it more efficient in accessing FS functions and data -- it would be far too much work and very complicated moving the whole system into a separate thread. There's also a new event: event.terminate("function name") which can be used in event -driven plugins to do specific tidying before being thrown off. There's 5 mSecs allowed here too (additional to the 5 mSecs above when both apply). Note that events aren't called when the plug-in is running, so it isn't any good for looping plug-ins or those engaged in such heavy work that the 5 mSecs could easily expire before the terminate event can occur. I've also changed the way the ipc.sleep(n) function works so that instead of using the Windows Sleep API directly with the value provided, making it non-interruptible for that time, is performs the sleep in small doses in a loop and checks the termination needs on each loop, finishing the sleep when an abort is indicated. I've not released these formally in the Download Links subforum yet, pending your findings. Regards Pete

I have two different programming definitions for the WCP. (it is actually the "GF-WCP" not "GF-WPC" as I wrote(. A. 6 indicators of almost any colour and 6 buttons (like the WP6), plus rotary dials A and B and four toggle switches A-D, but undefined toggle states OR B. 8 buttons, dials A and B which press as well, and a 4 toggles A-D each with 5 positions (mini-joysticks I assume), with the indicators only able to be off, red, amber or green. There is already code in FSUIPC for button and dial reading for the definition B above. If you have a GF-WP6 perhaps you can help? Does FSUIPC see any of its 6 buttons? If so could you please tell me the Joystick and Button numbers it comes up with? At least that will confirm whether the device is supposed to be the one I have details of, even if it is minus a few of its possibly-originally-intended features. Thanks, Pete

You can convert but it isn't easy. you need the air temperature and the true air speed (TAS). Googling will find you some formulae, like http://williams.best.vwh.net/avform.htm#Mach Regards Pete

Lucky I saw your post which you placed into the FAQ subforum, not in the Support Forum. I've moved it for you. Er, can you please explain what you mean about a license in this context? do you mean a commercial applications license fee? Or do you mean the normal user registration fee for access to FSUIPC's user facilities? Sorry, you cannot stay with 3.48 and expect any support. Why on Earth would you want to stay with such an out of date version? Pete

There is no change in WideClient between FS9 and FSX. There's only the one version of WideClient which can talk to ANY version of FS! You MUST have inserted the correct parameters in your INI file for it to ever work at all. You didn't have to change anything in the Client for FSX. Google? Why use Google? Why not just use the documentation supplied with wideFS? Look in the WideFS technical document for the section entitled: PTT (push to talk) for Roger Wilco, AVC and TeamSpeak and be sure to note the subsection there about TeamSpeak. All I know about driving these programs is there. I don't use any of that stuff myself. BTW, I did mention the WideFS technical guide and the bit about TeamSpeak in this thread two days ago, but you seem to have ignored that. :-( Regards Pete