Lua "bug"?

[guenseli]

Hello,

I found something strange...

It happend during my J41 command assigenments.

Now I have tested it also with a normal standard FSX plane and simple LUA commands

if you'd like to execute a LUA file with holding the buttons or keys down, then FSX will hang and crash.

i have a LUA test file created, just with this simple entry:

ipc.control(65879)

(it is heading bug increase)

Now, if you assign this LUA file to a Joy button or a key and hold the button or key down to let the heading bug move, FSX crashes after 5 to 30 seconds...

If you assign the normal heading_bug_increase via FSUIPC, there's everything normal as it should.

Can you confirm this?

Or it it as always, that something in my system is faulty or I have made something wrong? :lol:

guenter

[Pete Dowson]

if you'd like to execute a LUA file with holding the buttons or keys down, then FSX will hang and crash.

i have a LUA test file created, just with this simple entry:

ipc.control(65879)

(it is heading bug increase)

Now, if you assign this LUA file to a Joy button or a key and hold the button or key down to let the heading bug move, FSX crashes after 5 to 30 seconds

I am not at all surprised! You presumably have "repeat"set for that button. Each time it is repeated (20 times per second), the previous thread has to be killed and another Lua thread started, probably before the other has truly finished and completely terminated. After a few seconds, there could be so many threads in the process of being killed that the system is overloaded.

If people are going to do such crazy things I will have to put a BIG delay on obeying the next instigation of the same Lua thread! That will be unfortunate for those who use the facility properly.

I don't understand why you would even try such a thing! Can you explain, please?

:-(

Pete

[Pete Dowson]

If people are going to do such crazy things I will have to put a BIG delay on obeying the next instigation of the same Lua thread! That will be unfortunate for those who use the facility properly.

Actually, forget that -- I was too hasty. I think I've found a neat way around the problem.

I will upload new version (4.546 and 3.942) tomorrow (Sunday). Please try again and see if you can still break it! ;-)

Regards

Pete

[Pete Dowson]

I will upload new version (4.546 and 3.942) tomorrow (Sunday). Please try again and see if you can still break it! ;-)

Ok, the new version is up. this is the description of the change:

The way Lua plug-ins are started and terminated has been changed a little, to avoid problems with repeating controls (buttons and keypresses set to repeat whilst held). Whereas previously each repeated call to execute a plug-in would actively try to "kill" the previous incarnation then load and run a new one, the current repeat of the control is now discarded if the plug-in is still running. A repeated control only manages to load and run the plug-in if the previous incarnation has by then terminated.

This effectively makes such plug-ins run at their own speed, and not even attempt to repeat at the set repeat speed. Short fast Lua programs will repeat quickly, while longer more complex ones wil repeat only slowly -- and non-terminating ones cannot be killed or restarted by a repeated control, only by a fresh one or an explicit "Kill" control.

This makes assignment of Lua plug-ins to repeating buttons or keypresses more reliable. it was quite easy to crash FS before, due to a continuous build-up of pending thread terminations and creations.

Note that, if a Lua plug-in is really intended to be used repetitively, it may be much more efficient to actually program it with a loop in the Lua code and have it checking the state of the relevant button or key itself.

Have fun! ;-)

Regards

Pete

[guenseli]

Hello Pete,

the first post of you is exactly what I'm fear of: that you throw me out of your forum one day :lol:

Just kidding... hopefully not.

I'm very happy, that you changed your mind and found a solution.

Why I want to do this?

Because the fascinating PMDg J41 has no well working key command solution and with FSUIPC everything is possible.

And the LUA thing allows me to combine things, which just work with macros and things just working with LUA Vars.

Till now everything works fine, because that where just simple buttons.

But the heading bug is aomething you have to hold a key or button pressed.

And thet was then the situation when FSX crashed.

The example above with the heading bug, is just a simple example to show you that it has nothing to do with the J41 or or with my "special" codes.

I hope, you understand me now a little bit.

Unfortunately, when I want to download the update I get an error:

The requested URL /beta/FSUIPC4545.zip was not found on this server.

And please be sure, that, whatever I ask you, you never have to present me the solution as fast as possible.

Your support is outstanding and the fastest I know.

And I feel a little guilty to see you work in night and sundays...

So, I hope you have a little fun with your work.

And I have to thank you a lot!

[Pete Dowson]

Unfortunately, when I want to download the update I get an error:

The requested URL /beta/FSUIPC4545.zip was not found on this server.

Ahas I said, the fix is in 4.546. I saw that my updated Announcement (dated 25th not 23rd) didn't get uploaded! Strange. It should be okay now.

Regards

Pete

[guenseli]

WORKS :!: :!: :!:

Great!

Thank you!!!!

[guenseli]

Hello,

could it be that with the actual version (10th November) this bug has come up again??

[guenseli]

no, I'm sorry, there seems to be some other error in my code.

Sorry, was a little bit too fast :oops:

[guenseli]

hmmmm.... could you please have a look if theres sth wrong with the latest (10th Nov) version?

With a joystickbuttonpress (hold) there's no error, with a keypress (hold) the error comes as befor the fix....

thanks very much,

guenter

[Pete Dowson]

hmmmm.... could you please have a look if theres sth wrong with the latest (10th Nov) version?

With a joystickbuttonpress (hold) there's no error, with a keypress (hold) the error comes as befor the fix....

Er, can you elaborate please?

1. What is the "problem" exactly? Do you mean multiple Lua executions of the same program through repetition? If so, and you only get that with Keys assignments, that's very odd because

(a) I only tested it with key assignments, as I have no buttons on my dev. machine, and

(b) both call the same routine in any case.

2. If so, then presumably it is related to what the Lua program is doing, so can you possibly show me the Lua program you have the problem with?

3. Still need the version number of FSUIPC please. Dates don't tell me that really (I don't keep a diary and generally release a 3. and a 4. version on the same day in any case. And the 10th was yesterday and I've not released an update for several days!).

Thanks,

Pete

[guenseli]

Oh, Sorry... FSUIPC Version is 4.548

The Lua file is the same file as in the initial thread It only contains

ipc.control(65879)

(HDG Bug inc)

My normal file has an other code, but like I stated in the initial thread FSX also crashes with a standard plane and this simple code.

Do you mean multiple Lua executions of the same program through repetition?

Yes I mean that....

It is a little bit confusing to me now...

Right now I can't reproduce the error :roll:

Before it was every time...

So, don't waste your mind about that...

I just wanted to be sure that the fix of that problem wasn't get lost with the last update.

If I can definitely reproduce again it I will post again here.

Strange things happen with all this machines... ;-)

[Pete Dowson]

Oh, Sorry... FSUIPC Version is 4.548

Okay. That was the last one uploaded, about 6 days ago.

The Lua file is the same file as in the initial thread It only contains

ipc.control(65879)

(HDG Bug inc)

I still have that here, and it works fine.

It is a little bit confusing to me now...

Right now I can't reproduce the error :roll:

Before it was every time...

Strange.

I just wanted to be sure that the fix of that problem wasn't get lost with the last update.

Well, if I had a PC crash and restore without me knowing that might be possible ;-). But I do have good backup and source control to prevent any loss of code assuming no mystical happenings!

If I can definitely reproduce again it I will post again here.

Okay, but I would then be very mystified and need lots of information about how to reproduce it!

Regards

Pete

[guenseli]

Yes, and as always: thank you very much for the great support!

[guenseli]

Hello Pete,

I can reproduce the error again....

This is the situation:

code inside the LUA file:

ipc.control(65879)

(HDG Bug inc - just simple, just for testing)

aircraft: default Beech Baron

Joystickbutton or direct key input is working (the key is TAB+F9)

BUT: I have the MCP Combo from VRInsight.

There's a keymapper where you can assign keystrokes to the combo and then get this keystroke into FS.

This is why I get the TAB+F9 keycombination. (theres no other possibility unfortunately)

Now when I rotate with the HDG knob of the MCP Combo (which means fast repeated TAB+F9) the FSX is freezing after few seconds.

Like the same what we had at the beginning of this thread way back.

Hold a button pressed or holding down the keys does not produce the hangup.

Just the rotation with the HDG knob...

So, I know that must be fault with the Combo or the way the combo acts with keystrokes and communicates with FSUIPC or whatever...

I just write this to inform you, and maybe you have an idea.

I will write now into the VRInsight forum this problem, where Andydigitl could help me, hopefully.

I will report back...

[Pete Dowson]

BUT: I have the MCP Combo from VRInsight.

Ugh. I'm still waiting for them to contact me about a license -- they are using FSUIPC without any agreement, payment or permission.

There's a keymapper where you can assign keystrokes to the combo and then get this keystroke into FS.

This is why I get the TAB+F9 keycombination. (theres no other possibility unfortunately)

Hmmm. Maybe you manage to bypass my 2repeat" checks that way. I don't know.

Please enable key/button logging and show me the resulting log.

Pete

[Andydigital]

I'm still waiting for them to contact me about a license -- they are using FSUIPC without any agreement, payment or permission.

Are you saying that any developer that uses FSUIPC to simply connect to FS through FSUIPC has to pay a licence? They aren't doing anything fancy as far as I know. For example you turn a HDG dial on a VRI panel and it sends HDG_INC to FS9 or FSX when using default aircraft etc, do they have to pay for this?

The registered version of FSUIPC is not required to use any VRInsight hardware at all, although I personally recommend it to users at the VRInsight forum for mouse macro's etc with advanced third party aircraft that don't use the default AP system.

[Pete Dowson]

Are you saying that any developer that uses FSUIPC to simply connect to FS through FSUIPC has to pay a licence? They aren't doing anything fancy as far as I know. For example you turn a HDG dial on a VRI panel and it sends HDG_INC to FS9 or FSX when using default aircraft etc, do they have to pay for this?

If they are connecting through the programmable interface to FSUIPC, and not just acting like a standard joystick with buttons for users to program, and if they are a commercial company out to make some profit on what they are doing, then, yes, of course they should have a commercial agreement with me, and probably pay for a license (unless they are a charitable non-profit organisation which is doubtful). That has always been the case, even in the days of Adam Szofran's FS5IPC and FS6IPC.

The registered version of FSUIPC is not required to use any VRInsight hardware at all

That's the problem isn't it? I used to force programs to apply to me for an Application key else they couldn't get access. If now that I don't I find I get many more like VRInsight I shall have to reconsider that option. It's been working on trust quite well for a couple of years. I'd hope for that to continue.

I spoke to the VRInsight folks at Lelystad and they promised to get in touchmaybe they will. I've sent a reminder.

Regards

Pete

[Andydigital]

Oh they will get back to you Pete, I'll keep badgering them until they do, I'd appreciate a PM when they finally do so I know when to stop :D I moderate the forums for them and do quite a bit of support for them too, so if they don't get in contact I will have to stop supporting them :wink:

[Pete Dowson]

Oh they will get back to you Pete, I'll keep badgering them until they do, I'd appreciate a PM when they finally do so I know when to stop :D

Okay. Thanks,

Pete

[guenseli]

okay, maybe we're now a little step further...

I'm sure now that the issue is in my code or in the Aerosoft Catalina (or maybe in FSUIPC)...

But not in the VRInsight stuff, sorry that I have thought this, Andy...

I have some LUA codes programmed and here the FSX freezes after a while.

Then I have restarted FSX and tried the LUA file with the standard beech baron, which ended in a freeze, too.

Then I coded just the little single line from above to test, restated FSX and ended with a freeze, too.

That was the point I come back to this thread yesterday...

I now found out, that the error is somewhere "stored" and is present after starting FSX after the crash.

That was the big mistake in my thoughts... so every restart of FSX doesn't have eliminated the issue (whatever it is)

I have to completely log out or completely restart my PC that the issue is away.

Then the little LUA testfile (hdg bug inc) runs without any issues, even with joybuttons or keyboard or MCP Combo.

Yesterday I have never restarted my whole computer, because I have thought a terminated FSX is enough.

OK, I have sent you the FSUIPC.log via mail. Hope this is ok...otherwise delete it...

Below is the LUA code segment wich is causing the error.

Some little explanations:

It is for the Aerosoft Catalina which is having nearly no keycommands.

The part below is for the special Autopilot. it is a very good replica of an old, hydraulic or pressure driven sperry AP.

But the other side is, that the normal AP commands will not work.

If you can find here an obvisous error in my code or some part which could cause this issue, then please correct me.

Or you have an other idea...

But we shouldn't waste our times too long.

The worst case is, that the Catalinas Sperry AP couldn't be managed with keycommands, just with the mouse in the VC.

And that isn't a great tragedy...

thank you very much!

guenter

-- Sperry Pitch Inc (down)
if ipcPARAM == 22 then


SPVar = ipc.readLvar("L:Sperry_pitch_set")

	SPVarInc = SPVar + 0.25

	if SPVarInc 	ipc.writeLvar("L:Sperry_pitch_set", SPVarInc)

	elseif SPVarInc == 12 then
	end

-- Sperry Pitch Dec (up)
elseif ipcPARAM == 23 then


SPVar = ipc.readLvar("L:Sperry_pitch_set")

	SPVarDec = SPVar - 0.25

	if SPVarDec > -12 then
	ipc.writeLvar("L:Sperry_pitch_set", SPVarDec)

	elseif SPVarDec == -12 then
	end



-- Sperry Gain Elevator ON/OFF (value 3.5)
elseif ipcPARAM == 24 then

GEVar = ipc.readLvar("L:Sperry_gain_elevator")

	if GEVar 	ipc.writeLvar("L:Sperry_gain_elevator", 44)

	elseif GEVar > 0 then
	ipc.writeLvar("L:Sperry_gain_elevator", 0)

	end



-- Sperry Bank Inc (left)
elseif ipcPARAM == 25 then

SBVar = ipc.readLvar("L:Cat_Desired_Bank")

	SBVarInc = SBVar + 1

	if SBVarInc 	ipc.writeLvar("L:Cat_Desired_Bank", SBVarInc)

	elseif SBVarInc == 26 then
	end

-- Sperry Bank Dec (right)
elseif ipcPARAM == 26 then

SBVar = ipc.readLvar("L:Cat_Desired_Bank")

	SBVarDec = SBVar - 1

	if SBVarDec >= -26 then
	ipc.writeLvar("L:Cat_Desired_Bank", SBVarDec)

	elseif SBVarDec == -26 then
	end

-- Sperry Gain Aileron ON/OFF (value 3.5)
elseif ipcPARAM == 27 then

GAVar = ipc.readLvar("L:Sperry_gain_aileron")

	if GAVar 	ipc.writeLvar("L:Sperry_gain_aileron", 44)

	elseif GAVar > 0 then
	ipc.writeLvar("L:Sperry_gain_aileron", 0)

	end




-- Sperry HDG Inc (left)
elseif ipcPARAM == 28 then

SAVar = ipc.readLvar("L:Desired_Heading")

	SAVarInc = SAVar + 2

	if SAVarInc 	ipc.writeLvar("L:Desired_Heading", SAVarInc)

	elseif SAVarInc >= 360 then SAVarDec = 1
	ipc.writeLvar("L:Desired_Heading", SAVarDec)

	end

-- Sperry HDG Dec (right)
elseif ipcPARAM == 29 then

SAVar = ipc.readLvar("L:Desired_Heading")

	SAVarDec = SAVar - 2

	if SAVarDec >= 0 then
	ipc.writeLvar("L:Desired_Heading", SAVarDec)

	elseif SAVarDec 	ipc.writeLvar("L:Desired_Heading", SAVarDec)

	end

-- Sperry Gain Rudder ON/OFF (value 3.5)
elseif ipcPARAM == 30 then

GRVar = ipc.readLvar("L:Sperry_gain_rudder")

	if GRVar 	ipc.writeLvar("L:Sperry_gain_rudder", 44)

	elseif GRVar > 0 then
	ipc.writeLvar("L:Sperry_gain_rudder", 0)

	end





end

[Pete Dowson]

I'm sure now that the issue is in my code or in the Aerosoft Catalina (or maybe in FSUIPC)...

The log certainly shows it isn't to do with the Lua threads piling up.

There are 1153 cases of the Lua program starting, and 1151 cases of it ending. So, at the end of the log there are still two cases of it still running. I've not yet located where these extras were started, but I do find it not coincidental there are two distinct key combinations both running the same Lua program -- Tab+1 and Tab+3, so probably there's one instance of each.

Looking furthur at your code, it is rather large for something you might want to have repeating reasonably quickly. It contains multiple functions which are really completely separate and could be much faster shorter separate Lua plug-ins. Don't forget it is re-read and re-compiled each time it is executed. You could probably, instead, have a Lua program running continuously which acts on Events. Butbefore going into that I think it would be much more efficient for you to split it up into its separate parts, each executed for their separate functions.

You have some odd parts in the Lua which could be deleted. These have no effect and should be deleted:

elseif SPVarInc == 12 then

elseif SPVarDec == -12 then

elseif SBVarInc == 26 then

elseif SBVarDec == -26 then

Also, this sort of thing

GEVar = ipc.readLvar("L:Sperry_gain_elevator")
if GEVar <= 0 then
   ipc.writeLvar("L:Sperry_gain_elevator", 44)
elseif GEVar > 0 then
   ipc.writeLvar("L:Sperry_gain_elevator", 0)
end

would be more efficient as:

gain_elev = "L:Sperry_gain_elevator"
val = 0
if ipc.readLvar(gain_elev) <= 0 then
   val = 44
end
ipc.writeLvar(gain_elev, val)

Anyway, I can't see what might possibly be causing a crash, unless the gauges dealing with these L:vars cannot cope -- maybe they don't have protection against re-entry, and they are getting their stack corrupted and hence probably corrupting other code -- maybe even to the extent of affecting saved parameters (FLT or other files?).

You may need to consider another method of doing the updates. There are standard ways around this sort of thing. For instance, you could have a value in which you accumulate the increments/decrements, and only read/write the Lvar at intervals, say every 250 mSecs or so, or when there's been no further call for 500 mSecs.

You'd certainly need to use the Event library facilities for this -- you can trap key presses as events -- and you can have your Lua program automatically started when you load the relevant aircraft. Having a Lua program ready compiled and running awaiting keypresses (sleeping most of the time, of course) is much more efficient in any case, even if you don't regulate the changes into the L:vars, which I suspect you'd need to do.

Regards

Pete

[guenseli]

Hello Pete,

I have now reworked my complete code with the kind of smarter coding of your example...

Thats the difference between a good programmer and me: I don't have these ideas y myself :?

Also I have made for the AP rotaring functions a extra LUA file so if they don't work I will delete them, forget them and command the rotary switches with the mouse again....

BUT:

I haven't made exzessive testing with it, but it seems that it will work now with smarter codes...

We will see...

Thank you very much for your effort!!!!

[guenseli]

No they don't work... FSX is freezing again.

Ok, doesn't matter!

I will throw out this codelines and everybody have to hand-dial the rotary knobs...

btw: the same commands worl with the PMDG J41 without problems.

So I slightly come to the conclusion that sth must be hiccup inside the Catalina codes....

Anyway,

thanks and a good evening!

[Pete Dowson]

No they don't work... FSX is freezing again.

These are with separate little Lua programs, one for each function?

If so, I think you need to do it the other way I suggested: accumulating changes and sending them to the L:var in measured doses, limiting it to a speed it can cope with. It does really sound like something is getting corrupted by re-entry.

btw: the same commands worl with the PMDG J41 without problems.

Probably either faster code handling the L:vars, or they have coded it to be re-entrant . It can be done.

So I slightly come to the conclusion that sth must be hiccup inside the Catalina codes....

Yes, indeed, I agree that is where the problem lies. Of course you are trying to use it in a way they hadn't designed for.

Regards

Pete