Crash with LUA and rotary switch

[guenseli]

Hello Pete,

I have a LUA script for the PMDG J41.

I can make FSX reproduceable crash when dialing on my MCP combo.

I can dial longer in SP mode, but Online on IVAO it crashed two times today after some dials of ALT or HDG.

Never have noticed the crash in SP Mode, but it needs a really long dial before it is crashing, I have found out now.

So its possible in SP, too...

This issue was also with my old PC, but I have thought it is solved with the new one: I7 930@ 4,4 Ghz, GTX470, 6 Gig Ram 1600

I have of course installed the latest FSUIPC 4.661

Here is the relevant LUA script part:

-- ALT plus

elseif ipcPARAM == 10 then

		Var = ipc.readLvar("IrcAltSelKnob")
		if Var >= 100 then 
		Var = 1
		end
		ipc.writeLvar("IrcAltSelKnob", Var+1)

	   	ipc.control(66587,3921)

		ipc.control(66587,8031)
	   	ipc.sleep(40)


-- ALT plus fast
elseif ipcPARAM == 11 then

		Var = ipc.readLvar("IrcAltSelKnob")
		if Var >= 100 then 
		Var = 1
		end
		ipc.writeLvar("IrcAltSelKnob", Var+5)


		for n=1, 10, 1 do
	   	ipc.control(66587,3921)
		end
		ipc.control(66587,8031)
	   	ipc.sleep(40)



-- ALT minus

elseif ipcPARAM == 12 then



		Var = ipc.readLvar("IrcAltSelKnob")
		if Var <= 1 then 
		Var = 100
		end
		ipc.writeLvar("IrcAltSelKnob", Var-1)

	   	ipc.control(66587,3920)
		ipc.control(66587,8031)
	   	ipc.sleep(40)



-- ALT minus fast

elseif ipcPARAM == 13 then

		Var = ipc.readLvar("IrcAltSelKnob")
		if Var <= 1 then 
		Var = 100
		end
		ipc.writeLvar("IrcAltSelKnob", Var-5)

		for n=1, 10, 1 do
		ipc.control(66587,3920)
		end
		ipc.control(66587,8031)
	   	ipc.sleep(40)

-- HDG plus

elseif ipcPARAM == 15 then


	   	ipc.control(66587,26902)

		ipc.control(66587,8031)
	   	ipc.sleep(50)



-- HDG plus fast

elseif ipcPARAM == 16 then

		for n=1, 10, 1 do
	   	ipc.control(66587,26902)
		end

		ipc.control(66587,8031)
	   	ipc.sleep(50)


-- HDG minus

elseif ipcPARAM == 17 then


	   	ipc.control(66587,26901)

		ipc.control(66587,8031)
	   	ipc.sleep(50)


-- HDG minus fast

elseif ipcPARAM == 18 then

		for n=1, 10, 1 do
	   	ipc.control(66587,26901)
		end

		ipc.control(66587,8031)
	   	ipc.sleep(50)

You can find the whole (long) LUA Script in your "User contributions"

Do you think, the complete LUA is too big?

So the rotary parts should be layed out in an extra, shorter LUA? Could that help?

Or do have any other idea what could lead to the FSX crash...?

Btw: there's no warning or LOG noted about. FSx is still hanging and crashes after a while.

Hope you have a good idea (as always)!

Many thanks,

Günter

[Pete Dowson]

I can make FSX reproduceable crash when dialing on my MCP combo.

I can dial longer in SP mode, but Online on IVAO it crashed two times today after some dials of ALT or HDG.

Never have noticed the crash in SP Mode, but it needs a really long dial before it is crashing, I have found out now.

So its possible in SP, too...

"SP mode" being what .. single player instead of multiplayer? I've not seen the term before.

This issue was also with my old PC

Why did you never mention it? I thought we solved all the Lua re-entry crashes way back, over a year ago. There's been no reports at all since then!

Here is the relevant LUA script part:

I see you still have not discovered events? Much more sensible to use events, and now you can use the LuaValue controls to send them ipcPARAM values your method of having lots of functions in one Lua plug-in would work much tidier. No constant Killing, Reloading, Recompiling all the time.

You can find the whole (long) LUA Script in your "User contributions"

That's all very well, but I would need to reproduce the problem here, and I don't have the aircraft. Do you have anything which will do it on a default FSX aircraft?

Do you think, the complete LUA is too big?

Maybe. The safety valve is the re-run delay, the parameter

LuaRerunDelay=66

It was this mechanism that fixed the crashes. If your Lua is too long, taking over 66 mSecs to load, compile, and execute each time, then that would be the reason. You can test that by increasing the delay. This will of course slow your dial repeat rates. Try it and see. Double it first. If that fixes it, zero in on a good value. If not, double again. If it still doesn't fix it let me know because at that sort of delay it must be something else.

So the rotary parts should be layed out in an extra, shorter LUA? Could that help?

It certainly could. But i also notice other long sections in your script: Like these:

              for n=1, 10, 1 do
                ipc.control(66587,3921)
                end
                ipc.control(66587,8031)
                ipc.sleep(40)

That alone is going to bring the time for execution perilously close to the 66 limit, more maybe when adding the load and compile time. Why all the sleep(40)'s? That surely makes things worse when trying to re-execute fast?

Btw: there's no warning or LOG noted about. FSx is still hanging and crashes after a while.

Yes. Typical of a stack overflow.

The better method is to use event.param to receive the parameter values and program the buttons to send LuaValue controls instead. You'd just need to get the Lua started at the beginning of the session, or maybe make it load with the aircraft. In the latter case you should make it also monitor the aircraft name offset (via event.offset of course) and terminate itself when that isn't the right one (or doesn't contain the substring "J41", say).

Let me know how you get on, and if you have any more questions.

Regards

Pete

[guenseli]

Hello Pete,

thanks for answering!

"SP mode" being what .. single player instead of multiplayer? I've not seen the term before.

Yes, SinglePlayer...maybe thats just a german term...

Why did you never mention it? I thought we solved all the Lua re-entry crashes way back, over a year ago. There's been no reports at all since then!

It never came up again... but just very seldom from time to time. And not in every case I could be sure thats cause of the LUAs

I never had it till yesterday with my new PC. And Online in IVAO yesterday it happened twice. So I forced it to happen in "SP" (offline) too to be sure that was not caused by the IVAP software.

I see you still have not discovered events?

No... :oops:

But I ignrore new things as long as I don't need them urgently... :wink:

You know, I'm no programmer!

I will have a look into this... but I need some examples, please! Are there any examples you can point me to, please?

Why all the sleep(40)'s

Indeed because I thought that solves this crashing.

As you explain it, it makes things obvisiously worser. Will immediatelly delete them!

Maybe that is enough to solve my problem, otherwise I will "outsource" the dialing code from the main LUA.

And I will have a look into the event-stuff, of course.

[Pete Dowson]

I will have a look into this... but I need some examples, please! Are there any examples you can point me to, please?

All these examples in the package installed by the FSUIPC installer use events:

GFDdisplay.lua

TripleUse.lua

VRI_SetMach.lua

VRI_SetrBaro.lua

The concept is easy. Istead of having a Lua program loaded, compiled, run and discarded on every use of a control, you have it loaded once, at the beginning (perhaps by a "runlua" call in the ipcReady.lua, or by using the Auto facility for aircraft specific applications), and it stays loaded and always ready to act upon events signalled in FS.

Your type of events would be the parameters you have already assigned, using "event.param" to direct them to your processing finction. The whole decode of the parameter value would be in a function declared in the event.param call.

You could still split things into smaller Luas if you wanted to, but there's far less need when the program remains loaded. The only advantage then of several smaller ones is that several could be doing things at the same time. With only one, it can only process one of your inputs at a time, and there's no queuing except that if the parameter is changed whilst processing the previous change the function will be re-entered when it exits. However, this isn't any 'worse' than your current arrangement -- in fact it is much better because execution is a lot faster.

The presence of an event to be processed in the Lua stops the Lua from being discarded. It is only removed in one of four circumstances:

1) if you re-execute it (as when testing, or perhaps when reloading the aircraft with [auto loading)

2) all the events it is "catching" are cancelled (by the event.cancel function).

3) it is explicitly terminated by the ipc.exit function.

4) an unrecovered error occurs (eg bad Lua) -- the Log would show this.

Note that the event.param function and the accompanying LuaValue assignable control have only been added quite recently, so this method would not have been applicable to your Lua programs originally. Most event-using plug-ins react to things like offset changes -- needed to keep GoFlight displasys up to date, for instance -- and the VRI Baro and Mach displays, the examples made specifically for the VRI MCP Combi and M-panel devices.

Regards

Pete

[guenseli]

Many thanks for explaining, Pete!!!

I understand the system behind it and it looks much better, yes.

Just one question is left:

How do I assign now a button (I don't want to do that in the script itself with event.button)?

Is

if ipcPARAM == 10 then

something like

if event.param == 10 then

or how do I do that?

[Pete Dowson]

How do I assign now a button (I don't want to do that in the script itself with event.button)?

Assign the button to LuaValue <name of Lua> with the parameter as usual! That's what the LuaValue control is for! The Lua plug-in named must already be running, of course, otherwise this will do nothing.

if ipcPARAM == 10 then

You don't need to use "if ipcPARAM == 10" because the value is provided as the parameter to the function. So it the function is

function J41buttons(param)

The value is the param is "param". This is actually the same as "ipcPARAM" AT THAT TIME, but another button could change that.

something like

if event.param == 10 then

or how do I do that?

Er .. event.param() is a function! It tells FSUIPC which of your functions to call when the parameter is changed (i.e set by the LuaValue control).

Please do look at the examples using events. I don't think you understand them yet! Also please look at the definition of the event library functions. You will clearly see that there's no such thing as "event.param" without providing the function name as, foe example.

event.param("J41buttons")

and that there is no return value to this. It simply sets up that function to receive parameter values set by LuaValue.

Pete

[guenseli]

I don't think you understand them yet!

Yes, you are absolutelly right!!!

But I think you have helped me now with your explaining to start with that stuff.

Will try and see what happens if I have time for...

Will report back!!!

thanks a lot!

Günter

[guenseli]

Hi Pete,

now, a few days later I have "understood" now the function stuff and especially the event.param one.

This is a little testscript which is working as it should and I'm proud of :wink:

function Test(param)

if ipcPARAM == 1 then
	ipc.display("parameter 1")


elseif ipcPARAM == 2 then
	ipc.display("parameter 2")

end
end

event.param("Test")

Next hard work will be to rewrite my current LUA scripts to this method, especial the J41 LUA ...

Thanks again very much much for your patience and help!

Günter

[Pete Dowson]

This is a little testscript which is working as it should and I'm proud of :wink:

function Test(param)

if ipcPARAM == 1 then
	ipc.display("parameter 1")


elseif ipcPARAM == 2 then
	ipc.display("parameter 2")

end
end

event.param("Test")

Yes, that's good, but the ipcPARAM value might change whilst you are in the procedure, if another button is pressed, and then the event will trigger after you exit for the same value. Really you should use the parameter supplied -- that is why it is supplied, to make it easier in any case. i.e.

function Test(param)
if param == 1 then
	ipc.display("parameter 1")
elseif param == 2 then
	ipc.display("parameter 2")
end
end

event.param("Test")

Rehards

Pete

[guenseli]

Ah ok. As you see I haven't understood it 100%

"if param == 1 then" is what I really wanted...

[alexandre-mbm]

@guenseli, I have been interested in knowing the code of your script, for studies. If you gives it for me, please do comment about what has never worked. I found them here but all lines are joined.

Edited August 15, 2015 by alexandre-mbm