Jump to content
The simFlight Network Forums
Scotfleiger

FSUIPC5 - LINDA Interface Changes

Recommended Posts

LauKill commands are sent to FSUIPC for the 2 running LINDA LUA processes when the user forces a restart. I am not sure what happens when ipcReady.lua restarts the LINDA LUA processes by calling LINDA.LUA which in turn loads INIT.LUA.

Share this post


Link to post
Share on other sites

Hi Pete

I took your comments on using com.close with the handle for the VRI MCP panel (5 as allocated originally). It would appear that if it is closed then the same handle will be reused for the VRI device on restarting. With this the event.vriread(handle) is correctly assigned and working. The various HID com handles still increase as I have not disposed of them.

The above situation will not occur when the ipcReady is called to restart the LUA code without any killLUA calls. Therefore, the handles still need to managed within FSUIPC5. 

FSUIPC5.log

Share this post


Link to post
Share on other sites
1 hour ago, Scotfleiger said:

I am not sure what happens when ipcReady.lua restarts the LINDA LUA processes by calling LINDA.LUA which in turn loads INIT.LUA.

FSUIPC automatically kills any threads still running when asked to restart them (i.e. load them again).

I'll upload a 5.101p version with some fixes to test shortly.

Pete

 

Share this post


Link to post
Share on other sites
1 minute ago, Scotfleiger said:

It would appear that if it is closed then the same handle will be reused for the VRI device on restarting. With this the event.vriread(handle) is correctly assigned and working.

Yes, as I surmised. I will fix this in any case -- for the same "real" handle the same "local" handle should be assigned.

That will be fix #1.

Fix #2 will be to stop those attempts to provide local handles for real handles with are invalid, like 0.

And Fix #3, which may not be so easy, will be to work out how to free the local handle automatically when the COM device is closed by enforced killing of a thread.

Pete

 

Share this post


Link to post
Share on other sites
2 minutes ago, Scotfleiger said:

Good news and thanks for all the effort you are putting in. I'm afraid I must finish for today.

Me too, soon. If I can't do all three "fixes" I mentioned I will continue in the morning. But I would dearly love to get this sorted soon, then, because I feel I need to release a full Install package before I go away for a week.

So many of the support responses Thomas and I have to attend to here are due simply to folks not knowing there are interim releases which already fix their issues.

Pete

 

Share this post


Link to post
Share on other sites

Morning Pete

The management of the VRI handle is fixed in 5.101p. After multiple restart of the 'original' LUA code the same handle (5) is assigned by the com.open() and used by event.vriread(). LINDA retains full control of the VRI MCP panel.

FSUIPC5.log - original LUA code - same handle used.

When I repeat the test with the 'modified' LUA code which closes the VRI handle before restarting with com.close() (see line [COMM] Closing VRI port Dev=), FSUIPC5 allocates a new handle to the VRI device. LINDA correctly uses the new handle and LINDA retains full control of the VRI MCP panel.

FSUIPC5.log - with VRI com closed before restart

The same behaviour occurs in both cases with the HID device handles. New handles are assigned to each device on restart leading to the long list of handles. This does not affect LINDA operations. My code in both cases does not attend to close the HID com handles. Should I will look further at closing the HID handles on my side?

Thank you for burning the late night candle.

 

Share this post


Link to post
Share on other sites
1 hour ago, Scotfleiger said:

Should I will look further at closing the HID handles on my side?

It would be tidier, but there's no need to go right out of your way. I have a limit of 1023 handles in a table shared by COM (com, vri, hid) and windows (ext), for all loaded threads. Provided your setup is unlikely to get anywhere near filling (leaves some for others!) then it should be fine.

Incidentally, I don't suppose this error matters, does it?

*** LUA Error: C:\P3Dv4\modules\linda/system/events.lua:460: attempt to index global 'JH' (a nil value)

It is occurring at every LINDA start.

I'll be releasing the full Install 5.102 this afternoon.

Thanks,
Pete

 

Share this post


Link to post
Share on other sites

I am hitting problems trying to close the HID handles. P3Dv4 is locking up. This is probably down to the different way 5.101p now manages the VRI and HID handles.

The 1023 handles limit is only ever a problem for us developers who need to restart regularly to test new LUA code. So it is not a problem.

The LUA error is my coding error and can be ignored.

I am happy for 5.102 to be released.

Edited by Scotfleiger
Rewording

Share this post


Link to post
Share on other sites
31 minutes ago, Scotfleiger said:

I am hitting problems trying to close the HID handles. P3Dv4 is locking up. This is probably down to the different way 5.101p now manages the VRI and HID handles.

How are you trying to close them? It should be just the usual com.close, the same as you use for your VRi devices.

If could could supply a short plug-in which demnstrates this, please, I'd like not to have it outstanding in a full User Release if possible. I at least have plenty of "Hid" devices, I can patch such a plug in with different VID and PID values.

If it isn't so easy for you I can see if I can adapt one of my Lua examples. I think there's a one which Logs HID stuff.

Pete

Share this post


Link to post
Share on other sites

Pete

I have decided not to attempt to close any device (VRI/HID) using com.close. I will leave it FSUIPC5 to manage. It works for LINDA.

I do not have time this week to do any more work as I am far, far behind with my other work. Do not let me stop you formally releasing 1.102.

Andrew

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • 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.