ID:152627
 
My arguement is that !src.client is too rigid and makes all NPCs do the requested thing. Common example is Movement - you might not want a certain one to move without boxing them in.


When I use src.npc = 1, I can form what can do the requested thing and what can't. Once more using the example of Movement is Mob Shopkeepers - Set their NPC var to 0 and they won't move. Set it to 1 and they move. (Preferably using a Trailer?)

Can be used for attack systems as well, in this example of different variations...

Client = Avoid the players and attack the other NPCs, Or avoid the NPCs and attack the players.

NPC var = Client + Attack the NPCs but stay off the Shopkeepers/Important people/Players.



If you want a even more flexible Attack system, make another var based on Important NPCs. (I will call it SuperNPC)

So...

SuperNPC + NPC vars = Client + NPC var + Attack Players and NPCs, lay off the Important ones. ETC.


You get a lot more options using variables from what I see. Argue here.
you should have general variables to control behavior. there may be cases where you don't want players to move, or some situation where a player takes control of another mob, so just checking whether or not the mob has a client isn't always sufficient.

another thing you can do is group common behaviors by type. this way you can also control how certain functions affect the mob. for example:

mob
var
hp
npc
proc
damage(x)
//deals x damage to the mob
enemy
damage(x)
hp -= x
civilian
damage(x)
return 0


if you don't want certain mobs (shopkeepers, townspeople, etc.) to be able to take damage, then you can change that damage function accordingly.
In response to OneFishDown
No no, when I used a Attack system I meant the Quest/Shopkeeper/Important NPCs can't attack YOU.


Then you can make so you can't attack them using those variables...
In response to RedlineM203
You can do that with his system as well...

Have a general Attack() proc, then override (with just a return) it for the types that you don't want to attack...