[chief1983]

That sounds like a silly restriction on FREDers.

[Iss Mneur]

That sounds like a silly restriction on FREDers.

What does?  The locking the weapons?

[chief1983]

No the enemy ships in range thing.

[Iss Mneur]

I suppose.  Though remember that this code was written specifically for WCSaga, so it follows the Wing Commander rules. 

But honestly, I don't know if anyone would want to allow the player to autopilot while the their are enemies near, because (to be clear) the autopilot is not a intrasystem jump like FreeSpace uses whereas under autopilot the ships envolved are physically "flying" the route (in fact, even though the cinematic autopilot code slews the ships around the world it still checks the "flight path" for the rules so that you don't autopilot past some enemies).

That being said, removing that test with a tbl setting would be easy enough if someone actually wants this type of feature.

[The E]

A "$No autopilot if enemy within distance: NUMBER" setting would be good (defaulting to 5000).

[Iss Mneur]

Okay, new build (hopefully the last before it gets put into trunk), is available in the first post.

Adds: $Interrupt autopilot if enemy within distance:, $Interrupt autopilot if asteroid within distance:, and $Lock Weapons During Autopilot:.
Cleans up some more duplicated code.  Removed some useless code.
Clarified some warnings that may be emitted by the new code.  Also clarified some comments in the code.

Delaying pushing the patch to chief1983 until July 13th.

[Woolie Wool]

Does that mean I can have a cinematic autopilot and have enemies jump in midway between the two nav points (or simply have them sitting there, waiting for someone to stumble across them) and the cinematic autopilot will drop out as the player is waylaid by the enemies?

[chief1983]

Interrupt may be misleading, I think the original intent was to prevent it being initialized in the first place.

[Iss Mneur]

Interrupt may be misleading, I think the original intent was to prevent it being initialized in the first place.

No, interrupt is exactly what it will do.

Does that mean I can have a cinematic autopilot and have enemies jump in midway between the two nav points (or simply have them sitting there, waiting for someone to stumble across them) and the cinematic autopilot will drop out as the player is waylaid by the enemies?

No. Yes.

The enemies (or asteroids for that matter) have to be within the Interrupt distance of the flight path when the autopilot is calculating the route.  So  the enemies cannot warp in after the autopilot has engaged, but if they are just sitting there within Interrupt distance of the flight path (same goes for the asteroids) then the autopilot will drop the group out the Interrupt distance from the object causing the interrupt.

I have not changed this behaviour, just exposed the distance value to the MODer.  This also applies to both the cinematic autopilot and the time compression autopilot.

[Talon 1024]

I'm sorry I was so late on this, but if a ship is given the ai-waypoints goal, it only follows the waypoint path once, instead of patrolling the path like it should.

[chief1983]

Can't you reset the goal upon completion?

[Iss Mneur]

I'm sorry I was so late on this, but if a ship is given the ai-waypoints goal, it only follows the waypoint path once, instead of patrolling the path like it should.

Please try: http://www.box.net/shared/j235mil0mf

[Talon 1024]

Hmmm...  Using this build, the ai-waypoints AI goal does not work properly if it is in the wing/ship's initial orders, but it does work properly if that AI goal is assigned via a SEXP.

EDIT: Edited for clarity

[Iss Mneur]

Okay, I have looked at the code that assigns the initial orders, and it seems that initial orders are sexps  and as such implemented by the sexp system which means it follows pretty much exactly the same code path as when the goal is assigned by the events sexps.  Also, the only part of the ai code that I have changed for this patch interacts at the mode level of the AI (ie the part that actually makes a goal happen).

Thus, Talon 1024, can you please provide a basic mission that exhibits ai-waypoints not working as initial orders and a mission that exhibits ai-waypoints working as a sexp.

Also, does this issue only appear in builds after my autopilot fixes where added, or before?

[chief1983]

Easy build to test that last bit would be RC3, as it had no autopilot fixes but is otherwise very close to RC4 which does have them all save for this last tweak.

[The E]

Please try this build:
http://blueplanet.fsmods.net/E/fs2_open_3_6_13d_INF_SSE2.7z

It seems that the waypoint goal was cleared, regardless of whether or not the AI was ordered to fly them once or repeatedly.

[Iss Mneur]

Please try this build:
http://blueplanet.fsmods.net/E/fs2_open_3_6_13d_INF_SSE2.7z

It seems that the waypoint goal was cleared, regardless of whether or not the AI was ordered to fly them once or repeatedly.

Did my build provided in my post further up not fix ai-waypoints for you?

The issue now it seems is that ai-waypoints does not repeat when used as an initial order for a wing or ship, but works find when used as an order later.

[The E]

Hey, I did not test this (due to a lack of a test case), I am just trying to fix the issue.

Here's the code patch:

Code: [Select]

Index: aicode.cpp
===================================================================
--- aicode.cpp (revision 6332)
+++ aicode.cpp (working copy)
@@ -4453,18 +4453,18 @@
  aip->wp_index = 0; // go back to the start.
  } else {
  aip->wp_index = (wpl->count - 1); // stay on the last waypoint
+ // Log a message that the wing or ship reached his waypoint and
+ // remove the goal from the AI goals of the ship pr wing, respectively.
+ // Wether or not we should treat this as a ship or a wing is determined by
+ // ai_fly_to_target_position when it marks the AI directive as complete
+ if ( treat_as_ship ) {
+ ai_mission_goal_complete( aip ); // this call should reset the AI mode
+ mission_log_add_entry( LOG_WAYPOINTS_DONE, Ships[Pl_objp->instance].ship_name, wpl->name, -1 );
+ } else {
+ ai_mission_wing_goal_complete( Ships[Pl_objp->instance].wingnum, &(aip->goals[aip->active_goal]) );
+ mission_log_add_entry( LOG_WAYPOINTS_DONE, Wings[Ships[Pl_objp->instance].wingnum].name, wpl->name, -1 );
+ }
  }
- // Log a message that the wing or ship reached his waypoint and
- // remove the goal from the AI goals of the ship pr wing, respectively.
- // Wether or not we should treat this as a ship or a wing is determined by
- // ai_fly_to_target_position when it marks the AI directive as complete
- if ( treat_as_ship ) {
- ai_mission_goal_complete( aip ); // this call should reset the AI mode
- mission_log_add_entry( LOG_WAYPOINTS_DONE, Ships[Pl_objp->instance].ship_name, wpl->name, -1 );
- } else {
- ai_mission_wing_goal_complete( Ships[Pl_objp->instance].wingnum, &(aip->goals[aip->active_goal]) );
- mission_log_add_entry( LOG_WAYPOINTS_DONE, Wings[Ships[Pl_objp->instance].wingnum].name, wpl->name, -1 );
- }
  }
  }
 }

The problem, as I understood it by reading the code, was that the ai-waypoints goal was cleared once the ship reached the last waypoint, regardless of whether or not it was supposed to repeat the waypoint path. I think this should fix it, but as noone was around on IRC to talk to regarding the AI, I kinda had to take a guess.

[Talon 1024]

Hmmm...  Using this build, the ai-waypoints AI goal does not work properly if it is in the wing/ship's initial orders...

Oh shoot.  I'm sorry.

This was actually a stupid oversight on my part.  I had two wings, one of them was given the ai-waypoints goal (Bravo), and one was given the ai-waypoints-once goal (Charlie).  I had an event that fired once Charlie wing finished it's waypoints, and Charlie wing coincidentially finished their waypoints at the same time that Bravo wing had nearly finished theirs, and that event cleared Bravo's orders and assigned Charlie the orders to patrol another waypoint path.  Bravo's AI goals being cleared had lead me to believe that this SEXP was not working properly if it was being called from initial orders, but that was not the case.

[Zacam]

So, to clarify, the build Iss Mneur linked on 07-28-2010 does work? Or that a build earlier than that worked?