Simple ai code locking up game

ID:2408729
 
Oct 31 2018, 5:55 pm
Code:
mob/Enemies/New()
    src.HP=src.MaxHP
    spawn(-1)    src.CombatAI()
    return ..()/dm>

<b>Problem description:</b>

 I've been using the falacy tutorial and I'm at the AI section when I write this code the game will run slow or crash or not at all I just copied and pasted from my phone so not sure if it will show up right. Any idea why this happening
Oct 31 2018, 5:57 pm
You don't wanna spawn the Combat AI in New() it would be better to call the AI proc when a Enemy mob is in range of a player through the movement proc.
Oct 31 2018, 6:22 pm
I don't know what that means/how to do that I'll look at other examples and come back to it thanks buddy
Oct 31 2018, 6:40 pm
 
mob/Move()
  ..()
  for(var/mob/Enemies/E in view())
    if(E)
      E.CombatAI()


you would also want to have a variable that tells when the Enemy mob is activated or not and Deactivate them once they are out of range.
Oct 31 2018, 7:03 pm
having a for loop called with every mob/Move() is very bad. especially considering that will apply to all enemies as well.
Oct 31 2018, 9:40 pm
True though for me its only called in mob/combatant/player Move proc
Nov 1 2018, 5:04 am
I wouldn't suggest adding a loop every step a mob makes.. That's really horrible..
Nov 1 2018, 6:46 am
In response to Laser50
 
combatant/player/Move(var/turf/NewTurf,NewDir)
    if(!CanMove())return
    if(guarding)
        dir = NewDir
        return
    if(Target)  Track_Target()
    for(var/combatant/enemy/M in range(src,10))
        if(!M.active)
            M.active = 1
            spawn(2) M.ai()
    ..()


Works fine for me and takes little to no CPU at all.
Nov 1 2018, 11:16 am
range() can get very expensive when called too much, but at least you're not using view().

You'd likely want to do something like split the game up into regions which store the enemies within them in a list, then you can trigger said enemies in a very light-weight loop, since your list wouldn't be being generated each time you take a step by calling range().

You could then call get_dist() and ultimately view() if all of the other checks pass to save resources unless the conditions are met.

But if you're not worried about opacity at all, you can stop with the get_dist() part.

Even storing every enemy in a single list and looping over that every time you move (barring having thousands upon thousands of enemies in the list at once which would point at other design issues) instead of calling range() or view() would be less expensive.

You have to remember that procs like range() have to do a bit of behind the scenes work to ultimately give you a list which it can loop over -- and the list doesn't even only contain what you're looking for, it contains everything within that distance.
Nov 1 2018, 3:31 pm
At minimum, you should probably be looping through viewers, oviewers, hearers or ohearers. I assume they are less costly than view.
Nov 1 2018, 4:23 pm
They're not. Might even be slower from my profiler results.