Source Code Project Mantis - FSSCP
View Issue Details
0001815FSSCPmultiplayerpublic2008-11-10 22:332020-08-30 23:54
ReporterFUBAR-BDHR 
Assigned ToFSCyborg 
PrioritynormalSeveritymajorReproducibilitysometimes
StatusresolvedResolutionreopened 
PlatformOSOS Version
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.
related to 0001633resolved karajorma Player ship AI do not obey play dead orders 
related to 0001863resolved karajorma Ships with arrival cue true and delay don't arrive on standalone 
Attached Filesjpg screen0027.jpg (55,881) 2008-11-10 22:33
http://scp.indiegames.us/mantis/file_download.php?file_id=1143&type=bug
jpg

Notes
(0010175)
taylor   
2008-11-10 23:16   
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   
2008-11-20 15:05   
Does this one still occur now that I've changed the way initial orders work?
(0010245)
FUBAR-BDHR   
2008-11-20 19:25   
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   
2008-12-30 16:28   
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   
2009-01-04 07:03   
And another change, as soon as SVN is back up I'll commit it.
(0010508)
FUBAR-BDHR   
2009-01-05 18:12   
(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   
2009-01-07 10:02   
So this one is fixed now? Or is there still an issue with stand alones?
(0010510)
FUBAR-BDHR   
2009-01-07 14:58   
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   
2009-01-19 19:56   
I wonder if this is related to the form-on-wing change. Try a recent build.

(0010552)
FUBAR-BDHR   
2009-01-19 20:39   
How recent? Already built or next Knightly?
(0010555)
Goober5000   
2009-01-19 21:14   
The most recent nightly build should have the fix.
(0010557)
FUBAR-BDHR   
2009-01-19 22:08   
Just tried r5045 and still the same behavior.
(0010626)
karajorma   
2009-01-31 12:10   
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   
2009-01-31 13:15   
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   
2009-01-31 14:30   
Nope. It appears that this bug is intermittent and it merely happened to fix itself when I tried that.
(0010646)
Wanderer   
2009-02-03 14:34   
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   
2009-02-03 16:56   
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   
2012-07-25 00:08   
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   
2012-12-19 00:48   
Bump for another test.
(0014546)
FUBAR-BDHR   
2012-12-19 22:58   
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   
2013-05-31 04:11   
Fix committed to trunk@9683.
(0015102)
karajorma   
2013-05-31 04:24   
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   
2013-06-05 23:37   
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   
2020-07-24 15:08   
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   
2020-08-30 23:54   
Fixed Merged

Issue History
2008-11-10 22:33FUBAR-BDHRNew Issue
2008-11-10 22:33FUBAR-BDHRFile Added: screen0027.jpg
2008-11-10 23:16taylorNote Added: 0010175
2008-11-10 23:16taylorStatusnew => assigned
2008-11-10 23:16taylorAssigned To => taylor
2008-11-20 15:05karajormaNote Added: 0010242
2008-11-20 19:25FUBAR-BDHRNote Added: 0010245
2008-12-16 19:49taylorAssigned Totaylor =>
2008-12-16 19:49taylorStatusassigned => new
2008-12-18 04:11karajormaStatusnew => assigned
2008-12-18 04:11karajormaAssigned To => karajorma
2008-12-30 16:28karajormaNote Added: 0010493
2009-01-03 10:16karajormaRelationship addedrelated to 0001633
2009-01-04 07:03karajormaNote Added: 0010504
2009-01-05 18:12FUBAR-BDHRNote Added: 0010508
2009-01-05 22:04FUBAR-BDHRNote Edited: 0010508
2009-01-07 10:02karajormaNote Added: 0010509
2009-01-07 14:58FUBAR-BDHRNote Added: 0010510
2009-01-19 19:56Goober5000Note Added: 0010549
2009-01-19 19:56Goober5000Note Edited: 0010549
2009-01-19 20:39FUBAR-BDHRNote Added: 0010552
2009-01-19 21:14Goober5000Note Added: 0010555
2009-01-19 22:08FUBAR-BDHRNote Added: 0010557
2009-01-31 12:10karajormaNote Added: 0010626
2009-01-31 13:15karajormaNote Added: 0010627
2009-01-31 14:30karajormaNote Added: 0010628
2009-02-03 14:34WandererNote Added: 0010646
2009-02-03 16:56FUBAR-BDHRNote Added: 0010647
2012-07-25 00:06Goober5000Assigned Tokarajorma => Goober5000
2012-07-25 00:08Goober5000Note Added: 0013887
2012-12-19 00:48Goober5000Note Added: 0014539
2012-12-19 22:58FUBAR-BDHRNote Added: 0014546
2013-05-02 02:01karajormaRelationship addedrelated to 0001863
2013-05-31 04:11karajormaChangeset attached => fs2open trunk r9683
2013-05-31 04:11karajormaNote Added: 0015101
2013-05-31 04:11karajormaStatusassigned => resolved
2013-05-31 04:11karajormaResolutionopen => fixed
2013-05-31 04:24karajormaNote Added: 0015102
2013-05-31 04:24karajormaStatusresolved => feedback
2013-05-31 04:24karajormaResolutionfixed => reopened
2013-06-05 23:37FUBAR-BDHRNote Added: 0015121
2013-06-05 23:37FUBAR-BDHRStatusfeedback => assigned
2020-04-28 02:27Goober5000Assigned ToGoober5000 =>
2020-05-23 13:53taylorAssigned To => taylor
2020-07-24 15:08FSCyborgNote Added: 0017009
2020-07-24 15:09FSCyborgAssigned Totaylor => FSCyborg
2020-07-24 15:09FSCyborgStatusassigned => code review
2020-08-30 23:54FSCyborgStatuscode review => resolved
2020-08-30 23:54FSCyborgNote Added: 0017014