Scotfleiger
-
Posts
392 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by Scotfleiger
-
Please stop. Obviously, my ability to communicate in English in failing. Please let me run the tests here when I get a moment. Please stop trying until I have time to think. I will get back to you when I have something more concrete. I should not be expecting you to learn a new utility remotely.
-
You are correct. As I said above, in LINDA Setup, select Developer Mode and use dropdown to Verbose and tick LUA checkbox. This repeats the lower pane option in Console and stop you getting the warning message you are seeing. I have the test FSUIPC5 and will report back later.
-
I can understand your frustration with users. With the Console open, you need to click on the 3 down arrows to open a lower pane. Here you will find the logging options.
-
Sorry. You need to open the LINDA Console and select Verbose logging (dropbox at bottom) to see the level of LINDA logging you mention. Alternatively, goto LINDA setup and tick Developer Mode to do the same.
-
Sorry for the conclusion. When I have been talking about LINDA restart, I mean the LUA restarting only. This is to load the modules for different aircraft, changes in device assignments/configuration, to overcome other issues or, in my case, to reload edited code for testing purposes. Most users do not need to restart unless they hit a problem. Send to linda@awginfosys.net please.
-
There are 2 elements to LINDA. The GUI (LINDA.EXE) which is started manually or via the entry in [Programs] block of FSUIPCx.ini. GUI actions can be carried out with the flight sim running. The LAU element is triggered by the ipcReady.lua file which calls \modules\linda.lua which in turn runs \modules\linda\system\init.lua. A restart is also triggered on load a new aircraft or scenario. Sorry for the confusion. The LUAxx.dll are used by the LINDA Editor only. The 2 files is how I inherited the code - I leave it well alone. Thank you for your efforts. Please don't waste any further effort. I can handle the issue by forcing a second restart if I detect the invalid argument error.
-
Hi Pete Interesting as Guenseli has also reported the problem. Do you have a Flt Sim running? This is needed to 'load' the restart process. The pathname listed immediately below 'Aircraft module detected:' and 'Calling Initialisation...' contains the argument ("Path =linda/system/init") used in RunLua(path). The error seen (module not found) is a corrupted read of a file name. I will look at that.
-
The problem affects both versions you have. The latest beta build is the one I am working with. The LINDA Console (Verbose logging) is a repeat of what is logged in FSUIPCx.log but is displayed in real time so you can see the error after a restart (CTRL+ALT+R). Every second or third restart should highlight the error. The subsequent restart should run ok (through to "Ready to go, Captain").
-
Hi Pete I have produced a stripped out version of the key .lua code (linda.lua and init.lua) which will enter a repeating loop when ipcReady.lua is called on FSX start. Copy files and folders into \modules directory. I have had it running for some time and, unfortunately, it is not producing the invalid argument error. I will dig deeper. I was wondering whether the mix of forward and backward slashes in the file address has something to do with it. I can only suggest that you try the full LINDA 3.0.0 with the Console open. The LUA Engine can be restarted by the hotkey (CTRL+ALT+R) as required. If you see the error as a red highlighted line. LuaRunTest.zip
-
I get back to you later with a smaller test.
-
The logs are from fsuipc4. Nothing in the LINDA code has changed (except the removal of the luakill commands you advised). It has been occurring while I was working on getting LINDA working with FSUIPC5 when I was performing multiple LUA restarts (from my GUI) as I tested. However, when I returned to my development system (with 4.964) I could see it happening and was able to isolate the cause to the runlua() command. I also installed 4.969 on the development system and am running 5.103. It is occurring in all cases.
-
Hi Pete Thank you for your prompt reply. I have removed the LuaKill calls as you recommend but I am still getting the Invalid Argument LUA error when calling RunLua(). It does not happen every time I restart the LUA threads (linda.lua and init.lua) but 1 in 2 or 1 in 3 times. Tests run with 4.969. FSUIPC4.log-KillLuaRemoved.txt
-
Hi Pete I have started to see a repeating LUA Error Invalid Argument when running LINDA LUA code to start a second module using the LUA function ipc.runlua(path) (where path is \linda\system\init). 944344 LUA.1: LINDA:: [START] Path = linda/system/init 944625 LUA: "C:\FSX\Modules\linda/system/init.lua": killed 944860 *** LUA Error: cannot open : Invalid argument 1001125 LUA: "linda.lua": killed 1001125 LUA.0: [START] *********************** STARTING LINDA *********************** This could come down to sequencing where the ipc.runlua() is being caused before FSUIPC has actioned the LauKill() function although the kill command is passed before the run command. It appears that the kill command is being delayed. The LuaKill is called from the LINDA GUI followed by a RunLua(linda). Linda.lua calls the following (executed via the GUI) to FSUIPC: path = ipc.get("PATH_SYS") .. "init" where PATH_SYS = linda/system/ if file_exists(path .. '.lua') then ipc.runlua(path) else _log('[START] Unable to find INIT.LUA - Try Restarting') end When the restart is run a second time init.lua is dead and there is no error. We are seeing with 4.964, 4.968 and 5.103. Has anything change in recently? What delay should be built in to ensure the first command is completed before the second is sent? We have not seen this problem until the last month or so. It is only now that I have pinned down the cause. FSUIPC4.log-Invalid Argment.txt FSUIPC4 .log-Invalid Argument2
-
FSUIPC4 SDK on LAZARUS platform
Scotfleiger replied to Lubor's topic in FSUIPC Support Pete Dowson Modules
I do not know LAZARUS. We use the SDK for LINDA using Pascal with the Delphi XE6 IDE. This includes the 2 .pas files and 2 .inc (include) files. I have recently revisited the code to ensure LINDA would work with FSUIPC5. No Changes were required. I have used Pascal for years and is by far my preferred programming language. -
That's great. Thank you Pete.
-
I do mean *** EVENT entries. A LogExtras/TestOptions bit would be most welcome for our purposes please. I can see the logic of removing any confusing log information for the normal user.
-
Thanks for the prompt reply. FSLabs appear to be using the 196880 and 196881 controls for their 'flat' buttons in the A320X virtual cockpit. Operating the mouse over these buttons (left/right and wheel) returns these control values and various params depending on the button state. The same technique can be used for 'normal' switches, buttons and knobs but these return values for control 66587. At present I would not like to see the higher values being filtered out until I work out what is happening. FSLabs has a big problem with their Enigma anti-piracy software if it detects any alternation to its memory. So far using pic.control(196881,xxxx) has not caused this problem. At present, FSUIPC4 is reporting the control EVENTS for 196880 and 196881 so I can see what is happening. Hopefully, soon FSLabs will be releasing a SDK to allow me to circumvent this detective exercise.
-
Hi Pete I am analysing the Control values used by FSLabs A320X to operate various switches for LINDA. For most they use FSX Control ROTOR_BRAKE (66587) but for others they use control 196881. I am using the LUA function ipc.control(value, param) to send commands into the simulator. The value of 66587 (ROTOR_BRAKE) is no problem but I am not sure that control values outside the normal range (e.g. 196881) are transmitted. Under FSUIPC Options and Settings users can set a custom control value from 65536 to 131070 (x10000 to x1FFFE). Does this upper limit apply to the LUA ipc.control(value, param)? I need to send params in the range 0x00010000 to 0x00FF0000. When I do send the control ipc.control(196881, xxxxxxx), I see in fsuipc4.log the line "FS Control Sent: Ctrl=196881. param:xxxxxxx" which suggests the control is sent but I am not seeing the expected effect. Any comments would be welcome. I am currently, using FSUIPC4 4.968 and P3Dv3.4 but the question equally applies to FSUIPC5.
-
FSUIPC4 and FSUIPC5 are different products. You will need to purchase a new key for FSUIPC5 64-bit.
-
FSUIPC5 documentation
Scotfleiger replied to herve_sors's topic in FSUIPC Support Pete Dowson Modules
Correct. FSUIPC5 has to be installed to access the documentation in the modules folder. None other is available. -
FSUIPC5 documentation
Scotfleiger replied to herve_sors's topic in FSUIPC Support Pete Dowson Modules
The current available functions in FSUIPC5 5.102 can be found in the downloaded zip file. Otherwise, the existing FSUIPC4 documents in modules folder are still valid in most cases for FSUIPC5. -
I did managed to compile the SDK pascal functions but it was necessary to change some of the fixed value to system variables. It was in other areas on my code (not the SDK) that I could not get to compile in 64-bit and my knowledge was stretched to the limit.
-
If you are using the FSUIPC functions in the SDK to interface with FSUIPC5 (fsuipc_open, _read, _write, etc) then you may be able to use your 32-bit code. On Pete's advise I was able to update LINDA for 32- and 64-bit use using a 32-bit compilation. The FSUIPC5 interface read/write types remain unchanged.
-
Can I suggest you read the many threads on multiple throttles before starting a new one? You should find your question has already answered. Are you using the latest formal release 5.102? This addresses the problem.
-
Fixed thank you