View Issue Details

IDProjectCategoryView StatusLast Update
0002787FSSCPdockingpublic2013-02-27 02:01
ReporterFelixJim Assigned ToGoober5000  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformWindowsOSWindows 7OS VersionSP 1
Product Version3.6.16 
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.

Activities

FelixJim

2013-02-02 13:41

reporter  

dockbug.7z (1,704 bytes)

Goober5000

2013-02-02 16:45

administrator   ~0014682

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

2013-02-20 04:09

administrator   ~0014724

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

2013-02-22 05:32

administrator   ~0014737

Fix committed to trunk@9542.

chief1983

2013-02-26 19:56

administrator   ~0014738

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

Goober5000

2013-02-27 02:01

administrator   ~0014739

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

Related Changesets

fs2open: trunk r9542

2013-02-22 01:13

Goober5000


Ported: N/A

Details Diff
proper movement of ships attached to other ships
fixes Mantis 0002787
Affected Issues
0002787
mod - /trunk/fs2_open/code/ai/aicode.cpp Diff File

Issue History

Date Modified Username Field Change
2013-02-02 13:41 FelixJim New Issue
2013-02-02 13:41 FelixJim Status new => assigned
2013-02-02 13:41 FelixJim Assigned To => Goober5000
2013-02-02 13:41 FelixJim File Added: dockbug.7z
2013-02-02 16:45 Goober5000 Note Added: 0014682
2013-02-20 04:09 Goober5000 Note Added: 0014724
2013-02-22 05:32 Goober5000 Changeset attached => fs2open trunk r9542
2013-02-22 05:32 Goober5000 Note Added: 0014737
2013-02-22 05:32 Goober5000 Status assigned => resolved
2013-02-22 05:32 Goober5000 Resolution open => fixed
2013-02-26 19:56 chief1983 Note Added: 0014738
2013-02-27 02:01 Goober5000 Note Added: 0014739