2019-01-21 14:44 EST

View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0002787FSSCPdockingpublic2013-02-26 21:01
Assigned ToGoober5000 
PlatformWindowsOSWindows 7OS VersionSP 1
Product Version3.6.16 
Target VersionFixed in Version 
Summary0002787: set-docked and jettison-cargo-delay being called in the same event causes overlay of ships
DescriptionCalling these two sexps causes the two ships involved to become overlayed on top of one another if they are the same class. Also appears to be no delay in jettison-cargo-delay.
Steps To ReproduceSee attached mission.

Scenario 1: Ship 1 set-docked to Ship 2 , and then a chained event 3 seconds later fires off a jettison-cargo delay. This works as expected.

Scenario 2: Ship 1 set-docked to Ship 2 and Ship 1 then jettisons Ship 2. Causes ships to become overlayed (oddly enough, if called again in the same manner by trigger count works as expected.)

Scenario 3: Ship 1 set-docked to Ship 2 and Ship 2 then jettisons Ship 2. Same as Scenario 2.

Scenario 4: Ship 1 set-docked to Ship 3 (a different class) and then jettisons after a delay set by jettison-cargo-delay. Works as expected but there is no delay.

Scenario 5: Ship 1 set-docked to Ship 2 and then jettisons after delay set in the jettison-cargo-delay sexp. No delay, same as scenario 2.

Additional InformationFirst noticed this whilst scripting calling these SEXPs and started getting null vec3d errors - I've been unable to reproduce this error in isolation though.
TagsNo tags attached.
Attached Files




Goober5000 (administrator)

The sexp help for jettison-cargo-delay says that the sexp doesn't use a delay. It's not implemented and it likely won't be.

I'll take a look at Scenario 2.


Goober5000 (administrator)

Well, this is very interesting. Consider the following lines in dock_orient_and_approach(), for the DOA_DOCK_STAY case:

docker_objp->orient = dom;

vm_vec_sub(&offset, &dockee_point, &docker_point);
vm_vec_add2(&docker_objp->pos, &offset);

The docker orientation is instantly set to the new docked orientation, but the docker_point vector is still relative to the original orientation! To solve this bug, the difference between the old and new orientations must be calculated and the result applied to the docker orientation, just as the difference in positions is applied to the docker position.

The reason the chained delay method works is that the object move code takes care of dragging the transport to the correct position on the next frame. The reason the orientation problem hasn't been spotted until now is that DOA_DOCK_STAY is usually called when the orientations are already very similar.

So the next step is to figure out how to calculate a rotation matrix that will transform orientation A into orientation B.


Goober5000 (administrator)

Fix committed to trunk@9542.


chief1983 (administrator)

FelixJim mentioned in IRC that this did fix the issues in the test mission and also the null vec3d errors that were experienced.


Goober5000 (administrator)

Yup, I tested it with the mission he provided before committing it. It's cool that it fixed null vec3d errors too.

+Related Changesets

-Issue History
Date Modified Username Field Change
2013-02-02 08:41 FelixJim New Issue
2013-02-02 08:41 FelixJim Status new => assigned
2013-02-02 08:41 FelixJim Assigned To => Goober5000
2013-02-02 08:41 FelixJim File Added: dockbug.7z
2013-02-02 11:45 Goober5000 Note Added: 0014682
2013-02-19 23:09 Goober5000 Note Added: 0014724
2013-02-22 00:32 Goober5000 Changeset attached => fs2open trunk r9542
2013-02-22 00:32 Goober5000 Note Added: 0014737
2013-02-22 00:32 Goober5000 Status assigned => resolved
2013-02-22 00:32 Goober5000 Resolution open => fixed
2013-02-26 14:56 chief1983 Note Added: 0014738
2013-02-26 21:01 Goober5000 Note Added: 0014739
+Issue History