MCRO L:Var=SET when "0" broken

[Gypsy Baron]

Pete,

That topic title should read "broken when the parameter is 0"

I was away in Europe since mid-May and just returned thus the 'late' post relating to a problem.

I updated FSUIPC4 from 4.817 to 4.837 yesterday.

When I went to start my A2A B-17G, which has all the switches, etc mapped via FSUIPC4 and uses both

MCRO file entries and Lua scripts, I noted problems. Any of the switches that had "SET" as the operation

in my MCRO file failed when the passed parameter was "0". passing any other number worked OK.

Today, I checked two other aircraft and their functioning and found the MCRO file xx=L:Var=SET construct was

also failing when a "0" was the parameter.

One switch that selects fuel tanks also triggers a Lua display to indicate the selected tank. I noticed that

when I selected tanks with select values of 1,2,3 or 4, they worked OK. When I selected the tank "0", the

display indicated the previous tank that was selected.

I then checked to see what the passed parameter actually was by sending it to the Lua display.

As expected, the 1 through 4 selections showed "1" through"4". However, the "0" tank selection

displayed a passed parameter of "-2147483648".

I then changed the passed parameter to "-1" and that was passed correctly but "0" was not!

I reverted back to version 4.827 and everything worked as programmed. next I installed version 4.829

and the "0" problem occured.

I then checked the "changes" PDF and noted the 'bug fix' entry for 4.829:

13.  Fixed a problem with the LVar macro format "L:<name>=DEC,0", to decrement the named L:Var
value down to 0. The "0" was taken as omission and so did not limit the decrementing process.
[/CODE]

That seems to me to indicate that something that was 'fixed' there also 'broke' something as well.

For now I have no option but to stay with 4.827 as any version after that will not work correctly

as all of my aircraft assignments are made via FSUIPC4 and rely heavily upon the use of the

MCRO files and Lua scripts.

I also noted a problem with my Lua scripts that use the "ipc.display" function. I use a change to

offset 0x66C0 to trigger a display of my current 'control set', which is defined by the value in

that offset. Upon entry to that function I set the position and size of the lua display with:

[CODE]
ipc.setdisplay(650, 200, 500, 100)
[/CODE]

What is happening now with 4.829 and above is that the display location seems to randomly

change from the position I set and the default position so the window moves to 2 different

locations. This apparently is linked to:

[CODE]
12 Added new Lua function lua.setowndisplay, which enables the ipc.linedisplay and ipc.display
functions to have their own private Window entitled, positioned and sized as needed. Full details
are provided in the updated Lua plug-ins documentation published separately. .
[/CODE]

I have not used this new function "lua.setowndisplay".

Paul

[Pete Dowson]

When I went to start my A2A B-17G, which has all the switches, etc mapped via FSUIPC4 and uses both

MCRO file entries and Lua scripts, I noted problems. Any of the switches that had "SET" as the operation

in my MCRO file failed when the passed parameter was "0". passing any other number worked OK.

...

That seems to me to indicate that something that was 'fixed' there also 'broke' something as well.

Okay, thanks for your diagnosis. I shall take a look -- but tomorrow now, England vs Italy on at present. I'll get to this in the morning.

I also noted a problem with my Lua scripts that use the "ipc.display" function. I use a change to

offset 0x66C0 to trigger a display of my current 'control set', which is defined by the value in

that offset. Upon entry to that function I set the position and size of the lua display with:

ipc.setdisplay(650, 200, 500, 100)
[/CODE]

What is happening now with 4.829 and above is that the display location seems to randomly

change from the position I set and the default position so the window moves to 2 different

locations. This apparently is linked to:

[CODE]
12 Added new Lua function lua.setowndisplay, which enables the ipc.linedisplay and ipc.display
functions to have their own private Window entitled, positioned and sized as needed. Full details
are provided in the updated Lua plug-ins documentation published separately. .
[/CODE]

Hmm. not so sure about this diagnosis as the two functions aren't connected. The change really was in the display and linedisplay functions. But I'll check that tomorrow morning too.

Thanks,

Pete

[Pete Dowson]

That topic title should read "broken when the parameter is 0"

Okay, I've found that problem and fixed it here -- it was a typo in that change you entioned, so thanks again for that.

However, this:

What is happening now with 4.829 and above is that the display location seems to randomly

change from the position I set and the default position so the window moves to 2 different

locations. This apparently is linked to:

12  Added new Lua function lua.setowndisplay, which enables the ipc.linedisplay and ipc.display
functions to have their own private Window entitled, positioned and sized as needed. Full details
are provided in the updated Lua plug-ins documentation published separately. .
[/CODE]

is definitely not a correct assumption. I've checked thoroughly. The two functions are completely separate. I'm not sure what is going on with your system. Could you paste in the complete code which uses the function, please? I'll need to try to reproduce it here. It's a simple enough function, just using a standard wndows API to size and position the Window. Maybe there's a timing change or something which affects it.

I assume you ARE creating the display first? As noted in the manual, the [b]ipc.setdisplay[/b] and [b]ipc.getdisplay [/b]functions operate on the communal Lua display window[i] if[/i] one is already created. All it does it call the Windows API to move and size it. From what you say the results you are getting suggest that sometimes there was a previous "Lua Display" window to be sized and moved, and other times there was not. In the latter case it would do nothing.

The [b]ipc.setowndispla[/b]y function is different in that it doesn't call any Windows function, but merely set the parameters ready for the next[b] ipc.display[/b] or[b] ipc.linedisplay [/b]calls, the first of which then creates the Lua thread specific Window with those parameters.

Maybe I should change the [b]ipc.setdisplay[/b] function. I could at least return a FALSE or TRUE result depending on whether the Window existed. If it doesn't, maybe I could remember the size and position parameters and apply them after the window is next created -- but ony if that is done by a display call in this thread (bearing in mind that there is only one such communal Window for all threads).

[LATER]

The TRUE/FALSE return is easy enough, so I'll do that, but the other is messy and I don't think it is worthwhile. Best to do the setdisplay after first creating the display I think, as documented -- or change over to using setowndisplay which is probably more desirable for most applications now.

Regards

Pete

[Gypsy Baron]

Thanks for the quick 'fix' Pete. I'll pass along one of the lua scripts I use that make use of the ipc.display routine.

For the most part, they all have a section similar to the first function in the file below that displays the 'current control set', or

mode assignments for a given aircraft. It is this lua display window that I saw moving between 2 locations.

Off the top of my head, when I load a new aircraft that uses an 'aircraft specific' display.lua I have the plugin called, I believe, through

the use of the 'Auto.name' functions in the INI file.This should satisfy the criteria you mention above for having a window opened before

using the set.display routine, methinks. I often have one of my throttle detent switches programmed to send the 'kill all' and then the

'aircraft-specific-name-display.lua'

101=PD,11,C1084,0 ;//Lua Kill ALL
102=PD,12,CL21:R,0 ;//Run Lua Disp
[/CODE]

This is the 'auto.aircraft-name' sectiopn of my INI file:

[CODE]
[Auto.Boeing B-17G]
1=Lua KillAll
2=Lua DispB17CS
3=Lua B17G_Turbo
4=Lua B17G_Gear
[Auto.Boeing Stratocruiser]
1=Lua KillAll
2=Lua A2A_B377_icflap
[Auto.P-47D]
1=Lua KillAll
2=Lua DispP47CS
[Auto.Spitfire Mk I]
1=Lua KillAll
2=Lua DispSPIT
[Auto.Curtiss P-40]
1=Lua KillAll
2=Lua DispP40
[Auto.Tomahawk]
1=Lua KillAll
2=Lua DispP40
[Auto.P-51D 'Boomerang ! X]
1=Lua KillAll
2=Lua DispP51CS
[Auto.P-51D]
1=Lua KillAll
2=Lua DispP51ASCS
[Auto.MAAM-SIM Douglas C-47]
1=Lua KillAll
[Auto.R4D]
1=Lua KillAll
2=Lua DispC47CS
[/CODE]

I believe I see a Lua Display window open when this occurs as I use 'event.offset' routine to call the display functions.

Here is one example where I saw the two differt display positions when simply changing the value in 0x66C0 which

calls the first function in the file. This is my DispP51ASCS.lus file.

[CODE]
function dispP51_CS(offs, val)
conset=val+1
ipc.setdisplay(650, 200, 500, 100)
if val == 0 then
ipc.display("MAG INC _ BATTERY _ RECOG _ NAV LIGHTS _ LAND LIGHTS\nMAG DEC _ AV MASTER _ GEN _ APU _ PANEL LIGHTS\nControl Set = "..conset, 10)
end
if val == 1 then
ipc.display("FUSELAGE _ LEFT MAIN _ RIGHT MAIN _ REL L DT _ REL R DT\nFUEL OFF _ LEFT AUX _ RIGHT AUX _ SPARE _ SPARE\nControl Set = "..conset, 10)
end
if val == 2 then
ipc.display("PRIME _ FUEL PUMP _ SPARE _ GUN SIGHT _ GUNS \nSTART _ PITOT HEAT _ SIGHT GYRO _ SIGHT MODE _ SMOKE OFF\nControl Set = "..conset, 10)
end
if val == 3 then
ipc.display("GPS _ AP CHART _ TAGS _ WING LEVEL _ CANOPY\nRADAR _ MAP _ HEADPHONES _ OXYGEN _ CABIN VENT\nControl Set = "..conset, 10)
end
end
function dispFUEL_TANK(offs, dummy)

TANK =ipc.readLvar("L:FSelP51State")
if TANK == 2 then x = "R MAIN" end
if TANK == 1 then x = "L MAIN" end
if TANK == 0 then x = "FUSELAGE" end
if TANK == 4 then x = "R DROP" end
if TANK == 3 then x = "L DROP" end
ipc.display("FUEL TANK = "..x, 2)
-- ipc.display("L:FSelP51State = "..TANK, 2)

end

function dispFUEL_VALVE(offs, dummy)

STATE =ipc.readLvar("L:Eng1_FuelCutOffSwitch")
if STATE == 0 then y = "CUTOFF" end
if STATE == 1 then y = "CLOSED" end
ipc.display("FUEL VALVE = "..y, 2)
end

function Vent(offset, val)

Vent_Set =ipc.readLvar("L:CabinVent")
ipc.display("Vent = "..Vent_Set, 1)

end

event.offset(0x66C0,"UB","dispP51_CS")
event.offset(0x66C6,"UB","dispFUEL_TANK")
event.offset(0x66C5,"UB","dispFUEL_VALVE")
event.offset(0x66C4,"UB","Vent")
[/CODE]

I hope this all makes sense. I'll do a bit more testing of the display issue I saw tomorrow,

using version 4837.

Paul

[Pete Dowson]

I'll pass along one of the lua scripts I use that make use of the ipc.display routine.

For the most part, they all have a section similar to the first function in the file below that displays the 'current control set', or

mode assignments for a given aircraft. It is this lua display window that I saw moving between 2 locations.

Off the top of my head, when I load a new aircraft that uses an 'aircraft specific' display.lua I have the plugin called, I believe, through

the use of the 'Auto.name' functions in the INI file.This should satisfy the criteria you mention above for having a window opened before

using the set.display routine, methinks.

The "Lua KillAll" you have in many is (or should be) always closing any display window.

Also the closing of any Lua which was using the generic Lua Display will and should be closing that Window.

In one recent release (it may have been 4.829) I did find a fix a few holes in the logic which may have left the generic Lua Display window open still when it shouldn't. Perhaps the change was this fix, not specifically the addition of the completely separately coded "setowndisplay" function.

In your example function:

function dispP51_CS(offs, val)
  conset=val+1
  ipc.setdisplay(650, 200, 500, 100)
  if val == 0 then
   ipc.display("MAG INC  _ BATTERY	_ RECOG _ NAV LIGHTS _ LAND LIGHTS\nMAG DEC _ AV MASTER _ GEN	 _ APU		 _ PANEL LIGHTS\nControl Set = "..conset, 10)
  end
  if val == 1 then
   ipc.display("FUSELAGE _ LEFT MAIN  _ RIGHT MAIN _ REL L DT  _ REL R DT\nFUEL OFF   _ LEFT AUX   _ RIGHT AUX  _ SPARE  _ SPARE\nControl Set = "..conset, 10)
  end
  if val == 2 then
   ipc.display("PRIME  _ FUEL PUMP  _ SPARE	   _ GUN SIGHT  _ GUNS	\nSTART _ PITOT HEAT  _ SIGHT GYRO _ SIGHT MODE _ SMOKE OFF\nControl Set = "..conset, 10)
  end
  if val == 3 then
   ipc.display("GPS	 _ AP CHART _ TAGS		  _ WING LEVEL  _ CANOPY\nRADAR _ MAP		 _ HEADPHONES	_ OXYGEN	 _ CABIN VENT\nControl Set = "..conset, 10)
  end
end[/CODE]

Really the "setdisplay" call should be at the end.

I realise this isn't very logical, but it is the way it works at present, unless you have initialisation code outside all the functions which creates the window for you, mybe even displaying one space, just to create a blank window (a null string won't do).

Anyway, having slept on it I have woken with a few ideas as to how to get around the problem I have in implementing it the way you would have logically expected. The original problem is simply that the generic display has to be written to in the main FS thread, whilst of course the functions are in the Lua threads. The "setdispay" function was implemented simply as a "SetWindowPos" API call to Windows, executed in the Lua thread -- easy, but not working if the Wndow is not yet created.

I'm now looking at saving the size and position parameters in the case where the window didn't exist and applying them when the Window is next written to, in the main thread. It's not a pretty solution, but doable I think.

To be honest, if I had known how popular the Lua display mechanism was to become I'd have implemented it the way the "setowndisplay" works now in the first place and would never have invented the original setdisplay facilities that way. The way the own display system works is thoroughly logical and tidy throughout, with each thread having its own controlable Window., and everything properly organised internally.

I'll let you know later today how I get on.

BTW, in this:

[CODE]function dispFUEL_TANK(offs, dummy)[/CODE]

there is no need to include the "dummy" parameter. I didn't know this when I first started with Lua, but, unlike many languages, especially C/C++, Lua's function declarations can include more or less parameters than those used in the calls to them (and vice versa). Where you supply parameters not declared they are simply discarded, and where you declare them and they are not supplied they would be read as 'nil'.

Regards

Pete

[Pete Dowson]

Can you try this test version please (4.839). Seems okay here, but I've got nowhere near your complexity of Lua usage, and it would take be a while otherwise to test thoroughly.

FSUIPC4839 test.zip

This should fix both your concerns. Let me know please. I will then have to do similar changes to 3.999 as well.

Thanks,

Pete

[Gypsy Baron]

Hello Pete,

I just d/l'd 4839 and will test in in a few hours, once I get through my morning online chores :)

Thanks for the quick find and fix!

Paul

EDIT: OK, I checked the L:var=SET condition and that does appear to be fixed. Thanks.

With regards to the Lua display window, what I see now is a blank, tan window that opens

and remains open as long as FSX is running. It minimizes as soon as I put the focus on the

main FSX window. Does this need to be opened to insure the operation of the lua.display

positioning?

Here is what I am seeing:

Paul

[Gypsy Baron]

Pete,

If I close that blank window then my ipc.display routines no longer function.

The problem with it is if I minimize FSX to get to shortcuts on my desktop, if they are under that blank window

I can't get to them. As you can see, I tend to accumulate a good many shortcuts :)

Paul

[Pete Dowson]

With regards to the Lua display window, what I see now is a blank, tan window that opens

and remains open as long as FSX is running. It minimizes as soon as I put the focus on the

main FSX window. Does this need to be opened to insure the operation of the lua.display

positioning?

Here is what I am seeing:

That's really weird. It certainly doesn't happen here. I'll try to reproduce it. Are you saying that happens even before any of your Lua stuff is run? If not, when does it first appear? I might need the Lua sequence which does it.

Apart from that odd Window, do the Lua display things all work correctly now. You forgot to say.

[LATER]

Messing about with "setdisplay", I too can now get that extra Window called "UIPCMAIN". So i should be able to fix it forthwith ...

Regards

Pete

[Pete Dowson]

So i should be able to fix it forthwith ...

Fixed. Sorry to have wasted your time -- a silly typo, as usual. That's the trouble with thinking up "easy fixes", they are so easy that it makes one careless. Complex changes take a lot more care and are less prone to stupid mistakes.

Please check this one:

FSUIPC4839 test2.zip

Only the date has changed on the ID. I didn't yet want to move on to 4.84.

Regards

Pete

[Gypsy Baron]

Hello Pete,

First, yes, the fluctuating window position seems to be resolved however since I was not able to reproduce that

action 'on demand'...it was rather random, I will keep any eye on the windows, so to speak :)

Thanks for digging into the phantom window issue. I'll be testing the updated 4839 within the hour.

And thanks again for the quick fix. You didn't 'waste' any of my time. I'm a 'tweaker' and 'troubleshooter' by

nature and training (retired electronic engineer). :)

Paul

[Gypsy Baron]

Ok, I finally got to test 4839test2 a bit more....first, the good news. The blank window is gone and my lua.displays

seem to be working fine.

Now the bad news. In both 4389test and 4389test2 all my switch assignments that use a TOGGLE function via

the LVar entry is a MCRO file are now 'uni-directional'. That is, they toggle OFF but not ON.

I didn't see this earlier as I entered the cockpit of my test aircraft with the major functions already on. Just a bit ago

I went back to test everything again and saw this behavior. I tested on 3 different aircraft and the common element was

the controls assigned via the MCRO entries with 'TOGGLE' as the action. If the function is ON I can hit my switch and

the function goes OFF but I can not then turn it back ON.

The standard FSX commands assigned directly Cxxxxxx, work OK but not those as noted above.

I also tested with 4387 and the TOGGLE functions worked in that version, but that was the version where

the "SET" with a '0' parameter failed. So, something got introduced in the 4839test and test2 versions that

messed up the 'xx=LVar=TOGGLE' actions. I also loaded 4827 to make sure that nothing else on my system

was involved and 4827 worked fine.

Paul

[Pete Dowson]

Now the bad news. In both 4389test and 4389test2 all my switch assignments that use a TOGGLE function via

the LVar entry is a MCRO file are now 'uni-directional'. That is, they toggle OFF but not ON.

Hmm. I'll try to do a test here to see what is going on, but I only have default aircraft -- not sure which has a value I can toggle, but there should be one.

[LATER]

Yes, default 738, MFD Centred and scale display. I've repro'd the problem so it'l be fixed today. Just looking at the code I couldn't see how it could happen, but further experiments showed that if a non-zero parameter is provided, then the toggle works. ANY non-zero.

It was yet another stupid typo: an "=" instead of an "==", which changed the Toggle into a Set if the parameter was omitted or 0. Duh! That's two stupid typos in one line of code! I'm getting senile I'm afraid.

Fixed in 4839test3, same ID different date again. I think this is it now. I'll probably release it and the FSUIPC3 version tonight or tomorrow morning.

FSUIPC4839 test3.zip

Thanks,

Pete

[Gypsy Baron]

Good day Pete,

I just ran through my tests of 'test3' and everything looks good now. That 'anything but 0' issue sure was

a strange one. Glad you tracked it done.

Thanks for your time if squashing these couple of problems.

Paul

[Pete Dowson]

I just ran through my tests of 'test3' and everything looks good now.

Okay, good. Making release in Download Links now.

Best Regards

Pete