View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000983 | FSSCP | docking | public | 2006-07-10 13:52 | 2006-11-01 04:53 |
| Reporter | taylor | Assigned To | taylor | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000983: Docked objects aren't created with SF_ARRIVING_STAGE_1 flag during warpin | ||||
| Description | I haven't had time to debug this more than just being anoyed by it, so this may be less of an issue that I'm seeing. The problem is obvious with the "A Lion at the Door" mission, when the Dis warps in it's cargo container (which is attached at the front) magically appears immediately. The SF_ARRIVING_STAGE_1 flag does not appear to be set (with a quick gdb session) for that cargo container, like it is for the Dis. This causes the container to always render when it should instead be hidden until the warpin timer expires and the ship moves to stage 2. It's possible that, because the cargo container doesn't have a warpin effect, may have the flag removed when it should have (that's my guess, but I haven't confirmed it). | ||||
| Additional Information | With a quick printf() it appears that all docked objects are always rendered when they shouldn't be, in the case of warpin. The clip plane is still in use regardless, but that does no good if the docked object is in front of the parent object since it has already passed the clip plane (at least in part). This was first noticed after 0000911 was fixed, but think that bug may have just hidden this one rather than caused it. | ||||
| Tags | No tags attached. | ||||
|
|
Uh oh. Have a look at http://fs2source.warpcore.org/cgi-bin/cvsweb/cvsweb.cgi/fs2_open/code/ship/shipfx.cpp?annotate=1.1 lines 760 and 805. It was commented out in :V:'s code. Actually, now that I look at it, I wonder if :V: just confused objnum and shipnum. The commented code is obviously buggy, but I wonder if it was commented for a reason or just because they didn't bother to debug it. Curiously, running it in retail with the code uncommented causes the freighter to render before it goes through the warp effect. ??? |
|
|
Hmm, that is pretty buggy. :V: also appeared to be going about it the wrong way since that is a rather strange method to address the problem (it wouldn't even work properly in several cases). A docked object should probably be totally slaved to the object it's docked to. In that case perhaps just adding the SF_ARRIVING_STAGE_1 flag is going in the same wrong direction that :V: did. I'm not sure what all the docking code can handle already, but it probably just needs to check all dock-related ship flags for SF_ARRIVING_STAGE_1 and not render any of them if one object has it (through existing ship_render() check for same flag). I think that the basic effect of SF_ARRIVING_STAGE_2 may pretty much be covered by the existing code. But, all of this also points out an even greater oversight of the handling of ships with docked objects in front than I originaly thought. shipfx_calculate_warp_dist/_time() don't take into account docked objects (only ones which change ship length are at issue) when figuring out how long it will take a ship to pass through the warp effect. The calculation to figure out where the warp effect should be created in space also suffers from this, not accounting for a large object docked to the front of a warping-in ship. |
|
|
Okay, a few points: 1) It's fairly easy to add SF_ARRIVING_STAGE_* to all docked objects. We might want to do that for clarity's sake anyway. There are probably a few places in the code that check for that; I know the radar blip is one. 2) Since retail handles warping in docked ships properly, the clipping plane might be linked to something other than SF_ARRIVING_STAGE_* and we might be looking in the wrong place. (That doesn't discount the remaining points here however. ;)) 3) I had to set up several calculation routines for the docking code anyhow. I already use dock_calc_cross_sectional_radius_perpendicular_to_axis in the warpout code to approximate this; you could very easily use it for warpin too. (Pedantically speaking, we want length instead of radius, but this won't matter unless we end up with a ship that's much taller than it is long, like the mothership in Homeworld. I may end up fixing it one of these days, but who knows.) 4) The only part I'm puzzled at is why uncommenting the retail code caused the *main* object to render improperly. (This is before it comes out of the warp effect - "behind" it, so to speak - and even after fixing the objnum/shipnum mixup. I'm not sure if the flipped Knossos warp effect has anything to do with it or not.) |
|
|
1) It's apparent from looking as :V:'s attempt that going with the flag is a rather bad hack though. To do it properly the one or more objects docked with another need to be evaluated as a single object, not multiple objects. To do anything else is inviting problems with timing and speed of warps. 2) It's linked to SF_ARRIVING, which is defined as (SF_ARRIVING_STAGE_1 | SF_ARRIVING_STAGE_2). I already now how the clipping stuff works and it is already setup properly, evaluating the docked objects, getting the base object, and setting the clipping plane based on it. 4) Don't know either. I'd have to debug to figure it out, but I think that would be a waste of time. :) (the flipped Knossos thing that I fixed before was stupid of me, I need to redo how I handled that since Axem's new warp POF renders very wrong there). Based on the same thing you did for the clipping check I know that 1) works well like that, not using flags. Though, the docked object will still pop through the clip plane since it was already past it when it starts rendering (checking "Lion at the Door"). But the only way to really fix that would be to handle docked objects in the warp time/length/position calculations, as already mentioned. |
|
|
Don't know if you'd actually want to use this, it was just for my test, but here is a diff of the fix I tried. After going over the code a bit more today I'm pretty convinced that going with the flag is a bad idea. Something like this would probably be better in any case where the check is needed, though you may be able to simplify this with a helper function check just for the two arrival flags. |
|
2006-07-21 05:04
|
warp_test.diff (2,465 bytes)
Index: code/ship/ship.cpp
===================================================================
RCS file: /home/fs2source/cvsroot/fs2_open/code/ship/ship.cpp,v
retrieving revision 2.336.2.17
diff -u -r2.336.2.17 ship.cpp
--- code/ship/ship.cpp 20 Jul 2006 00:41:26 -0000 2.336.2.17
+++ code/ship/ship.cpp 21 Jul 2006 02:51:41 -0000
@@ -5761,9 +5761,11 @@
int num = obj->instance;
Assert( num >= 0);
ship *shipp = &Ships[num];
+ ship *warp_shipp = NULL;
ship_info *si = &Ship_info[Ships[num].ship_info_index];
bool reset_proj_when_done = false;
-
+ dock_function_info dfi;
+
#if 0
// show target when attacking big ship
@@ -5832,12 +5834,26 @@
}
}
- MONITOR_INC( NumShipsRend, 1 );
+ MONITOR_INC( NumShipsRend, 1 );
- // Make ships that are warping in not render during stage 1
- if (!(shipp->flags & SF_ARRIVING_STAGE_1))
- {
+ bool is_first_stage_arrival = false;
+
+ memset( &dfi, 0, sizeof(dock_function_info) );
+ // look for a warping ship, whether for me or for anybody I'm docked with
+ dock_evaluate_all_docked_objects(obj, &dfi, ship_find_warping_ship_helper);
+
+ // if any docked objects are set to stage 1 arrival then set bool
+ if (dfi.maintained_variables.bool_value) {
+ warp_shipp = &Ships[dfi.maintained_variables.objp_value->instance];
+
+ is_first_stage_arrival = ((warp_shipp->flags & SF_ARRIVING_STAGE_1) > 0);
+ }
+
+
+ // Make ships that are warping in not render during stage 1
+ if ( !(is_first_stage_arrival) )
+ {
if ( Ship_shadows && shipfx_in_shadow( obj ) ) {
light_set_shadow(1);
} else {
@@ -6078,18 +6094,12 @@
// set up the model renderer to only draw the polygons in front
// of the warp in effect
int clip_started = 0;
- dock_function_info dfi;
-
- // look for a warping ship, whether for me or for anybody I'm docked with
- dock_evaluate_all_docked_objects(obj, &dfi, ship_find_warping_ship_helper);
// Warp_shipp points to the ship that is going through a
// warp... either this ship or the ship it is docked with.
- if ( dfi.maintained_variables.bool_value )
+ if ( warp_shipp != NULL )
{
- ship *warp_shipp = &Ships[dfi.maintained_variables.objp_value->instance];
-
- if(Ship_info[warp_shipp->ship_info_index].warpout_type == WT_DEFAULT)
+ if (Ship_info[warp_shipp->ship_info_index].warpout_type == WT_DEFAULT)
{
clip_started = 1;
g3_start_user_clip_plane( &warp_shipp->warp_effect_pos, &warp_shipp->warp_effect_fvec );
|
|
|
Okay, I just committed code to properly calculate length, width, or height of a docked group of objects. This, plus the cross-section method, should provide everything needed to fix 3). :) Incidentally, the word "rectum" is now part of the SCP codebase. :p :p :p EDIT: Bleh. Simultaneous posting again. :D Okay, I concur with your flag findings. edited on: 07-21-06 01:12 |
|
|
Ok, my fix is in, so that solves the obvious problem. Do you want to consider this resolved, or hold on to it so that we'll remember to try and fix all of this (the warpin for docked ships stuff) better later on? |
|
|
I like the scent of resolved bugs in the morning, so let's resolve this and open a new bug for the warpin stuff. :) I'm not sure exactly what needs to be done in the latter, so maybe you'd better open it. :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-07-10 13:52 | taylor | New Issue | |
| 2006-07-20 00:54 | Goober5000 | Note Added: 0006244 | |
| 2006-07-20 03:03 | taylor | Note Added: 0006255 | |
| 2006-07-20 04:34 | Goober5000 | Note Added: 0006256 | |
| 2006-07-20 06:15 | taylor | Note Added: 0006259 | |
| 2006-07-21 05:03 | taylor | Note Added: 0006274 | |
| 2006-07-21 05:04 | taylor | File Added: warp_test.diff | |
| 2006-07-21 05:10 | Goober5000 | Note Added: 0006275 | |
| 2006-07-21 05:12 | Goober5000 | Note Edited: 0006275 | |
| 2006-07-28 02:22 | taylor | Note Added: 0006361 | |
| 2006-07-28 13:00 | Goober5000 | Status | assigned => resolved |
| 2006-07-28 13:00 | Goober5000 | Resolution | open => fixed |
| 2006-07-28 13:00 | Goober5000 | Note Added: 0006364 | |
| 2006-07-28 13:01 | Goober5000 | Status | resolved => feedback |
| 2006-07-28 13:01 | Goober5000 | Resolution | fixed => reopened |
| 2006-07-28 13:01 | Goober5000 | Assigned To | Goober5000 => taylor |
| 2006-07-28 13:01 | Goober5000 | Status | feedback => resolved |
| 2006-11-01 04:53 | taylor | Resolution | reopened => fixed |
