2020-10-19 13:10 EDT


View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0001815FSSCPmultiplayerpublic2020-08-30 23:54
ReporterFUBAR-BDHR 
Assigned ToFSCyborg 
PrioritynormalSeveritymajorReproducibilitysometimes
StatusresolvedResolutionreopened 
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

-Relationships
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 
+Relationships

-Notes

~0010175

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.

~0010242

karajorma (administrator)

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

~0010245

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.

~0010493

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.

~0010504

karajorma (administrator)

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

~0010508

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.

~0010509

karajorma (administrator)

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

~0010510

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.

~0010549

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.

~0010552

FUBAR-BDHR (developer)

How recent? Already built or next Knightly?

~0010555

Goober5000 (administrator)

The most recent nightly build should have the fix.

~0010557

FUBAR-BDHR (developer)

Just tried r5045 and still the same behavior.

~0010626

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).

~0010627

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.

~0010628

karajorma (administrator)

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

~0010646

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.

~0010647

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.

~0013887

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.

~0014539

Goober5000 (administrator)

Bump for another test.

~0014546

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.

~0015101

karajorma (administrator)

Fix committed to trunk@9683.

~0015102

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?

~0015121

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.

~0017009

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.

~0017014

FSCyborg (developer)

Fixed Merged
+Notes

+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