Enemy not attacking?

[ScatterBox]

So as some of you might know I've been coding in a new enemy bot for my mod. Well, it's more or less a bot. I'm trying to make it more of a "Stay still" bot, so instead of it roaming the level it stays still until it notices the player..

Well, I deleted all of the old monsters from Quake since they weren't needed, and then got to work. First I made the bot base. I wrote a completely new spawn function to where the bot doesn't spawn until the player walks into a trigger tied to the bot entity. Really my reason for doing this is to save ram since my mod is for the PSP. So instead of the bots just standing around the level waiting for the player, they spawn when the player walks into the trigger. so they don't take up as much memory usage. Anyways, my spawn function *sort of* works. But really my main problem right now is that when the bot sees a player, he runs up to them and does nothing. Now, he's based off the soldier code, so what he should do is start shooting/running towards the player. So my main problem here is that the bot doesn't want to attack the player...

Now I have thought of the number of reasons as to why this doesn't work, as well as re-went through all of the forum pages looking for similar problems. The one thing that I could come up with is that the players hitbox/size has changed. I heard this makes the monsters not want to attack the player, but I looked through all of my code and compared it to fresh QC and all of the view off sets and hitbox sizes are the same.. I also completely removed crouching from the code as well. (partially because I don't feel like there's a use for it in my mod anyways) so that couldn't be the problem either..

So if anyone could think of a reason as to why this isn't working it would be great! I've been in the IRC getting help for a couple says now getting help for all of this. Thanks to everyone who has helped me so far!

[ceriux]

its hard to tell with no code preview.

[ScatterBox]

[Seven]

Hello ScatterBox,

it worries me a little that you deleted all the monsters code, as you say.
Do you also mean the monsters code inside ai.qc and fight.qc ?

Your new monster is hunting the player.
That means that you left this function chain intact:
from FindTarget() until HuntTarget(), which will make use of self.th_run

But if your new monster does not shoot at the player, you seem to lost the call for: self.th_missile
The first important function for it is: CheckAnyAttack() (comparable with FindTarget() )
The soldiers classname is monster_army, i do not see a specific classname for your new monster.
Be sure to check for its classname inside CheckAnyAttack(), otherwise the standard function will be used: CheckAttack()
CheckAttack() is declared inside fight.qc
This function will then start your desired self.th_missile

You also didnt post your function: army_atk1(), which will be used then for your new monster.
You only posted the spawn functon of the new monster. Be sure to have army_atk1() in your code.

I am not sure if this is the problem, but I hope it helps a tiny little bit to find it.

Best wishes,
Seven

[ScatterBox]

[frag.machine]

Glad you managed to find by yourself the fix. Just a small correction: unless PSP ports of the engine works in a radically different way from standard Quake, there's no "memory allocation" when spawning a new entity. All entities live in a preallocated static (DP and I think FTE uses heap memory, but still preallocated) array, and the spawn() builtin just finds an empty slot in this array.

In other words, deferring entities allocation won't save a single byte, and even may turn the game choppy if a great number of them are spawned at the same time.

[Cobalt]

[Spike]

you're brave if you're willing to let spawn return world. no code checks its return value. expect explosions.

if it helps, I've seen a mod intentionally and without bugs use about 200,000 entities, flood-filling a map with waypoints. Making them all visible did indeed slow things down somewhat...
certainly mods can recycle through a whole boatload of ents. especially ones that spawn worker entities for traceline contexts or whatever.

FTE uses preallocated address space, but not preallocated memory for entities, as part of its VM sandbox.
DP uses heap memory for entities. Nothing is allocated in advance.
Neither engine frees the memory until the map is changed.

Actually, memory allocation is generally regarded as faster than memory freeing. Allocation can just split blocks, while freeing requires merging things and mutex issues etc.

spawning an entity in qc involves looping through all the previously allocated entities to check to see if there are any gaps. if that wasn't enough, each one calling find or findradius or checkclient+a traceline every frame is a performance nightmare.
if they're nonsolid, invisible, and inactive they all get culled away and you won't notice.

quad-core won't help you. quake is mostly single threaded.

[frag.machine]

[ScatterBox]

Hm, well after seeing all of this I'm quite surprised! Even if this doesn't help to much with performance it would still look nicer. Instead of seeing the bots just standing around the map, maybe you could walk into a trigger and one spawn behind you to add some more challenge.

[frag.machine]

It's OK if it's a gameplay mechanism. But if the intention was to do premature optmization, think again.

[ScatterBox]

[Spike]

if you just want to reduce the cpu load on the server, one trick is to just stagger the nextthinks slightly, so the monsters don't all think at once. this reduces the spikes and leaves everything much smoother, despite actually increasing cpu load slightly (due to the extra calls to random() ).
you can also switch monsters to use a framegroup for at least their idle animation, which a) reduces network traffic. b) allows you to reduce the interval at which they check for players without making them jerky if there's a player sneaking up behind them.
also, make sure your map is vised. the ai will use tracelines if it thinks a player is in range and in pvs. these will hurt if you have a lot of monsters.
also, don't use gyro or equivelents, at least if the monster is still idle.

[frag.machine]

^^^ what Spike said.

@Spike: do you think moving some of the builtins (specially traceline() ) to run in separated threads would improve the responsiveness ?

[Spike]

you mean like a dedicated server?.. try it.
by the time you get the result of your traceline back, you're likely to have forgotten why you wanted it anyway.
if its specific to idle monsters, then 'meh' is my answer.
if its instead some routing algorithm to get from a to b, then threading that might help, but it would still have to cope with other changes happening while its running, which might be messy (especially as linked lists are generally involved, take a snapshot of all position state perhaps?). that would be a proper workload for a thread.
the easier solution is to just use a dedicated server.