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