FTEQW - AI's and CSQC

[IcarusV]

I'm trying to make an AI and I need to check whether it can walk to a given position.
The quake c manual here: QuakeC Manual
tells me that the checkpos function can do that, but that the function is disabled.
I have not seen that or an equivalent in any defs file I've come across, is such a function available?

Also, what value should be used for MSG_ENTITY when sending an entity from SSQC to CSQC? I have seen 5, but that and whatever else I try is getting thrown up at me as a bad destination.

[Spike]

MSG_ENTITY is only valid within a .SendEntity callback.
you can find defs for the various fteqw builtins+extensions here: http://triptohell.info/moodles/fteqcc/fteextensions.qc
use tracebox if you want to check if an area is empty (start=end, or trace downwards to find a floor or so). this does not mean the ai can find a route to it, only that it is valid should the ai somehow manage to not be shite. you could also use droptofloor in a similar way. checkbottom will tell you if the point is over a ledge, as far as the ai is concerned.

[Zop]

I decided to take a look at the code to see what they "disabled":

/*
=================
PF_checkpos

Returns true if the given entity can move to the given position from it's
current position by walking or rolling.
FIXME: make work...
scalar checkpos (entity, vector)
=================
*/
void PF_checkpos (void)
{
}

My bet is that a function that can determine if a location can be visited turned out to be way more complicated to code than expected, so they didn't ever code it. It seems like such a function would have to trace lines all over the floor, up steps, around every corner, and perhaps up platforms and down holes to be "good enough", but such a task would probably be too intensive to be use extensively.

I'd recommend looking into solving the problem a different way. Monsters in Quake don't "know" if they can reach the player or not, but they keep trying and reevaluating their target's location indefinitely. With some random directions thrown in, it works in some instances.

[IcarusV]

In that light, I think I know what to do for AI.

For CSQC, server-side I have a copypaste from the csqc_for_idiots.txt that's been floating around

float MSG_ENTITY = 5;
.float SendFlags;
.void(entity to, float sendflags) SendEntity;

float(entity to, float sendflags) MySendEntity =
{
	WriteByte(MSG_ENTITY, 5);		//write some entity type header
	WriteByte(MSG_ENTITY, sendflags);	//tell the csqc what is actually present.
	if (sendflags & 1)
	{
		WriteCoord(self.origin_x);
		WriteCoord(self.origin_y);
		WriteCoord(self.origin_z);
	}
	if (sendflags & 2)
		WriteByte(self.frame);

	if (sendflags & 128)
		WriteByte(self.modelindex);	//sending a modelindex is smaller than sending an entire string.
};

Looking again, my problem isn't in sending an entity header or sendflags, but the writes that come afterward. The server crashes on whatever comes after WriteByte(MSG_ENTITY, sendflags).
I'm taking stock QW QuakeC and giving fired rockets MySendEntity as a .SendEntity. This makes the server crash whenever a rocket is fired due to bad destination from the first three WriteCoords after WriteByte(MSG_ENTITY, sendflags). Similar happens with the next in line if I comment the offending writes out.
As I understand it, whenever an update is needed, the server calls an entity's SendEntity with 'sendflags' being the entity's SendFlags and the requesting client being 'to'.
I'm seeing that the writes after the first two WriteBytes have no 'to' specified, should I assume that those get set up with MSG_ONE and msg_entity=client?
As well, regardless of how I set the sendflags before, everything is being run, so I don't know what's going on there.

[Zop]

Assuming that the code is correct, I know of a one problem. Last I knew, there were two very similar types of CSQC, one for Darkplaces and one for FTEqw. What I read (since I never tried CSQC) is that sometimes code for one works on the other, but my bet is entity handling would be different.

Obviously you have to question code if it's not working, but we don't know how the writes should be done.

.float SendFlags;
.void(entity to, float sendflags) SendEntity;

These things aren't used by the code you posted.

Now that I'm actually looking in the file, did you just take a chunk of a code from here and put it on its own in your code?

[MadGypsy]

Why not just do it like this?
Looking Smart feature - In The Shadows mod for Quake - Mod DB

or borrow from this
http://www.insideqc.com/frikbot/fbx/

[MadGypsy]

one for Darkplaces and one for FTEqw. What I read (since I never tried CSQC) is that sometimes code for one works on the other

probably cause of stuff like

if (constate != "" && constate != "active") //allow empty, so things still kinda work with dp too.
{
drawfill(pos, ui.screensize, '0 0 0', 1, 0);
}

and

if (dp_workarounds)
{ //lame, but whatever
ui.drawstring(pos, chr2str(0xe080, 0xe082), '1 1 0' * this.item_scale, this.item_rgb, this.item_alpha, 0);
if (truth)
ui.drawstring(pos + '4 0', chr2str(0xe083), '1 1 0' * this.item_scale, this.item_rgb, this.item_alpha, 0);
}

Yep @ Spike - I read the hell out of your QC classes. Thank you for that too. I get it.

[IcarusV]

These things aren't used by the code you posted.

Now that I'm actually looking in the file, did you just take a chunk of a code from here and put it on its own in your code?

The code is from this tutorial:
FTE QuakeWorld / Code / [r4996] /trunk/specs/csqc_for_idiots.txt
If I recall, that was written by Spike, I'd imagine that it's FTE compatible in that case.
Regarding SendEntity and SendFlags, from what I can tell, SendFlags is used by the engine to call SendEntity. I was applying MySendEntity to the SendEntity of new rockets in otherwise stock Quakeworld QC.

Why not just do it like this?
Looking Smart feature - In The Shadows mod for Quake - Mod DB

or borrow from this
FrikBot

That Mod DB page sounds about like what I'm trying to do. I've actually got a semi-working system so far, the AI follows preset nodes on a map until it can walk to the player. The AI, then, needs to know if it can walk to the first node in a path and if it can walk to the player at the end. Right now the test works by sending a fast moving entity to the destination and waiting for it to either touch the destination or time out, but it would be much more convenient to be able to test within one think.
I'm thinking tracebox with droptofloor calls along the line might work, or using walkmove and setting the origin back again.

I'll look through Frikbot, seems useful.

[Spike]

the WriteCoord+WriteByte calls should all have MSG_ENTITY as the first argument, not just some of them. passing too few arguments ought to be a compiler error (grr, legacy compat! - note that fteextensions.qc contains a few #pragmas to fix that)
yeah, there's a typo in the tutorial.

use of tracebox is always preferable to trying to use movetypes to replicate tracebox, so long as you're prepared to limit your mod to engines that provide a tracebox builtin.
that said, its worth noting that tracebox will generally fail as soon as it hits the first hill. if these waypoints are manually placed then it should be trivial enough to just place the waypoints a bit higher or on top of said hill. tracebox won't detect valleys at all, of course... unless you're spamming tracebox calls that is in which case it'll detect whatever is in the way of whatever tracebox calls you make.

if you want to assume that the ai won't do random yaw angle shifts, you can always just call walkmove multiple times to walk an entity along a line using the same sort of tests that movetogoal will use. be warned that this does tend to trigger triggers...
movetogoal basically uses walkmove internally. walkmove basically uses tracebox internally. it does a downwards trace at the point that its trying to move to, and if its empty and the ground isn't too sloped and there is actually ground somewhere there then it does some pointcontents to make sure that there really is ground, and then it moves there. the pointcontents is kinda annoying really, and doesn't really work too well when its walking over strange geometry and is the cause of monsters getting 'stuck' on steps. and all because coverage checks are too expensive. that said, I guess something like reversing part of clipped decals could be used to check if the ground makes more sense, but that wouldn't respect clip brushes and things, and now I'm babbling about things that I'm far too lazy to implement anyway and besides it would probably break too many mods so I'll just shut up now.
anyway, point is that just because you can walkmove or tracebox or whatever to the destination, it doesn't mean that movetogoal will be able to replicate that, thanks to movetogoal's habit of moving diagonally or axially rather than direct, as well as ledges and precision issues and related gotchas.