2021-04-17 16:30 EDT

View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0001815FSSCPmultiplayerpublic2020-08-30 23:54
Assigned ToFSCyborg 
Product Version3.6.9 
Target VersionFixed in Version 
Summary0001815: Player AI ships do not initally attack on standalone
DescriptionBeen trying to figure this one out for awhile now. Sometimes the player AI ships just sit there at the start of a mission and basically let themselves be slaughtered. If given an order or they respawn they start behaving normally. I do not believe this behavior is happening during normal hosting.
Additional InformationHave notice in both TBP and FS2. Last noticed in Taylor's multi_test build dated 11/09. Attaching screen shot of them still sitting there in initial formation 1:15 into the mission. This was in M-01b.
TagsNo tags attached.
Attached Files

related to 0001633resolvedkarajorma Player ship AI do not obey play dead orders 
related to 0001863resolvedkarajorma Ships with arrival cue true and delay don't arrive on standalone 



taylor (administrator)

I noticed this during testing a couple of weeks ago. It only happened once though, and I couldn't reproduce it, so I thought it was some weird fluke related to what I was working on at the time. I'll try and reproduce it again this weekend during testing and see if I can't track it down.


karajorma (administrator)

Does this one still occur now that I've changed the way initial orders work?


FUBAR-BDHR (developer)

Yep. Just tried a quick run using the latest Knightly build (4955). AI just sat there doing nothing with a cap right in front of them. Even when the fighters arrived they sat there. Both BDHR standalones are running that build now.


karajorma (administrator)

I forgot that the changes I made last time would be carried out on the host, not the server. That means I need to include a change that may fix this bug. If it doesn't I'll take another look at it.


karajorma (administrator)

And another change, as soon as SVN is back up I'll commit it.


FUBAR-BDHR (developer)

Last edited: 2009-01-05 22:04

So far I only tested the standalone not attacking part of the bug. It's still there. Fired up M01b and the AI just sat there. I even drew the enemy fighters withing 200 of them and nothing. In that mission the AI don't have any initial orders. Haven't tried any missions where the fighters actually have initial orders. I'll test that out tonight.

Just checked out the fix for 1633 and it seems to work just fine. Turns that TBP ground attack mission into a whole new ballgame.


karajorma (administrator)

So this one is fixed now? Or is there still an issue with stand alones?


FUBAR-BDHR (developer)

Still an issue with the standalone but it's not an issue with initial orders. Normally a player AI ship with no orders will do whatever a normal AI would do. In most cases engage the enemy. For some reason they don't do that on a standalone they just either sit there or fly formation even when being shot at. When they respawn they return to normal behavior.

I'm wondering if there is some kind of timing issue where things like this and that arrival cue from that RI bug report don't get processed at mission start due to lag.


Goober5000 (administrator)

Last edited: 2009-01-19 19:56

I wonder if this is related to the form-on-wing change. Try a recent build.


FUBAR-BDHR (developer)

How recent? Already built or next Knightly?


Goober5000 (administrator)

The most recent nightly build should have the fix.


FUBAR-BDHR (developer)

Just tried r5045 and still the same behavior.


karajorma (administrator)

I tried it and noticed the same behaviour on both Standalone and normal multiplayer. The AI ships circle around in both for about a minute and then fly in to attack. In fact I actually had them attack more quickly on the standalone the first time.

If you fly towards the Moloch then the AI attack. Could this be the cause of the discrepancy you saw? Are you certain this isn't the default retail behaviour? I'll give the mission a try in FS2 but either both standalone and hosted server are doing the same thing now or it was simply a peculiarity of the fact that the ships in M1b don't appear to have initial orders from their behaviour (don't have a VP editor on this machine at the moment so I can't verify that).


karajorma (administrator)

Okay. Reverting Goober's revision 4958 seems to fix this and restore retail behaviour. I think I'll have to have a word with Goober over it.


karajorma (administrator)

Nope. It appears that this bug is intermittent and it merely happened to fix itself when I tried that.


Wanderer (developer)

Looking at the code this seems to be some thing of an odd case. Problem seems to be caused by having ships without any goals or default orders in the mission while the actual target ship is just beyond the 'engagement limit' of the fighters (seemingly odd distances possibly due random checkup times, use of vm_vec_mag_quick and bbox).

Not sure if this actually is a bug or not.


FUBAR-BDHR (developer)

Well no mission should play differently on a standalone then on a regular server. That and it's not retail behavior. Either one of those should be enough for it to be classified as a bug.

Wouldn't be near as bad if they would fight back when attacked. I've watched an entire wing get wiped out without taking evasive action of firing a shot in return. It's almost like the server doesn't even know they are AI ship until after respawn.


Goober5000 (administrator)

Try RC7 and see if that fixes it. It rolls back revision 2170 (referenced by r4958) which was a small deviation from the retail behavior of wings.


Goober5000 (administrator)

Bump for another test.


FUBAR-BDHR (developer)

Just tried m-02b and while the ships didn't just sit in one place they didn't try to attack the enemy ships or even shoot. Just kind of flew at initial speed.


karajorma (administrator)

Fix committed to trunk@9683.


karajorma (administrator)

Committing the fix for 1863 appears to have closed this one automatically too. Can we confirm if it is actually fixed or not please?


FUBAR-BDHR (developer)

Appears that this did not fix the issue. Started up a M-02b and the friendly AI just kind of sat around and got shot at still.


FSCyborg (developer)

This is hopefully a fix for it: https://github.com/scp-fs2open/fs2open.github.com/pull/2593

It seems like whenever AI were not given orders at mission start, the AI would try to form on the wing of the "Player_AI" but that Ai is of course the standalone pseudo-ship, so they would do nothing until given instructions. I am setting it to form on the wing of their team's leader or Alpha 1 depending on the mode.


FSCyborg (developer)

Fixed Merged

+Related Changesets

-Issue History
Date Modified Username Field Change
2008-11-10 22:33 FUBAR-BDHR New Issue
2008-11-10 22:33 FUBAR-BDHR File Added: screen0027.jpg
2008-11-10 23:16 taylor Note Added: 0010175
2008-11-10 23:16 taylor Status new => assigned
2008-11-10 23:16 taylor Assigned To => taylor
2008-11-20 15:05 karajorma Note Added: 0010242
2008-11-20 19:25 FUBAR-BDHR Note Added: 0010245
2008-12-16 19:49 taylor Assigned To taylor =>
2008-12-16 19:49 taylor Status assigned => new
2008-12-18 04:11 karajorma Status new => assigned
2008-12-18 04:11 karajorma Assigned To => karajorma
2008-12-30 16:28 karajorma Note Added: 0010493
2009-01-03 10:16 karajorma Relationship added related to 0001633
2009-01-04 07:03 karajorma Note Added: 0010504
2009-01-05 18:12 FUBAR-BDHR Note Added: 0010508
2009-01-05 22:04 FUBAR-BDHR Note Edited: 0010508
2009-01-07 10:02 karajorma Note Added: 0010509
2009-01-07 14:58 FUBAR-BDHR Note Added: 0010510
2009-01-19 19:56 Goober5000 Note Added: 0010549
2009-01-19 19:56 Goober5000 Note Edited: 0010549
2009-01-19 20:39 FUBAR-BDHR Note Added: 0010552
2009-01-19 21:14 Goober5000 Note Added: 0010555
2009-01-19 22:08 FUBAR-BDHR Note Added: 0010557
2009-01-31 12:10 karajorma Note Added: 0010626
2009-01-31 13:15 karajorma Note Added: 0010627
2009-01-31 14:30 karajorma Note Added: 0010628
2009-02-03 14:34 Wanderer Note Added: 0010646
2009-02-03 16:56 FUBAR-BDHR Note Added: 0010647
2012-07-25 00:06 Goober5000 Assigned To karajorma => Goober5000
2012-07-25 00:08 Goober5000 Note Added: 0013887
2012-12-19 00:48 Goober5000 Note Added: 0014539
2012-12-19 22:58 FUBAR-BDHR Note Added: 0014546
2013-05-02 02:01 karajorma Relationship added related to 0001863
2013-05-31 04:11 karajorma Changeset attached => fs2open trunk r9683
2013-05-31 04:11 karajorma Note Added: 0015101
2013-05-31 04:11 karajorma Status assigned => resolved
2013-05-31 04:11 karajorma Resolution open => fixed
2013-05-31 04:24 karajorma Note Added: 0015102
2013-05-31 04:24 karajorma Status resolved => feedback
2013-05-31 04:24 karajorma Resolution fixed => reopened
2013-06-05 23:37 FUBAR-BDHR Note Added: 0015121
2013-06-05 23:37 FUBAR-BDHR Status feedback => assigned
2020-04-28 02:27 Goober5000 Assigned To Goober5000 =>
2020-05-23 13:53 taylor Assigned To => taylor
2020-07-24 15:08 FSCyborg Note Added: 0017009
2020-07-24 15:09 FSCyborg Assigned To taylor => FSCyborg
2020-07-24 15:09 FSCyborg Status assigned => code review
2020-08-30 23:54 FSCyborg Status code review => resolved
2020-08-30 23:54 FSCyborg Note Added: 0017014
+Issue History