View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001815 | FSSCP | multiplayer | public | 2008-11-11 03:33 | 2020-08-31 03:54 |
Reporter | FUBAR-BDHR | Assigned To | FSCyborg | ||
Priority | normal | Severity | major | Reproducibility | sometimes |
Status | resolved | Resolution | reopened | ||
Product Version | 3.6.9 | ||||
Summary | 0001815: Player AI ships do not initally attack on standalone | ||||
Description | Been 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 Information | Have 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. | ||||
Tags | No tags attached. | ||||
2008-11-11 03:33
|
|
|
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. |
|
Does this one still occur now that I've changed the way initial orders work? |
|
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. |
|
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. |
|
And another change, as soon as SVN is back up I'll commit it. |
|
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. |
|
So this one is fixed now? Or is there still an issue with stand alones? |
|
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. |
|
I wonder if this is related to the form-on-wing change. Try a recent build. |
|
How recent? Already built or next Knightly? |
|
The most recent nightly build should have the fix. |
|
Just tried r5045 and still the same behavior. |
|
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). |
|
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. |
|
Nope. It appears that this bug is intermittent and it merely happened to fix itself when I tried that. |
|
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. |
|
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. |
|
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. |
|
Bump for another test. |
|
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. |
|
Fix committed to trunk@9683. |
|
Committing the fix for 1863 appears to have closed this one automatically too. Can we confirm if it is actually fixed or not please? |
|
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. |
|
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. |
|
Fixed Merged |
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 |