View Issue Details

IDProjectCategoryView StatusLast Update
0001815FSSCPmultiplayerpublic2020-08-31 03:54
ReporterFUBAR-BDHR Assigned ToFSCyborg  
PrioritynormalSeveritymajorReproducibilitysometimes
Status resolvedResolutionreopened 
Product Version3.6.9 
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.

Relationships

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

Activities

2008-11-11 03:33

 

screen0027.jpg (55,881 bytes)   
screen0027.jpg (55,881 bytes)   

taylor

2008-11-11 04:16

administrator   ~0010175

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

2008-11-20 20:05

administrator   ~0010242

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

FUBAR-BDHR

2008-11-21 00:25

developer   ~0010245

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

2008-12-30 21:28

administrator   ~0010493

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

2009-01-04 12:03

administrator   ~0010504

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

FUBAR-BDHR

2009-01-05 23:12

developer   ~0010508

Last edited: 2009-01-06 03: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

2009-01-07 15:02

administrator   ~0010509

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

FUBAR-BDHR

2009-01-07 19:58

developer   ~0010510

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

2009-01-20 00:56

administrator   ~0010549

Last edited: 2009-01-20 00:56

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

FUBAR-BDHR

2009-01-20 01:39

developer   ~0010552

How recent? Already built or next Knightly?

Goober5000

2009-01-20 02:14

administrator   ~0010555

The most recent nightly build should have the fix.

FUBAR-BDHR

2009-01-20 03:08

developer   ~0010557

Just tried r5045 and still the same behavior.

karajorma

2009-01-31 17:10

administrator   ~0010626

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

2009-01-31 18:15

administrator   ~0010627

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

2009-01-31 19:30

administrator   ~0010628

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

Wanderer

2009-02-03 19:34

developer   ~0010646

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

2009-02-03 21:56

developer   ~0010647

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

2012-07-25 04:08

administrator   ~0013887

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

2012-12-19 05:48

administrator   ~0014539

Bump for another test.

FUBAR-BDHR

2012-12-20 03:58

developer   ~0014546

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

2013-05-31 08:11

administrator   ~0015101

Fix committed to trunk@9683.

karajorma

2013-05-31 08:24

administrator   ~0015102

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

2013-06-06 03:37

developer   ~0015121

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

2020-07-24 19:08

developer   ~0017009

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

2020-08-31 03:54

developer   ~0017014

Fixed Merged

Related Changesets

fs2open: trunk r9683

2013-05-31 05:09

karajorma


Ported: N/A

Details Diff
Fix for Mantis 1863 (Ships with an arrival cue of true and a delay do not arrive on the standalone). Might possibly fix Mantis 1815 too. Affected Issues
0001815, 0001863
mod - /trunk/fs2_open/code/freespace2/freespace.cpp Diff File

Issue History

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