View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002787 | FSSCP | docking | public | 2013-02-02 13:41 | 2013-02-27 02:01 |
| Reporter | FelixJim | Assigned To | Goober5000 | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Windows | OS | Windows 7 | OS Version | SP 1 |
| Product Version | 3.6.16 | ||||
| Summary | 0002787: set-docked and jettison-cargo-delay being called in the same event causes overlay of ships | ||||
| Description | Calling 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 Reproduce | See 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 Information | First noticed this whilst scripting calling these SEXPs and started getting null vec3d errors - I've been unable to reproduce this error in isolation though. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
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. |
|
|
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. |
|
|
Fix committed to trunk@9542. |
|
|
FelixJim mentioned in IRC that this did fix the issues in the test mission and also the null vec3d errors that were experienced. |
|
|
Yup, I tested it with the mission he provided before committing it. It's cool that it fixed null vec3d errors too. |
| 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 |
