Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
 View Profile  See their activity

  • Posts

    38,265

  • Joined

  • Days Won

    170

 Content Type 

Everything posted by Pete Dowson

  1. Pete Dowson
    Referring to the above, from your first meassage, I note there's a gap of 235 mSecs between the Kill and the Error. I've searched the complete source of both FSUIPC itself and the built-in Lua code. There is no errors message starting "cannot open" except in the LFS (file system) library where the code it is in is actually not included unless the system is not a "WIN32" one -- which all Windows systems are these days (even if supporting 64 bit too -- even all the 64 bit Windows API DLLs have "32" in the names. In any case the format of the non-included "cannot open" message is "cannot open <path>: <windows reported error for the error number>", so not like the one you are seeing. Might Linda be invoking external Lua interpretation somewhere? I see two DLLs in the Linda\Lua subfolder -- lus5.1.dll and lua51.dll. Could they be involved? Since I seem unable to track down where to put any specific logging I don't think i can proceed to help without being able to reproduce it. Pete
  2. Pete Dowson
    Same as the FSUIPC Console log then. I must have done between 10 and 20 restarts, everyone the same, no error reported. Where is "Ready to go" displayed? I wasn't watching the P3D screen. Should I have been? Do I have to wait a while after each restart? I searched the FSUIPC4 log after closing P3D. The only error, in one of the restarts, was this: 224345 *** LUA Error: E:\Prepar3D v4\Modules\linda/system/init.lua:118: module '0lib-aivlasoft' not found: Odd that it occurred just the once. I've just counted the occurences of "beginning "E:\Prepar3D v4\Modules\linda/system/init.lua"" -- 15 restarts, with just that one error above. Sorry, but I need to reproduce it to find it. Can you log the actual "argument" being used for each Open, Load or Run request? Or shall I try and locate the place within the Lua where the Open error is being diagnosed, and log the reason in more detail there? Pete
  3. Pete Dowson
    You can only register WideFS (in the FSUIPC Installer) using one license. The license is for the SERVER, not the CLIENT. You can have as many client PCs (running WideClient) as you want. There is a limit, but it's quite high. I have up to 12 at any time with my cockpit set up. Pete
  4. Pete Dowson
    Questions about this. I've installed LINDA 3.0.0 (did it not happen with the earlier one you gave me?): Why do I need to see a red highlighted line in the LINDA console? You said the error is an FSUIPC reported one so it should appear in the FSUIPC log, shouldn't it? Do I have to do the restart many times to generate the error? Pete
  5. Pete Dowson
    Found the problem. A 32-bit pointer in a structure expanding to 64-bit (of course). Missed it, sorry. It will be fixed in interim update 5.103b (or later). Check the Download Links subforum over the next couple of days. Pete
  6. Pete Dowson
    As an aside with this, I've just turning on Content Error reporting, and i get 999 entries! I susepct it would be a lot more if it counted any higher. These include one caused by FSDT's AddonManager, a couple of XML sysntax errors in LM's own "DISConfiguration.xml" file, errors loading DLLs from the default P3D ProgramData folder (TargetInfo.dll, Fsury_1500.dll), one about the RAASPRO.DLL installed by the P3D4 version of PMDG's 747 being 32-bit not 64-bit, and the other many hindreds complaining about MyTraffic6 aircraft CFG files with "Duplicate Key Names". Pete
  7. Pete Dowson
    What are the symptoms? Have you reported these to PMDG? Did you uninstall the original completely before installing the updated 747? Pete
  8. Pete Dowson
    Probably because only FSUIPC is querying Payloads so its offsets are correctly populated for applications to access -- as it has done, using the correct SIMCONNECT requests, and code unchanged, since 2005. It is easy to blame FSUIPC. I get used to it (though it is really depressing). But in this case it should be obvious that it is down to something changed in the P3D HotFix. I have added appropriate comments to the thread you referenced. Pete
  9. Pete Dowson
    See earlier posts in this thread. It's the same thing, as you must have seen else why add to it. but then why repeat it almost word for word. I explained why it probably only happens with FSUIPC -- the payload stations are always read, via SimConnect, by FSUIPC. What is the problem facing you in any case? The content errors are advisory. They don't cause a problem. There are often hundreds of them with some add-ons. Just turn the reporting off if it worries you. It's an option mainly intended to help content add-on providers to debug their products. It has to be an error in P3d related to the HotFix. "Content errors" are just that, errors in the content, not errors in an application. I see it isn't only marked as "RESOLVED" but the thread has been locked too, with no sign of anyone in L-M contributing one word. I find that odd and rather irritating and I've written to them about it. Pete
  10. Pete Dowson
    I was going to ask how that arises. I thought \ was used in paths whilst / is used in URLs. Though it shouldn't work some times and not others either way. Seems odd -- someting more complex than it appears on the surface then. I'll try and fit it in tomorrow. Pete
  11. Pete Dowson
    Well, the code is still there, and it is unrelated to to the conversion to 64-bit, so whilst i've not specifically tested it (it is pretty impossible to test everything every time), yes, it should be fine. Let me know if it isn't. Pete
  12. Pete Dowson
    Maybe. Sorry, I don't know. Generally there can be lots of "content errors" logged. You can worry about then, report them, or ... just switch them off. Pete
  13. Pete Dowson
    I've searched the complete source, and the only "Invalid Argument" error using built-in messages only occurs with WideServer, and Windows socket errors. The latter from the original Lua code. The *** ERROR message is produced by FSUIPC when it receives an error from the Lua code, and the part of the message which explains the error is actually supplied by Lua -- I think it might get the bfull error data from Windows, which has a function to do that given the error number. For "runlua" the *** ERROR can only occur when it calls Lua code to "loadfile", and the only parameter is the path. So something seems to go wrong with the path occasinally on repeats. The full path os made up of the FSUIPC path (i.e. the Modules folder, plus what you add to it. I can log that, but it seems to me that it would be far more productive if I could reproduce the error here so I could track to down to te actual error within the Lua code (i.e. the code that isn't actually mine). So, do you think you can provide anything? Pete
  14. Pete Dowson
    Are you assigning in FSUIPC? If so, what versions of FSUIPC are you using in each? The currently supported versions are 4.969 and 5.103. Pete
  15. Pete Dowson
    It shouldn't happen with 4.969 unless it DOES identify itself as a joystick type device. So I can see what is going on please add these lines to the General section of the FSUIPC ini file and show me the Log file and the CSV file. Debug=Please Logextras=x200000 Pete
  16. Pete Dowson
    FSUIPC may be the only thing causing P3D to access that section of the Aircraft CFG. As it didn't happen before the hotfix is might well be an L-M problem. Report it to them. And without FSUIPC loaded, see if accessing the payloads menu in P3D causes them. Pete
  17. Pete Dowson
    Ok Can you create a small Lua which recreates the symptom? Lua files aren't kept open, so access whilst the previous incarnation is active can't be the cause. When I get back I'll see what can give rise to that error, and add more logging if necessary. "Invalid parameter " doesn't mean any sort of file access problem unless the path is crazy -- i.e. not even recognisable as a path. I'll leave further responses till I get back -- it isn't easy for me on a phone! Pete
  18. Pete Dowson
    Seems like on of your aircraft has a bad payload definition section. Did you update FSUIPC to 5.103, the version for the HOTFIX? Pete
  19. Pete Dowson
    I'm out this afternoon, so this is from my iPhone. I'll be brief. You said it occurs with 4.964 too. So it must have been happening for many weeks. Or have you changed something to bring it on? It looks odd having that Error line with no Lua line number. Is the report from FSUIPC or your code? Pete
  20. Pete Dowson
    Whether a Lua thread is running or not shouldn't prevent RunLua finding the file. Or are you saying it gets loaded then killed? Why are you killing it before RunLua in any case? Running the same Lua again automatically kills the previous edition. You should leave it all to FSUIPC. There's no relation in the timing between the KillLua in one thread and any other threads or "RunLua" action. You cannot predict the order with separate threads -- it depends on Windows threading, loading, processor usage, hyperthreading, etc. Nothing in any of that. In any case you mention 4.964 from long ago. BTW 4.968 is superseded by 4.969. Pete
  21. Pete Dowson
    Good news. It should work in P3D4 as well then. Pete
  22. Pete Dowson
    First off, that is the very original version ofr P3D4 and it has been superseded over three times already. If you want support you MUST check that you are using the latest version first! The currently supported version is 5.103. Please also update your P3D4. The Hotfix for lots of problems, including with SimConnect, was released yesterday. What is the point of that, then, even if I could support an old version? You need the log up to and including the "freeze"! Pete
  23. Pete Dowson
    That shows you are using FSUIPC 4.966c, which I cannot support. The currently supported version is 4.969. Pete
  24. Pete Dowson
    Blimey! You shoud have said up front! Remember I said "The 64-bit solution for external 64-bit programs interfacing to FSUIPC5 is now available"? It is even quoted in an earlier message in this thread! Note the FSUIPC5. Sorry, there will never be 64-bit interface into FSUIPC3. I am no longer in any position to make changes to that 14 year old version! I am amazed anyone is still developing anything for it. It seems to make no sense at all when the latest versions are so good. I may not even develop a 64-bit interface for FSUIPC4, though I could do one there relatively easily if someone asks. Really my 64-bit development was only intended for 64-bit simulators. For FS9 you'll need to adapt the source of the LIB Read and Process functions to avoid using the 32-bit pointer as a pointer -- maybe some 32-bit index into your own data repository, or a 64-bit pointer converted into a 32-bit offset from the base of your code. The pointer itself is never used as such in FSUIPC, so you can adapt it to do whatever you want. Pete
  25. Pete Dowson
    Strange. It works fine here. Which version of FSUIPC are you using? It should be 5.103 now, but the 64-bit client features were added in version 5.102, at the same time as the 64-bit SDK release. Always check you are up to date with FSUIPC! Assuming you are now using the supported version of FSUIPC5, yes. Check the data format built up for the request being sent by the SendMessgeTimeout. i.e. the data in the buffer allocated as the shared memory-mapped file. It's the same as for 32-bit except the Read header has a different ID and the pointer to where the Read function will deposit the data is, of course, 64-bit instead of 32. Pete
×
×
  • 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.