Jump to content
The simFlight Network Forums

Strange ipc.ask() Behavior


Recommended Posts

Hi Pete,

I have a Lua script that uses the ipc.ask() function inside a while true do loop.  When the script is activated with a key stroke, the contents of the ipc.ask() is displayed on the green bar window as expected, but only about half the time. The other times nothing at all appears until an input is provided at which time both the contents of the ipc.ask() and the input that was provided is displayed, all before a carriage return is entered. It is as if the input to the ipc.ask() is required before the script is activated.  I can't seem to track down the cause of this behavior. I would appreciate hearing any ideas you may have. The while true loop is below.

Thanks,

Al

FSX, FSUIPC 4.96, Win10

(Edit: Just realized I put this in the wrong subforum but don't know how to move or delete it. Sorry. Moderator please move to Support subforum.)

while true do
move_distance_nm_str = ipc.ask(" Enter Distance to Move A/C in NMs (0-500), or just the ENTER key for 0 NM \n\n * to Exit " ,1)
 if move_distance_nm_str == "*" then
   ipc.exit()                                        --terminate the Lua script
 end
 move_distance_nm = tonumber(move_distance_nm_str)                      --convert string to a number
 if move_distance_nm == nil then
   move_distance_nm = 0
   break
 elseif move_distance_nm >= 0 and move_distance_nm <= 500 then      -- if values good, exit while loop
   break
 else
   ipc.writeSTR(0x3380, "Invalid Entry");             
   ipc.writeSW(0x32FA, 2);                                                                          --display on green bar for 2 sec
   ipc.sleep(2000)
 end
end

Link to comment
Share on other sites

2 hours ago, ark1320 said:

I have a Lua script that uses the ipc.ask() function inside a while true do loop.  When the script is activated with a key stroke, the contents of the ipc.ask() is displayed on the green bar window as expected, but only about half the time. The other times nothing at all appears until an input is provided at which time both the contents of the ipc.ask() and the input that was provided is displayed, all before a carriage return is entered. It is as if the input to the ipc.ask() is required before the script is activated.  I can't seem to track down the cause of this behavior. I would appreciate hearing any ideas you may have. The while true loop is below.

I'll try your script here later today, but meanwhile can you try it with the current version, 4.962, please?

Pete

 

 

Link to comment
Share on other sites

Okay. I can't reproduce your problem at all. I think it must be some interaction between the differrent parts of the display logic inside FS. All FSUIPC does when you execute the "Ask" is call the display function to do so. the capture of key presses is entirely separate, and later, and then each one results in a new disply call to show it again but wtith the keypress added. The characters aren't inserted into an existing disply, the system doesn't allow that. The whole thing is displayed each time. So I don't know how it's missing the first time there, but not here.

I'm using FSX-SE, mind, not FSX. That may make a difference. Maybe some code works better in FSX-SE.

Otherwise perhaps I need to set my situation up to be more exactly like yours. 

Pete

 

Link to comment
Share on other sites

Pete,

Following up on your suggestion about an interaction/conflict with display logic, I wonder if the handy little script below ( not mine ), which displays touchdown vertical speed, might be contributing to my ipc.ask() problem?  I've also now noticed I am having the same type of ipc.ask() display problem with another script different than the one above, which further supports your display logic conflict theory. Why entering a value suddenly allows the ipc.ask() message, and the entered value, to then both display is baffling.

Thx,

Al

ipc.setowndisplay("FPM", 0, 60, 6,  1)
 function logvs(off, val)
   if val ~= 0 then
    -- if on ground flag just set, get VS, convert it and log it
    vs = ipc.readSD(0x030C) --original was 030C then 31A0
    vs = vs * 60 * 3.28084 / 256
    ipc.log("Vertical speed at touchdown = " .. math.floor( (vs * 10^2) + 0.5) / (10^2), 5)
ipc.display(math.floor( (vs * 10^2) + 0.5) / (10^2), 45)  -- 30 means display for 30 sec
   end
end
 -- set to call above routine whenever "on ground" flag changes
event.offset(0x0366, "UW", "logvs")

Link to comment
Share on other sites

31 minutes ago, ark1320 said:

Following up on your suggestion about an interaction/conflict with display logic, I wonder if the handy little script below ( not mine ), which displays touchdown vertical speed, might be contributing to my ipc.ask() problem?

No, I don't think so. I tried running your "own display" script first -- though I had to make the display rather larger to find it! 1% of my display is very small indeed on this PC as FS is just one of the Windows on screen at any time.

Both displays worked fine, every time.

Anyway, please update your FSUIPC to the currently supported version, 4.962. You never know, perhaps it is different in this area, and it certainly fixes things elsewhere.

Pete

 

 

Link to comment
Share on other sites

Hi Pete,

Ran an experiment by going back to FSUIPC 4.959 -- above problem went away. Then went back to FSUIPC4.962 and the problem returned. Did this experiment twice with the same results.

Some other info that may be helpful:

- there is no problem with scripts that use the ipc.writeSTR(0x3380, "string");  ipc.writeSW(0x32FA, 2); display -- seems to work every time.

- when running a script that uses ipc.ask(), nothing is initially displayed, but if I then hit a key that calls a script using the ipc.writeSTR(0x3380, "string") display, this triggers the ipc.ask() argument to display along with the keystroke. Sometimes just any two keystrokes seems to trigger the ipc.ask() to display its argument and the keys there were inputted.

- once the script with the ipc.ask() gets working, it continues to work ok until the next start of FSX, so it seems to be some type of initialization problem perhaps.

- multiple scripts with the ipc.ask() function show the same problem.

Thx for any ideas,

Al

Link to comment
Share on other sites

2 hours ago, ark1320 said:

- there is no problem with scripts that use the ipc.writeSTR(0x3380, "string");  ipc.writeSW(0x32FA, 2); display -- seems to work every time.

Unless your string has multiple lines (i.e. includes newline or return characters in it, then that's not using the same facility. Have you tried a multiline string? If not, please do so. ("\r" or "\n" will start a new line).

2 hours ago, ark1320 said:

- when running a script that uses ipc.ask(), nothing is initially displayed, but if I then hit a key that calls a script using the ipc.writeSTR(0x3380, "string") display, this triggers the ipc.ask() argument to display along with the keystroke. Sometimes just any two keystrokes seems to trigger the ipc.ask() to display its argument and the keys there were inputted.

It must be some timing oddity in FS. There's no difference between 4.959 and 4.962 in this area -- excepting likely the timing of things, which sounds rather critical in this case. The calls are just that, calls to functions in the Sim. FSUIPC doesn't have any control over what it then does.

2 hours ago, ark1320 said:

- once the script with the ipc.ask() gets working, it continues to work ok until the next start of FSX, so it seems to be some type of initialization problem perhaps.

Strange. Obviously something gets speeded up (or slowed down). I think maybe the first time, the window is actually being created. The later times it is just being "unhidden".

2 hours ago, ark1320 said:

- multiple scripts with the ipc.ask() function show the same problem.

Do you mean they all have the weird delay/wait on the first time, separately, even in the same session? If so, since they will all be using the same window, that makes my immediately previous surmise incorrect.

I really can't do much without being able to reproduce it. I suppose I could try calling the same sim function twice each time on the assumption that the first time didn't work, but that seems rather extreme. If I do something like that, do you want to try it?

Pete

 

Link to comment
Share on other sites

1 hour ago, Pete Dowson said:

Unless your string has multiple lines (i.e. includes newline or return characters in it, then that's not using the same facility. Have you tried a multiline string? If not, please do so. ("\r" or "\n" will start a new line).

With both FSUIPC 4.959 and 4.962: Displaying multiple lines with ipc.writeSTR(0x3380, "string") with rare exception, required two or three calls to the script (key inputs). If, however, I first called a script with a single display line via ipc.writeSTR(0x3380, "string"), then the multiple line ipc.writeSTR(0x3380, "string") display worked with the first call (key input).

 

My comment about seeing the problem with different scripts, restarting FSX each time, was just to say the problem did not seem related to a particular script.

I will be glad to try any experiment that may help track down the problem. I don't have the No Repeats! turned on under the Keys Presses tab, but holding down a key still didn't help.

Thx,

Al

.

 

Link to comment
Share on other sites

2 hours ago, ark1320 said:

With both FSUIPC 4.959 and 4.962: Displaying multiple lines with ipc.writeSTR(0x3380, "string") with rare exception, required two or three calls to the script (key inputs).

Hmm. There's something really really strange with your system. That multi-line mechanism is used by Radar Contact (among others) for its menus, and has worked well for many many years (back several versions of FS -- FS2000 was it, or 2002?), with exactly the same code.

Also, I see now that you find 4.959 and 4.962 act the same, which of course they should because they use the exact same code.

2 hours ago, ark1320 said:

My comment about seeing the problem with different scripts, restarting FSX each time, was just to say the problem did not seem related to a particular script.

Ah, so you still mean it only happens once per session?

2 hours ago, ark1320 said:

don't have the No Repeats! turned on under the Keys Presses tab, but holding down a key still didn't help.

I'm not sure of the relevance of that remark. Sorry.

I'll think on it. I can't do anything till tomorrow in any case. Yours is the other report of anything like this, even over all the years that this display facility (not just the Ask function, that is only one user of it) has existed. I can't help thinking that there's something odd about your system somewhere.

Pete

 

Link to comment
Share on other sites

1 hour ago, Pete Dowson said:

Ah, so you still mean it only happens once per session?

 

Yes, once an ipc.ask() script starts working, all scripts using it work until FSX is restarted. Once in a while, the scripts do work right away after an FSX restart, but this does not happen very often.

1 hour ago, Pete Dowson said:

I'm not sure of the relevance of that remark. Sorry

My point, a poor one perhaps, was that holding the script activation key down, and thus making repeated calls to the script, did not help.

I have used scripts with ipc.ask() quite a bit in the past without any problem, and I can't put my finger on what has changed in the last week or so.  Very odd.

Thanks very much for the time you have spent on this. Maybe the problem will go away with the next forced Win10 update -- one can always hope!

Al

Link to comment
Share on other sites

9 hours ago, ark1320 said:

Once in a while, the scripts do work right away after an FSX restart, but this does not happen very often.

This shows it is timing related.

I've checked the code -- step for step identical between 4.959 and 4.962. Not only that, but whereas the Lua display facilities use hacked calls direct into FS/P3D code, both the Ask and all 3380/32FA requested displays, single line or multiline, use regular SimConnect facilities -- no hacks, no strange code at all. The SimConnect function is "SimConnect_Text".

So the problem looks like it may be a bit of a Win10 incompatibility with FSX's SimConnect coding.  I'm afraid you won't get that fixed in FSX. I suppose there's a small chance it would get fixed in FSX-SE if DoveTail games can be made interested.

I've tried it on my one and only Win10 PC (a Surface Pro, mainly only used to keep up with emails and so on, on the move), and I don't get your results on that.

Anyway, what I've done, for the present, and mainly to see if it works, is that on the very first call to display anything with SimConnect_Text, I repeat the exact same call 100 mSecs after the first. I've no idea whether it will help, but if you'd like to try it and let me know, download FSUIPC4962b_TEST.zip and let me know.

9 hours ago, ark1320 said:

Maybe the problem will go away with the next forced Win10 update -- one can always hope!

My new PC came with Win10 pre-installed. I had so many problems. Regular utilities I depend on didn't work properly -- crashing now and then, and quite innocuous drivers I need for some of my cockpit hardware not working at all. After struggling for a week with the awful thing I cleared the disk and started again with Windows 7 Ultimate. I am currently universally on Win7 (except on my Surface Pro as mentioned above) and will be staying with Win7 for good now! Best O/S Microsoft ever made (XP was their second best -- I only recently updated three of the mini-PCs inside my cockpit from XP to Win7 because ProSim's display modules were updated and needed .Net Framework 4.6 or later..

Pete

 

Link to comment
Share on other sites

6 hours ago, Pete Dowson said:

Anyway, what I've done, for the present, and mainly to see if it works, is that on the very first call to display anything with SimConnect_Text, I repeat the exact same call 100 mSecs after the first. I've no idea whether it will help, but if you'd like to try it and let me know, download FSUIPC4962b_TEST.zip and let me know.

Unfortunately, the test FSUIPC.dll did not help. I see that I had a Win10 update on 8 Feb. I'm not sure if this problem existed before that time or not, but I will do a Restore to roll back that update to see if it makes a difference and will let you know.

I sincerely appreciate your efforts on my behalf.

Al

Link to comment
Share on other sites

1 hour ago, ark1320 said:

Unfortunately, the test FSUIPC.dll did not help

Well, maybe 100 mSecs is not enough delay. But the trouble with a large delay is that it could result in missing keypress responses when the user does actually see the first.

I've increased it to 1 whole second, mainly just out of curiosity. Download FSUIPC4962b_TEST2.zip

Pete

 

Link to comment
Share on other sites

I get the same results with the Test2 dll as I did with Test1 dll.

I have noticed another strange thing. If I start FSX and load a flight, and then hit the ESC key and return to the Free Flight page of FSX, and then click on Fly Now to reload the same flight, when the flight reloads I immediately get a 3380/32FA type green bar one line display on the screen that is related to a Lua script that I have been using for years. And the display remains on the screen instead of closing after a few seconds as it normally would. This happens even though I did not run any Lua scripts since FSX was started, and this also happens when I start with different initial flights as well , but not with all initial flights. And if after returning to the Free Flight page as described above I reload a different flight then what was initially loaded, then the strange green bar display may or may not appear. And if it does display it is not always the same.

I thought maybe some type of corrupt display information was getting saved  with a stored flight, but didn't see anything in the .FLT file. This probably makes sense since this strange display is not seen on the initial flight load, but rather on the reload of the flight.

I was also wondering if FSUIPC saves information on scripts that have been run in a cache, or maintains a keystroke buffer, and perhaps something in the cache or buffer has become corrupt? I can't understand what is triggering the strange green bar display when no Lua scripts have been run since a restart of FSX. 

Despite two attempts, I wasn't able to roll back the latest Win10 update. For some reason the Restore operation couldn't find a file it wanted to restore. .

Al

Link to comment
Share on other sites

3 hours ago, ark1320 said:

I thought maybe some type of corrupt display information was getting saved  with a stored flight, but didn't see anything in the .FLT file. This probably makes sense since this strange display is not seen on the initial flight load, but rather on the reload of the flight.

If the display is from a Lua plug-in then you most certainly have a Lua plug-in being executed. There's no way any such thing will be produced by a flight file and anything else like that. The displays are howver produced by lots of other programs, of course, as well as through normal things like Shift+Z to display coordinates, frame rates and so on. It is the same display mechanism.

3 hours ago, ark1320 said:

I was also wondering if FSUIPC saves information on scripts that have been run in a cache, or maintains a keystroke buffer,

No, no way. Enable Button/Key logging and Lua Debu/Trace options in the Logging tab in FSUIPC.It will show you what Lua plug-in is being run, if any. Maybe through an "Auto" section you've forgettoen about.

Pete

 

 

 

Link to comment
Share on other sites

I created a temporary folder in the FSX modules folder and moved all my Lua scripts into this temporary folder to hide them from FSUIPC. I also renamed my FSX.cfg file so FSX would have to build a new one. I then rebooted the computer an restarted FSX.

After all that, I still got the same strange green bar, with a message which is definitely from one of my own scripts, when I loaded and then reloaded a file as described above. Amazing!

The only other text displayed was Shift+Z info, the Cockpit View Zoom setting, and the Parking Brakes set message.

Al

 

Link to comment
Share on other sites

7 hours ago, ark1320 said:

I

7 hours ago, ark1320 said:

After all that, I still got the same strange green bar, with a message which is definitely from one of my own scripts, when I loaded and then reloaded a file as described above. Amazing!

 

Where's the logging I suggested? It's no use saying these things without presenting information.

There's absolutely no storage or memory of Lua actions or  display scripts. There's no where for them to be stored. You've got something else going on there and it's only unexplained because you won't do the diagnostic actions I suggest.

Pete

 

Link to comment
Share on other sites

41 minutes ago, ark1320 said:

Attached is the log file. I loaded a flight, then returned to the Free Flight page, then reloaded the flight and upon reload got the strange green bar as described above.

As shown in the Log, you are still runningyour Ask application which is most certainly still in the Modules folder:

   370830 KEYDOWN: VK=65, Waiting=0, Repeat=N, Shifts=0
   370845 .. This key is programmed in FSUIPC4 'Keys' options
   370908 KEYUP: VK=65, Waiting=0
   370908 LUA.0: beginning "E:\Steam\steamapps\common\FSX\Modules\Ask.lua"
   370955 LUA Asks: " Enter Distance to Move A/C in NMs (0-500), or just the ENTER key for 0 NM 

 * to Exit "
   374683 LUA Reply: "a"
   374683 KEYUP: VK=13, Waiting=0

   

Pete

 

Link to comment
Share on other sites

I am really confused:

When I open that log file I don't see those lines you show above, and can't find them with notepad ++ search, but obviously you see them.

I did not push any keys, just used the mouse to load the flight, exit back to the Free Flight page, and then reload the flight.

I have FSX-SE installed but have only been running the boxed FSX, not Steam.

I don't have an E drive installed

Yet what you show above, the ask message,  is from one of my Lua scripts, but the message I get on the green bar is not from that script. The message I see is NAV1 Freq, 5 Digits.  And I don't have a Lua script called ask.Lua. I just did a complete search of my machine for a file with that name -- found nothing.

I just reran the flight load and reload experiment, got the green bar again, and here is the log file (looks like what the first log file looked like to me):

********* FSUIPC4, Version 4.962 (8th February 2017) by Pete Dowson *********
Windows 10 Pro 64 Bit reported as Build 14393, Release ID: 1607 (OS 10.0)
fsx.exe version = 10.0.61472.0
Reading options from "C:\FSX\Modules\FSUIPC4.ini"
Running inside FSX on Windows 10
Module base=59AF0000
User Name="Alan Klayton"
User Addr="arklayton@comcast.net"
FSUIPC4 Key is provided
WIDEFS7 not user registered, or expired
        0 System time = 14/02/2017 07:23:34
        0 FLT path = "C:\Users\Al\Documents\Flight Simulator X Files\"
        0 ------ Module Version Check ------
        0        acontain.dll: 10.0.61472.0
        0             api.dll: 10.0.61472.0
        0        controls.dll: 10.0.61472.0
        0      fs-traffic.dll: 10.0.61472.0
        0             G3D.dll: 10.0.61472.0
        0        language.dll: 10.0.61472.0
        0            sim1.dll: 10.0.61472.0
        0        visualfx.dll: 10.0.61472.0
        0         weather.dll: 10.0.61472.0
        0          window.dll: 10.0.61472.0
        0 ----------------------------------
       31 Trying to connect to SimConnect Acc/SP2 Oct07 ...
       47 FS path = "C:\FSX\"
      328 ---------------------- Joystick Device Scan -----------------------
      328 Product= Saitek Pro Flight Rudder Pedals
      328    Manufacturer= Saitek
      328    Vendor=06A3, Product=0763 (Version 1.1)
      328    Serial Number=
      328 Product= Saitek Pro Flight Yoke
      328    Manufacturer= Saitek
      328    Vendor=06A3, Product=0BAC (Version 3.4)
      328    Serial Number=
      328 Product= BU0836A Interface
      328    Manufacturer= Leo Bodnar
      328    Vendor=16C0, Product=05BA (Version 1.34)
      328    Serial Number= B56696
      328 -------------------------------------------------------------------
      703 LogOptions=40000000 00000001
      718 -------------------------------------------------------------------
      718 ------ Setting the hooks and direct calls into the simulator ------
      718 --- CONTROLS timer memory location obtained ok
      718 --- SIM1 Frictions access gained
      718 --- FS Controls Table located ok
      718 --- Installed Mouse Macro hooks ok.
      718 --- Wind smoothing fix is fully installed
      718 --- G3D.DLL fix attempt installed ok
      718 --- SimConnect intercept for texts and menus option is off
      718 --- All links checked okay
      718 -------------------------------------------------------------------
      718 SimConnect_Open succeeded: waiting to check version okay
      718 Trying to use SimConnect Acc/SP2 Oct07
      718 Opened separate AI Traffic client okay
     5562 Running in "Microsoft Flight Simulator X", Version: 10.0.61472.0 (SimConnect: 10.0.61259.0)
     5562 Initialising SimConnect data requests now
     5562 FSUIPC Menu entry added
     5578 c:\users\al\documents\flight simulator x files\Default Flight 35L KCOS L35A.FLT
     5578 C:\FSX\SimObjects\Airplanes\Learjet 35A FLYSIMWARE_17SEP16_Mod_11FEB17\Learjet35A.AIR
     6375 Monitor IPC:024C (S32) = 3436272
    15640 Monitor IPC:024C (S32) = 2753540
    25781 Monitor IPC:024C (S32) = 2600904
    30578 User Aircraft ID 1 supplied, now being used
    31109 System time = 14/02/2017 07:24:05, Simulator time = 07:23:39 (14:23Z)
    31500 Aircraft="Learjet 35A/C-21A USAF 01320 AF Academy BG GTN"
    31515 [Buttons] now profile-specific:
    31515    27=RY,20,C65602,0
    31515    30=PY,19,C65859,0
    31515    30=PY,19,C65859,0
    31515    31=CR(+Y,9)Y,7,C66277,0
    31515    31=CR(+Y,9)Y,7,C66277,0
    31515    32=CR(+Y,9)Y,6,C66276,0
    31515    32=CR(+Y,9)Y,6,C66276,0
    31515    38=PY,17,CL40:R,0
    31515    39=CP(+Y,8)Y,38,C65906,0
    31515    39=CP(+Y,8)Y,38,C65906,0
    31515    39=CP(+Y,8)Y,38,C65906,0
    31515    39=CP(+Y,8)Y,38,C65906,0
    31515    40=CP(+Y,8)Y,34,C65907,0
    31515    40=CP(+Y,8)Y,34,C65907,0
    31515    40=CP(+Y,8)Y,34,C65907,0
    31515    40=CP(+Y,8)Y,34,C65907,0
    31515    45=PY,14,CL73:R,0
    31515    47=CP(+Y,8)Y,32,C65913,0
    31515    47=CP(+Y,8)Y,32,C65913,0
    31515    47=CP(+Y,8)Y,32,C65913,0
    31515    47=CP(+Y,8)Y,32,C65913,0
    31515    402=CP(+Y,8)Y,36,K35,8
    31515    402=CP(+Y,8)Y,36,K35,8
    31515    402=CP(+Y,8)Y,36,K35,8
    31515    402=CP(+Y,8)Y,36,K35,8
    31515    432=CR(+Y,10)Y,33,C65856,0
    31515    432=CR(+Y,10)Y,33,C65856,0
    31515    436=CR(+Y,10)Y,35,C65857,0
    31515    436=CR(+Y,10)Y,35,C65857,0
    31515    440=CR(+Y,10)Y,37,C65855,0
    31515    440=CR(+Y,10)Y,37,C65855,0
    31515    444=CR(+Y,10)Y,39,C65854,0
    31515    444=CR(+Y,10)Y,39,C65854,0
    31515    446=RY,3,Cx32000BC0,x3FFF0010
    31515    448=RY,2,Cx42000BC0,xC0010010
    31515 [Buttons] now profile-specific:
    31515    27=RY,20,C65602,0
    31515    27=RY,20,C65602,0
    31515    30=PY,19,C65859,0
    31515    30=PY,19,C65859,0
    31515    31=CR(+Y,9)Y,7,C66277,0
    31515    31=CR(+Y,9)Y,7,C66277,0
    31515    32=CR(+Y,9)Y,6,C66276,0
    31515    32=CR(+Y,9)Y,6,C66276,0
    31515    38=PY,17,CL40:R,0
    31515    39=CP(+Y,8)Y,38,C65906,0
    31515    39=CP(+Y,8)Y,38,C65906,0
    31515    39=CP(+Y,8)Y,38,C65906,0
    31515    39=CP(+Y,8)Y,38,C65906,0
    31515    40=CP(+Y,8)Y,34,C65907,0
    31515    40=CP(+Y,8)Y,34,C65907,0
    31515    40=CP(+Y,8)Y,34,C65907,0
    31515    40=CP(+Y,8)Y,34,C65907,0
    31515    45=PY,14,CL73:R,0
    31515    47=CP(+Y,8)Y,32,C65913,0
    31515    47=CP(+Y,8)Y,32,C65913,0
    31515    47=CP(+Y,8)Y,32,C65913,0
    31515    47=CP(+Y,8)Y,32,C65913,0
    31515    402=CP(+Y,8)Y,36,K35,8
    31515    402=CP(+Y,8)Y,36,K35,8
    31515    402=CP(+Y,8)Y,36,K35,8
    31515    402=CP(+Y,8)Y,36,K35,8
    31515    432=CR(+Y,10)Y,33,C65856,0
    31515    432=CR(+Y,10)Y,33,C65856,0
    31515    436=CR(+Y,10)Y,35,C65857,0
    31515    436=CR(+Y,10)Y,35,C65857,0
    31515    440=CR(+Y,10)Y,37,C65855,0
    31515    440=CR(+Y,10)Y,37,C65855,0
    31515    444=CR(+Y,10)Y,39,C65854,0
    31515    444=CR(+Y,10)Y,39,C65854,0
    31515    446=RY,3,Cx32000BC0,x3FFF0010
    31515    448=RY,2,Cx42000BC0,xC0010010
    35672 Monitor IPC:024C (S32) = 2463548
    45765 Monitor IPC:024C (S32) = 2466636
    50562 Weather Mode now = Real World
    50562 C:\Users\Al\AppData\Roaming\Microsoft\FSX\Previous flight.FLT
    55703 Monitor IPC:024C (S32) = 2349496
    65734 Monitor IPC:024C (S32) = 2374840
    67281 Starting everything now ...
    68468 Advanced Weather Interface Enabled
    75890 Monitor IPC:024C (S32) = 2377932
    85765 Monitor IPC:024C (S32) = 2362056
    98375 System time = 14/02/2017 07:25:12, Simulator time = 07:23:39 (14:23Z)
    98375 *** FSUIPC log file being closed
Minimum frame rate was 30.1 fps, Maximum was 30.9 fps
Minimum available memory recorded was 32768Mb
Average frame rate for running time of 26 secs = 30.1 fps
G3D fix: Passes 12454, Null pointers 0, Bad pointers 0, Separate instances 0
Maximum AI traffic for session was 2 aircraft
Memory managed: 20 Allocs, 20 Freed
********* FSUIPC Log file closed ***********

 

Link to comment
Share on other sites

1 hour ago, ark1320 said:

I am really confused:

When I open that log file I don't see those lines you show above, and can't find them with notepad ++ search, but obviously you see them.

Oops. Sorry. My error. I clciked on your link which downloaded it to a folder on my PC, then I picked up the wrong file!! :-(  I was rather distracted, with guests here today and trying to do several things at once.

Please, unless files are really very long, just paste their contents into the message. Use the <> button to enclose them for tidiness. I've just done that with your last message, above, so you can see what it looks like. If the text is very long, it puts scroll bars on the right rather than showing it all at once.

I agree, there's no Lua plug-in being run by FSUIPC, and no display sent either. I have no idea where your FSX installation is getting that from, sorry.

Pete

 

 

Link to comment
Share on other sites

The source of the strange green bar appears to have been flightname.ipcbin files in the Flight Simulator X Files folder. I don't know what type of information these files hold, but deleting it for a given saved flight stopped the strange green bar behavior. I assume the flightname.ipcbin files will get regenerated -- don't know if the problem will then return.

As for now, I'm back to working on the original problem.

Al

Link to comment
Share on other sites

13 minutes ago, ark1320 said:

The source of the strange green bar appears to have been flightname.ipcbin files in the Flight Simulator X Files folder. I don't know what type of information these files hold, but deleting it for a given saved flight stopped the strange green bar behavior. I assume the flightname.ipcbin files will get regenerated -- don't know if the problem will then return.

Aha! The ipcbin files are optionally produced and reloaded. They store the complete state of all FSUIPC offsets, which includes the 3380 / 32FA ones.  Folks normally only use those when they are using complex cockpit accessories, like Project Magenta, and want to be able to continue a flight from where it crashed or was aborted without having to set the whole cockpit up again.

Unless this is what you need I suggest you turn off the options for this on the Miscellaneous tab in FSUIPC options.

I haven't heard of anyone using those options for many many years. I used to, but it doesn't really help with ProSim (I changed from Project Magenta a couple of years back).

Pete

 

Link to comment
Share on other sites

I turned off Pause after Crash in the Miscellaneous tab, so that should end the name.ipcbin problem.

Regarding the original problem, below is a part of a log file that shows the NpCmoveAircraft.lua file was called by the Ctrl+M keystroke and indicates the argument of the ipc.ask() function was displayed -- but in actuality nothing appeared on the screen until after the 3 keystroke input 256 was provided, but did display before a carriage return.  I need to figure out why this happens sometimes, but ipc.ask() works as expected other times.

Al

    30000    444=CR(+Y,10)Y,39,C65854,0
    30000    446=RY,3,Cx32000BC0,x3FFF0010
    30000    448=RY,2,Cx42000BC0,xC0010010
    31578 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=2
    31578 .. Key not programmed -- passed on to FS
    31969 KEYDOWN: VK=77, Waiting=0, Repeat=N, Shifts=2
    31969 .. This key is programmed in FSUIPC4 'Keys' options
    31969 LUA.0: beginning "C:\FSX\Modules\NpCmoveAircraft.lua"
    31969 LUA.0: C:\FSX\Modules\NpCmoveAircraft.lua:10
    31985 LUA.0: Global: ipcPARAM = 0
    31985 LUA.0: C:\FSX\Modules\NpCmoveAircraft.lua:13
    31985 LUA.0: Global: mag_variation_degs = 8.096923828125
    31985 LUA Asks: " Enter Distance to Move A/C in NMs (0-500), or just the ENTER key for 0 NM 

 * to Exit 

 (Longer distances tend to be less accurate due to changing magnetic declination)"
    35719 Monitor IPC:024C (S32) = 2454700
    39578 Starting everything now ...
    40891 Advanced Weather Interface Enabled
    55797 Monitor IPC:024C (S32) = 2448472
    56141 LUA Reply: "256"
    56141 LUA.0: C:\FSX\Modules\NpCmoveAircraft.lua:14
    56141 LUA.0: Global: move_distance_nm_str = 256
    56141 LUA.0: C:\FSX\Modules\NpCmoveAircraft.lua:17
    56141 LUA.0: C:\FSX\Modules\NpCmoveAircraft.lua:18
    56141 LUA.0: Global: move_distance_nm = 256
    56141 LUA.0: C:\FSX\Modules\NpCmoveAircraft.lua:21
    56141 LUA.0: C:\FSX\Modules\NpCmoveAircraft.lua:22
    56141 LUA.0: C:\FSX\Modules\NpCmoveAircraft.lua:31

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.