Talk:Assault

Good job on the article Tom :) -Zevensoft

I'm quite proud of it myself. ;) --TomEdwards 10:12, 29 Jun 2005 (PDT)

Don't know about anyone else, but I'm finding using and documenting the AI extrememly satisfying. :-) Have a look at the example map I've posted and see how it works, it's very cool! --TomEdwards 13:22, 29 Jun 2005 (PDT)

I managed to get assaults working in one of my own maps, but from reading all this it seems I got some aspects utterly and totally wrong. So, many thanks for the corrections - and I hope the rest of your articles are as useful! (How about battle lines and stuff next? They're just plain mysterious...) Cargo Cult 06:04, 30 Jun 2005 (PDT)

There's still work to do on assaults and I'm planning on dealing with hints after that, but battle lines are definitely on the list! --TomEdwards 07:23, 30 Jun 2005 (PDT)

Standoffs are done, battle lines are a part of them. :-) --TomEdwards 13:41, 1 Jul 2005 (PDT)

Updated Assault Info

Hiya! I'm a programmer at Valve and I worked extensively on the Assault behavior code. I just went through the Assault article, making some corrections and adding details to a few parts. I also removed some inaccurate pieces of information.

Tom, I'm curious what you saw the AI do that led you to this conclusion (which I removed from the article):

If enemies are in view of an assaultpoint, they will be seen just before the point is reached and probably calculated using the wrong (previous) settings. To avoid this, try to ensure assaultpoints are always in 'safe' areas.

One of the main jobs of the Assault behavior is to gracefully handle enemies and combat situations whilst NPC's are running the behavior and moving about. Level designers shouldn't have to worry whether moving from Assault Point to Assault Point would expose the Assaulting NPC to new enemies, as the behavior was specifically designed to work either way. It's possible you've found some other sort of bug or have an entity error in the Assault that was misbehaving for you.

-Steve

Nice to hear from you. :) What I meant in the quote is best shown with a diagram:

A.P. <-- Don't allow diversion
 ^
 |    Hostile
 |
A.P. <-- Allow diversion
 ^
 |
 |
NPC <-- Moving towards the first assaultpoint
 |
 |
R.P.

Being in full sight the hostile will be considered with the rules of the the first AP and the assault will divert to kill it, even if I want it to run past. The only solution is making sure the hostile can't be seen while the first AP is in use. --TomEdwards 07:39, 13 Jul 2005 (PDT)

This is the intended behavior when you have an Assault Point configured to Allow Diversion. The only reason you would configure an Assault Point to Allow Diversion is if you want the NPC to divert from the Assault temporarily to engage any enemies encountered on that leg of the Assault. If you want the NPC to press on through to the next Assault Point even if an enemy is encountered, then do not set Allow Diversion. Use the default behavior, which will allow the NPC to engage enemies, but does not permit the NPC to divert from the Assault to do so. -Steve

Yeah, I understand that. All I'm saying is there's no way to 'grade' hostiles per assaultpoint, unless you block LOS, and that can lead to things not working as they are meant to. In the example I do want the NPC to divert, but I then want it to run past the hostile at the next AP and that wouldn't happen. --TomEdwards 14:00, 13 Jul 2005 (PDT)

Sorry for the random plug, but.... Is there any possibility that a Valve programmer could give a synopsis/tutorial on how to work with the AI in a multiplayer mod? I've been dabbling in the code, using the SDK bots plus some theft of HL2 AI code, and I get some results. But a rundown on the structure of the extensive AI code would be a boon to us coders. e.g. The AI_whatever is the parent to AI_shootStuff and you could use this to....kinda deal. I dunno, I just need more to work with or a ton more time to work through it. There's just so much code!! I've put some stubs at AI Programming and such, and I'm going to start filling them in as I learn, but it's slow-going. Thanks for this awsome wiki! --Crazy_Monkey 22:28, 13 Jul 2005 (PDT)

random point find !!! lovely!!!!

hey i'm find my solution for my random wp style for NPC(to make very exciting NPC'AI),i have to got buy the game immediatly !!!!!

excellent AI program script for HL²

big thanks to you ;)

bye ! SirLevesque from France

Combinations of assaultpoint settings

I've tested every combination of the assaultpoint "clear on contact", "allow diversion", "never timeout", and "clear on arrival" settings in controlled, otherwise-identical conditions. I've drawn some tentative conclusions from these tests that I'd like comment on. (Specifically, it would be great to hear from Steve.) I don't mean them dogmatically, and they should not be considered complete or accurate.

• If "clear on contact" is set, a single enemy might clear not only the current assaultpoint but the next one(s). A consequence of this is that if an NPC encounters an enemy on the way to a "clear on contact" assaultpoint the assaulting NPC may never procede to another rallypoint. This occurs regardless of the subsequent assaultpoint's "Clear on contact" and "Allow diversion" settings.
• If "allow diversion" is set and the NPC encounters an enemy, the assaulting NPC will pause for a while after killing the enemy before proceding. The article says that this pause is the length of the "timeout" setting, but in my tests it was several times as long.
• If an NPC encounters an enemy on the way to an assaultpoint marked "allow diversion" but not "clear on arrival" the assaulting NPC will be pausing twice. Mappers might need to consider this if timing is important.
• An asasultpoint with both "clear on contact" and "allow diversion" causes wierdness: if an enemy is encountered on the way to the assaultpoint the assaulting NPC will kill it, but then upon reaching the assaultpoint will not pursue or return fire from other enemies until the next assaultpoint is reached. In fact, the assaulting NPC doesn't even change direction to face the fire. This happens regardless of the "clear on arrival" or "never time out" settings.
• I didn't observe any effect of the "never time out" setting. However, all firefights were fairly brief, so it might not have had a chance to come into effect.
• All-settings-off is great for making the NPC dash to a point regardless of enemy fire and then attack everyone at the point.
• Having only "clear on arrival" on is great for making the NPC dash from point to point without pausing, regardless of enemy fire.

If this wiki supported uploads of VMF files (it doesn't... yet?) I'd gladly make the two test maps available (eight tests per map). I should do further tests on the effects of the following assaultpoint (in all these it had all settings off). —Maven ^(talk) 12:09, 19 Sep 2005 (PDT)

Nice job, I don't have any problems with them being merged to the article. Your first point is part of what I was talking about above. --TomEdwards 12:24, 19 Sep 2005 (PDT)

Thanks. However, I plan not to merge it into the article until I've done further testing and/or received verification from someone else's testing or authority. —Maven ^(talk) 12:32, 19 Sep 2005 (PDT)

More data:

• The OnAssaultClear output is only fired for the last assaultpoint in a chain. All assaultpoints will fire their OnArrival output, however.
• The delay after a "Allow diversions" diversion is about 18 seconds for a 3-second "timeout" time.
• In my new test map a diversion causes another such delay immediately upon reaching the assaultpoint, and then the assaultpoint OnArrive re-fires. If the NPC is again diverted before the timeout, the OnArrive output will fire again, ad infinitum. So don't spawn enemies during from the OnArrive output.
• If the first assaultpoint is set to "Clear on contact" and an enemy is sighted before reaching the assasultpoint, the assaulting NPC will never make it to the assaultpoint. If the subsequent assaultpoint has "Allow diversion" off, this will cause that (or perhaps the final) assaultpoint to fire the OnArrival output—despite the assaulting NPC being nowhere nearby and having not even gotten to the first assaultpoint, nor having yet finished dealing with the enemies. If, on the other hand, the second assaultpoint has "Allow diversion" on, no messages are sent whatsoever.

—Maven ^(talk) 15:15, 19 Sep 2005 (PDT)

Agh.

However good article this probably is, it needs to be butchered into several entity pages (and probably have the remains link to these entities) and not just have redirections to a tutorial, because that sucks consistency-wise. Now I would normally do this myself, but the entities linking here are so many that so I could need some assistance to transfer everything. Despite his best interest, I'm starting to curse TomEdwards name. :P --Andreasen 02:24, 6 Apr 2006 (PDT)

There are already pages for the individual entities. What this page really needs is a list of "To accomplish X, you need A, B, and C." mini-tuts. —Maven ^(talk) 19:35, 5 Feb 2007 (PST)

While we're on the subject of changing this article, it needs to be moved to assault. Jupix 03:40, 6 Feb 2007 (PST)

Done —Maven ^(talk) 16:35, 6 Feb 2007 (PST)

Bah!

I'm fairly sure that some of the notes are completely wrong. Do we have an expert on the subject? —Maven ^(talk) 16:13, 18 Mar 2007 (PDT)

Enemies?

It seems that giving a npc_combine_s an Assault input doesn't work if the soldier is too busy trying to kill stuff at the moment of the input. I'm not too sure what's happening here. Is this always true? --Darthkillyou 19:53, 13 May 2008 (PDT)

Branching Assaults

The Episode 2 commentary mentions, in regards to the White Forest Inn seige,

One issue with a number of our encounters with the Combine is that they don't live long enough for players to experience some of their more interesting AI. Some unique elements introduced here with respect to the Combine are: Branching assaults, so that soldiers introduced to the field don't take up predictable positions. Flexible assault points, so that soldiers can stray from designer specified locations to establish line of fire or cover. Assault progression is a feedback system so that the timing of the soldiers advances responds to player actions and skill rather than timing. We give soldiers different tactical roles. For instance, squads in the field distract the player, allowing other soldiers to execute surprise moves not present in our typical frontal assault scenarios. The net effect of these changes is that the soldiers are perceived to have awareness of the layout of the building that you're trapped in, and a strategy for flushing you out. (Tom Leonard)

Is this a new feature in the Orange Box engine or a clever use of existing features? It would be nice to either document the new info or somehow explain how to set up such a situation.