Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Scotfleiger

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location
    Scotland, UK

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thank you for your careful consideration. We will have to disagree.
  2. OK. FSUIPC is looking for files in the installation location and nothing has changed. What was the FSUIPC5 installation location? Regardless, the effect is that FSUIPC6 is looking is a different relative location for these files and this risks causing confusion and adding unnecessary FSUIPC6 files to the add-ons directory. Can I respectfully suggest that the reference to the installation directory be changed to place all files inside with the /FSUIPC6 or /Modules folders? Andrew
  3. Sorry if it is confusing you but it has confused me and my users. I don't understand why the relative install location for .MCRO files has changed between FSUIPC5 (and earlier), namely the enclosing /Modules folder, and FSUIPC6. With the FSUIPC6 add-ons installation, the /FSUIPC6 folder equates directly to the old /Modules and should contain everything related to FSUIPC6 (.dll, .ini, ipcready.lua, etc, .MCRO files and LINDA). Moving the macro files reference to the "installation" directory is wrong. It has broken things.
  4. Hi John Thank you again. Moving the .MCRO to the add-ons directory alongside /FSUIPC6 works as before. With the new P3Dv5 file structure would it not be useful to place all .MCRO files within the /FSUIPC6 folder? This would keep them separate from the many other add-ons that will be installed. EDIT: In the past in the /modules structure the .MCRO were located inside the /modules. This seems to have changed with FSUIPC6.
  5. With FSUIPC6 installed in P3D v5 Addons for P3Dv4 and P3Dv5, a previously working .MCRO installed in /FSUIPC6 is not longer responding the LUA ipc.macro instruction (eg. ipc.macro("FSLTEST2: BAT1)) for aircraft running in P3Dv4.5 (ie. FSLabs A320). I re-recorded some key mouse macros and they proved identical to those I am using. I then ran P3Dv5 and set up a new mouse macro and referenced it using the LUA ipc.macro instruction. This failed to work. FSUIPC6.log contains no data relevant to this problem. I am using FSUIPC 6.0.8 with LINDA 3.2.x. The problem did not exist in FSUIPC5 or FSUIPC4.
  6. FSUIPC6 uninstalled and reinstalled into /modules as suggested. It works fine by redirecting the p3dv5 add-ons/add-ons.xml to /modules/fsuipc6.dll. The dll.xml is unchanged/unused. Many thanks again.
  7. With the alternative P3Dv5 / FSUIPC6 installation using the traditional /Modules with P3Dv5, what is the correct DLL.XML entry? I have been trying the following copied from P3Dv4 but FSUIPC6 is not starting: fsuipcp3d<?xml version="1.0" encoding="UTF-8"?> <SimBase.Document Type="AceXML" version="3,0" id="dll"> <Descr>AceXML Document</Descr> <Filename>dll.xml</Filename> <Launch.Addon> <Name>FSUIPC 6</Name> <Disabled>False</Disabled> <manualload>false</manualload> <Path>C:\P3Dv5\Modules\FSUIPC6.dll</Path> </Launch.Addon> </SimBase.Document> The reason for asking is that I am trying to set up the alternative installation for user support testing.
  8. Hi John Following extensive testing I have established that the contents of 0x3E00 (Flt Sim Path) and 0x3124 (Flt Sim Version) depend on when it is read. LINDA was reading these values on start up whether or not P3D was running. If read with a running P3D the values are correct. Thank you again for your help.
  9. My error I was looking at the wrong offset (3C00 not 3E00). The .dll works on my system. I will pass it on to my user to test. FSUIPC6.log
  10. Further information. With P3Dv4 0x3C00 also appears to point to the current AIR FILE for the loaded aircraft and not the Flt Sim path.
  11. One of my LINDA users has installed FSUIPC 6.0.7 with P3Dv4.5 using the c:/users/{name}/prepar3d v4 add-ons/FSUIPC6 option. He does not have P3Dv5 installed. LINDA reads offsets 0x3E00 to read the path to the Flt Sim and 0x3124 to read the Flt Sim version number (eg 45). On his system the former lists the add-on path to FSUIPC6 and the latter is blank. On my system running P3Dv5 the Flt Sim path and version are read correctly from the offsets. With P3Dv4.5 the results are intermittent sometimes the offsets are populated correctly and are blank at other times. Can you check this from your end?
  12. The hanging background task is what started this whole conversation. It is labelled 'Prepar3d...' of size 560KB. The process of elimination you suggested identified that it was the VRI device that was stopping FSUIPC6 terminating. I say it is stopping FSUIPC6 terminating as the fusipc6.log cannot have its name changed until this task ends. LINDA is long terminated by this time - at the 25-30s point with 6.0.3g. The only VRI driver is the COMPORT FDTI device driver. No other VRI software is running or used. I take back what said. It was not a failure. LINDA consists of 2 parts - GUI and LUA. The GUI LINDA.EXE is the on-screen interface for assigning functions to buttons and interfaces with FSUIPC. It can be started manually (before P3D) or via the FSUIPC [programs] block. The LUA code is triggered by FSUIPC running ipcReady.lua that calls linda.lua which in turn calls init.lua for loading all other LINDA code. This code can operate without the GUI. When I say 'manually close' LINDA it is me clicking on the red quit icon (top right) to close the application. I will need to double check but I believe the LUA code is left loaded and running when the GUI terminates. I will take a look at the GUI code to see what can be done. Andrew
  13. Hi Pete I am sorry to report that 6.0.3h is a failure. On exiting P3D the auto start program LINDA displayed 'Not responding' and nothing closed even after over 2 minutes. This was both with and without logging. 6.0.3h is only killing one of the 2 LINDA LUA thread (init.lua). The other (linda.lua) is not reported. See previous logs. Further to my earlier statement, LINDA closes and ends in task in less than a second when manually closed. Andrew FSUIPC6-603h-NoLog.log FSUIPC6-603h-YesLog.log
  14. Hi Pete I agree the delays times are a little excessive if you are closing and wanting to reopen P3D. Typically the shutdown took 30+ seconds to complete so I am not complaining as I and users need a full shutdown without manually checking the Task Manager. I started my stopwatch when I clicked on the Yes button on the exit P3D dialog. It was 25-30s to FSUIPC closing the external apps (eg. LINDA), sending the CMDRST and updating fsuipc6.ini. These events all happened within a second. When FSUIPC closes LINDA it displays ‘not responding’ for several seconds, waits for several more seconds and then closes. When I close LINDA manually it takes less than 5s. It was a further 25-30s before the ‘hanging’ P3D background task (or stub as I called it) closed. At this point the fsuipc6.log was released and could be renamed. The total time to close everything was under 60s (30+30). I only have 2 comms ports defined COM3 and COM4 for the 2 different VRi Combos I use for testing. I will run tests on the new dll later. Andrew
  15. That sounds good. I suggest a comment be added to the release notes about leaving 60s to close down. Andrew
  • 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.