View Issue Details

IDProjectCategoryView StatusLast Update
0001888FSSCPgameplaypublic2010-07-13 22:52
ReporterWoolie Wool Assigned Toiss_mneur  
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.6.11 
Target Version3.6.12 RC1 
Summary0001888: autopilot cinematics broken in recent 3.6.10 builds, renders certain missions unplayable
DescriptionAutopilot missions using cinematics display various sorts of abnormalities when autopilot is attempted. These abnormalities include, but are not limited to: bizarre whirling camera angles, ships moving in unnatural directions (such as moving staight up while facing forwards), and even ships leaving autopilot up to 60 kilometers apart from each other. A download of a mod that displays these problems is in Additional Information.
Additional Informationhttp://www.freespacemods.net/download.php?view.15

Twist of Fate demo for FSPort 3.0.4. The first two missions use autopilot, displaying problems with newer builds. The first mission has serious camera issues but is playable, the second is broken.
TagsNo tags attached.

Relationships

related to 0001520 resolvedtaylor Autopilot leads you to a random place if you are not Alpha 1 

Activities

chief1983

2009-02-25 20:19

administrator   ~0010692

Do these cinematics include cutscene bars? It could be related to changes made for 0001768.

Woolie Wool

2009-02-26 02:17

reporter   ~0010695

It makes no difference whether cutscene bars are enabled or not.

ARSPR

2009-02-27 21:30

reporter   ~0010696

@Woolie Wool:

Unless I'm seriously wrong, cinematics autopilot DID work fine in older builds...

So it must have been broken by some more or less recent code change. It would be really nice if someone could pinpoint WHICH one was (SirKnightly is up for this very same reason). It'll save a lot of time to coders...

If I find enough time I'll try to do it next week but if you have time, please help doing it.

chief1983

2009-02-27 21:53

administrator   ~0010697

Also WW, do you have the revision number of one you've tested for sure? The posts in the 0001768 thread somewhat highlight which revisions have had cutscene related changes applied to them. You might try the cutscene bars fix I posted in that bug as well. It had some code that was the basis for the current revisions but was never actually committed exactly as it was in that build. Supposedly though, that might have worked better than any of the other tweaks that were made for it.

Woolie Wool

2009-02-28 19:16

reporter   ~0010698

I've confirmed autopilot to be broken in 5037, 5060, and 5063. I'm going to try your fix build now.

Woolie Wool

2009-02-28 21:08

reporter   ~0010699

That build is broken. I doubt 1768 is related much to this problem.

ARSPR

2009-03-03 09:54

reporter   ~0010705

Last edited: 2009-03-06 21:39

Well I really think this is caused by 0001520 fixes. Legacy autopilot doesn't work either, the game freezes and crashes after starting it. So we have a FUBAR autopilot in any case.

I upload two test missions one with cinematic and other without it. (I've tweaked them with notepad, erasing +Scores and so on, so they also run with old builds).

Nevertheless, I don't get the legacy auto crash trouble with 0001520 test missions. The differences between these new missions and old 0001520 ones are:
+ Old 0001520 missions only have two fighters in the same wing: Alpha 1 and Alpha 2.
+ New 1888 missions add a GTC Aeolus.
+ New mission ships have "nav-carry-status" flag. They weren't needed in 0001520 ones, because all the ships from your wing follow you in the autopilot run (they don't seem to need the "nav-carry-status" flag).



SUMMARY OF TESTS:

+ This build (http://www.hard-light.net/forums/index.php/topic,50258.0.html) dated from 2007-10-28:
- Cinematic: It runs fine.
- Legacy: As explained in 0001520, it doesn't run fine but, nevertheless it at least runs. (The problem was that the autopilot run was randomly aimed).

+ XT-2007-12-07:
- Cinematic: It still works perfectly.
- Legacy: I suppose it works as I posted in comment 0008640 in 0001520. (It was more or less in the way of being fixed).

+ XT-2008-02-15 and 02-17:
- Cinematic: It works slightly different (beginning of the issue??). Aeoulus doesn't exactly travel with you. I arrives 600 m far from you.
- Legacy: It is broken again like with 2007-10-28 build.

+ XT-2008-02-22. This build behaves like current builds or just the next "SVN-pure" one.

+ This build (http://www.hard-light.net/forums/index.php/topic,52856.0.html) dated from 2008-03-21 which included some partial fixes for 0001520:
- Cinematic: It doesn't run fine.
- Legacy: It freezes and crashes a few seconds after the beginning of the autopilot run.

(I've also tested the crashes with debug builds. They are the same, no error or warning shown).

As additional info: I suppose that 0001521 has nothing to do with it but, nevertheless, check it...

2009-03-03 09:55

 

2009-03-03 09:55

 

Auto Test Normal.fs2 (3,984 bytes)

chief1983

2009-03-03 14:48

administrator   ~0010707

Thanks for all the info ARSPR, that should definitely help whoever takes a look at it.

chief1983

2009-03-06 20:04

administrator   ~0010715

If this doesn't get fixed for 3.6.10, it will have to be one of the first fixes in the new version, or possibly to go in with Taylor's new FS2NetD code towards the summer in a 3.6.10.1

ARSPR

2009-03-06 21:27

reporter   ~0010716

Last edited: 2009-03-06 21:36

I really think this should be fixed before 3.6.10.

I mean, I haven't tested but it really seems Autopilot is FUBAR. So we would have an official release which wouldn't be able to run WCS or other mods.

(And it wouldn't be a TBP-ish issue, I mean, an official build not running a mod because a more or less defective game data set. It would be an official build with a serious known bug in it not running a fine game data set.)

chief1983

2009-03-06 21:37

administrator   ~0010717

Right and the only reason I would consider that is because this wasn't a previously existing feature in a release build. But I still don't want to have to do that either, hopefully it can be worked out along with the Fiction Viewer issues (that apparently still need to be reported).

Woolie Wool

2009-04-17 20:05

reporter   ~0010810

Is anyone still working on this? This is a serious problem.

ARSPR

2009-04-19 05:47

reporter   ~0010811

@Tolwin, KeldorKatarn or any other WCS crew member:

Aren't you suffering a fully broken autopilot?

I just made some some basic tests and auto seems FULLY FUBAR. If you can make it work, HOW DO YOU DO IT?

Your info can be quite valuable.

chief1983

2009-04-29 20:48

administrator   ~0010851

Here's some info on some builds which were around some possible autopilot-breaking commits:

http://www.freespacefaq.com/Misc-Downloads/Builds/Old/Team_Loadout_Build.7z (Jan 26 2008 Stable Branch, before a bunch of Feb autopilot commits)

http://fs2source.warpcore.org/exes/latest/20080312-Goober5000.7z (March 12 2008, I think stable branch, right before the below one if so)

http://fs2source.warpcore.org/exes/latest/C03162008.zip (March 16 2008, right after WMC committed some scripting stuff)

http://wwwcsif.cs.ucdavis.edu/~chos/fs2_open_trackir.zip (March 5, 2008, another one before the last one if the goober one turns out to be the HEAD branch or something)

There was also a commit on August 30, but that's since I started the nightly build system so you should be able to find a build from that time frame easily, before and after r4773

I sent this info to Woolie over IM but thought adding it to some mantis reports would be prudent.

portej05

2009-05-08 18:36

reporter   ~0010873

I don't know if the waypoints are driven by the autopilot/AI (my guess is that they are), but line 1061 in autopilot.cpp is assuming that the wing number and ship number are the same.

This:
ai_goal *aigp = &Wings[i].ai_goals[j];

should probably be this:
ai_goal *aigp = &Wings[Ships[i].wingnum].ai_goals[j];

(cheers kara)

I think this may be related since 1) there is a commit from taylor 4454 (I think) which added this line, and 2) waypoints are referenced nearby. Whether this affects this problem, I'm not 100% sure.

karajorma

2009-06-01 12:07

administrator   ~0010925

That fix is in the nightly builds so someone needs to test the bug and see if it's dead now.

ARSPR

2009-06-02 13:56

reporter   ~0010932

Fast test with r5318 (2009-05-29) and both attached missions.

+ Cinematic: It doesn't run fine. Aeolus arrives FAR, FAR away from you.
+ Legacy: It crashes about 5 s after starting the autopilot run.

It behaves like latest builds so the bug is fully alive.

portej05

2009-06-02 17:36

reporter   ~0010933

Can confirm these problems.
Adding if ( !wing_leader ) wing_leader = Pl_objp; at line 5471 of aicode.cpp fixes the crash. The problem is that wing_leader is being derefenrenced on line 5471 and it is NULL.
I suspect that this problem exists in ai_fly_to_ship as well. ai_waypoint appears to be a copy and paste of ai_fly_to_ship.
That wackiness on startup I haven't managed to figure out. But it's weird. DAMN weird.
oh, and for anyone that is looking at this and can't figure out how to cause it, try opening the mission and pressing Alt-N, Alt-A

iss_mneur

2010-06-17 03:52

developer   ~0012085

Last edited: 2010-06-17 03:53

The reason that the Aeolus arrives far away is that the player, and his wing leader fly in a massive circle around the the camera's location during the cinematic. This is why the camera does not track anything and just spins it was actually tracking the player in his large orbit.

I think I have fixed the issue, the missions attached to this report work correctly now and all three ships arrive in the same location. This build was done against the SVN version of the 3.6.12 branch. The build can be found: http://www.box.net/shared/6xlc4n1cok

Woolie Wool

2010-06-18 00:33

reporter   ~0012088

I think this may have indeed fixed it.

iss_mneur

2010-06-21 04:39

developer   ~0012098

Last edited: 2010-06-21 04:49

Okay, I have attached the patch.

There is only two code changes from the build that I posted a few days ago:
1) Camera always points at the player
2) Ported these changes to the identical section of ai_fly_to_ship.

EDIT: The patch was generated against the 3.6.12 branch but the areas that this code touches do not seem to have been changed for several years so it also applied without modification to trunk.

Also, there is an minor bug that I have observed but have not been able to isolate when using the mission that I attached (Auto Test Cinematic Alpha 1.fs2). The mission is a modified version of "Auto Test Cinematic" and I have occasionally (and never with the debugger running) observed the Alpha 2 turn around during the cinematic and start flying back the direction that the group had come.This results in him being about 2-3 clicks behind the player flying the wrong direction. Sometimes the wingman will continue to fly back to where we autopiloted from, but most of the time he will turn around within about 2-5 seconds and fly to the correct nav point. At this point I have given up on trying to isolate this bug as I have already spent several days trying to track it down.

Nevertheless this bug is fixed and any resulting weirdness only results in the wing man being a few km away, not 20+.

2010-06-21 04:40

 

1888_fix.patch (18,105 bytes)   
Index: code/ai/aicode.cpp
===================================================================
--- code/ai/aicode.cpp	(revision 6217)
+++ code/ai/aicode.cpp	(working copy)
@@ -304,6 +304,9 @@
 //	Move to a position relative to a dock bay using thrusters.
 float dock_orient_and_approach(object *docker_objp, int docker_index, object *dockee_objp, int dockee_index, int dock_mode, rotating_dockpoint_info *rdinfo = NULL);
 
+// The object that is declared to be the leader of the group formation for
+// the "autopilot"
+object *Autopilot_flight_leader = NULL;
 
 // ai_set_rearm_status takes a team (friendly, hostile, neutral) and a time.  This function
 // sets the timestamp used to tell is it is a good time for this team to rearm.  Once the timestamp
@@ -4262,38 +4265,37 @@
 	// this needs to be done for ALL SHIPS not just capships STOP CHANGING THIS
 	// ----------------------------------------------
 
-	object *wing_leader = get_wing_leader(aip->wing);
-
 	vec3d perp, goal_point;
 
 	bool carry_flag = ((shipp->flags2 & SF2_NAVPOINT_CARRY) || ((shipp->wingnum >= 0) && (Wings[shipp->wingnum].flags & WF_NAV_CARRY)));
 
 	if (AutoPilotEngaged && timestamp_elapsed(LockAPConv) && carry_flag
-		&& ((The_mission.flags & MISSION_FLAG_USE_AP_CINEMATICS) || (Pl_objp != wing_leader)) )
+		&& ((The_mission.flags & MISSION_FLAG_USE_AP_CINEMATICS) || (Pl_objp != Autopilot_flight_leader)) )
 	{
+		Assertion( Autopilot_flight_leader != NULL, "When under autopliot there must be a flight leader" );
 		// snap wings into formation them into formation
 		if (The_mission.flags & MISSION_FLAG_USE_AP_CINEMATICS) {
 			if (aip->wing != -1) {
 				int wing_index = get_wing_index(Pl_objp, aip->wing);
 
-				if (wing_leader != Pl_objp) {
+				if (Autopilot_flight_leader != Pl_objp) {
 					// not leader.. get our position relative to leader
-					get_absolute_wing_pos_autopilot(&goal_point, wing_leader, wing_index, aip->ai_flags & AIF_FORMATION_OBJECT);
+					get_absolute_wing_pos_autopilot(&goal_point, Autopilot_flight_leader, wing_index, aip->ai_flags & AIF_FORMATION_OBJECT);
 				} else {
 					j = 1+int( (float)floor(double(autopilot_wings[aip->wing]-1)/2.0) );
 
 					switch (autopilot_wings[aip->wing] % 2) {
 						case 1: // back-left
-							vm_vec_copy_normalize(&perp, &Player_obj->orient.vec.rvec);
+							vm_vec_copy_normalize(&perp, &Autopilot_flight_leader->orient.vec.rvec);
 							vm_vec_scale(&perp, -166.0f*j); // 166m is supposedly the optimal range according to tolwyn
-							vm_vec_add(&goal_point, &Player_obj->pos, &perp);
+							vm_vec_add(&goal_point, &Autopilot_flight_leader->pos, &perp);
 							break;
 
 						default: //back-right
 						case 0:
-							vm_vec_copy_normalize(&perp, &Player_obj->orient.vec.rvec);
+							vm_vec_copy_normalize(&perp, &Autopilot_flight_leader->orient.vec.rvec);
 							vm_vec_scale(&perp, 166.0f*j);
-							vm_vec_add(&goal_point, &Player_obj->pos, &perp);
+							vm_vec_add(&goal_point, &Autopilot_flight_leader->pos, &perp);
 							break;
 					}
 
@@ -4305,7 +4307,7 @@
 			vm_vec_sub(&perp, Navs[CurrentNav].GetPosition(), &Player_obj->pos);
 			vm_vector_2_matrix(&Pl_objp->orient, &perp, NULL, NULL);
 		} else {
-			vm_vec_scale_add(&perp, &Pl_objp->pos, &wing_leader->phys_info.vel, 1000.0f);
+			vm_vec_scale_add(&perp, &Pl_objp->pos, &Autopilot_flight_leader->phys_info.vel, 1000.0f);
 			ai_turn_towards_vector(&perp, Pl_objp, flFrametime, sip->srotation_time*3.0f*scale, slop_vec, NULL, 0.0f, 0);
 		}
 	} else {
@@ -4512,38 +4514,36 @@
 	// this needs to be done for ALL SHIPS not just capships STOP CHANGING THIS
 	// ----------------------------------------------
 
-	object *wing_leader = get_wing_leader(aip->wing);
-
 	vec3d perp, goal_point;
 
 	bool carry_flag = ((shipp->flags2 & SF2_NAVPOINT_CARRY) || ((shipp->wingnum >= 0) && (Wings[shipp->wingnum].flags & WF_NAV_CARRY)));
 
 	if (AutoPilotEngaged && timestamp_elapsed(LockAPConv) && carry_flag
-		&& ((The_mission.flags & MISSION_FLAG_USE_AP_CINEMATICS) || (Pl_objp != wing_leader)) )
+		&& ((The_mission.flags & MISSION_FLAG_USE_AP_CINEMATICS) || (Pl_objp != Autopilot_flight_leader)) )
 	{
 		// snap wings into formation them into formation
 		if (The_mission.flags & MISSION_FLAG_USE_AP_CINEMATICS) {
 			if (aip->wing != -1) {
 				int wing_index = get_wing_index(Pl_objp, aip->wing);
 
-				if (wing_leader != Pl_objp) {
+				if (Autopilot_flight_leader != Pl_objp) {
 					// not leader.. get our position relative to leader
-					get_absolute_wing_pos_autopilot(&goal_point, wing_leader, wing_index, aip->ai_flags & AIF_FORMATION_OBJECT);
+					get_absolute_wing_pos_autopilot(&goal_point, Autopilot_flight_leader, wing_index, aip->ai_flags & AIF_FORMATION_OBJECT);
 				} else {
 					j = 1+int( (float)floor(double(autopilot_wings[aip->wing]-1)/2.0) );
 
 					switch (autopilot_wings[aip->wing] % 2) {
 						case 1: // back-left
-							vm_vec_copy_normalize(&perp, &Player_obj->orient.vec.rvec);
+							vm_vec_copy_normalize(&perp, &Autopilot_flight_leader->orient.vec.rvec);
 							vm_vec_scale(&perp, -166.0f*j); // 166m is supposedly the optimal range according to tolwyn
-							vm_vec_add(&goal_point, &Player_obj->pos, &perp);
+							vm_vec_add(&goal_point, &Autopilot_flight_leader->pos, &perp);
 							break;
 
 						default: //back-right
 						case 0:
-							vm_vec_copy_normalize(&perp, &Player_obj->orient.vec.rvec);
+							vm_vec_copy_normalize(&perp, &Autopilot_flight_leader->orient.vec.rvec);
 							vm_vec_scale(&perp, 166.0f*j);
-							vm_vec_add(&goal_point, &Player_obj->pos, &perp);
+							vm_vec_add(&goal_point, &Autopilot_flight_leader->pos, &perp);
 							break;
 					}
 
@@ -4552,12 +4552,10 @@
 				Pl_objp->pos = goal_point;
 			}
 
-			vm_vec_sub(&perp, Navs[CurrentNav].GetPosition(), &Player_obj->pos);
+			vm_vec_sub(&perp, Navs[CurrentNav].GetPosition(), &Autopilot_flight_leader->pos);
 			vm_vector_2_matrix(&Pl_objp->orient, &perp, NULL, NULL);
 		} else {
-			if ( !wing_leader )
-				wing_leader = Pl_objp;
-			vm_vec_scale_add(&perp, &Pl_objp->pos, &wing_leader->phys_info.vel, 1000.0f);
+			vm_vec_scale_add(&perp, &Pl_objp->pos, &Autopilot_flight_leader->phys_info.vel, 1000.0f);
 			ai_turn_towards_vector(&perp, Pl_objp, flFrametime, sip->srotation_time*3.0f*scale, slop_vec, NULL, 0.0f, 0);
 		}
 	} else {
Index: code/autopilot/autopilot.cpp
===================================================================
--- code/autopilot/autopilot.cpp	(revision 6217)
+++ code/autopilot/autopilot.cpp	(working copy)
@@ -255,6 +255,7 @@
 	return true;
 }
 
+extern object* Autopilot_flight_leader;
 // ********************************************************************************************
 // Engages autopilot
 // This does:
@@ -270,6 +271,18 @@
 
 	AutoPilotEngaged = true;
 
+	// find the ship that is "leading" all of the ships when the player starts
+	// autopilot
+	// by default the ship that is leading the autopilot session the player's
+	// wing leader (if the player is the wing leader then it will be the
+	// player).
+	// TODO:implement a way to allow a FREDer to say a different ship is leader
+	Autopilot_flight_leader = get_wing_leader(Player_ship->wingnum);
+	if ( Autopilot_flight_leader == NULL ) {
+		// force player to be the leader if he doesn't have a wing
+		Autopilot_flight_leader = Player_obj;
+	}
+
 	if (The_mission.flags & MISSION_FLAG_USE_AP_CINEMATICS)
 		LockAPConv = timestamp(); // lock convergence instantly
 	else
@@ -400,7 +413,7 @@
 			// snap wings into formation them into formation
 			if (The_mission.flags & MISSION_FLAG_USE_AP_CINEMATICS &&  // only if using cinematics 
 				(Ships[i].wingnum != -1 && Wings[Ships[i].wingnum].flags & WF_NAV_CARRY) // only if in a wing
-				&& Player_obj != &Objects[Ships[i].objnum]) //only if not player object
+				&& Autopilot_flight_leader != &Objects[Ships[i].objnum]) //only if not flight leader's object
 			{	
 				ai_info	*aip = &Ai_info[Ships[i].ai_index];
 				int wingnum = aip->wing, wing_index = get_wing_index(&Objects[Ships[i].objnum], wingnum);
@@ -419,29 +432,29 @@
 					switch (wcount % 2)
 					{
 						case 1: // back-left
-							vm_vec_add(&perp, &zero, &Player_obj->orient.vec.rvec);
+							vm_vec_add(&perp, &zero, &Autopilot_flight_leader->orient.vec.rvec);
 							//vm_vec_sub(&perp, &perp, &Player_obj->orient.vec.fvec);
 							vm_vec_normalize(&perp);
 							vm_vec_scale(&perp, -166.0f*j); // 166m is supposedly the optimal range according to tolwyn
-							vm_vec_add(&goal_point, &Player_obj->pos, &perp);
+							vm_vec_add(&goal_point, &Autopilot_flight_leader->pos, &perp);
 							break;
 
 						default: //back-right
 						case 0:
-							vm_vec_add(&perp, &zero, &Player_obj->orient.vec.rvec);
+							vm_vec_add(&perp, &zero, &Autopilot_flight_leader->orient.vec.rvec);
 							//vm_vec_sub(&perp, &perp, &Player_obj->orient.vec.fvec);
 							vm_vec_normalize(&perp);
 							vm_vec_scale(&perp, 166.0f*j);
-							vm_vec_add(&goal_point, &Player_obj->pos, &perp);
+							vm_vec_add(&goal_point, &Autopilot_flight_leader->pos, &perp);
 							break;
 					}
 					autopilot_wings[wingnum] = wcount;
 					wcount++;
 				}
 				Objects[Ships[i].objnum].pos = goal_point;			
-				if (vm_vec_dist_quick(&Player_obj->pos, &Objects[Ships[i].objnum].pos) > distance)
+				if (vm_vec_dist_quick(&Autopilot_flight_leader->pos, &Objects[Ships[i].objnum].pos) > distance)
 				{
-					distance = vm_vec_dist_quick(&Player_obj->pos, &Objects[Ships[i].objnum].pos);
+					distance = vm_vec_dist_quick(&Autopilot_flight_leader->pos, &Objects[Ships[i].objnum].pos);
 				}
 			}
 			// lock primary and secondary weapons
@@ -540,9 +553,9 @@
 			vec3d right, front, up, offset;
 			for (i = 0; i < (int)capIndexes.size(); i++)
 			{
-				vm_vec_add(&right, &Player_obj->orient.vec.rvec, &zero);
-				vm_vec_add(&front, &Player_obj->orient.vec.fvec, &zero);
-				vm_vec_add(&up, &Player_obj->orient.vec.uvec, &zero);
+				vm_vec_add(&right, &Autopilot_flight_leader->orient.vec.rvec, &zero);
+				vm_vec_add(&front, &Autopilot_flight_leader->orient.vec.fvec, &zero);
+				vm_vec_add(&up, &Autopilot_flight_leader->orient.vec.uvec, &zero);
 				vm_vec_add(&offset, &zero, &zero);
 				if (Ship_info[Ships[capIndexes[i]].ship_info_index].flags & (SIF_CAPITAL | SIF_SUPERCAP))
 				{
@@ -610,7 +623,7 @@
 					vm_vec_scale(&up, (1+((float)floor((float)capship_placed[1]/3))));
 
 					// move ourselves up and out of the way of the smaller ships
-					vm_vec_add(&perp, &Player_obj->orient.vec.uvec, &zero);
+					vm_vec_add(&perp, &Autopilot_flight_leader->orient.vec.uvec, &zero);
 					vm_vec_scale(&perp, capship_spreads[2]);
 					vm_vec_add(&up, &up, &perp);
 
@@ -665,7 +678,7 @@
 					vm_vec_scale(&front, 2*(1+((float)floor((float)capship_placed[2]/3))));
 
 					// move "out" by 166*(wcount-1) so we don't bump into fighters
-					vm_vec_add(&perp, &Player_obj->orient.vec.rvec, &zero);
+					vm_vec_add(&perp, &Autopilot_flight_leader->orient.vec.rvec, &zero);
 					vm_vec_scale(&perp, 166.0f*float(wcount-1));
 					if ( (capship_placed[2] % 2) == 0)
 						vm_vec_add(&right, &right, &perp);
@@ -687,16 +700,16 @@
 				// global scale the position by 50%
 				//vm_vec_scale(&offset, 1.5);
 
-				vm_vec_add(&Objects[Ships[capIndexes[i]].objnum].pos, &Player_obj->pos, &offset);
+				vm_vec_add(&Objects[Ships[capIndexes[i]].objnum].pos, &Autopilot_flight_leader->pos, &offset);
 
-				if (vm_vec_dist_quick(&Player_obj->pos, &Objects[Ships[i].objnum].pos) > distance)
+				if (vm_vec_dist_quick(&Autopilot_flight_leader->pos, &Objects[Ships[i].objnum].pos) > distance)
 				{
-					distance = vm_vec_dist_quick(&Player_obj->pos, &Objects[Ships[i].objnum].pos);
+					distance = vm_vec_dist_quick(&Autopilot_flight_leader->pos, &Objects[Ships[i].objnum].pos);
 				}
 			}
 		}
 
-		ftemp = floor(Player_obj->phys_info.max_vel.xyz.z/speed_cap);
+		ftemp = floor(Autopilot_flight_leader->phys_info.max_vel.xyz.z/speed_cap);
 		if (ftemp >= 2.0f && ftemp < 4.0f)
 			tc_factor = 2;
 		else if (ftemp >= 4.0f && ftemp < 8.0f)
@@ -723,74 +736,74 @@
 			case 9:
 			case 16:
 				if (capship_placed[0] == 0)
-					vm_vec_sub(&perp, &zero, &Player_obj->orient.vec.uvec);
+					vm_vec_sub(&perp, &zero, &Autopilot_flight_leader->orient.vec.uvec);
 				else
 				{	// become up-left
-					vm_vec_add(&perp, &zero, &Player_obj->orient.vec.uvec);
-					vm_vec_sub(&perp, &perp, &Player_obj->orient.vec.rvec);
+					vm_vec_add(&perp, &zero, &Autopilot_flight_leader->orient.vec.uvec);
+					vm_vec_sub(&perp, &perp, &Autopilot_flight_leader->orient.vec.rvec);
 				}
 				break;
 
 			case 2: // up
 			case 10:
 			case 23:
-				vm_vec_add(&perp, &perp, &Player_obj->orient.vec.uvec);
+				vm_vec_add(&perp, &perp, &Autopilot_flight_leader->orient.vec.uvec);
 				if (capshipPresent) // become up-right
-					vm_vec_add(&perp, &perp, &Player_obj->orient.vec.rvec);
+					vm_vec_add(&perp, &perp, &Autopilot_flight_leader->orient.vec.rvec);
 				break;
 
 			case 3: // left
 			case 11:
 			case 22:
-				vm_vec_sub(&perp, &zero, &Player_obj->orient.vec.rvec);
+				vm_vec_sub(&perp, &zero, &Autopilot_flight_leader->orient.vec.rvec);
 				break;
 
 			case 4: // up-left
 			case 12:
 			case 21:
-				vm_vec_sub(&perp, &zero, &Player_obj->orient.vec.rvec);
-				vm_vec_add(&perp, &perp, &Player_obj->orient.vec.uvec);
+				vm_vec_sub(&perp, &zero, &Autopilot_flight_leader->orient.vec.rvec);
+				vm_vec_add(&perp, &perp, &Autopilot_flight_leader->orient.vec.uvec);
 				break;
 
 			case 5: // up-right
 			case 13:
 			case 20:
-				vm_vec_add(&perp, &zero, &Player_obj->orient.vec.rvec);
-				vm_vec_add(&perp, &perp, &Player_obj->orient.vec.uvec);
+				vm_vec_add(&perp, &zero, &Autopilot_flight_leader->orient.vec.rvec);
+				vm_vec_add(&perp, &perp, &Autopilot_flight_leader->orient.vec.uvec);
 				break;
 
 			case 6: // down-left
 			case 14:
 			case 19:
-				vm_vec_sub(&perp, &zero, &Player_obj->orient.vec.rvec);
+				vm_vec_sub(&perp, &zero, &Autopilot_flight_leader->orient.vec.rvec);
 				if (capship_placed[0] < 2)
-					vm_vec_sub(&perp, &perp, &Player_obj->orient.vec.uvec);
+					vm_vec_sub(&perp, &perp, &Autopilot_flight_leader->orient.vec.uvec);
 				else
-					vm_vec_add(&perp, &perp, &Player_obj->orient.vec.uvec);
+					vm_vec_add(&perp, &perp, &Autopilot_flight_leader->orient.vec.uvec);
 				break;
 
 			case 7: // down-right
 			case 15:
 			case 18:
-				vm_vec_add(&perp, &zero, &Player_obj->orient.vec.rvec);
+				vm_vec_add(&perp, &zero, &Autopilot_flight_leader->orient.vec.rvec);
 				if (capship_placed[0] < 1)
-					vm_vec_sub(&perp, &perp, &Player_obj->orient.vec.uvec);
+					vm_vec_sub(&perp, &perp, &Autopilot_flight_leader->orient.vec.uvec);
 				else
-					vm_vec_add(&perp, &perp, &Player_obj->orient.vec.uvec);
+					vm_vec_add(&perp, &perp, &Autopilot_flight_leader->orient.vec.uvec);
 				break;
 
 			default:
 			case 0: // right
 			case 8:
 			case 17:
-				perp = Player_obj->orient.vec.rvec;
+				perp = Autopilot_flight_leader->orient.vec.rvec;
 				break;
 
 		}
 		vm_vec_normalize(&perp);
 		//vm_vec_scale(&perp, 2*radius+distance);
 
-		vm_vec_scale(&perp,  Player_obj->radius+radius);
+		vm_vec_scale(&perp,  Autopilot_flight_leader->radius+radius);
 
 		// randomly scale up/down by up to 20%
 		j = 20-myrand()%40; // [-20,20]
@@ -852,6 +865,8 @@
 {
 	AutoPilotEngaged = false;
 
+	Autopilot_flight_leader = NULL;
+
 	set_time_compression(1);
 	lock_time_compression(false);
 	Player_use_ai = 0;
@@ -975,25 +990,39 @@
 
 void nav_warp(bool prewarp=false)
 {
-	// ok... find our end distance - norm1 is still a unit vector in the direction from the player to the navpoint
-	vec3d targetPos, tpos=Player_obj->pos, pos;
-	
-	vm_vec_sub(&pos, Navs[CurrentNav].GetPosition(), &Player_obj->pos);
+	/* ok... find our end distance - norm1 is still a unit vector in the
+	direction from the flight leader to the navpoint */
+	vec3d targetPos, tpos=Autopilot_flight_leader->pos, pos;
+
+	/* calculate a vector that we can use to make a path from the flight
+	leader's location to the nav point */
+	vm_vec_sub(&pos, Navs[CurrentNav].GetPosition(), &Autopilot_flight_leader->pos);
 	vm_vec_normalize(&pos);
 	vm_vec_scale(&pos, 250.0f); // we move by increments of 250
 	
+	/* using the vector of the flight leaders's path, simulate moving the 
+	flight along this path by checking the autopilot conditions as specific
+	intervals along the path*/
 	while (CanAutopilotPos(tpos))
 	{
 		vm_vec_add(&tpos, &tpos, &pos);
 	}
-	vm_vec_sub(&targetPos, &tpos, &Player_obj->pos); //targetPos is actually a projection in a the direction toward the nav
+	vm_vec_sub(&targetPos, &tpos, &Autopilot_flight_leader->pos);
+	/* targetPos is actually a vector that describes the exact 3D movement that
+	the flgith leader needs to execute to reach the location that the auto 
+	pilot is to shut off */
 
+	// Check if we are actually just setting up for the cinimatic shot of the
+	// flight flying on autopilot. Only jump halfway.  Also we also need to
+	// put the camera in the correct position to show the player this cinimatic
 	if (prewarp)
 	{
 		vm_vec_scale(&targetPos, 0.5);
 		vm_vec_add(&cameraPos, &cameraPos, &targetPos);
 	}
 
+	// Find all ships that are supposed to autopilot with the player and move them
+	// to the cinimatic location or the final destination
 	for (int i = 0; i < MAX_SHIPS; i++)
 	{
 		if (Ships[i].objnum != -1 && 
@@ -1060,7 +1089,7 @@
 					if(cam != NULL)
 					{
 						cam->set_position(&cameraPos);
-						cam->set_rotation_facing(&Player_obj->pos);
+						cam->set_rotation_facing(&Autopilot_flight_leader->pos);
 					}
 
 					CinematicStarted = true;
@@ -1148,7 +1177,7 @@
 		{
 			object *other_objp = &Objects[Ships[i].objnum];
 
-			if (vm_vec_dist_quick(&Player_obj->pos, &other_objp->pos) < (NavLinkDistance + other_objp->radius))
+			if (vm_vec_dist_quick(&Autopilot_flight_leader->pos, &other_objp->pos) < (NavLinkDistance + other_objp->radius))
 			{
 				Ships[i].flags2 &= ~SF2_NAVPOINT_NEEDSLINK;
 				Ships[i].flags2 |= SF2_NAVPOINT_CARRY;
1888_fix.patch (18,105 bytes)   

2010-06-21 04:41

 

Woolie Wool

2010-06-21 20:47

reporter   ~0012109

Last edited: 2010-06-21 23:56

I have noticed some issues with cinematics with more complicated autopilot sequences where the scene would move too quickly and some ships would end up near the nav point while others are some distance away. Also sometimes ships autopilot inside each other causing collision damage. The missions are at least playable but some bugfixing remains.

EDIT: More strangeness. The bug, if you are not number 1 in the wing, is affected by whether or not you are set as leader in FRED or not, but not consistently. In the first Twist of Fate mission, it appears to work correctly if you ARE NOT leader. In the second it appears to work if you ARE leader. This makes no sense. In both cases the player is Alpha 2.

EDIT II: Apparently putting a capship as a nav point can cause additional problems.

EDIT the third: Apparently using orb radar can cause nullvec3d crashes using autopilot. Talon1024's debug stack has been attached.

2010-06-21 21:04

 

fubarautopilot.png (630,624 bytes)

2010-06-21 23:56

 

nullvec3derror.txt (923 bytes)   
Null vec3d in vec3d normalize.
Trace out of vecmat.cpp and find offending code.

<no module>! KiFastSystemCallRet
<no module>! WaitForSingleObject + 18 bytes
<no module>! SCP_DumpStack + 354 bytes
<no module>! Warning + 430 bytes
<no module>! vm_vec_copy_normalize + 80 bytes
<no module>! vm_vec_normalize + 43 bytes
<no module>! radar_plot_object_orb + 709 bytes
<no module>! ship_process_post + 712 bytes
<no module>! obj_move_all_post + 553 bytes
<no module>! obj_move_all + 355 bytes
<no module>! game_simulation_frame + 1075 bytes
<no module>! game_frame + 491 bytes
<no module>! game_do_frame + 237 bytes
<no module>! game_do_state + 379 bytes
<no module>! gameseq_process_events + 237 bytes
<no module>! game_main + 782 bytes
<no module>! WinMain + 330 bytes
<no module>! __tmainCRTStartup + 358 bytes
<no module>! WinMainCRTStartup + 15 bytes
<no module>! RegisterWaitForInputIdle + 73 bytes
nullvec3derror.txt (923 bytes)   

Woolie Wool

2010-06-22 01:36

reporter   ~0012111

Videos by Talon1024 displaying abnormal autopilot behavior:

http://www.ciinet.org/kevin/myimages/private/ToF/apseq1.avi
http://www.ciinet.org/kevin/myimages/private/ToF/apseq2.avi

iss_mneur

2010-06-22 05:53

developer   ~0012112

Okay, so I have checked the video, as far as I can tell, that is the minor bug that I noted before. If you can get FSO to make one regularly that would be fantastic.

RE Edit: can this seems to be a variation of the bug shown in Talon1024's videos (btw how far a part to the ships endup?).

RE: Edit 2: can you provide a mission that exbihits this? The returning to the ship in the first mission of tof seemed to work fine for me.

RE: Edit 3: I need to take a closer look at, but it thus far I have not been able to reproduce (ie. I need more context (also, when running tof I do not have a hud that looks like the one in the video)).

Also, the version of TOF that is in the original report is painful to try and debug with all of the warnings popping up (which could be also causing issues unrelated to the bug in question). Do you have a fixed version that I can use?

Also, please try this build: http://www.box.net/shared/qbzjz1cisv It has some changed mechanics for when the AI gets released from flying to the goal waypoint.

Woolie Wool

2010-06-22 14:33

reporter   ~0012116

The demo of Twist of Fate was made before FSO release builds started reporting warnings and thus has lots of warnings that have been stamped out in current developer versions. The current version of Twist of Fate gives no warnings in a debug build, but it's also WIP developer material and you would have to provide an email address or other contact information so I can send it privately.

As for the HUD, the HUD itself is the FSPort 3.1 HUD (Twist of Fate requires FSPort to run) and the font was made by Talon1024 for another mod of mine and really isn't supposed to be there.

As for the build, I will try it later today when I have time.

chief1983

2010-06-22 15:33

administrator   ~0012117

Woolie, send him a PM on HLP or IRC :P

Talon1024

2010-06-22 22:18

reporter   ~0012121

Last edited: 2010-06-23 04:24

Link to my debugged version of the ToF demo: http://www.ciinet.org/kevin/myimages/private/ToF/tofdemo.7z

The missions in the demo are not exactly the same as the dev version, but there are similar issues that occur when autopiloting to nav 3 and 4.

EDIT: fs2_open.log attached

EDIT2: FS2_Open 3.6.12 RC3 seems to have fixed some of the problems I was experiencing with autopilot.

Woolie Wool

2010-06-22 22:19

reporter   ~0012122

I can confirm that the fighter breakaway issue with the new build is absent on my machine. Talon claims to still experience it. Also, the player must be the leader of the wing if autopiloting with capships or ships arrive out of formation.

At least for me it's getting better.

2010-06-22 22:35

 

talon1024_fs2_open.log (50,382 bytes)

iss_mneur

2010-06-25 15:16

developer   ~0012130

Talon1024: Thank you for the updated demo.

Talon1024: 3.6.12 RC3 included the fix that was patched into the binary linked in Note:0012085.

Woolie Wool: How are they out of formation? ARSPR's test mission as attached has a cap ships, but everyone arrives in formation when I run it.

--------------------

It seems it is the support ship that is causing a lot of the problem so, here is another test build. It has some extra logging code so if you can get the autopilot to misbehave, please attach a log (but make sure that you zip it).

The build also forbids the support ship from being requested while in autopilot and forbids starting autopilot while a support ship is present. I know this is not the most user friendly solution but if this fixes the problem then we can work on making it more user friendly. For this new failure mode another autopilot failure mode "$Support Present:", has been added to autopilot.tbl. The default autopilot.tbl in the binary has been updated. Currently the build refuses to do autopilot while the support ships is present regardless of what the support ship is doing, so when everyone is done with the ship make sure that you dismiss it. Build can be found here: http://www.box.net/shared/mci5d15x7f

Woolie Wool

2010-06-25 21:49

reporter   ~0012132

Last edited: 2010-06-25 22:03

Engaging autopilot with capships being carried and cap-waypoint-speed appears to break cap-waypoint-speed and enable time compression. If the ships have different speeds they arrive in different places. The second mission of the Twist of Fate demo should display this bug. Talon's log will be forthcoming when I receive it.

EDIT: I have it. Uploaded. It is 27 MB unzipped and appears to have megabyte upon megabyte of spew relating to the ships and autopilot.

EDIT: This log was taken with time compression disabled in the mission. This prevents ships from appearing to move very rapidly in the autopilot cutscene, but also makes the cutscene last much longer, on the order of 30 seconds.

2010-06-25 21:52

 

fs2_open(1).7z (158,544 bytes)

iss_mneur

2010-06-26 05:32

developer   ~0012135

Regarding cap-waypoint-speed, I can't say that I noticed anything like that in the test mission with the capship nor in the 2nd mission of the demo, but I think I have found the cause of the issue that you are describing (assuming I understood correctly what the bug actually is). Please try this build to see if it resolves the issue: http://www.box.net/shared/459l39yprq

Regarding the log, unless you encounter the ships flying off in different directions bug I don't need it as the log does not show anything useful beyond the state of the AI.

As for time compression. Time compression is impossible for the autopilot to engage while in Cinematic mode.

Woolie Wool

2010-06-26 14:56

reporter   ~0012139

Last edited: 2010-06-26 15:06

It did, we can confirm it. Time compression engaged normally, and when it was forced off, the autopilot cutscene took much longer.

EDIT: This build makes the camera focus on the fighters instead of following the faster capships but cap-waypoint-speed is still broken and the freighter and science cruiser arrive ahead of the miner.

EDIT2: Uploaded current development build of Twist of Fate's second mission, which displays the autopilot failure condition I'm talking about.

2010-06-26 15:05

 

tof-1-2a.fs2 (76,065 bytes)

iss_mneur

2010-06-26 15:31

developer   ~0012140

Last edited: 2010-06-26 16:06

What did?

The camera should be focused on the player's ship, no matter its position in the group. This is contrary to what the current trunk and 3.6.12 RC are doing as they focus on the "Flight leader"/"wing leader" (which is still normally a fighter). If you like it can be made configurable but it is not at this time.

EDIT: Tested the provided mission and I can defiantly confirm what you both have been saying, as I have not had the issues shown in that mission. All of the fighters came out of autopilot on top of each other, and the cap ships definitely were moving faster than the fighters (actually it looked like the fighters were not moving at all because the camera did not pan).

As for the time compression I see what you are talking about. After experimenting it seems that the game is applying about 4x compression (based on the rotation speed of "The Curies"'s panels). I will have to look at it closer.


Also, I have PM'ed you (Woolie Wool) on HLP with my email address as this makes it obvious that the demo is not exhibiting the same bugs as the mainline mod.

Woolie Wool

2010-06-26 16:13

reporter   ~0012141

Last edited: 2010-06-27 00:06

Time compression did activate, that is what "did". Anyway, if you noticed with that second mission, the fighters come out on top of each other, with the Honorius and Curie around 1.6km ahead, and the Mercutio right next to you. The Honorius and Curie break cap-waypoint-speed and move ahead of the rest of the convoy. When it works properly they all arrive in formation with the Honorius and Curie on either side of the Mercutio.

EDIT: Sometimes the support ship will not jump out when ordered. There needs to be a way for the game to detect and make disappear all active support ships when autopilot is engaged.

iss_mneur

2010-06-28 01:26

developer   ~0012152

Last edited: 2010-06-28 04:10

RE: Time compression. I did finally find the code that actually does the compression change. It seems that it is there to compensate for the fact that the camera does not move the opposite direction of the ships. I suppose to keep the cinematic exciting.

Is the use of time compression a problem? Most of the code to get the camera translation to work is still in the code base so it shouldn't be too hard to get this to work correctly.

--------------

RE: Beta wing being on top of Alpha wing on autopilot exit (and actually they were on top of each other during the cinematic as well (notice that there are four ships in the formation)). This seems to be caused by a data error. Beta Wing requires "nav-carry-status" flag set on it so that the engine knows to move to the side.

EDIT2: it seems there is also a code change that is required to make "nav-carry-status" work as expected on wings.

--------------

I still have not figured out the cause of the fighters stopping or the speed differences between the caps. I do know that it is not caused by "cap-waypoint-speed" though, because removing all calls to that sexp still result in the same problem.

EDIT: Also a data error. "Cargo 1" cannot have "nav-carry-status" set as it itself cannot move. Because docked objects are handled correctly the flag is not needed for "Cargo 1" to be carried by the freighter in autopilot.

--------------

I don't plan on leaving it to the player to dismiss the support ship. The current code that stops AP is there to test to see if it is the support ship that is causing the fighters to turn around during the cinematic and so that the support ship being so far away does not cause other issues (like when the AI's takeoff at max speed for the support ship leaving the player to fend for himself).

The plan is to check to see if there are ships waiting on the support ship and only block AP in that case. If no one has an outstanding request for a support ship (that is, the support ship is "idle") then have the support ship leave automatically.

As for the support ship not jumping out when ordered, do you have a repeatable set of circumstances that will cause it? Because as far as I can tell, the support ship always leaves when ordered, but the players order to the support ship to leave does not clear open requests for the support ship so the support ship will almost immediately jump back in. This will be fixed at the same time that I fix the AP so that the support ship will be dismissed when idle.

Talon1024

2010-06-29 05:54

reporter   ~0012155

Last edited: 2010-06-29 05:56

I just played the mission "Escort Transport" in the WCSaga Prologue campaign "Behind Enemy Lines." BEL uses the hardcoded autopilot

There are two ships in Alpha wing, the player, and his wingman. The player is Alpha 1 in this mission.

When I autopiloted to Nav 1, my wingman Alpha 2 broke off and turned around during the autopilot cutscene. I attached the fs2_open.log from when I ran that mission.

2010-06-29 05:55

 

iss_mneur

2010-06-30 00:03

developer   ~0012159

Talon1024: I have looked at the log that you posted. Which ship was it that turned around? Alpha 2 vanishes from the mission about 30 seconds in and I don't see it mentioned any more. Alpha 1 appears when it goes into autopilot (as it should) but there does not appear to be any other ships flying with it. I will download the demo later and have a closer look to see if I can reproduce the issue. In the mean time, please try and repeat the glitch with the new build linked below as it has far more information about what is going on in the mission.

-------------

I have another build. It has more debugging information that it logs (so please zip up any logs that you post as before). And again I only need the log if a ship takes off during autopilot. http://www.box.net/shared/ldgp4cr5xa

The above build also includes the fixed Support ship code so the player is only prevented from warping when there is an active repair or rearm order. The player can still tell the support ship to depart manually (which will interrupt in process rearm/repairs). Otherwise the support ship is told to depart as the player warps off.

This build also include the fixed code that allows Beta wing to not autopilot ontop of Alpha wing as long as it has nav-carry-status set for the entire wing.

I have also added a warning to the code about the potential cause of the broken speed limiting and made it so that the speed limiting does not break when you trigger the condition, the ships just move at the minimum capped speed (1 unit per second).

Talon1024

2010-06-30 04:36

reporter   ~0012160

Last edited: 2010-06-30 06:12

Yes, it was Alpha 2 that turned around during the autopilot cutscene.

EDIT: I reproduced the issue and uploaded a new log generated by your build.

EDIT2: Alpha 2 arrived at Nav 1 correctly

2010-06-30 04:51

 

fs2_open_log_BEL3M1.7z (186,320 bytes)

iss_mneur

2010-07-02 16:45

developer   ~0012169

I posted a new build for this bug on the forum so that I can get more people to test it as I have needed to make some changes to the ai code to fix this bug completely. Note that the build posted on the forum does not log like the ones that I have provided previously. The post can be found here: http://www.hard-light.net/forums/index.php?topic=70178.0

Sorry, I thought I had posted to this bug last night after the posting the forum thread.

Talon1024: I have found the cause of the bug and it is fixed in the binary that I provided on the forum.

iss_mneur

2010-07-05 03:41

developer   ~0012188

FYI: Another new build has been posted in the above forum thread.

iss_mneur

2010-07-11 07:00

developer   ~0012227

FYI: Yet another new build has been posted at the above forum. This will hopefully be the final version of the patch.

iss_mneur

2010-07-13 22:52

developer   ~0012232

Fixed in trunk revisions revisions 6291 <https://svn.icculus.org/fs2open?view=rev&revision=6291> and 6242 <https://svn.icculus.org/fs2open?view=rev&revision=6242>. Is currently being back-ported to 3.6.12.

Issue History

Date Modified Username Field Change
2009-02-24 02:44 Woolie Wool New Issue
2009-02-25 20:19 chief1983 Note Added: 0010692
2009-02-26 02:17 Woolie Wool Note Added: 0010695
2009-02-27 21:30 ARSPR Note Added: 0010696
2009-02-27 21:53 chief1983 Note Added: 0010697
2009-02-28 19:16 Woolie Wool Note Added: 0010698
2009-02-28 21:08 Woolie Wool Note Added: 0010699
2009-03-03 09:54 ARSPR Note Added: 0010705
2009-03-03 09:55 ARSPR File Added: Auto Test Cinematic.fs2
2009-03-03 09:55 ARSPR File Added: Auto Test Normal.fs2
2009-03-03 09:57 ARSPR Note Edited: 0010705
2009-03-03 14:48 chief1983 Note Added: 0010707
2009-03-06 20:04 chief1983 Note Added: 0010715
2009-03-06 20:04 chief1983 Priority normal => high
2009-03-06 20:07 chief1983 Relationship added related to 0001520
2009-03-06 21:27 ARSPR Note Added: 0010716
2009-03-06 21:34 ARSPR Note Edited: 0010705
2009-03-06 21:36 ARSPR Note Edited: 0010716
2009-03-06 21:37 ARSPR Note Edited: 0010705
2009-03-06 21:37 chief1983 Note Added: 0010717
2009-03-06 21:39 ARSPR Note Edited: 0010705
2009-04-17 20:05 Woolie Wool Note Added: 0010810
2009-04-19 05:47 ARSPR Note Added: 0010811
2009-04-29 20:48 chief1983 Note Added: 0010851
2009-05-08 18:36 portej05 Note Added: 0010873
2009-06-01 12:07 karajorma Note Added: 0010925
2009-06-02 13:56 ARSPR Note Added: 0010932
2009-06-02 17:36 portej05 Note Added: 0010933
2009-06-04 12:15 portej05 Status new => confirmed
2009-11-05 23:27 chief1983 Product Version 3.6.9 => 3.6.11
2009-11-05 23:27 chief1983 Target Version => 3.6.12 RC1
2010-06-16 03:03 iss_mneur Status confirmed => assigned
2010-06-16 03:03 iss_mneur Assigned To => iss_mneur
2010-06-17 03:52 iss_mneur Note Added: 0012085
2010-06-17 03:52 iss_mneur Status assigned => feedback
2010-06-17 03:53 iss_mneur Note Edited: 0012085
2010-06-18 00:33 Woolie Wool Note Added: 0012088
2010-06-21 04:39 iss_mneur Note Added: 0012098
2010-06-21 04:40 iss_mneur File Added: 1888_fix.patch
2010-06-21 04:41 iss_mneur File Added: Auto+Test+Cinematic+Alpha+1.fs2
2010-06-21 04:46 iss_mneur Note Edited: 0012098
2010-06-21 04:49 iss_mneur Note Edited: 0012098
2010-06-21 20:47 Woolie Wool Note Added: 0012109
2010-06-21 21:04 Woolie Wool File Added: fubarautopilot.png
2010-06-21 21:29 Woolie Wool Note Edited: 0012109
2010-06-21 21:29 Woolie Wool Note Edited: 0012109
2010-06-21 21:30 Woolie Wool Note Edited: 0012109
2010-06-21 22:29 Woolie Wool Note Edited: 0012109
2010-06-21 23:56 Woolie Wool Note Edited: 0012109
2010-06-21 23:56 Woolie Wool File Added: nullvec3derror.txt
2010-06-22 01:36 Woolie Wool Note Added: 0012111
2010-06-22 05:53 iss_mneur Note Added: 0012112
2010-06-22 14:33 Woolie Wool Note Added: 0012116
2010-06-22 15:33 chief1983 Note Added: 0012117
2010-06-22 22:18 Talon1024 Note Added: 0012121
2010-06-22 22:19 Woolie Wool Note Added: 0012122
2010-06-22 22:20 Talon1024 Note Edited: 0012121
2010-06-22 22:35 Talon1024 File Added: talon1024_fs2_open.log
2010-06-22 22:35 Talon1024 Note Edited: 0012121
2010-06-23 04:24 Talon1024 Note Edited: 0012121
2010-06-25 15:16 iss_mneur Note Added: 0012130
2010-06-25 21:49 Woolie Wool Note Added: 0012132
2010-06-25 21:52 Woolie Wool File Added: fs2_open(1).7z
2010-06-25 21:54 Woolie Wool Note Edited: 0012132
2010-06-25 22:03 Woolie Wool Note Edited: 0012132
2010-06-26 05:32 iss_mneur Note Added: 0012135
2010-06-26 14:56 Woolie Wool Note Added: 0012139
2010-06-26 15:04 Woolie Wool Note Edited: 0012139
2010-06-26 15:05 Woolie Wool File Added: tof-1-2a.fs2
2010-06-26 15:06 Woolie Wool Note Edited: 0012139
2010-06-26 15:31 iss_mneur Note Added: 0012140
2010-06-26 16:06 iss_mneur Note Edited: 0012140
2010-06-26 16:13 Woolie Wool Note Added: 0012141
2010-06-27 00:06 Woolie Wool Note Edited: 0012141
2010-06-28 01:26 iss_mneur Note Added: 0012152
2010-06-28 03:36 iss_mneur Note Edited: 0012152
2010-06-28 04:10 iss_mneur Note Edited: 0012152
2010-06-29 05:54 Talon1024 Note Added: 0012155
2010-06-29 05:55 Talon1024 File Added: fs2_open_BEL_Escort_Transport.7z
2010-06-29 05:56 Talon1024 Note Edited: 0012155
2010-06-30 00:03 iss_mneur Note Added: 0012159
2010-06-30 04:36 Talon1024 Note Added: 0012160
2010-06-30 04:51 Talon1024 File Added: fs2_open_log_BEL3M1.7z
2010-06-30 04:52 Talon1024 Note Edited: 0012160
2010-06-30 06:12 Talon1024 Note Edited: 0012160
2010-07-02 16:45 iss_mneur Note Added: 0012169
2010-07-05 03:41 iss_mneur Note Added: 0012188
2010-07-11 07:00 iss_mneur Note Added: 0012227
2010-07-13 22:52 iss_mneur Note Added: 0012232
2010-07-13 22:52 iss_mneur Status feedback => resolved
2010-07-13 22:52 iss_mneur Resolution open => fixed