Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Great news! Thank you. I was about to try to revive my cockpit and test it there, but one of the PC's I use (the one actually running ProSim737.exe) crashed before I went on holiday, and although I have a replacement for it that has not been set up yet. I hope to have it up and running over the weekend in any case. Can you post this news in the Prosim forum please (including, if you like, the stuff about Win10, just in case -- I only have Win7 PCs for my systems). FSUIPC5 is still progressing. 5.101j will be uploaded shortly with more fixes and facilities, but possibly none affecting ProSim. Pete
  2. Found it! One of the entries in a table of "event" types was missing. The only event types which would work correctly were those preceding the missing one -- Key, Button, Offset, and Control! I'm just checking a couple of other things then I'll upload FSUIPC 5.101j to the Download Links subforum. Have a look in about 30 minutes or so. Pete
  3. FSUIPC has nothing to do with sounds, unless you have some Lua plug-in or application which uses it for sounds. Check your add-ons and add-ins. Is this your first use of FSUIPC? Pete
  4. You misunderstand the options on that Tab, or you've not read the documentation. "Clear" does not delete the assignment in the INI. You can reload it using the "Reload" key. Clear just clears your input there so you can re-assign it. To delete a key assignment you need to use the right-hand side of that options tab. Do you not see where it says "Review or delete settings here" in the display box at the top, and you haven't noticed the "Delete this entry" button at the bottom? Pete
  5. Here I can make the PMDG 747 work flawlessly on my Win7 system -- provided I load itt as the first aircraft at the Scenario menu. And thereafter I can swap aircraft back and forth at will. If I load a different aircraft as the first aircraft and THEN load the PMDG 747, it gives me a black screen only and P3D4 hangs, needing a Task Manager "terminate process" to get rid of it. And this is exactly the same whether FSUIPC5 is being loaded or not! This does suggest a loading or initialisation problem in the 747 code. Incidentally, have you asked PMDG to create a Win7-targetted build to test with? If not, why not? Why only ask me? Pete
  6. Not sure why that is -- should be no different from doing that in FSUIPC4. The reading and writing are both done in separate threads, working into and out of cyclic buffers. Is the "com.test" on time but the "com.read" lagging, or doesn't the test respond on time. And lagging by how long? More than your 100 mSecs cycle? Have you tried 50Hz (20 mSec) instead? Okay. Thanks That narrows it down considerably I'll see if I can fake input to test it with. Pete
  7. Does it? Where do you see that? It isn't according to what PMDG are telling me. Pete
  8. Well, of course. Aren't you using com.write for writing? com.read is for reading. Logical? There's also a com.rreadlast. Check the La documents in your FSUIPC Documents folder. Where are the "handles" in the Logs you show me? I'd like to see them, from the start of the session, because something doesn't seem right. You said "my debug code logs do list the handle used. ". Pete
  9. So, does the 5 occur after 4 previous Open requests, do you think? The same handle sequence is also used for the EXT window handles. I don't suppose you use that Lua library as well do you? Pete
  10. And you get device nubers like 5 and 59? Really? They are sequentially assigned! That is perplexing. Are you perhaps terminating and restarting many times without ports being closed? What is the significance of "5 and 59". Are they two opened simultaneously? Perhpas your Lua code could log the handle being provided/ used? Pete
  11. But you are still on the original 5.10 release from over a week ago! Haven't you read any of the threads in this Forum? You should be using 5.101g which has all known joystick issues fixed. See the Download Links subforum. And please don't post pictures. They are completely unnecessary and I don't look at them anyway. Pete
  12. If it didn't recognise the name you'd get a LUA error reported in the Log. I know it is case sensitive, but I've added alternatives where they seemed obvious. They link to the same function, it's just a table entry. Pete
  13. What is the "device number"? Sorry, you've lost me there. Do you mean the handle returned? The first handle should be 1. they are allocated in turn as they are requested, from 1 to 1024, but when a port is closed it is free for reassignment. so if you do mean handles, i don't know how it can get to 5 let alone 59 (though 5 is feasible if you are trying to open several things). Yes, that puzzles me. As I said, read / write is perfectly symmetrical except for the data flow, and that's just a matter of which direction it travels to and from a buffer. I'll see if i can dig out some serial port COM device which I can connect via USB adapter. Then I can at least test the Comms side here. The VRI code uses that. Won't be till tomorrow though, now. I'm afraid I am nearly falling off my office chair through tiredness. I've barely slept these last two weeks (max 5 hours most nights -- not enough for a 74 year old! :-( ). Almost every day has been a long 12-15 hour stint. An hour of so off for dinner (I don't eat lunch). We had a power cut yesterday evening which gave me a bit of rest, but it only lasted an hour! I'm going to flake out now and fall asleep in front of the TV. ;-) Pete
  14. Yes, of course. There's 64-bit addressing for the Virtual Memory space for a 64 bit program! So, the available Virtual Address Space is 18,446,744,013,709,551,615 less whatever small part of that is currently being used!8What's the point of trying to provide you with such a huge number, even if it would fit? What would you do with it? Pete
  15. I'll check. It might depend upon some P3Dv4 functions I cannot use without hacking into the code. I'll see if they should be on the list for L-M implementation. [LATER] Yes, confirmed. not implemented (yet). No traffic settings read or written. This should have been on my "what's missing" list. I'll take another look when other pressure lessen a bit to see if there's anything easy to solve it. Pete
  16. But don't you get messages from it to confirm connection? Are no "reads" working? I don't see any in your Log. No calls to your event.VRIread function? Is there still a problem with that event function? (Mind you, I don't think the FSUIPC VRI logging is dependent on that). Looking at the code, the VRI read and write operations look to be perfectly symettrical. I can see no difference other than the direction of data travel. Pete
  17. I'll check. I think that's what "LINDA" translates into ... ... Yes. 5.101h on its way. BTW I programmed buttons to send increments and decrements of 32 to 0BC0, and it all worked as it should. So your problems are a puzzle. It sends axis events, "ELEVATOR_TRIM_SET", with the value as parameter. Maybe P3D4 has some occasional problems with that? The normal axis assigment you might assign to is "AXIS_ELEVATOR_TRIM_SET". It would be easy for me to change over -- the other one is more an historical remainder (originally the FS98 control). Do you want to try that or debug the issue further first? Pete
  18. Is that the one called just "LINDA"
  19. Yes, this is what I've now fixed. There was one place I missed replacing the handle index by the indexed handle itself. Sorry. Should be fine in 5.101h. Do you want that now, for testing, or shall I check writing low values to 0BC0 first? Pete
  20. For the VRi comms stuff, I found a couple of silly errors I missed in visual checking. I can provide an update for that for you to test, so don't do any more on that till I provide it. On the 0BC0 problem, can you suggest a way I can reproduce it here? I've checked FSUIPC's tables for these. NAV SOUND:1, NAV SOUND:2 and ADF SOUND are marked as being writeable! Maybe they aren't -- and, as you say, it was that way in FSUIPC4 too. (Offset 3122 includes those 3 and there they are marked as not writeable!!!) I'll fix it in FSUIPC5 in any case. I'm concerned about your 0BC0 problem. Pete
  21. BTW, this thread: seems to confirm that 0BC0 for Elev Trim works now? Pete
  22. Thanks. No problems, though? Pete
  23. I did say it was for testing. I can't test it here. Does that log show this somewhere? I see three exceptions: 272391 Exception 20 "DATA_ERROR", Ref 3143, Index param 1 on write SetData for "NAV SOUND:1" 272391 Exception 20 "DATA_ERROR", Ref 3144, Index param 1 on write SetData for "NAV SOUND:2" 272391 Exception 20 "DATA_ERROR", Ref 3145, Index param 1 on write SetData for "ADF SOUND" which I'll investigate. What offset(s) are you writing for those? I can't find any line with the VRIread error. What failure do you get? That log finishes with FSUIPC waiting for DLLStop to be called. Did it then terminate normally, hang, or did you abort? Not so much a lock up, no. By "locking up LINDA", do you mean P3D4 carries on okay? I didn't know the earlier version had any problem with Elev Trim (0xBC0). Did you mention that and I missed it? I can't find anything relevant in the log. It would help, when you supply a log, to provide a pointer to where anything relevant to what you are saying is logged. Mayve the elapsed trim value on the left, or a line number? In this case, as before, enabling "ipcWrite" logging in FSUIPC would have helped. That log finishes abruptly on the part where it has killed "init.lua". did P3D4 crash or hang there? Sorry, I've got nothing to work with here. Did the test you sent me before do anything with 0xBC0? Pete
  24. FSUIPC 5.101g is now released in the Download Links subforum. Pete
  25. FSUIPC 5.101g is now released in the Download Links subforum. 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.