The following issues I've encountered while working to port the VRS TacPack to Prepar3D 1.2. Forgive me if I should have broken this up, but figured the safer way to start was in a single post, rather than spamming multiple messages. If any of these are intended changes in functionality from FSX, please let me know.
For what it's worth, this is using a module (DLL) compiled on VS2008, using the SP2/Acceleration SimConnect interface, and thus loadable in both FSX and Prepar3D. The Prepar3D docs claim this is a workable method, and for the most part that seems to be true.
****************************
- Objects in Multiplayer
In FSX, the only objects that would be injected into an MP session were aircraft with panels. (By "injected" I mean visible to all users in the MP session, rather than just to the user who spawned the object) Non-pilotable (panel-less) aircraft, as well as any other SimObject type (boats, ground vehicles, simple objects, etc) would not be injected. They'd exist only in the local simulation of whoever spawned them.
In Prepar3D, however, this behavior has changed, but in a rather strange way. Now, it seems that any object type (boats and simple objects for sure) will be injected into the MP session. But, and this is the strange bit, they will NOT be properly instantiated in remote user sims UNLESS they are aircraft. If they are not aircraft, the remote user sim will see that a user tried to spawn, for example, "veh_carrier01_high_detail_sm" but will refuse to actually create the object, instead replacing it with the default substitution of "Submersible". (And yes, the object does exist on both installations. If "User A" spawns the carrier object, "User A" sees it as expected, while "User B" sees the submersible in that location. And if "User B" spawns the carrier, "User B" sees it as expected, while "User A" sees the submersible in that location)
It seems that either the old behavior needs to be restored (no injection of objects that's aren't pilotable aircraft) or the new behavior needs to be consistent such that the proper object is indeed spawned on remote systems, rather than the halfway behavior (injected, but always substituted) currently present.
****************************
- "Bogus" SimConnect Exceptions
I've not yet tracked down what specifically leads to this, as the TacPack is actually a single module with many separate internal SimConnect client connections. However, in Prepar3D (and not FSX) I rapidly end up getting many, many SimConnect exceptions. They are always exception 3 and index 3, and what's odd is that they seem to be entirely bogus, not actually being the result of an invalid ID. (The calls implicated are either RequestDataOnSimObject [idx 3 = ObjectID] or TransmitClientEvent [idx 3 is dwData?])
Even stranger, I tend to get HUGE numbers of duplicate calls for each "bogus" exception, on the order of 3500+ for each one. (They're the same because everything about them, including the SendID remains the same) For clarity's sake, here's a snippet of the SimConnect log:
< 42.75082 [64] >>>>> EXCEPTION=3, SendID=858, Index=3 <<<<<
< 42.75083 [64] >>>>> EXCEPTION=3, SendID=858, Index=3 <<<<<
[Snipped 3,548 repetitions differing only in timestamp, along with some other SimConnect traffic]
< 43.74659 [64] >>>>> EXCEPTION=3, SendID=858, Index=3 <<<<<
< 43.74660 [64] >>>>> EXCEPTION=3, SendID=858, Index=3 <<<<<
I see nothing remotely like this running under FSX.
****************************
- menu.dll crash on exit
http://www.prepar3d.com/forum-5/?mingle ... ic&t=468.0
If there's any further data I can provide about any of these, please let me know.
Thanks.
FSX to Prepar3D Porting Oddities
-
Mike Schroeter
- Lockheed Martin
- Posts: 341
- Joined: Thu Jan 12, 2012 7:05 pm
Made the requested change to Prepar3D.cfg on my two test systems:
[Main]
User Objects=Airplane, Helicopter, Boat, Submersible, ExternalSim
Observed no change in behavior. I still get half-injected carriers substituted by the default Submersible. (Though a critical part of this may be the fact that the carrier has no panel, and thus is not pilotable. Given that FSX will not inject panel-less aircraft, I'm guessing that Prepar3D is similarly forcing a substitution for 'veh_carrier01_high_detail_sm" because it has no panel. I've not tested that though because carriers, generally, don't have panels by default, so even if that yields proper behavior, and I suspect it will, it doesn't really solve my issue in a generic way)
And honestly, even if full injection can be made to work for non-aircraft, in the case of SimpleObjects I'd still have a problem as the SimpleObjects I'm creating explicitly rely on NOT being injected into the MP system. (They're objects that only the user who spawned them should see.) I can add code to detect and delete any SimpleObjects I see owned by another user, but the "owning" sim is still going to be sending traffic related to them. (And that approach seems rather horribly hackish anyway)
[Main]
User Objects=Airplane, Helicopter, Boat, Submersible, ExternalSim
Observed no change in behavior. I still get half-injected carriers substituted by the default Submersible. (Though a critical part of this may be the fact that the carrier has no panel, and thus is not pilotable. Given that FSX will not inject panel-less aircraft, I'm guessing that Prepar3D is similarly forcing a substitution for 'veh_carrier01_high_detail_sm" because it has no panel. I've not tested that though because carriers, generally, don't have panels by default, so even if that yields proper behavior, and I suspect it will, it doesn't really solve my issue in a generic way)
And honestly, even if full injection can be made to work for non-aircraft, in the case of SimpleObjects I'd still have a problem as the SimpleObjects I'm creating explicitly rely on NOT being injected into the MP system. (They're objects that only the user who spawned them should see.) I can add code to detect and delete any SimpleObjects I see owned by another user, but the "owning" sim is still going to be sending traffic related to them. (And that approach seems rather horribly hackish anyway)
Also, related to the exception issue, I've done a bit more digging and found that it appears to manifest after a few valid exception 3's are raised. (Usually in response to an ongoing call for an object that was just deleted) Consider the following relevant snippets from SimConnect's log:
(First some relevant setup)
> 2.45547 [64, 1]Open: Version=0x00000004 Name="VRS_TP_Util"
[Snip]
> 2.45569 [64, 6]AddToDataDefinition:DefineID=2, DatumName="PLANE ALTITUDE", UnitsName="meters", DatumType=4, fEpsilon=0.000000, DatumID=-1
[Snip]
> 2.45752 [64, 67]MapClientEventToSimEvent:EventID=24, EventName="SLEW_SET"
> 2.45782 [64, 68]AddClientEventToNotificationGroup:GroupID=2, EventID=24, bMaskable=1
And the creation of the object in question:
> 14.55074 [71, 6]AICreateNonATCAircraft:szContainerTitle="VRS_AI_RDR_Emitter_AI", szTailNumber="Emit", InitPos=0, RequestID=0
< 14.63422 [64] ObjectAddRemove: EventID=12 Type=2 ObjectID=5
< 14.63434 [71] AssignedObjectID: RequestID=2 ObjectID=5
(Sidenote, why is RequestID reading 0 in the log for AICreateNonATCAircraft? It was actually 2, as reflected in the AssignedObjectID line)
Now the appearance of the bug:
< 56.07475 [64] EventFrame: 1 30.030497
< 56.07478 [70] EventFrame: 3 30.030497
< 56.11553 [64] Event: 4
< 56.11556 [64] Event: 5
< 56.47972 [64] Flight: 8
[NOTE: The time gap here is due to moving the aircraft to a new location, and is exactly how the log reads. Changing the aircraft position via "Go to airport" seems to be a reliable way to produce this bug, along with starting an MP session from inside a running SP session, which appears to be the common case in Prepar3D]
< 103.69292 [64] ObjectAddRemove: EventID=13 Type=2 ObjectID=6
< 103.69306 [64] ObjectAddRemove: EventID=13 Type=2 ObjectID=5
< 103.69314 [64] ObjectAddRemove: EventID=13 Type=2 ObjectID=4
< 103.69347 [64] ObjectAddRemove: EventID=13 Type=2 ObjectID=2
< 103.69356 [64] EventMultiplayerClientStarted: 16
> 103.87188 [64, 314]TransmitClientEvent:ObjectID=5, EventID=24, dwData=0, GroupID=1900000000, Flags=16
< 103.87192 [64] >>>>> EXCEPTION=3, SendID=314, Index=1 <<<<<
> 103.87194 [64, 315]SetDataOnSimObject:DefineID=2, ObjectID=5, Flags=0, ArrayCount=1, cbUnitSize=8, pDataSet=737459228
< 103.87196 [64] >>>>> EXCEPTION=3, SendID=315, Index=2 <<<<<
< 103.90698 [64] Event: 14
< 103.93465 [64] Facilities Request: RequestID=18 count=5
< 103.93469 [72] Facilities Request: RequestID=18 count=5
< 109.94222 [64] Event: 11
< 109.94225 [66] Event: 1
< 109.94933 [64] EventFrame: 1 0.165692
< 109.94935 [70] EventFrame: 3 0.165692
< 109.95574 [64] Event: 2
< 109.95576 [65] Event: 1
< 109.95577 [66] Event: 2
< 109.95579 [67] Event: 2
< 109.95580 [68] Event: 2
< 109.95582 [69] Event: 1
< 109.95583 [71] Event: 1
< 109.95585 [70] Event: 2
< 109.95586 [72] Event: 1
< 109.95588 [64] >>>>> EXCEPTION=3, SendID=315, Index=3 <<<<<
< 109.95590 [64] >>>>> EXCEPTION=3, SendID=315, Index=3 <<<<<
< 109.95592 [64] >>>>> EXCEPTION=3, SendID=315, Index=3 <<<<<
The first two exceptions are completely valid. Object 5 has already been removed from the sim, but remains in some internal data structures of the TacPack for at least a frame, resulting in the calls that lead to the valid exceptions. (Note that the deletion of object 5 takes place in the same frame as the calls that lead to the valid exceptions) However, those last three lines are the first "bogus" exceptions in this log (coming six seconds after the valid exception they appear to be "mirroring"), and they seem to snowball from there. (This same code, the same compiled module, functions without this issue under otherwise identical circumstances on FSX)
[NOTE: The three "bogus" exceptions here are the only ones in this first group. The next few "bogus" groups have relatively small numbers of duplicates, but fairly rapidly things escalate to 125 duplicates, and 1301 duplicates, and so on. I'm happy to provide full logs if that would be of any use]
(First some relevant setup)
> 2.45547 [64, 1]Open: Version=0x00000004 Name="VRS_TP_Util"
[Snip]
> 2.45569 [64, 6]AddToDataDefinition:DefineID=2, DatumName="PLANE ALTITUDE", UnitsName="meters", DatumType=4, fEpsilon=0.000000, DatumID=-1
[Snip]
> 2.45752 [64, 67]MapClientEventToSimEvent:EventID=24, EventName="SLEW_SET"
> 2.45782 [64, 68]AddClientEventToNotificationGroup:GroupID=2, EventID=24, bMaskable=1
And the creation of the object in question:
> 14.55074 [71, 6]AICreateNonATCAircraft:szContainerTitle="VRS_AI_RDR_Emitter_AI", szTailNumber="Emit", InitPos=0, RequestID=0
< 14.63422 [64] ObjectAddRemove: EventID=12 Type=2 ObjectID=5
< 14.63434 [71] AssignedObjectID: RequestID=2 ObjectID=5
(Sidenote, why is RequestID reading 0 in the log for AICreateNonATCAircraft? It was actually 2, as reflected in the AssignedObjectID line)
Now the appearance of the bug:
< 56.07475 [64] EventFrame: 1 30.030497
< 56.07478 [70] EventFrame: 3 30.030497
< 56.11553 [64] Event: 4
< 56.11556 [64] Event: 5
< 56.47972 [64] Flight: 8
[NOTE: The time gap here is due to moving the aircraft to a new location, and is exactly how the log reads. Changing the aircraft position via "Go to airport" seems to be a reliable way to produce this bug, along with starting an MP session from inside a running SP session, which appears to be the common case in Prepar3D]
< 103.69292 [64] ObjectAddRemove: EventID=13 Type=2 ObjectID=6
< 103.69306 [64] ObjectAddRemove: EventID=13 Type=2 ObjectID=5
< 103.69314 [64] ObjectAddRemove: EventID=13 Type=2 ObjectID=4
< 103.69347 [64] ObjectAddRemove: EventID=13 Type=2 ObjectID=2
< 103.69356 [64] EventMultiplayerClientStarted: 16
> 103.87188 [64, 314]TransmitClientEvent:ObjectID=5, EventID=24, dwData=0, GroupID=1900000000, Flags=16
< 103.87192 [64] >>>>> EXCEPTION=3, SendID=314, Index=1 <<<<<
> 103.87194 [64, 315]SetDataOnSimObject:DefineID=2, ObjectID=5, Flags=0, ArrayCount=1, cbUnitSize=8, pDataSet=737459228
< 103.87196 [64] >>>>> EXCEPTION=3, SendID=315, Index=2 <<<<<
< 103.90698 [64] Event: 14
< 103.93465 [64] Facilities Request: RequestID=18 count=5
< 103.93469 [72] Facilities Request: RequestID=18 count=5
< 109.94222 [64] Event: 11
< 109.94225 [66] Event: 1
< 109.94933 [64] EventFrame: 1 0.165692
< 109.94935 [70] EventFrame: 3 0.165692
< 109.95574 [64] Event: 2
< 109.95576 [65] Event: 1
< 109.95577 [66] Event: 2
< 109.95579 [67] Event: 2
< 109.95580 [68] Event: 2
< 109.95582 [69] Event: 1
< 109.95583 [71] Event: 1
< 109.95585 [70] Event: 2
< 109.95586 [72] Event: 1
< 109.95588 [64] >>>>> EXCEPTION=3, SendID=315, Index=3 <<<<<
< 109.95590 [64] >>>>> EXCEPTION=3, SendID=315, Index=3 <<<<<
< 109.95592 [64] >>>>> EXCEPTION=3, SendID=315, Index=3 <<<<<
The first two exceptions are completely valid. Object 5 has already been removed from the sim, but remains in some internal data structures of the TacPack for at least a frame, resulting in the calls that lead to the valid exceptions. (Note that the deletion of object 5 takes place in the same frame as the calls that lead to the valid exceptions) However, those last three lines are the first "bogus" exceptions in this log (coming six seconds after the valid exception they appear to be "mirroring"), and they seem to snowball from there. (This same code, the same compiled module, functions without this issue under otherwise identical circumstances on FSX)
[NOTE: The three "bogus" exceptions here are the only ones in this first group. The next few "bogus" groups have relatively small numbers of duplicates, but fairly rapidly things escalate to 125 duplicates, and 1301 duplicates, and so on. I'm happy to provide full logs if that would be of any use]
I've encountered another issue, this time related to objects created by MP clients (not the MP host) during MP session initiation. The simulation seems to send 'SIMCONNECT_RECV_ID_EVENT_MULTIPLAYER_CLIENT_STARTED' to indicate MP session initiation and then a bit later sends 'SimStart'. However, this first SimStart is not when the actual simulation starts, as that seems to come later, after at least one (but sometimes more) SimStarts are received. However, if a client creates an object after the first SimStart, it gets created and properly injected into the MP system. (ie, the object shows up on everyone else's system) However, any attempts to do things like set radio frequencies, transponder values, or light states on said object inside its 'ASSIGNED_OBJECT_ID' callback results in those values not making it into the MP system. Setting the same values on the same object IDs after the sim has actually started results in the expected behavior. (The values set properly propagate into the MP session) The MP host does NOT have this issue, nor is it present in FSX for either hosts or clients.
By way of example, on the first SimStart received after MP session initiation, the TacPack creates objects to signal what version of the TacPack each user is running. In FSX this works great. In Prepar3D, the object created by the MP host gets set properly and its version info gets properly propagated out to everyone in the MP session. However, the version objects created by the MP clients end up with default values visible to everyone in the MP session, resulting in incorrect version detection and processing. If I hack things to create these objects and set their values later, it works, but I have no consistent way to detect when the simulation has truly started. (In FSX, the first SimStart after MP session initiation also tends to come before the actual simulation has loaded, but object values set by clients after this SimStart are properly propagated to the other clients in the MP session, so I have no compelling need to determine when the simulation is "actually" loaded)
By way of example, on the first SimStart received after MP session initiation, the TacPack creates objects to signal what version of the TacPack each user is running. In FSX this works great. In Prepar3D, the object created by the MP host gets set properly and its version info gets properly propagated out to everyone in the MP session. However, the version objects created by the MP clients end up with default values visible to everyone in the MP session, resulting in incorrect version detection and processing. If I hack things to create these objects and set their values later, it works, but I have no consistent way to detect when the simulation has truly started. (In FSX, the first SimStart after MP session initiation also tends to come before the actual simulation has loaded, but object values set by clients after this SimStart are properly propagated to the other clients in the MP session, so I have no compelling need to determine when the simulation is "actually" loaded)
-
Adam Breed
- Lockheed Martin
- Posts: 1382
- Joined: Mon Sep 20, 2010 6:17 pm
Hi adiemus,
SimStart modifications have been made in 1.3 and they should fix the issue you are having. More information will be coming in the next few days. Please see this post for more information on previous SimStart questions: http://www.prepar3d.com/forum-5/?mingle ... opic&t=246
SimStart modifications have been made in 1.3 and they should fix the issue you are having. More information will be coming in the next few days. Please see this post for more information on previous SimStart questions: http://www.prepar3d.com/forum-5/?mingle ... opic&t=246
Prepar3D® Engineering Project Manager
Downloading Prepar3D 1.3 now and will see what impact it makes on the issues I've mentioned, but I do have a generic question. In FSX/Prepar3D, I can enable slew in SP/MP free flight and in SP missions. (The TacPack internally prevents users from slewing their own aircraft to prevent cheating, but it MUST be able to put certain non-user objects into slew mode to make certain core features of the TacPack work)
However, I cannot (and I've spent LOTS of time trying in FSX) find a way to enable slew inside an MP mission. This essentially means that the TacPack can't be used in MP missions, because I rely on slew mode being available for the smooth motion of quite a few objects. Without it, the best I can do is fallback to "SIM DISABLED" and continual position updates. (Which is not nearly good enough for things like communicating dynamic emitter envelopes in MP, since disabled objects end up "falling" and "resetting" continually on remote sessions)
Anyway, is there any way at all to enable slew inside an MP mission in Prepar3D? If not, is that something that could be changed in the future? For my own curiosity, I would love to know why such a limitation exists. (I've always guessed it was because of MP racing and the issues slew could cause there, but that's wild speculation)
However, I cannot (and I've spent LOTS of time trying in FSX) find a way to enable slew inside an MP mission. This essentially means that the TacPack can't be used in MP missions, because I rely on slew mode being available for the smooth motion of quite a few objects. Without it, the best I can do is fallback to "SIM DISABLED" and continual position updates. (Which is not nearly good enough for things like communicating dynamic emitter envelopes in MP, since disabled objects end up "falling" and "resetting" continually on remote sessions)
Anyway, is there any way at all to enable slew inside an MP mission in Prepar3D? If not, is that something that could be changed in the future? For my own curiosity, I would love to know why such a limitation exists. (I've always guessed it was because of MP racing and the issues slew could cause there, but that's wild speculation)
Having tested 1.3, the status of my reported issues are as follows:
Resolved:
- Crash in menu.dll on exit after using SimConnect menus or dialogs
Unresolved:
- "Half-injection" of non-aircraft objects in MP
- "Bogus" SimConnect exceptions (though so far they now seem to be in the dozens rather than thousands, but I've only done limited testing)
- Slew mode globally disabled in MP missions
Untested:
- MP issue with object creation on SimStart. (I made changes to my code to work around the issue in 1.2, and have not yet had time to remove those changes to see if the problem is resolved or still present on 1.3)
Resolved:
- Crash in menu.dll on exit after using SimConnect menus or dialogs
Unresolved:
- "Half-injection" of non-aircraft objects in MP
- "Bogus" SimConnect exceptions (though so far they now seem to be in the dozens rather than thousands, but I've only done limited testing)
- Slew mode globally disabled in MP missions
Untested:
- MP issue with object creation on SimStart. (I made changes to my code to work around the issue in 1.2, and have not yet had time to remove those changes to see if the problem is resolved or still present on 1.3)
A few more issues I've not previously mentioned, from 1.3. (Some of them may be new in 1.3, I'm not sure. I can go test on 1.2 to verify, if necessary)
* SimConnect MP object position issues
This issue has existed since FSX, but remains in Prepar3D 1.3. Objects spawned in MP by one system show up on that system in the expected location, (whatever was in the SIMCONNECT_DATA_INITPOSITION structure of the call to SimConnect_AICreateNonATCAircraft()), frequently however, on remote systems, these objects show up at lat/lon/alt 0/0/0. If moved by their owner (manually setting PLANE LATITUDE, etc) after creation, they eventually end up in the right place in MP, though if never "repositioned" by their owner, they will simply remain at 0/0/0, even if moving on the owner system.
* SimConnect request race condition
In FSX, when an object is deleted, any ongoing SimConnect request for that object is cleared. In Prepar3D, it seems that if an object ID is recycled fast enough (ie, the original object that has an ongoing request is deleted, then a new object gets created with the same ID) the original SimConnect request continues, this time with the new object. This is causing me a fair amount of trouble.
* Airport Selection Dialog Entry Issue
This one is quite minor. In the airport selection, typing a space into the "City" field seems to break the auto-selection functionality of the actual list. Try typing "Port Angeles" (or any city with a space in it) into the edit box. Once you get to the space, it's as though the space wipes out the previous character and no further characters are processed. In my example, if you've typed "port" the selection is set to "Port-Au-Prince", the first city entry that starts with the string "port". However, after entering the space, ie. "port ", the selection jumps up to "Porrentruy", and remains there regardless of what else I type.
* SimConnect MP object position issues
This issue has existed since FSX, but remains in Prepar3D 1.3. Objects spawned in MP by one system show up on that system in the expected location, (whatever was in the SIMCONNECT_DATA_INITPOSITION structure of the call to SimConnect_AICreateNonATCAircraft()), frequently however, on remote systems, these objects show up at lat/lon/alt 0/0/0. If moved by their owner (manually setting PLANE LATITUDE, etc) after creation, they eventually end up in the right place in MP, though if never "repositioned" by their owner, they will simply remain at 0/0/0, even if moving on the owner system.
* SimConnect request race condition
In FSX, when an object is deleted, any ongoing SimConnect request for that object is cleared. In Prepar3D, it seems that if an object ID is recycled fast enough (ie, the original object that has an ongoing request is deleted, then a new object gets created with the same ID) the original SimConnect request continues, this time with the new object. This is causing me a fair amount of trouble.
* Airport Selection Dialog Entry Issue
This one is quite minor. In the airport selection, typing a space into the "City" field seems to break the auto-selection functionality of the actual list. Try typing "Port Angeles" (or any city with a space in it) into the edit box. Once you get to the space, it's as though the space wipes out the previous character and no further characters are processed. In my example, if you've typed "port" the selection is set to "Port-Au-Prince", the first city entry that starts with the string "port". However, after entering the space, ie. "port ", the selection jumps up to "Porrentruy", and remains there regardless of what else I type.
-
Adam Breed
- Lockheed Martin
- Posts: 1382
- Joined: Mon Sep 20, 2010 6:17 pm
Quote:
Quote from adiemus on March 29, 2012, 21:23
Couldn't help but notice the weapon related additions to SimConnect.h in the P3D 1.3 SDK. There don't seem to be any associated documentation updates. Is there any explanation of these changes anywhere?
Hi adiemus,
The weapon event struct (SIMCONNECT_RECV_EVENT_WEAPON) in the SimConnect.h is simply a stub piece of code that does not connect to anything in our system. The changes affect nothing in 1.3 and add no new features. Sorry for any excitement that was caused
.Prepar3D® Engineering Project Manager
