Okay it's Done (to Mal & Ghost)

[Denny]

Okay i finished typing up some stuff that could be included in the waypointing system, download this file...

Right click on this link, and select "Save Target As..."
http://denny8303.tripod.com/waypointing.zip
(NOTE: If you use Mozilla Firefox, you may need to use a download manager to get the file, it kep corrupting the download when i tried selecting the save link as option using this browser.)

Please only Mal & Ghost download this, i don't wanna throw people off thinking this stuff is in the mod already because it's not at the moment, this is just a proposal. So people, plese DO NOT download this.

You'll need Word to view the document, Notepad will work for the Sample Script.

I recommend you read the document first up to section IV, then look at the sample script, then back to the document, just so you don't get thrown off looking at the script first.

Let me know what each of you thinks, if you have any questions, feel free to ask.

[Maleficus]

Originally Posted by Denny

Okay i finished typing up some stuff that could be included in the waypointing system, download this file...

Got it.

Gave it a good look over.

One question tho: nearly everything you listed in the script.ini file is already done in Fritz's path system.

Unlike Wolfbot, objectives aren't tied to nodes, they are a seperate system thats inside the nav file, called "Actions". An action could be stealing the docs, camping, planting a bomb, etc. And for every action for one team, you can set the reaction for the other inside the same "Action" (if allies steal, axis freak; if allies plant, axis defuse, etc, etc). This system is pretty flexible, and can be drawn along with the paths, to give you an idea of whats going on. And gives you that whole "action/reaction" effect.

Would you prefer that they were put into an external script file, instead of the current system, where they are a part of the nav file?

Also they see most most button-less doors/jumps/crouch areas on their own already, since they have environmental sampling, and use the same movement code as the player. And thats totally without the path system - its built into their AI. This comes at a cost of a bit more CPU power, BUT - as a waypointer you don't have to micromanage their paths. And they look totally real and human-like when they move, unlike Wolbot, which looked artificial.

The path system lets them see buttons and levers and anything more complex.

Check out the console when you load up beach, and you'll see some various stats about the path file loaded.

Two way and one way paths already exist. They also have "ladder paths", but I haven't added a whole lot for it yet. They have "danger - high drop" paths, and they already sense when they're stuck, and already find the closest waypoint to get themselves "unstuck".


We think a lot alike.

All of the console cmds already exist, plus a lot more. Since I don't have a GUI or menus yet, everything is console based, but you can edit every single aspect of the nav system currently. Its cumbersome and slow - it took nearly 4 days to path for BEACH, but its powerful.

Nodes can be set for just one team already, and there is a way to give the same effect as "BLOCKED_PATH", by not connecting certain nodes until a certain action is done.

The only thing that doesn't exist yet is tram/elevator support, and that will probably be lower down on my list, since supporting the vanilla RtCW maps will be the first priority for now. GoTY and custom maps will come after that.

The actual waypoint menu and GUI need to be written as well. I haven't done ANYTHING for that yet, and probably won't have time until after the patch I'm working on ATM.

More intelligent use of actions is needed - its possible to see two bots fight over an area to camp sometimes. I totally agree with that a lot of other things need to be addressed with their path system too, and an external script system for the map goal logic is needed.

Good suggestions, keep them coming!

[Denny]

Wow, you got alot of stuff implemented already. Yeah if it already exists than there would be no need to include it in a script file only, but you could possibly use the script file together with the current system to provide more information for the objectives and such (i'd have to see the current waypoint structure to make comments on that).

But yeah we do think alot alike, you pretty much got everything implemented that i had suggested, and that's great!

That environmental sampling really sounds cool, and worth the extra CPU loss (which probably isn't much for modern CPU's, especially with HT enabled, or even 64-bit CPU's). But having this method implemented can make waypointing alot easier because we wouldn't have to tell the bots where those types of conditions are.

From the sounds of it though you got pretty much the whole system setup, you just need a streamlined way of using it (i.e. in-game menu).

The bots are great though, i mean the medics are awesome, i never have to call out for a medic there usually right there. And from what you say and from what i've seen the waypointing system looks pretty good all it needs is a menu and support for some of the really advanced stuff and we'd be set. Keep up the good work mal and anytime you need any suggestions or anything don't hesitate to ask.

If you need help getting the Vanilla RTCW and GoTY maps waypointed, whenever your ready, i'd be happy too help and i'm pretty sure Ghost would be up for it. I call mp_castle though, so don't even think about taking it!
Well i mean once you get a menu system worked out, your right that console command stuff sounds like i'd take forever to do, but i'd do it if it came down to that.

Another thing i just remembered to ask, is there a limitation on the distance between waypoints? I mean do they have to be a certain max length apart?

[Maleficus]

Originally Posted by Denny

That environmental sampling really sounds cool, and worth the extra CPU loss (which probably isn't much for modern CPU's, especially with HT enabled, or even 64-bit CPU's). But having this method implemented can make waypointing alot easier because we wouldn't have to tell the bots where those types of conditions are.

From the sounds of it though you got pretty much the whole system setup, you just need a streamlined way of using it (i.e. in-game menu).

Another thing i just remembered to ask, is there a limitation on the distance between waypoints? I mean do they have to be a certain max length apart?

The CPU drain isn't much, but it makes it hard to get too many bots running at a time. 16 is usually the number I shoot for and "officially" support, tho I did try 32 and didn't have too much lag.

I need a menu system, and I'd like an external script system to handle the map logic. That, I feel, would be better as an external system. i.e. control through a script what actions the bots consider a valid goal under what circumstances. That way anyone can easily modify it on the fly, to create any kind of game scenarios they want.

There is a distance limit - if the bot doesn't reach its next waypoint in a certain amount of time, it will start looking for a way around whatever obstacle is blocking it.

[Denny]

What kinds of stuff would be included in that?

At present, what is the default time?

[Maleficus]

Denny: I'm really sorry man - I hit the edit button instead of the "quote" button by mistake!! :o 8o o_O
I didn't even realize my mistake until after I posted it. Sorry about that!!

================================================== ====



An example for beach: there are two walls to blow. An action for bots that aren't eng's at first, would be to guard engs, and roam around the wall, killing any axis that jump over. When one of the walls blow, an action for patroling the walls is no longer valid. The action for stealing objs is now. Well, I use a funky system that handles one action "dying" and another being used. I don't like it: its overly complex unless you really know how it works and its not user friendly. So, I want to transfer that to an external script system.

Something simple like this:

If (door1 == BLOWN_UP)
AlliedBotGoals = Steal

if (wall1 == BLOWN_UP)
AlliedBotGoals = Steal

Thats a very simple example, but thats something along the lines of what I want to do. Fritz already hooks into the internal game script stuff, so it wouldn't be hard to catch events like an objective being destroyed, or stolen, and then deciding what the next option is for the bots. I still have to plan that part out, and then code it, but thats where I'm at with this ATM.

The time is 4 seconds, IIRC.

[Denny]

Okay i think i get what your saying here. So like behavioral type scripting for the bots correct? Like the following.....

IfNot (door1 == BLOWN_UP)
AlliedBotGoals = Defend & Cover (Cover would be covering the engineer)

If (door1 == BLOWN_UP)
AlliedBotGoals = Steal

IfNot (wall1 == BLOWN_UP)
AlliedBotGoals = Defend & Cover (Cover would be covering the engineer)

if (wall1 == BLOWN_UP)
AlliedBotGoals = Steal

I couldn't see the script file being to extravagant though, i mean most of it would lie within the AI and actual waypoint layout more than anything i imagine. Kind of depends where you wanna go with the script file. Personally stuff like the above would be fine with me, you just setup the bots bahaviors before and after the objectives, that in and of itself would make waypointing flexable. Well because everything in the map focuses around the main objective.

Some other types of behaviors could be "Roam", "Next Target" and so on. I hope that helped ya somewhat with an idea of how to set the script type stuff up.

[CrapShoot]

I like the idea of a script file. My initial thought of an implementation would be for the class specific actions.

If I had the ability to send a sniper to a different node on beach without editing the NAV file itself, that would be sweet.

I was toying around with thoughts of bot specific default 'actions' defined in each individual bot file as well, but that may be a bit cumbersome I guess. The thought was that as a waypointer, one could give each seperate bot specific default actions if all other cases weren't met. i.e. Having a specific med and lieutenant guard the upper bunker by the back stairs if allies had flag, but didn't have the docs. The initial problem I see with this is defining map specific actions in a bot file when multiple maps will be supported...

[Denny]

That's a good idea too. Kind of like ordering certain bot positions to goto specific positions, such as snipers would be cool.

[Maleficus]

Originally Posted by CrapShoot

I like the idea of a script file. My initial thought of an implementation would be for the class specific actions.

Already possible, but with actions. An action can be class specific, even weapon specific: say you only want snipers and meds to camp a certain action - its possible! OR, you don't want certain classes to do an action - say you dont want axis engs just running onto the beach to get killed, but instead to wait back until someone plants - also possible. I don't want to tie a specific action to a specific bot tho - I was going to do that originally, but I've been doing a lot of thinking, and I want actions to be "suggestions", not "orders".

I think by default, I'd prefer to keep access to the actions themselves in the nav file, but I could make it where you could add an action externally, or perhaps control what nav file was loaded (maybe thru a CVAR). That way, if you wanted a nav file where all of the axis charged out onto the beach, and all of the allies sniped them at certain points, you could actually do that, without screwing up the default nav file.