Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Content Count

    35,880
  • Joined

  • Last visited

  • Days Won

    122

Pete Dowson last won the day on February 23

Pete Dowson had the most liked content!

Community Reputation

229 Excellent

About Pete Dowson

  • Rank
    Advanced Member
  • Birthday 08/27/1943

Contact Methods

  • Website URL
    http://

Profile Information

  • Gender
    Male
  • Location
    Near Stoke-on-Trent, UK
  • Interests
    Flight Simming, Steam Railways, Travelling, Real / Craft Ale,, worldwide

Recent Profile Visitors

33,737 profile views
  1. P3D and FSUIPC detect both axes and button presses in slightly different ways. But P3D actually has two ways -- you can select between Raw and DirectX (I think they are labelled like that, or similar). Take a look. Try the other. But I must ask. If you can detect them in FSUIPC why not just assign them there? There's a much wider choice in FSUIPC, and you can have different assignments for different aircraft types, using Profiles. Pete
  2. Okay. I won't see it till tomorrow. Late here -- off to bed now. ;-0 Pete
  3. All this is not really relevant to FSUIPC. As a purchaser of an FSUIPC license you are entitled to use it on as many PCs of yours for your private use as you like. There is no restriction to a single PC! My point was merely that WideFS cannot link to another PC which is also running a version of FS, any version. Pete
  4. Have you set the server IP address or server name, and the protocol to be used, in the WideCliernt.INI file for each client. That is always the first thing to do in such cases, as discussed in the WideFS user guide. Don't rely on Broadcasts. Are all your PCs in the same workgroup? If not, broadcasts won't work. Change the workgroup names to match. (I'm pretty sure this is also in the user guide). WideFS doesn't link two PCs both running FSX. I thought the old PC wasn't going to be used with FSUIPC in any case? Pete
  5. Rain all day most days. Occasional breaks and glimpses of sun. Warmer today -- predicted to go right up to 10C this afternoon! But some days it doesn't get higher than 5C. Better than a couple of weeks ago though. It was cold when you wore shorts last time, so I expect you will this time as well.😉 Not as far as I know. But if merely adding some log lines has changed it, this points to some nasty obscure timing problem. Which would probably also explain why others don't have the same problem. It may be related to the attempted closing of the socket listeners of WideServer and those of ASP4 DLL at more or less the same time. One test we didn't do, but too late for now till you return, is whether it happens when WideServer actually has a connection to deal with. After all, when the ASP4 server has a connection you don't get the problem. The solution in WideServer then may be simply not to delay closing in order to send shutdown messages to connected clients which don't exist. It can simply close down immediately it is notified. Pete
  6. If you mean using SPAD to drive Saitek panels, then you really want SPAD support. SPAD is not one of our products, and I know nothing about it. John may know more however. I'm sure he'll respond within the next days if he does. Pete
  7. Hmm. I'll read about it, but I thought that must mean installing some part of VS on the subject PC. See you Tuesday at EGCC. Cheers Pete
  8. I replaced my later version of the P3D client with the 4.5.13.32097 version, and this time the ASP4 module as_connect_64 produced a full log (btstrp.txt), matching yours ... but at the end of the session P3D closed perfectly. So, unfortunately, I cannot reproduce your problem. There must be something else going on. I wonder if it may be something to do with a Win10 update. I am of course using Win7 on this testing & development PC. Tomorrow I may test it on my VFR PC, which is running the very latest, fully updated, Win10, plus P3D 4.5.13 Academic (the Pro version is on my cockpit PC). However, on that PC I don't have any debugging tools installed, and don't really want them on either of my cockpit PCs. Pete
  9. I suspect that you can only get this information by reading the CDU text and trying to interpret that -- but the information would have to be displayed on one of the CDUs in order for you to receive it. There are offsets dedicated to receive the text displayed on the CDUs (if enabled). See the Offset Mapping for PMDG 737NGX pdf in your FSUIPC Documents subfolder. It would be very messy. This data is really provided for you to replicate the CDU display on an external hardware CDU, not for interpreting by program. But it isn't impossible, just messy. Pete
  10. Thanks. If you look at the [JoyNames] section you will see 4 labels "missing joystick", devices A, B, C, D. And the samed named joysticks have been added as E, F, G and H. This is because, as expected, the GUIDs have changed -- Windows has generated new ones. So all that was needed was to rename the E F G and H lines as A, B, C and D, to correspond to their original labels. I've done this for you. Just replace the entire [Joynames] section with the one below. [JoyNames] AutoAssignLetters=Yes 0=CH PRO PEDALS USB 0.GUID={115B0EA0-557B-11EA-8003-444553540000} 1=CH ECLIPSE YOKE 1.GUID={115B0EA0-557B-11EA-8001-444553540000} 2=T.16000M 2.GUID={115B0EA0-557B-11EA-8005-444553540000} 3=TWCS Throttle 3.GUID={115B0EA0-557B-11EA-8002-444553540000} A=CH PRO PEDALS USB A.GUID={115B0EA0-557B-11EA-8003-444553540000} B=CH ECLIPSE YOKE B.GUID={115B0EA0-557B-11EA-8001-444553540000} C=T.16000M C.GUID={115B0EA0-557B-11EA-8005-444553540000} D=TWCS Throttle D.GUID={115B0EA0-557B-11EA-8002-444553540000} Then all of your existing assignments should work as before. Test it all, and only then remove FSUIPC etc on your old PC. Now you'll know what to do next time! 😉 Pete
  11. Same here. And as you know, I don't have an operational "main FS PC" at present. Also, my debugging tools (VS etc) are only on my development PC, so I put the Beta there -- except for those which must have Win10, in which case they are currently on my VFR PC (55" 4K screen). Pete
  12. No, leave it be for now. Register FSUIPC on the new PC then run FSX once. Close it down then copy the old PC's INI file over to the FSX Modules folder in the new PC, replacing the one which is there. Then run FSX again on the new PC, then close it down, and paste the FSUIPC4.LOG and FSUIPC4.INI files here so I can see how to edit your new JoyNames section. Only then delete the Modules folder on the old PC. There's nothing else to do on the PC. Pete
  13. That looks like the log for a connected ASP4. My total btstrp.txt is: 02/22/20 14:37:57 SHOW: Incompatible P3D version. This version of as_connect is designed to be used with P3D versions 4.0.23.21468 up to 4.5.13.32097 02/22/20 14:37:57 SimVersion=-1 02/22/20 14:37:57 p3dBuild=1432669 02/22/20 14:49:43 Dll stop called but you are not running the latest P3D4.5, which may also explain it. Looks like I'll have to uninstall the Client and go back to the current release. I know all that. It was the remote ASP4 connection to as_connect which I was thinking might have been using a different socket, as i said. I don't need to sort out the true network connection if i am trying to repro your problem which occurs when ASP4 is NOT running. In fact I'm testing with no client PCs switched on in any case. Okay, that's fine then. I'll try going back to 4.5.13. I should really have noticed you weren't using the Beta from the FSUIPC log files you've posted. Pete
  14. Hmmm. I just enabled the ASP4 DLL for installation into P3D4.5 on my test PC, so I cauld run a debug session on it. ASP4 itself isn't running anywhere. Though WideFS is enabled, and FSUIPC is definitely linking to the ASP4 DLL (I have the log entries ASN active function link set Ready for ActiveSky WX radar with additional data as in your logs), it closes fine. My version of as_connect.dll is 17.1.1.126 dating from 26/09/2019. Can you check your please? The other difference is that I am using Win7 still on this PC. Looking in the as_srv folder, where as_connect is kept, I see the file "bstrp.txt" has this entry in it: 02/22/20 14:37:57 SHOW: Incompatible P3D version. This version of as_connect is designed to be used with P3D versions 4.0.23.21468 up to 4.5.13.32097 I am on the last 4.5 Beta, so maybe this means as_connect isn't doing much, though it is responding to FSUIPC's connection requests. Maybe there's something different in the as_connect.dll setup when set for using ASP4 on a different PC, though I don't see any configuration file? Pete
  15. Aha! Thanks. You decided to start a new thread. I already answered your post on the old thread, and all I can do here is repeat more or less what I said there. In that earlier post you said: Now that tells me that your A320 is running on FSX or P3D1-3. Correct? I'm not sure how you get the "1:" part of that encoding. It should be more like RX10db120*X55cc. The value after the X is a code address in whatever gauge file is used (shown in the .mcro file), and the X55cc is a check value which stops the macro jumping into the wrong place if the aircraft has been changed (updated). Whatever gauge or DLL it is seems to be very large -- nearly 18 Mbytes! Are you sure that that aircraft add-on will support mouse macros? The mouse macro facility in FSUIPC4 was implemented by hacking directly into FSX or P3D code, and this process certainly doesn't work for everything. It wasn't until P3D4.1 that facilities were provided by L-M to allow them to be used for all aircraft. By all means show me the .mcro file you made, for me to check, but please also check how other users of the same aircraft are managing. Check in User Contributions, above, and also in the FSLabs forums. Maybe FSLabs provides another way (eg additional custom controls) to do things? 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.