Jump to content
The simFlight Network Forums

adiemus

Members
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

0 Neutral

About adiemus

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    Chicago
  1. Thanks, Pete. Hope you are as well. For what it's worth, I've just tested here locally with the VRS Superbug (our FA-18E) and TacPack without issue on both 4.859m and 4.859t_Test3. Whatever it is, it's not something VRS code is unavoidably causing. To the users reporting the issue: In addition to both running the TacPack, you're both running the user-contributed LUA "SuperScript" as well, aren't you? I'm wondering if perhaps that's where the spurious shift release is coming from. (I'm not running it here, nor is it something VRS supports, and FSUIPC's LUA capabilities are not something I have any experience or knowledge of. I've asked that script's author to review this thread) Is it possible you both have the same stick and/or profiling software that might be causing it? Like Pete, I'm quite curious to see an FSUIPC log of button/key events from one (or both) of you with the TacPack disabled. (You can disable the TacPack easily via the TPM) Here are the relevant sections of my log from the test with the Superbug/TacPack on FSUIPC 4.859t_Test3 ********* FSUIPC4, Version 4.859t by Pete Dowson ********* <snip> 177938 Button changed: bRef=0, Joy=0, Btn=6, Pressed 177938 [Buttons] 1=H0,6,K46,9 177938 SendKeyToFS(0004002E=[shft+Del], KEYDOWN) ctr=0 177953 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=2 177969 Sending WM_KEYDOWN, Key=46 (Scan code 83), Ctr=1 177984 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 177984 .. Key not programmed -- passed on to FS 177984 KEYDOWN: VK=46, Waiting=0, Repeat=N, Shifts=1 177984 .. Key not programmed -- passed on to FS 178156 Button changed: bRef=0, Joy=0, Btn=6, Released 178156 [Buttons] 1=H0,6,K46,9 178156 SendKeyToFS(0004002E=[shft+Del], KEYUP) ctr=0 178156 Sending WM_KEYUP, Key=46 (Scan code 83), Ctr=2 178172 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=1 178188 KEYUP: VK=46, Waiting=0 178188 KEYUP: VK=16, Waiting=0 304375 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=2 304375 .. Key not programmed -- passed on to FS 304469 KEYDOWN: VK=67, Waiting=0, Repeat=N, Shifts=2 304469 .. Key not programmed -- passed on to FS[/CODE]
  2. Pete, This is Chris Tracy, the primary developer of the VRS TacPack. (A module that adds various weapon/sensor functionality to FSX. It runs globally as a DLL) If indeed you find that something the TacPack is doing is the source of this issue, I'm most interested to fix it on our end rather than forcing you to work around it. Though I confess I too am confused by what's been reported here so far. Chris
  3. Just to confirm, 4.851 resolves the issue we were seeing with offsets returning NULL before the simulation started. Thanks.
  4. Pete, In the same vein, we're seeing that FSUIPC is refusing to provide at least its version info to clients attempting to connect before the sim is loaded. (ie, in the "Free Flight" dialog) We're just using the example code distributed with FSUIPC for connecting to it. The problem is that the read of 0x3304 and 0x3308 both come back NULL, leading FSUIPC_Open2() to return FSUIPC_ERR_VERSION. Once inside the sim, things work as expected. (So for now we're just telling our users to reload the aircraft once they get back into the sim) Haven't had a chance to test with 4.84 yet as I can't find a copy anywhere.
  5. I was unable to get this to crash in any configuration, including with SimConnectP3D.dll from 1.2. While not necessarily a true resolution, it may indeed be a truly generic workaround for Prepar3D 1.3.
  6. Pete, the new SimConnectP3D.dll made no difference. Would be quite curious though to have someone else run the same test (4.812d with the updated SimConnectP3D) just to confirm.
  7. The crash remains on 4.812d until I removed SimConnectP3D.dll, which seems to resolve it. (On this system, that ends up forcing a connection to the FSX SP2/Acceleration version of SimConnect, since I have Acceleration installed in addition to P3D. Not sure how it'll behave on a system that's never had FSX installed, as I don't have one with which to test and no easy way to force FSUIPC to ignore the FSX SimConnect DLLs)
  8. Unfortunately, this one still crashes on joining an MP session. (Not always, still trying to work out the conditions under which it crashes)
  9. I'm afraid 4.812b still crashes when entering MP, but does so differently than 4.812. Looking at it now. Will e-mail more details.
  10. Pete, Actually, the crash does seem to happen inside FSUIPC. Sent you an e-mail with some technical details that will hopefully be helpful. Chris VRS
×
×
  • 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.