New AI for Mobs

[SamJBarney]

The way I see it, by implementing partial pathing, the weight of the function would be more evenly distributed. Instead of calculating the full path in a single tick, you would calculate only part of it, then walk that part, then generate another part, and so on and so forth.

Plus, when it comes to following a target, I would only need to regen a partial if the target was within a specific amount of blocks. So I would get a performance boost there.

I'm going to go implement it that way, and if anyone has any problems with it, we can always go back and change it later (preferably when the AI is nearing completion).

[xoft]

I'm considering the following example, in fig. A:

The partial path could take the entity from src into the "peninsula", because it wouldn't see that it's blocked further, thus the mob would move in, like in fig B. Once there, it will realize it is a dead end and try to walk out again, going back to fig A.

[SamJBarney]

Yeah, I can see that, but its the only other way that I know to speed up pathfinding would be to precalculate all of the pathing weights, and that would be a lot of info to cook up.

You know, I'm just going to leave it the pathing alone right now. Someone else who knows what they are doing can make it better. I'll just move on to the rest of the AI bits.

---

I'm just running out of ideas here to speed it up... :/

[xoft]

If I were to write pathfinding, I'd first impose some limits - I know that there won't be paths longer than, say 64 blocks, and the max (direct) distance from start to end won't be more than 16 blocks in each direction (I'll make these named constants so that they can later be changed).
This would allow me to represent everything with flat arrays - a flat array of 64 Vector3is for the path and flat 33x33x33 arrays of ints (cost) and bytes (direction of previous block in path). Allocate these once, by using a cPathFinder class to wrap them and having one instance of such class per cWorld. Only one mob can be path-finding at a time, anyway (if we ever need more, we'll make more objects). Thus, I'd eliminate dynamic reallocation altogether from the algorithm and the algorithm itself is reduced into the simplest case of more or less floodfilling the array. Of course that needs some storage, too, include that as another flat array in cPathFinder, while imposing another limit (the current queue of open blocks must be less than N items, supposedly N ~~ 64 * 64).

[tigerw]

What's actually making it slow? Loads of GetBlocks?

---

For something like this:

do
                {
                        ++Height;
                        Block = Chunk->GetBlock(a_NextBlock.x, Height, a_NextBlock.z);
                        //Chunk->UnboundedRelGetBlockType(a_NextBlock.x, Height, a_NextBlock.z, Block);
                }
                while(g_BlockIsSolid[Block]);

Are you trying to get the height of a X, Z coordinate? If so, just use a_Chunk->GetHeight(X, Z);

[SamJBarney]

I wish it were that simple. But a_Chunk->GetHeight(X, Z) just compares against the height map, which has no knowledge of caves. It just tells you the highest, non-air block at those coords.

---

Man, I think I'm going to have to sit down and study what you said, Xoft. I understand what you're saying, but my mind is just spinning right now; I'm having to track down potential sql injection attack vectors for work.

[tigerw]

Attack vectors?

Code:

'anything' OR 'x'='x'

:D

[SamJBarney]

Yeah. It sounds a bit weirder than it is. Honestly, the phrasing just makes me think of giant space battles, which has nothing to do with it.

---

Ugh... its so boring. It's like painting grass and watching it dry as it grows.

[tigerw]

Thou art mixing data types:

Code:

7>..\src\MobBehaviors\BehaviorPathToPosition.cpp(84): warning C4244: 'argument' : conversion from 'float' to 'int', possible loss of data
7>..\src\MobBehaviors\BehaviorPathToPosition.cpp(86): warning C4244: 'initializing' : conversion from 'float' to 'int', possible loss of data
7>..\src\MobBehaviors\BehaviorPathToPosition.cpp(87): warning C4244: 'initializing' : conversion from 'float' to 'int', possible loss of data
7>..\src\MobBehaviors\BehaviorPathToPosition.cpp(88): warning C4244: 'initializing' : conversion from 'float' to 'int', possible loss of data
7>..\src\MobBehaviors\BehaviorMoveToPosition.cpp(25): warning C4244: 'argument' : conversion from 'float' to 'int', possible loss of data
7>..\src\MobBehaviors\BehaviorMoveToPosition.cpp(31): warning C4244: '=' : conversion from 'float' to 'int', possible loss of data
7>..\src\MobBehaviors\BehaviorMoveToPosition.cpp(32): warning C4244: '=' : conversion from 'float' to 'int', possible loss of data
7>..\src\MobBehaviors\BehaviorPathToPosition.cpp(157): warning C4244: 'initializing' : conversion from 'float' to 'int', possible loss of data
7>..\src\MobBehaviors\BehaviorPathToPosition.cpp(208): warning C4244: 'argument' : conversion from 'double' to 'float', possible loss of data
7>..\src\MobBehaviors\BehaviorPathToPosition.cpp(208): warning C4244: 'argument' : conversion from 'int' to 'float', possible loss of data
7>  BehaviorWander.cpp
7>..\src\MobBehaviors\BehaviorWander.cpp(14): warning C4244: '=' : conversion from 'int' to 'float', possible loss of data
7>..\src\MobBehaviors\BehaviorWander.cpp(15): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data
7>..\src\MobBehaviors\BehaviorWander.cpp(18): warning C4244: '+=' : conversion from 'double' to 'float', possible loss of data
7>..\src\MobBehaviors\BehaviorWander.cpp(19): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data
7>..\src\MobBehaviors\BehaviorWander.cpp(22): warning C4244: 'argument' : conversion from 'float' to 'int', possible loss of data

I don't think that they are intentional?

[SamJBarney]

They are intentional, at least the float to ints. I need to go review that code.