budman9mm
-
Posts
20 -
Joined
-
Last visited
budman9mm's Achievements
Newbie (1/14)
0
Reputation
-
I like to hear that. I don't know why these files are so hard to find, so I hope we can keep them here when someone else inevitably runs into the same problem. Dustin
-
Although I no longer use LUA to interface with my cockpit modules, I still have it set up from when I did and it works. The only confusion I have is that I have a core.dll *size 102,912) in the Modules root and I have one in the Modules\lua\socket folder and they appear to be the same. Make sure you have this at the top of the lua file. local socket = require("socket") Also, I noticed that you have to have a socket.lua and a socket_core.dll that may actually be the 64 bit DLL(?). These go in the Modules root. socket_core.dll socket.lua
-
I think this is it. Let me know if it works. Dustin core.dll
-
I was finally get some real time to test this out and I am happy to report that after a few initial tests, sockets is now working! It's the first step that, the best I can recall, that I didn't do before. I think I was only overwriting the core.dll in the second step. So many thanks for getting this to work! -Dustin
-
I tried what Luis suggests early on into this thread. The require statement was the problem I ran into because Lua kept balking at everything I tried ( I cannot recall right now as to the exact error, I can try again if it will help). Luis, if you figured this out, I will be very happy! Intently awaiting your reply. -Dustin
-
Interesting work around. The main reason I change to using lua sockets in the first place was due to the fact that I was losing a lot of data using the USB serial ports with the com lib and connecting to my panels which are Arduino Megas. I suspect there are multiple reasons for this, but have you experienced any data loss and/or corruption with this method? Dustin
-
That's correct. It does not currently work from FSUIPC 5. It will work with some slight modifications within WideFS since it is 32 bit. Pete was unable to get sockets to compile correctly as 64 bit last I heard. Dustin
-
fsuipc FSUIPC + PMDG or others = How to Set???
budman9mm replied to Diogo Alencar's topic in FSUIPC Support Pete Dowson Modules
In addition to what Luke said, don't forget to activate the SDK broadcast in the 737NGX_Options.ini, per the instructions in the Offset Mapping for PMDG737NGX.pdf file in the FSUIPC Documents folder. I use P3Dv4 and every time I install a hot fix, etc. it rewrites the .ini file and I have to change it back. I map a button on the yoke to 70636 which is the A/P DISC on the sim yoke. I believe you should also set the parameter to 1. Good luck, Dustin -
This offset works as it should. I discovered that during the last update from PMDG, the SDK was reinstalled and overwrote the .ini and the SDK was disabled. I corrected that and all offsets are triggering with desired results. I think we can put this to bed. I see. That can't be easy to decipher. I don't know if the author, Diego can help from his gitHub. I don't want to force the issue down your throat more than I have. Thanks for giving this issue so much attention. I probably would have given up on it long ago without your help. Regards, Dustin
-
I have made some progress with the UDP issues and WideClient. First, without a doubt, the lua file of this size must be run as "initial.lua" and WC started before P3D in order to allocate enough memory (you mentioned this before, but I think it's absolutely required). Secondly, changing the event.timer that checks the UDP connection for received data to somewhere around 50msec AND adjusting my udp socket.bind timeout to something other than zero (2) appears to have fixed the connection refused problems. Best I can tell, with some limited testing, the UDP connections are working as they should, and quite well. No more LUA out of memory errors! A problem I am running into now is that all of my event.offsets are getting sent one time, at startup, as they should. However, after that, no further state changes are reported by WideClient as well as the STR type offsets are reported as nil by WC. I confirmed that "initial.lua" is still running. This may well be a PMDG issue. They have just released an update to the NGX on Tuesday, so I'm getting that now. Will test this out tomorrow hopefully. Thanks again, Dustin
-
EDIT: Pete, please see my next message first! Hello again, I misread the WideFS user guide where it mentioned this thinking it was an exception in the com library. Anyway, I tried varying the duration of the timer same with ipc.sleep as mentioned (see below) and it still goes through a few messages passed back and forth and ends up with the same out of memory errors. I agree. It should not make a difference. However, I tried using ipc.sleep(2) within a loop that then calls my function to receive the UDP and I get the same connection refused every iteration. I also tried varying the duration up from a few msec, to 50 msec, 100, etc. up to 2 full seconds...same result. I will continue to try and track this down using event.timer. Did you see my previous post regarding what is "supposed" to be just that (copied below)? I'm just asking because I was excited to see this, yet I have no idea what to make of whether it is applicable or not. I would be certainly willing to investigate incorporating it if you think it is worthwhile. Affirmative. I haven't given up yet though. I just haven't had time yet, but I am going to try and rebuild the code step by step. And thanks for the list. I have a printed "FSUIPC Lia Library Reference" that I have referenced at least a hundred times and it just did not register that it specifically says "[Not WideClient]". I don't know why I'm forgetting these details...*sigh* I regret wasting my efforts as well as yours. Thanks, Dustin
-
Pete, I'm sorry for missing this, but I was unaware until you said as much that some of the plug-in commands weren't available - I later see it in the User Guide. I was able to find a case of event.timer being used being used to check my UDP connection for receive data every 2msec. So I tried tried removing that and instead using a loop to execute my "receiveUDP()" function. It now does not give any Lua out of memory error, but it results in a UDP connection refused. With "event.timer" it was making connection with my Arduino nicely, but after a number of commands sent back and forth, it would start the memory issues. I may keep trying to chase this down for a bit. Maybe you have some idea as well. However, I'm just wondering if you think the sockets issue will ever be able to be compiled into FSUIPC5? I may just go back to working in the previous versions of software until that time. Thanks D
-
Yes. Mostly for troubleshooting so I can see values of variables. I have now commented out all of the ipc.lineDisplay and ipc.display commands. There was nothing in the log when I sent that except the windows event viewer. However, I tried a few more times and WideClient did terminate with a message to check the log. I attached it to this message along with the windows event viewer details. These are from after removing the ipc.display cmds. I did as you asked with tstsrver and tstclient and it ran without error and seems to be connecting just fine. I've attached the log for that anyway as well. I've started adding points in my code to log. It does seem that the memory errors start once I start receiving event offset triggers...somewhere. It's going to take some doing to find out just where. Thanks, D WideClient.log windows_event_view.txt testclnt.log
-
Thank you for explaining how the memory is allocated. To clarify, I ran the script as normal, not using WideClient ,but just FSUIPC4, it ran fine. So, I tried using WideClient in P3Dv3 and the script runs, although an error occurs in the FSUIPC console... ***ERROR C0000005 at 1AF27076 ExWriteStateData(Offset=9BFC, Size=4) *** Access violation trying to read address 000064C8 *** EAX 00000026 EBX 00000001 ECX 00000000 EDX 00000000 EDI 1 I have no offsets to 0x64C8. Even so, and without tracing down what is causing this, it is not a fatal error and the script continues to run. I'm not sure if it is relevant to the problem or not. Going back to P3Dv4...I attempted to run WideClient before running P3D and it (WideClient) crashes. I then execute WideClient again and it throws the out of memory error. I will try and do as you suggested about tracing it down with ipc.log statements next, but time is short right now as I expect you can understand. Dustin
-
I was able to get WideFS registered and configured to allow connections on the same PC. I have my lua script in the separate wideclient folder I created. Unfortunately it is giving me "6989 *** LUA Error: not enough memory" and just repeats trying with the same. I verified that it does execute properly in P3Dv3 still. It's roughly a 45kb file and growing. I guess since it's not running within the P3D thread that there is significantly less memory allocated? Any thoughts? This whole 64 bit thing we all wished for is starting to look fraught with caveats. Thanks, Dustin