Let go off auto-waypointing?

[stefanhendriks]

I did some tests on the line of code you mentioned Evy, but it is not it. So i am looking it somewhere else...

EDIT:

Around line 642, you find some lines that look similiar to the following updated lines... this makes the de_dust crates connectable now.. and i will test as_oilrig now, but i don't forsee any problems

// 14/06/05 - FIXED: Some slopes are not counted in here..., de_dust jump from crates connects now
	 if ((bIndexFloats /* && bNeighbourFloats */ ) && (Nodes[j].origin.z > Nodes[index].origin.z) && (Nodes[j].origin.z - Nodes[index].origin.z > MAX_FALLHEIGHT) 
	&& (bNeighbourWater == false && bIsInWater == false))
{

EDIT 2:

I have tested oilrig, and i see another problem. Its done in a few lines later, and actually the lines are not wrong...

The slopes are so steep that a player walking on it is having to much velocity, causing a good distance and also a great difference of height. When checking the node you create and the last created node. The height can be HIGHER then a max possible jump (60 units). THe check fails here, it says "its to high to jump". So going down is no problem now due the given fix above, but going UP is a problem now.

You could say, okay, we remove the height check. But then again you have the problem that nodes will be connected to stuff a bot cannot jump to. Both nodes are not floating. When jumping on normal crates, both nodes are also not floating, so there is not much to change. The condition is here:

	 if (bIndexFloats == false && // we stand on something
	 Nodes[j].origin.z > Nodes[index].origin.z && // we MUST jump (not fall)
	 bNeighbourWater == false && 
	fabs (Nodes[j].origin.z - Nodes[index].origin.z) > MAX_JUMPHEIGHT) // and cannot jump to it
{
	SERVER_PRINT("Cannot jump to it");
continue; // next neighbour	 
}

perhaps some genius can stand up here?

EDIT 3:

Thanks to PMB i could distinguish a steep slope and a normal slope (crate/flat) and so i adjusted the code and now it connects FINE on oilrig! I have updated the CVS ladies....

EDIT 4:
CVS seems to be down, cannot update yet.

[dstruct2k]

EDIT 14918279487329857235:
9_9

(Joking lol)


Did that oilrig problem get fixed? Because, what I would suggest, is if there is upwards motion already (or any motion, really) to allow jumps that extend to 75 or even 90 units, depending on what's needed on oilrig.



By the way... Is there some code somewhere that's limiting the bots to 3/4 walking speed? They do a walk/run constantly... not full running speed but faster than walk (and it makes footsteps)....

[stefanhendriks]

the oilrig problem is solved yes.

The walk speed is limited somewhere in the cBot::UpdateStatus() function. It differs for CS 1.6 and CS 1.5, but there is no way to tell how much a bot is limited.

here is the snippet:

  // Set max speed and such when CS 1.6
  if (counterstrike == 1)
  {
 f_max_speed = pEdict->v.maxspeed;
 bot_health = pEdict->v.health;
 bot_armor = pEdict->v.armorvalue;
  }

in CS 1.5 this info is sent by engine messages, but in CS 1.6 you can directly catch this because engine messages are not sent this way.

[stefanhendriks]

source is updated.

Stefan

Last CVS version is MUCH better regarding the selection of goals and paths. Really

On the other, when trying to waypoint a new map, I still find some issues/suggestions:

1) doors seem to prevent finding neighbours (probably because the tracehull function detects a door 8o and assumes that it is a wall)... I was unable to put a path between each side of a door in cs_siege and es_cell due.

1.bis) a similar issue would be a 'breakable' between two nodes, if tracehull detects a breakable, it should anyway establish a neighbour

2) the limit of 80 nodes per meredian is not enough... I made some test, and numbers like 100 or 120 are common on some maps. The attached NodeMachine.h has increased the limit to 120 for NODES_MEREDIANS

3) the attached NodeMachine.* is also checking for other goals like VIP rescue zone. There are also 2 ways to find the hostage rescue zone

3.bis) what about adding goals for pre-dropped weapons like on some maps fy_iceworld, ... ? I will try anyway to do it and see what happens

4) cosmetic 8D the comments in BotShouldDuck are a simple cut & paste of BotShouldJump and therefore are quite misleading

5) the debug bitmap has been rescaled a little to avoid placing points just at the border of the bitmap

6) last point, the attached ChatEngine.cpp contains some more code to work with accute letters (I'm French speaking ): basically it removes all accent from letters and make the sentence comparison without being case sensitive

NB: the attached DumpNodes & DrawNodes are a little sexier (like drawing the axis & meredians, ...)

Hope it helps you to continue your EXCELLENT job

-eric

[stefanhendriks]

Do you encounter any trouble with noding new maps Evy? I hear people got problems and i have to figure this out first before i do anything. It might be musicmans dll or it is a real bug in the bot (which i assume)....

thx for the source files i will download them and apply changes where i find nescesary Ie meredians is a good hint, i never really did a research i did a simple math though

Originally Posted by stefanhendriks

Do you encounter any trouble with noding new maps Evy? I hear people got problems and i have to figure this out first before i do anything.

You are right, except for es_cell which was new, the cs_siege one was relying on an existing RBN file where the connectivity between nodes is already bad... So, even your fixes of Friday will not help this 'old' RBN file. I'll try to restart from scratch.

-eric

[stefanhendriks]

I have made some changes to the distance check and the 'steep' check. Its not much, but its recommended to use them. I will update the source. The changes you proposed are not yet in though, so backup your files first.

[V or 'Tex]

I suggest you add display of these 'meredians' (not a clue what you're talking about).

And I also suggest you fix the "realbot node draw" display. The nodes are often invisible even though I am standing right next to them. Is this because there is a limit to the number of sprites it is rendering? I have a Celeron 1.3GHz (a crappy P3, basically) and I find absolutely no problems with filling the screen with those nodes. It'd help a ton because it's difficult noding a map when you can't tell where you've gone.

[stefanhendriks]

well, there should be a more effecient way of drawing the nodes. However, i thought there was a limit that the engine could show... dunno exactly though.