gr8guitar

Pete Dowson said: All I suggested is that it would be better for you to refer to the list of offsets I actually provide AND install on your computer than to go off and find some possibly incorrect and incomplete document on someone else's site. I don't deserve all your criticism. If you reads through more of the Forum you see I go out of my way to ensure my users hsave a good working product and in fact most of the facilities have been added due to user requests. And this process has been continuous over the last 18 years, the first 6 of which were for no reward but the satisfacton of doing it. Pete I don't know why this did not show up in this particular topic. 1) yes, you do give support, which is good since it is now a purchased product, not to mention, an actual complex product, at least to me. 2) But by your own words, you said you don't deserve all my criticism. I only have one, and your above note indicates you don't have much patience. Again, you are the expert, and as such, I would hope you know more than most - definitely more than me but a little patience or even no response is better than a message that seems to belittle or berate someone. Also, numerous times, I have also thanked you for FSUIPC. And I believe both "criticisms" are valid - from my point of view. The positives of FSUIPC and its forum far out way its negatives...

Yes, but are you not the writer of the documents? If so, I would think you have a better idea of where to look than anyone else. I must admit, reading through the years, of the various questions of users you responded to, at times, you're not very patient. To you, FSUIPC options and functions should be obvious. But for me, and seems like others, do miss things or even simply don't understand). For example, it's been there for many years in the documentation, but I over-looked the part where a Lvar could be assigned in a macro (*.mcro as well as in a *.lua) until I had an issue with a Lvar (specifically with an xml gauge and FSUIPC offsets). I use the documentation, but if I can't find or recognize what can help me, I turn to the forum, and then search the Internet. Which brings to mind: Is this not the reason the forum exists? Many times, for me, just a change for wording can help me understand a concept I have trouble grasping. Again, I am grateful for FSUIPC, GPSOut and the forum. It's made the simulator experience much more interactive.

I used the PM website because I was under the impression, unknown to me, it was your website and I thought it might be more up to date than the old FSUIPC for FS9. And yes, I have the FSUIPC docs and use them but unlike the author of those documents, I do not know all the information, nor can remember all the details of its vast material. Thanks for the heads up but I don't having anything confidential of significance on that computer and I don't have any viruses or anything like that. I heard another person with a very simple set up could not lower his gear using the [g] key so I know, somehow through FSInn, that the administrator can affect an aircraft. For a test, I renamed the FSInn's dll and there were no issues although no multi-player function either. I use Excel for sooo many many things, other than word-processing. It's been my "bread and butter" in work and for home hobbies. I'm grateful for whomever added the visual basic code to access the FSUIPC offsets as well as FSUIPC and GPSout.

Okay, you got me confused. Looking at: http://www.projectmagenta.com/all-fsuipc-offsets/ , I cannot find offset 0558. But in any case, as I mentioned above, a direct write to the airspeed and groundspeed did not work. However, adjusting thrust is a new thought I hadn't tried - so I will - thank you. I must also mention, I am using FS2004 (FS9). I know, I know... Also mentioned above, using Excel, I am able to move the aircraft using a pre-defined groundspeed and heading, and predicting what the next latitude and longitude would be, and writing those to FSUIPC. I'm also doing that with altitude using a pre-defined vertical speed. I'm doing this because, 1) I was curious if I could. I use Excel and its VBA like many use WideFS (sorry Mr. Dowson but one must save money when one can, no matter the amount). I use Excel for many things, my FMC, abnormal procedures, like a stuck flap, runway vibration, etc. 2) The long story mentioned above: I recently joined a multi-player session and somehow (through FSInn), someone was able to cut my engines in a B737800. I could re-start them but then the engines would be cut again. I had to fly in this manner all the way to my destination - slow and frustrating. I have flown this aircraft for many years and never had it lose engines on its own - unless set to a random failure mode or using Excel. So now I use Excel and whomever on FSInn, cannot effect my aircraft's position anymore. From takeoff to descent, is done in this manner and the others "see" my aircraft moving in "real" time. This was important because (I don't like the idea someone could mess with my flight. 2) And my virtual airline keeps track of the flight. If I "crashed" I don't get credit for the flight. I can accept the consequences if I did something but not if someone else was the cause. I'm still curious how "they" were able to take control of my aircraft, and how I can prevent them from doing it. If I could then all of this would have been just a good learning process and fly the aircraft normally.

Well, I appreciate your response but I already tried those - THEY DO NOT WORK ...to write to FSUIPC.... But thanks.

Well, not sure what the above means, including ( NAV1 frequency, 4 digits in BCD format. A frequency of 113.45 is represented by 0×1345. The leading 1 is assumed. (See also offset 0388) from Project Magenta's FSUIPC offsets. I am using Excel with VBA and FSUIPC and to be able to Write to FSUIPC, this is what I did to make it work: Given a number (nav radio frequency, say 112.10.), 1) Cell (AU1) = 112.10 needs to become: 1210. I did it this way: Cell(AU2)=MID(AU1,2,4)*100. 2) Caveat: 1210 is the hex value. So perhaps this is the BCD format mention in Project Magenta's FSUIPC offsets. So then: Cell(AU3)=HEX2DEC(AU2). This result is: 4624 in decimal value, that will be sent to FSUIPC. 3) In my VBA, in part: Dim dwresult as Long ' this is actually done above in my code. '------ NAV 1 ----------- Dim NAV1Send As Integer NAV1Send = [au3] If FSUIPC_Write(&H350, 2, VarPtr(NAV1Send), dwresult) Then If FSUIPC_Process(dwresult) Then End If End If And Wha La, I can see the Nav 1 frequency change to the 112.10 that I desired. My only question is: Does anyone know if a person can send indicated or true airspeed or ground speed through FSUIPC? Currently I had to set a speed and then determine the next latitude and longitude position based on that speed and desired heading. Long story as to why....

Update: Thanks to Gypsy Baron's information, I was able to make a gauge that displays offsets like 66C0, etc. Even though it added more lua's and xml's, it's cleaner than using ipc.display and/or using FSUIPC's logging of the offsets. Although it did work and I used it for many years, the gauge is nicer and can be placed as desired. So again, thanks.

Hello. Actually, we are discussing the same program (following your URL - please see attached pic). Yes, It's a good one. Many other programs do not have a "FSUIPC" to make life easier - wouldn't know what to do with out it.

True, but once I re-ordered USB game controllers, FSUIPC ran fine with the FSUIPC.ini I had transferred. I found the program a few years ago, free - somewhere. It's called JoyIDsInstall.exe. It's good for other programs I have that use the game controllers.

Hello Gypsy Baron. Sorry I didn't get back sooner. I don't know if you had to re-install FS but it's a hassle. I have many USB devices but of course, they don't install in the same order of the previous computer. I do have a software that allows re-assignment but even though I copied the fs9.cfg to the new computer, I still had to delete all the assignments of all the buttons and axes, re-install purchased products, etc. - ugh. Thank you for your time and information. I will see about applying that information for my usage. I used the 66C0, etc very simplistically, as I try to do everything else. I use one rotary switch to cycle the 66CX's values for selection of panel windows, gauges, buttons, ATC reply and then use another rotary switch to activate as needed using the lua's.

Well XML gauges are okay, have to use RPN logic, awkward for me to keep straight in my head. It is computer memory-efficient though. So, yes, I suppose I'll have to go back to lua's. I tried to avoid those - if possible but "one must do what one must do. Thanks for your reply.

Hello. has anyone ever developed an XML gauge that can read/write to FSUIPC offsets? I particularly use (66C0, etc but only 4 can be seen when logging) would prefer to make a gauge, if it's possible.

Yes, yes, yes, I mentioned it twice and Pete Dowson mentioned it once about using lua's, I have made and use many of them... I was just wondering if someone had found a way to set conditions within FSUIPC.ini without an actual push-button or keyboard input. Further mention of lua is not required. It's along story but VRiSight's FCU is a piece of crap compared to its mPanel and CDU-I and am looking for an alternative than adding more xml gauges and lua libraries - if it was possible. Again, it's no biggie... I guess I lied, it must be a biggie or I wouldn't have kept trying or searching until I got what I could use. From A2A Simulation forum, someone very smart instructed to list the Lvar's in a .mcro file - I didn't know this could be done. And then buttons, and in my case (due to VRInsight's FCU - ugh), keys can be assigned to the .mcro file. This allows me to now use the FCU with CaptainSim's 757 without addition lua's and is easier and faster (for me) to use. I had already written lua's for the pushbuttons but I needed keys because after much effort, I couldn't get the COM port diverter to work for the extra buttons like I did with the mPanel and CDU-I. I was going to go into the individual xml's but no longer required either. :) In the Advanced User's manual, on page 42, it explains it but with so much to learn of FSUIPC, not to mention other things, this eluded me. But boy, is it handy.

I realize programming can be done with a gauge or lua, I mentioned that above and have done that. But I would like to reduce extra mcro's, lua's and xml's - if possible. As the years and aircraft have built up, those files are becoming quite extensive in number. I recently purchased VRInsight's Airbus FCU, and with many attempts, I cannot make it work like I can with mPanel and CDU-I. As you are aware, with FSUIPC's ability to divert com ports, extra buttons can be obtained. However, and like I said with several attempts and scenarios, the FCU is unable to function (or see the diverted com port) like mPanel and CDU-I. It supposedly can work with FS Controls (6xxxx), but I was not able to get it to work either. So this was to see if someone had a clever method - other than xml's and lua's - no biggie if not possible.

This is a strange request so I didn't know how to set up the Topic Title, but in any case, here is my request: Does anyone know a clever way, within FSUIPC.ini to activate an FS Control (6xxxx) or FSUIPC offset (xXXX) without the activation a push-button or key to initiate the variable? In other words, I am looking for a way that under a certain condition, a variable can be activated automatically. Starting on page 24 in the manual, there are numerous techniques but all require a push-button or keyboard input. I suppose one could make an *.xml gauge or a *.lua library but I would like to do it, if it's possible, within FSUIPC.ini. Thanks.

Hello MartinP. It seems you have your FCU running with the virtual serial ports. I have it running partially but I think that FSUIPC is very fickle because, it seems to me, if one part works, the others should as well. Let me demonstrate, here is my setup: VSPE pairs: com13-com14 com15-com16 FSUIPC4.ini: [VRInsight] 1=COM6,COM13 2=COM4,COM15 (I had 1 and 2 the other way but then nothing worked - confused me). devmgmt.msc: USB serial port COM4 (CDU) USB Serial Port COM6 (MCP2A) SERIALFP2.ini: [port] COM4=CDU COM16=CDU COM6=MCP2A COM14=MCP2A (swapping these around had no observable impact - realized after deleting the .ini file, it just loads what it finds when it loads). Here is is my FSUIPC4.log (in part): FSUIPC4 Key is provided WIDEFS7 not user registered, or expired 46 System time = 09/04/2016 15:54:56 46 FLT path = "H:\Documents and Settings\Administrator\My Documents\Flight Simulator X Files\" 46 Trying to connect to SimConnect Acc/SP2 Oct07 ... 62 FS path = "H:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\" 6406 LogOptions=00000000 00000001 6406 SIM1 Frictions access gained 6406 Wind smoothing fix is fully installed 6406 G3D.DLL fix attempt installed ok 6406 SimConnect_Open succeeded: waiting to check version okay 6406 Trying to use SimConnect Acc/SP2 Oct07 6453 VRI port 2 "COM4" opened 6453 VRI driver port 2 "COM15" also opened 6468 VRI port 1 "COM6" opened 6468 VRI driver port 1 "COM13" also opened 17546 Running in "Microsoft Flight Simulator X", Version: 10.0.61472.0 (SimConnect: 10.0.61259.0) 17546 Initialising SimConnect data requests now 17546 FSUIPC Menu entry added 17609 H:\Documents and Settings\Administrator\My Documents\Flight Simulator X Files\A320UA-Default-running.FLT 17609 H:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\jf_A320_IAE\jf_A320.AIR 18703 System time = 09/04/2016 15:55:15, Simulator time = 12:39:36 (19:39Z) 25031 Aircraft="jf_A320-232_IAE V2527-A5_UA" 42890 Starting everything now ... 44062 Advanced Weather Interface Enabled 60328 VRI CDU ("CDU") detected on port COM4 295046 Sim stopped: average frame rate for last 256 secs = 23.5 fps 302250 System time = 09/04/2016 15:59:59, Simulator time = 12:43:51 (19:43Z) 302250 *** FSUIPC log file being closed Average frame rate for running time of 262 secs = 23.6 fps G3D fix: Passes 11258, Null pointers 0, Bad pointers 0, Separate instances 0 Memory managed: 728 Allocs, 728 Freed ********* FSUIPC Log file closed *********** Notice that line 60328 is: 60328 VRI CDU ("CDU") detected on port COM4 but the log never shows MCP2A (FCU) is detected and yet, I can use the FCU on the default Airbus just fine, but the buttons aren't available like they are with the CDU. I noticed that when I start SerialFP2.exe the first time, it is ready to load COM16 for the CDU, that is fine, it works, I have access to the alternate buttons. But when I start SerialFP2 again, it wants to load the MCP2A using COM6 instead of COM14 unlike how SerialFP2 sees the CDU at the first loading. It seems to me that even though FSUIPC's serial diverter works for the CDU, it doesn't work for the MCP2A. Actually, I think it has something going on with FSUIPC because sometimes it works in some computers and sometimes it doesn't work in others even though I have used the same setup. I realize FSUIPC, by diverting COM ports is a bit unusual, but it's strange how inconsistent it is. In one computer, I had to force the MPanel to COM 3 and then it worked for the MPanel but that didn't work this time with MCP2A (FCU). Any advice? Well, it's been awhile and there has been no response for help. After spending many hours trying to make it work for the FCU, I've come to the conclusion that neither using SerialFP2.exe nor VRiSim.exe will allow or recognize either the virtual serial port pairs or FSUIPC's port diverting. I got it running for the CDU-I and mPanel but not for the Airbus FCU. In addition, I saw that the keymapper for the FCU allows direct mapping to FSUIPC's offsets so perhaps the diverting isn't required, although I like having access to the extra buttons I get with the CDU-I and mPanel because with many .xml gauges, I need a button to activate a key to control the gauge. I also tried through the years but I have not found that xml allows inputs from a game port adapter - unless somehow someone knows how to do that. Ugh, another correction: FCU's keymapping only allows mapping to FS's controls (6XXXX), and not FSUIPC's hex offsets (xXXXX), thus, making it more frustrating/awkward to use as hoped.

Hello. This may help if you are trying to send serial port data through TCP/IP. Many years ago I was doing the same thing and I found a free software called HW Virtual Port. I used v1.25 and my setup was as follows: PC1: using Microsoft Flight Simulator with a GPS output: IP=10.0.0.2, VSP: Client, IP=10.0.0.4, Ports=23 [√]=HW VSP works as the TCP server. PC2: using Anywheremap XP as the GPS input: IP=10.0.0.4, VSP: Server, IP=10.0.0.2, Ports=23 [ ]=HW VSP works as the TCP server. Of course, I must tell you, that was using Windows XP. I have no idea what Windows Vista, and onward will do...

This may help. I use a lot of old drivers and Windows 8 & 8.1 want these drivers signed - ugh! Back in the "good ole days," this was not required. For example, I use VSPE's virtual serial port software because it allows one GPS (whether Bluetooth or hard-wired) to service many applications (an option called a Splitter). This is handy for my Electronic Flight Bag. I use Chartflier and AnywhereMap, anyway, I digress. To get VSPE to work with Windows 8 & 8.1, MS does allow unsign drivers to work but it takes a few steps to get there. I found the info. on the Internet but basically, you get the where you can make the selection of "disabling unsigned driver protection." Anytime one chooses to install an unsigned driver, this is required - which it is recommended to install all unsigned drives you can think of at the same time because the option is not persistent. I digress again, maybe it's just me but it seems Microsoft's security is to prevent the user from their OWN computer. The other step I take is to take complete ownership of the C: drive, its folders, and subfolders. That way, I have complete access to ALL the folders, like ProgramData, AppData, etc. Installations/software seem to work more reliably this way for me...

Hello fatcharlie. Well I haven't heard from you in quite awhile so perhaps I can assume you've gone on to other things. After some thought, I realized that perhaps I was defeating the purpose of WIDEFS by going a different route by trying to use Excel. And although WIDEFS most likely would solve my TCAS network, I'm under the impression that FSUIPC and WIDEFS for FS2004 (FS9) is to be no longer supported. If that being the case, and I understand the logic, then I don't see the need to purchase WIDEFS for the sole purpose of displaying TCAS. I did come across a couple of ways (free - of course) to show TCAS directly through using a VSI gauge with TCAS and MEDIT's airbus' ND showing traffic. XP Reality's EFISv4 is superb but it has a nominal charge. As far as networking other aircraft info. for free, I've come across, already mentioned: Excel, FSManager 2.85 and Wideview 2000. And there is also: AIBridge using FSINN (if memory serves me correctly) and a strange program called: navyg. So I too will go forward. Good flying...

Wow, druid! What is the purpose of "syncing" the current heading to the CDI (this is sort of taken care of by the autopilot's NAV or LOC button under certain conditions) !? This is my understanding of VOR receiver operation: Only proper interpretation of the CDI/OBS and heading will provide meaningful information. It's perhaps the best thing that the VOR transmitters are being phased out for the more user-friendly GPS but until then... A Horizontal Situation Indicator (HSI) is a combination of a VOR receiver and heading indicator (as long as it matches the magnetic compass' heading) and is a great way to give a "bird eye's" view. One must keep in mind that the VOR receiver, with a valid signal, only "knows" what radial it's on - that is all it can "know" - period! Again, only proper interpretation of the OBS, CDI and heading can provide valuable information. For example, the only time that the heading could match the CDI centered would be 1) The aircraft would be located on the exact radial that the OBS is set. 2) And the aircraft is actually heading in the same direction set by the OBS and there is no wind. With a "FROM" flag showing, this would then indicate that the aircraft is flying outbound from the VOR transmitter. If the CDI was centered and the aircraft's heading was 180 Deg. opposite of the OBS setting, then the aircraft would be located opposite of the radial selected, provided there was no wind. With a "TO" flag showing, then the aircraft would be inbound to the VOR transmitter. In particular, if you were instructed by ATC to track inbound on a particular radial, you would not want the heading and CDI (OBS) to be in "sync." If wind is present (depending on its magnitude and direction), and the CDI was centered, then the heading could not match the OBS and should not match if tracking the assigned radial. In addition, if you were instructed by ATC to intercept and either track inbound or outbound on a particular radial, again, heading should not match the OBS (...at least until on the outbound radial and no wind). Given the above understanding, how could "syncing" CDI and heading be useful?

Hello fatcharlie. Maybe we can help each other. I have used 2 programs to network FS9, 1) Wideview 2000 (yes, it works for FS9) and 2) FSManager v2.85. Both are free versions I got from the Internet. Another free program is: TCASv7-3. It is a gauge that shows AI traffic. Wideview2000 works well but requires IPX instead of TCP/IP, which I found an IPX wrapper that works for 64-bit computers and 32-bit computers. I only use Wideview2000 for the right-front and left-front views on another computer. I use FSManager to a tablet for my EFB as it updates only about every second. I'm not so interested in seeing AI traffic on the network computers, although that would be nice, because I primarly fly IFR but would like to see the traffic on the EFB using the TCASv7-3 program/gauge. In my interest in PID control testing for my personal aircraft, a long story, I have been able to read and write using FSUIPC, GPSout and Excel's 2003 VBA between two computers. Below are 3 "paragraphs" that read FSUIPC data. the first two work great but I cannot get the 3rd "paragraph to work. Perhaps this can give you insight on how to read AI traffic and if you're able, please tell my why and how I can correct the 3rd "paragraph." : '-- 1st paragraph -- Dim Altitude64 As Currency Dim Altitude As Double If FSUIPC_Read(&H570, 8, VarPtr(Altitude64), dwResult) Then If FSUIPC_Process(dwResult) Then Altitude = Altitude64 * 10000# Altitude = Altitude * 3.28084 / (65536# * 65536#) Range("a5") = Format(Altitude, "000000") ' this works--------- End If End If '---2nd paragraph --- Dim workArray(256) As Byte Dim idx As Integer If FSUIPC_Read(&H3D00, 256, VarPtr(workArray(1)), dwResult) Then If FSUIPC_Process(dwResult) Then idx = 1 While workArray(idx) <> 0 AircraftType = AircraftType & Chr(workArray(idx)) idx = idx + 1 Wend End If this works, it accesses the aircraft.cfg file -------------- Range("A21").Value = AircraftType '----3rd paragraph ---- Dim workArrayx(1920) As Byte Dim idxx As Integer If FSUIPC_Read(&HD040, 1920, VarPtr(workArrayx(1)), dwResult) Then If FSUIPC_Process(dwResult) Then idxx = 1 While workArrayx(idxx) <> 0 AircraftTraffic = AircraftTraffic & Chr(workArrayx(idxx)) idxx = idxx + 1 Wend End If ' this does NOT work ----------- Range("C21").Value = AircraftTraffic '-------------------------------------------------------------------------- End If '-- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ --

Hello, to be honest, unfortunately the answer to the question providing no useful information for me. I believe the question was asked, in part "...how to get values like AP Altimeter or HDG from a Lvar to the 7 segment displayor other values..." First, let me begin in that I am a novice but I may be able to provide information that might be helpful. Second, any Lvars to be sent to hardware I would assume would be provided by the hardware provider. But then again, when I asked Captainsim for Lvars for CS757 (FS9) so I wouldn't have to use the mouse and use my homemade MCP (since offsets and FS's parameters don't work), they told me there was no way to access them. They either lied, are lazy or incompetent. They are indeed accessible. I got access to them in 3 ways. 1) I looked at the cs.b757.cab and looked at the xml's. 2) There is a free program on the Internet called "Blackbox3" that helps and there is FS Panel Studio. The latter was the most helpful yet costs but it makes it very easy. I have not delved into outputs yet but there are 2 examples provided by the installation of FSUIPC called "gfdDisplay.lua" that I am assuming, not sure, is for GoFlight. Code in part, the Lvar is: ...testdisplay(gfd.SetDisplay, id, "888888").... In GFpower.lua, the Lvar is...gfd.SetBright(m, u, 15- b ).... Hopefully your hardware provider would supply Lvars such as this.

I realize I could be dubugging but no changes were made and then it stopped working correctly. I'll either delve into it or not and just move on. This will be the last time I deal with you. You get angry when you shouldn't. I know you don't want to spoon feed as you would probably being doing that for everyone but once in awhile you could and should show someone the actual code to get them jumpstarted. I obviously have read the material but it wasn't clear (at least to me) and I have tried many of the lua examples, and they don't all work!!! ie, mrudder.lua. In addition, you've either written the lua and FSUIPC so what may seem obvious to you, that's why you charge (FSUIPC, and should), but it may not be obvious to the rest of us, thus it's why we ask for help!!! Think about it. Why have the forum at all if there were'nt problems to be solved? And since you're not going to support FSUIPC for FS9, then I too have no further use for you. Have a nice day.

ugh, and lol. I tried to tell you several times, the only code in WriteOffset.lua is: ipc.WriteSW(0x66C0, 3), that's it. When I hit the [w] key (assigned to WriteOffset.lua), I wanted to send "3" to offset 66C0. Anyway, It doesn't matter now until I figure how to do it correctly. Yeah, I know FS9 is dead for most but I use it due to monetary, thus processor limitations. I have FSX but it's not efficient for my computer. Also, I've spent some money and a lot of time with hardware, aircraft and gauges for FS9. It has become ad hoc through the years as I've added "stuff." Just changing computers has been so time-consuming. If yo're not going to support FSUIPC 3, then just let me know and I'll go forward. My new issue is, all of a sudden, when the 172G1000.lua was working, now it'll only display when 66C0 is "0" or "4" and not the in-between values - even after re-booting - ugh! I'll be delving into the lua. So far what I've seen, i see no references to ipc with lua (other than docs supplied with FSUIPC). Where would I go for that? Thanks for your time and information. It is appreciated.

Well,I will try to be clearer. I am using FSUIPC 3.999z8. I had downloaded 3.999z9 but it shows it to be 3.999z8. In the WriteOffset.lua, I have the code: ipcwriteSW(0x66C0, 3). In other words, in the code saved as WriteOffset.lua, I have one line of code: ipcwriteSW(0x66C0,3). My goal is to send 3 to offset 66C0 as a test. SInce ipc.readSW(0x66C0) works in retrieving the wanted information, I think it's logical to assume to use ipc.writeSW(0x66C0, 3) to send 3 to 66C0. In the code saved as 172G1000.lua, that works, in part I have: -- sleep for 1.5 sec. ipc.sleep(1500) --- Delay for a number of seconds. -- @param delay Number of seconds function delay_s(delay) delay = delay or 5 local time_to = os.time() + delay while os.time() < time_to do end I mentioned it was convoluted but it works well to display for a set time, I am happy with this but I also did come to like the endless loop as I prefer to keep the window open as I cycle through offset 66C0, and trying to add 66C1. The reason I want to add 66C1 is now I want to be able to cycle the PA, Attitude bar and Kohlsman in the aux panel. It works just fine in FSUIPC.ini. The goal is now to display in Lua. As far as the lockup, it occurs anytime I assign a key to luakill on any of the lua scripts. But again, it is now a non-issue because I can either use the time delay, which works and I like the endless loop while FS is running. Now back to the ... I appreciate the explanation. I did miss the lua.org reference so I will delve into that (http://lua-users.org/wiki/StringsTutorial).