|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001129||FSSCP||gameplay||public||2006-10-29 04:33||2012-12-04 22:51|
|Status||closed||Resolution||no change required|
|Platform||P4 2.8 HT - 1.5GB - 7800GS||OS||Windows XP||OS Version||SP2|
|Target Version||Fixed in Version|
|Summary||0001129: GTI Acheron quickly spinning over its axis or docking point|
|Description||In the mod "Into The Depths of Hell" in the mission "Final Evacuation" (CH2-12.fs2), the GTI Acheron named "Sentry 2" appears spinning at great speed over its axis or the docking point over a GVFR Satis ("GVFR Satis-2"). (I cannot determine its exact turning axis).|
You can colide with it in its "dance", which causes your instant death.
And the funny thing is that when "Sentry 2" gets hit by a laser, (my own laser as example), it stops spinning.
|Steps To Reproduce||Just play that mission. GTI Acheron "Sentry 2" is in it from the begining.|
|Additional Information||I've tested with and without mediavps, and it's the same. It happens even with only ItDoH2.vp, (the mod vp from Hades-Combine), and the retail vps.|
I've tested the mission from campaign (it is my actual mission) and from Simulator (through Ctrl+Shif+S pressing to show the mission).
gdb backtrace of where it gets modified:
Hardware watchpoint 1: Objects.orient.vec.fvec.xyz.x
Old value = -0.747945964
New value = -0.260800004
0x0000000000431691 in dock_orient_and_approach (docker_objp=0x17cdc70, docker_index=0, dockee_objp=0x17cda40,
dockee_index=0, dock_mode=6, rdinfo=0x7fff9af20d50) at ai/aicode.cpp:9913
9913 docker_objp->orient = dom;
#0 0x0000000000431691 in dock_orient_and_approach (docker_objp=0x17cdc70, docker_index=0, dockee_objp=0x17cda40,
dockee_index=0, dock_mode=6, rdinfo=0x7fff9af20d50) at ai/aicode.cpp:9913
0000001 0x0000000000431b25 in call_doa (child=0x17cdc70, parent=0x17cda40) at ai/aicode.cpp:12661
0000002 0x0000000000636e06 in obj_move_one_docked_object (objp=0x17cdc70, parent_objp=0x17cda40) at object/object.cpp:1390
0000003 0x0000000000633423 in dock_move_docked_children_tree (objp=0x17cdc70, parent_objp=0x17cda40)
0000004 0x0000000000633445 in dock_move_docked_children_tree (objp=0x17cda40, parent_objp=0x0) at object/objectdock.cpp:487
0000005 0x0000000000633541 in dock_move_docked_objects (objp=0x17cda40) at object/objectdock.cpp:464
0000006 0x0000000000637510 in obj_move_all (frametime=0.25) at object/object.cpp:2112
0000007 0x0000000000411eb3 in game_simulation_frame () at freespace2/freespace.cpp:5830
0000008 0x000000000041745f in game_frame (paused=0) at freespace2/freespace.cpp:6231
0000009 0x0000000000417a48 in game_do_frame () at freespace2/freespace.cpp:6673
0000010 0x0000000000417c79 in game_do_state (state=2) at freespace2/freespace.cpp:8483
#11 0x0000000000488d78 in gameseq_process_events () at gamesequence/gamesequence.cpp:651
0000012 0x0000000000414d25 in game_main (cmdline=0x27eb800 "-mod") at freespace2/freespace.cpp:9034
0000013 0x0000000000414ead in main (argc=5, argv=0x7fff9af21548) at freespace2/freespace.cpp:9171
|Tags||No tags attached.|
I've tried building up a mission using a docked Satis and an Acheron, but the bug doesn't show up. Nevertheless here you've got the mission (BadTry.fs2)
(ItDoH2.vp is needed)
I remember something like this happening with an Arcadia installation in retail. Been years so I'm not sure on the details but think it had something to do with rotating the installation in FRED and docking ships. I don't have the mod so I can't try it. Basically if you put the installation and didn't touch it it would work but as soon as you turned it something would go wrong. Gany installation didn't seem to have this problem. I still have all the test missions but don't know what is what anymore. Try your BadTry.fs2 with the installation rotated like 90 degrees and see if you get the bug. Only commenting because I've been meaning to try and see if that old Arcadia bug still exists if I can ever figure out exactally what it was.
I've just tested with a debug build (RC7.9) and it also happens.
OTOH, I've asked about it in HLP forum and it seems to be an old known issue. See my post (http://www.hard-light.net/forums/index.php/topic,40999.msg881038.html#msg881038) and Dark Hunter's answer.
I'll try tweaking BadTry.fs with FUBAR-BDHR's hint to see if I can reproduce it in a "clean" mission.
I'VE GOT IT!
I've copied with Notepad the starting positions of my ship, the Satis and the Acheron and I get the error.
See GoodTry.fs2 and forget about CH2-12.fs2. (Although you'll need ItDoH2.vp for GTI Acheron definition and files).
I'll try moving, turning the ships and so on to see if I can narrow down when you get the spin.
I'm leaving till tomorrow but here you've got some more info:
+ As expected it doesn't matter if I move Alpha 1.
+ Each time you save within FRED, the Acheron turns and moves a little (I've check that with WinDiff (???!??!). I upload a set of missions from GoodTry.fs2 (GoodTry-Zoom.rar). The first time I've just done "Zoom extension" and then I've saved. In the rest of missions, I've just saved the same file. All these missions suffer the bug.
|The orient keeps getting changed in dock_orient_and_approach(), for dock_mode DOA_DOCK_STAY. So, it's something screwy with the docking code. But I don't know whether this is from the new docking code, or whether it could have happend in retail as well. I think it would be best to leave this one to Goober, it's probably not safe for me to go mucking around in there. :)|
|Ack. Not another docking bug. :(|
Last edited: 2006-10-31 11:16
Hi, I've made 3 more tests from the original file GoodTry.fs2
+++ GoodTry-ByNotepad.fs2 +++
I've moved Acheron and Satis editing their $Locations with Notepad (+50, -50, +50). So their $Orientations are exactly the same as in GoodTry.fs2.
You get the bug.
+++ GoodTry-ByMouse.fs2 +++
I've changed their positions dragging them within FRED then saving. Three interesting things happen:
1. Acheron $Orientation has changed to be equal to GoodTry-Zoom1.fs2 one.
2. Satis $Orientation has also changed.
3. You DON'T get the bug.
+++ GoodTry-Undock.fs2 +++
I've added an event to make Satis undock when 10 s have passed. (Logically, I've used FRED).
This mission suffers the bug till Satis undocks. Then Acheron stops
An interesting thing is that Acheron $Orientation and $Location are like GoodTry-Zoom1.fs2 ones. So when you save, FRED always changes Acheron position in the same way.
(* Really, really small bump *)
Just don't forget about this funny docking bug... (at least don't forget about it too much).
(I can feel how Goober is just getting happier and happier about it ;) ).
Last edited: 2011-09-28 08:36
Just as a reminder. This bug is still alive. Just tested with 7811.
As the used mod is quite old, I upload just the GTI Acheron definition files in a vp zipped in GTI_Acheron.zip, (it just contains a tbm and its pof, as it uses retail textures), so you don't need ItDoH2.vp anymore
Nevertheless, the previously provided test missions use ItDoH2 weapons and ships as possible loadout options, so FS2 complains a little... (Nevertheless, they perfectly run, just don't change your loadout...).
|I can't help but notice that the Acheron has no MOI defined. Open the POF in PCS2, click the button to auto calculate and see if it goes away. I have seen all sorts of weird spinning behavior on models without MOI.|
Last edited: 2012-11-19 21:23
Alright, I've uploaded 1129Files.7z. That has everything necessary to reproduce the bug.
Based on what I'm reading there's 2 "issues" being discussed here. One is the docking issue with the Acheron. The other sounds like simple float error with position values as FRED saves missions. I'm ignoring the latter.
In my 7z there's the Acheron with MOI and tbm. There's the three missions from before, but the non-retail weapons and ships have been removed. One mission shows the bug. Another does not. The third shows the bug until the Satis undocks. So it's clearly a docking related issue.
You can drop all the files into a mod or just into freespace2/data (keeping things in the correct folders). It should run with no mods.
For kicks. Here's what the issue looks like. https://www.youtube.com/watch?v=wuhJZtYUipo
|The test mission model has identical docking slot positions. This caused the spinning. No code will be changed to fix it but a Warning has been committed to trunk @ 9394. Closing this bug as asset issue.|
|Fine work figuring this out. :yes:|
|2006-10-29 04:33||ARSPR||New Issue|
|2006-10-29 11:18||ARSPR||Note Added: 0007040|
|2006-10-29 11:19||ARSPR||File Added: BadTry.fs2|
|2006-10-29 19:04||FUBAR-BDHR||Note Added: 0007041|
|2006-10-30 12:22||ARSPR||Note Added: 0007043|
|2006-10-30 12:50||ARSPR||Note Added: 0007044|
|2006-10-30 12:51||ARSPR||File Added: GoodTry.fs2|
|2006-10-30 14:09||ARSPR||Note Added: 0007045|
|2006-10-30 14:11||ARSPR||File Added: GoodTry-Zoom.rar|
|2006-10-30 15:19||taylor||Note Added: 0007046|
|2006-10-30 15:19||taylor||Assigned To||=> Goober5000|
|2006-10-30 15:19||taylor||Status||new => assigned|
|2006-10-30 15:19||taylor||Additional Information Updated|
|2006-10-30 18:29||Goober5000||Note Added: 0007047|
|2006-10-31 10:55||ARSPR||File Added: MoreTestsFromGoodTry.rar|
|2006-10-31 11:13||ARSPR||Note Added: 0007049|
|2006-10-31 11:15||ARSPR||Note Edited: 0007049|
|2006-10-31 11:16||ARSPR||Note Edited: 0007049|
|2007-01-15 13:49||ARSPR||Note Added: 0007462|
|2011-09-28 08:25||ARSPR||Note Added: 0012867|
|2011-09-28 08:31||ARSPR||File Added: GTI_Acheron.zip|
|2011-09-28 08:33||ARSPR||Note Edited: 0012867|
|2011-09-28 08:36||ARSPR||Note Edited: 0012867|
|2011-11-29 15:39||AdmiralNelson||Note Added: 0012987|
|2012-11-19 19:42||MjnMixael||File Added: 1129Files.7z|
|2012-11-19 19:45||MjnMixael||Note Added: 0014103|
|2012-11-19 21:23||MjnMixael||Note Edited: 0014103||View Revisions|
|2012-12-04 14:58||Valathil||Note Added: 0014291|
|2012-12-04 14:58||Valathil||Status||assigned => closed|
|2012-12-04 14:58||Valathil||Resolution||open => no change required|
|2012-12-04 22:51||Goober5000||Note Added: 0014298|
|2012-12-04 22:51||Goober5000||Assigned To||Goober5000 => Valathil|