jabloomf1230
-
Posts
204 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by jabloomf1230
-
-
Tom,
I did that first before trying the old key file. The key for the version you referenced says it is valid until 3 November not 8 November. At this point I think I'll just wait for the RTM version on SimMarket.
Jay
-
I read on the forum that the beta key was time based and expired, so I uninstalled FSUIPC7 using its uninstaller and then reinstalled using the installer. The version runs but does not have a registration key. I did save the old .KEY file in a different location but when I put that file in the FSUIPC7 folder and run the app it still says it is not registered.
-
Pete,
A thank you from me also, as an fsaerodata user.
Jay
-
Pete,
I managed to get the Traffic Look 1.56 main window to display with P3d4 and Win10. I took a look at TrafficLook.ini and I noticed that the window settings were -8,-8, 2546, 1576. I changed them to 10,10,640,480 and the window displayed correctly. I'm guessing that the negative x/y origin location causes the window to not display.
Jay
-
1
-
-
Pete,
I don't know if you are back online or not, but I just checked TrafficLook 1.56 with P3d4 and the most recent version of FSUIPC5 and I get the same result as John reported above. It's not a big deal to me, but I just wanted to confirm his results that TrafficLook was reported as running in the Task Manager, but its main window does not display. I'm running Win 10 and not WideClient.
Jay
-
Good news, I think I realized why this was happening. If one saves a scenario and then uses that scenario to start a new flight, the P3d4 scenario file (FXML) has a bunch of XML that initializes numerous variables. A number of them have to do with the last used VC cockpit state and aircraft settings. This appears to be similar to the P3d4 VC serialization feature, but it happens even if the box is left unchecked in the P3d UI. I'm guessing that one or more of those variables is corrupting an internal variable that is used by the TD. Eventually, this bad initialization leads to strange aircraft behaviors, like loss of flight control.
To test this, I tried opening the default sim scenario and changing only the aircraft type to the TD. Then I always used that scenario when starting and changed the location, etc. by using a PLN flightplan file which only contains minimal information. It seems like successively opening and saving the same scenario at different airports makes the probability of corruption higher and higher. This was a habit of mine to hop from one airport to the next in different sessions. I've learned my lesson.
-
Well... after much testing and fiddling I'm chalking this up to my hardware not being able to cope with my settings. The TrackIR 5 produces so many entries in the SimConnect log under precision mode (the logfile becomes GBs in size after only about ten minutes of flying), that I set the mode to "standard", which is really designed for TrackIR 4. This reduced the number of entries in the SimConnect log file substantially and also improved the mouse issue. I then set the joystick FSUIPC polling interval to 20 from 10 and that pretty much fixed the issue altogether. Either those two "fixes" compensated for what's broken or my CPU can't handle the SimConnect load, even though it's an i6700k OCed at 4.4 GHZ. Why this issue showed up all of a sudden, coincidently with a minor revision to FSUIPC5 and the release of P3d 4.1 is beyond my pay grade to figure out.The mysteries of flight sims.
-
Thanks Pete, I'm suspecting the RealAir Turbine Duke, but only because RA is out of business and thus there is no official support. All the other installed 3rd party aircraft with DLLs are deemed P3d4 compatible. Milviz staff have posted on AVSim that they are still trying to buy the rights to RA aircraft, so there is some hope.
If this is the problem. I'll see what P3d 4.2 brings.
-
On 9/15/2017 at 5:44 AM, Pete Dowson said:
I can reproduce this, but I'm stumped. FSUIPC itself is not interpreting the Space bar, nor is it setting the cursor position. The SPACE bar is, as it is defaulted in P3D, sends P3D the "MOUSE LOOK TOGGLE", as shown here in FSUIPC's logging:
1048218 KEYDOWN: VK=32, Waiting=0, Repeat=N, Shifts=0
1048218 .. Key not programmed -- passed on to FS
1048218 *** EVENT: Cntrl= 66734 (0x000104ae), Param= 1 (0x00000001) MOUSE_LOOK_TOGGLE
1048390 KEYUP: VK=32, Waiting=0
I've put traps in FSUIPC in all the places where the mouse might be moved (normally in one of the Mouse facilities enabled in the Misc Tab in FSUIPC options), but none are triggered.So it is something else in P3D which is somehow being affected by some small change in FSUIPC. I don't know how to locate it, though. I might have to ask L-M to help explain what is causing P3D to do this.
One other nasty, which I'll need to report to L--M too. As part of my test I tried to change the assignment of the SPACE bar in L-M Options-Controls, but it crashes L-M with a great long error display!
First I'll see if I can undo one change between 5.113 and 5.12 at a time, to see if I can identify the trigger, but it still looks like a P3D problem which FSUIPC is somehow triggering.
This could take a while. :-(
Pete
Pete,
What became of your discussions with LM on this? I'm asking because since upgrading to any versions of 5.1x I am experiencing the strangest behavior in P3d4.1. Sometimes, when I start a scenario, any movement of the mouse in the P3d view temporarily reduces performance to 1-2 FPS. Moving the mouse outside the view (P3d menus, or the Windows taskbar) has no effect. My Saitek X-65F controller is active in FSUIPC 5 and all controllers are disabled in P3d. Once this behavior is encountered during a flight it persists. However, other times when starting a scenario, this behavior is completely absent.
There is nothing of interest (at least to me) in the FSUIPC5 log. Deleting Prepar3d.cfg and letting the sim rebuild it eliminates the issue, until I disable all controllers again in P3d. I tried rebuilding FSUIPC5.ini and that also had no effect. I tried switching between raw input and DirectInput in P3d and that had no effect. It happens whether using either with the default aircraft in the P3d default scenario or with any scenario and any 3rd party aircraft. I even bought a new mouse and this had no effect on the behavior either. It almost seems like either Mouse Look or Mouse Yoke gets permanently enabled in P3d.
Anyway, you can file this away for informational purposes as it may not be related to FSUIPC5 at all.
Jay
-
Pete,
The door issue in P3d V4 has been reported elsewhere and has been supposedly worked around by adding the old FSX open/close doors panel gauge instead of using the sim's built-in recognition of the key sequence.
Last I saw, the gauge was still available for download on Simviation.com.
-
22 hours ago, Pete Dowson said:
Not really talking about additions. I'm looking for the same information as I always did -- only stuff in airport records, nothing else.
The ID codes for the Runway entries and the TaxiPath entries are different. I can see that. They are also different sized structures. So this certainly means a different structure format. Whether there's additional information there I do not know, and I don't think "materials" figure in basic airport data, do they?
This is only with a pre-P3D4 BGL re-compiled with the new BGL compiles, after using ADE 1.75 to decompile the original. With a scenery designed explicitly using new facilities, I might not even get the parts I can currently see. I just don't know at present.
I will be looking into it, of course, but if things aren't reasonably quickly discernible I would have to shelve it for a while, and preferably wait either for some young hacker to decode it, or maybe get L-M to suply documentation.
Pete
Pete,
I don't want to completely derail this user support thread, but here's a comparison of the "tail end" of the Runway entries between the V3 SDK:
http://www.prepar3d.com/SDKv3/LearningCenter/environment/compiling_bgl.html#Runway
and the V4 SDK (which can't be directly linked, so here's the entry):
QuotesecondaryPattern (optional)Indication of pattern orientation for secondary heading (optional)LEFT, RIGHT. Default is LEFT.
primaryMarkingBiasBias from the end of the runway for primary markings.Distance in feet, nautical miles, or meters (F, N or M suffix).
secondaryMarkingBiasBias from the end of the runway for secondary markings.Distance in feet, nautical miles, or meters (F, N or M suffix)
.materialSet (optional)MaterialSet guid to override default seasonal materials. The MaterialSet order should be Winter(0), Hard Winter(1), Spring(2), Summer(3), Fall(4). If not all seasons are filled out, will select first material in set.GUID in the format:
{nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn}The structure (materialSet) that you referred to contains the seasonal material set GUIDs that allows differing materials to be used for runways during the 5 P3d "seasons". I apologize for not writing more clearly in my previous post above. I'm not sure why LM changed the IDs, but a few other utilities don't work correctly (yet) because of this change. Actually, the more that I think about it, this was to differentiate between runways with and without the materialSet entry. I could be wrong on that, though.
Jay
-
The only item that was added to the BGL format that affects ADE is the ability to support P3d materials. It is of minor consequence unless a developer wants to take advantage of this new feature.
-
When Superman retired...
-
See John' Cook's FSUIPC Configuration Guide:
http://www.tropicairvirtual.com/company/misc/utility/tutorial/fsuipc-guide-v1.pdf
That's about the best one can do with it, unless someone has a LUA script.
-
Well, as it turns out, the VOXATC panel gauge DLL might not use an affinity mask. That setting is used by the VOXATC ATC server which is an EXE file. I only figured this out recently when P3d CTDed and the ATC server was still running.
-
On 2/10/2017 at 9:54 AM, Pete Dowson said:
However, I still have doubts as to whether it actually uses it. Not sure how to check that.
Pete
Yep, That's the problem that I was having trying to understand how VOXATC does it. I suppose one could create a debug version of the DLL that had a looping thread that artificially creates a lot of CPU use. That might be a way of testing the AM.
As to the VOXATC GAU DLL it is fairly CPU intensive in bursts as it utilizes the built-in Windows speech synthesis and speech recognition. On a recent CPU like my i7-6700k, AM doesn't seem to really matter though for speech stuff. Running the gauge on a single HT logical core, does seem to slow down the response time but it could also be my imagination.
Jay
-
This would allow for fine-tuning the AI limit number. I suspect most people just pick a round number like 100 or 150 and then see what happens. Ultimate Traffic 2 has such a "frame rate" parameter and it seems to work okay. However, this improvement to the FSUIPC limiter would help out those people using My Traffic 6 and WOAI, etc..
-
I can't add too much except that it appears to work via my limited testing with a few flight plans and it doesn't seem to break anything either. I'm just curious, though, what happens when there is no flight plan loaded at all?
-
10 hours ago, Pete Dowson said:
However, I still have doubts as to whether it actually uses it. Not sure how to check that.
Pete
Yep, That's the problem that I was having trying to understand how VOXATC does it. I suppose one could create a debug version of the DLL that had a looping thread that artificially creates a lot of CPU use. That might be a way of testing the AM.
As to the VOXATC GAU DLL it is fairly CPU intensive in bursts as it utilizes the built-in Windows speech synthesis and speech recognition. On a recent CPU like my i7-6700k, AM doesn't seem to really matter though for speech stuff. Running the gauge on a single HT logical core, does seem to slow down the response time but it could also be my imagination.
Also see this VC extension (Concurrency Visualizer):
https://msdn.microsoft.com/en-us/library/dd537632.aspx
Jay
-
Pete,
I'm sorry I didn't get back to you right away, but I just got home from a weeks vacation and our boiler's propane tank had run out of gas, so we had no heat.
VOXATC is a GAU file which is added to the user's aircraft. The only exes that come with it are utilities for fine tuning the voice recognition and overall settings for the panel (text color, etc.). As to the link, your assumption is correct ( "SetThreadAffinityMask".). I apologize because I'm also trying "reverse engineer" in my head what the developer of VOXATC did to get a DLL to have a user settable affinity mask.
VOXATC 7 is still in beta and version 7.2 is a free time-limited (60 days) download if you want to test it out, but you need a microphone on your PC. It's actually quite a clever piece of software, as it uses the built-in Windows speech synthesis and speech recognition for its ATC. It also creates its own AI aircraft and controls them. It scans all the AI traffic BGLs and then generates the AI Traffic. It works with My Traffic 6, WOAI and and UT2 . The only drawback is that it is thus not compatible with SuperTrafficBoard.
As I said above, there is no way for a user to tell which threads of an app use which cores, unless it's like the time when LM staff broadly explained on their forum how they arranged the P3d threads on various cores.
Jay
-
Luke,
Pete doesn't seem too keen on adding this functionality, probably due to reasons that he stated. I'm pretty sure that any process can be assigned an affinity mask. As to a DLL, any thread that it creates can be assigned to a logical core. My guess is that is how VOXATC does it with its DLL. The assignment is not dynamic but rather it happens via the DLL reading a configuration file (created prior to running the sim by a separate setup utility that determines the number of logical cores and allows the user to set the AM).and then the DLL knows what cores to use. Based on what Pete stated above, it really doesn't seem worth it.
Jay
-
Hah, actually I'm not sure, but FSUIPC does handle controller inputs and now does allow for management of AI traffic levels. Again, since FSUIPC is a DLL, there is no easy way to know (at least for me) how it affects CPU load. But keeping it off the first physical core might help P3d.
It was just an idle suggestion for future consideration.
-
Pete,
No, VOXATC sets the AM for just its DLL (GAU). I didn't think that a DLL could set its own affinity mask independent of the app that references the library , but I looked it up and according to Microsoft documentation, it is doable without too much fuss. Maybe the option in VOXATC doesn’t really work, because there is no easy way of checking what cores it uses.
-
I know that FSUIPC can set an affinity mask for the specific apps that it spawns via the ini file, but has there been any thought to adding an option to allow setting an AM for the host FSUIPC process? I only thought about this because I had posted something here recently about VOXATC. VOXATC consists of a gauge that has an option to allow the user to set its AM prior to run time.
FSUIPC7 no longer registers
in FSUIPC7 MSFS
Posted
John,
Also, could you contact Malwarebytes as they are reporting your zip files as containing a trojan? I excluded it, but you might have other people asking about this. This also applies to the link on SimMarket.
Jay