This is a very disorganized encyclopedia tracking all the different matters to keep in mind when waypointing. Use [CTRL] + F to find an article topic; additionally, each article has its own sections and subsections. Try finding The Proximity Factor, or the article Pathing's section The Invisible Circle. Those two in particular are two of three of the most important concepts in this post.
When setting a path of waypoints, you must imagine that you are taking that path yourself, pushing the exact same buttons right as the waypoints signal, and you must predict the soldat's movement accordingly. For example, if you place a Left waypoint and connect it westwards to an Up waypoint, any bots that follow said instructions will immediately press Up after running left. What happens when you yourself do that and don't halt the leftward momentum? Your vertical jump drifts a bit west simultaneously. So the Up waypoint must not be positioned directly above the Left one, but a bit left of it too (depending on the slope of the landscape and whether or not you use a special function).
ALL WAYPOINTING IS LIKE THIS. Don't ever tell a bot to Down unless you want the bot to crouch upon touching the corresponding waypoint with such a command; each function correlates to the literal keymap. And that is, with The Invisible Circle and The Proximity Factor, basically the world of waypointing!
Contents: use [CTRL] + F to get to where you want:
Rough Guide Intro
Example: The Waypointing of ctf_Aamu from beginning to end (this kinda failed but you get the drift)
Article: M4d Sk1llz - Advanced Bot Movement (camping and special functions)
Article: Pathing - joining Paths 1 & 2, and trail splits
Article: On Waypointing Formats for Various Game Modes
Article: The Proximity Factor (this is VERY important for insurance that bots stick to a path after combat or errors in wide space)
Article: Notes on Soldaten's Momentum
Article: Notes on Soldat PolyWorks
Article: Known Bugs in MapMaker, MapMaker Plus, & Soldat PolyWorks
Article: Synchronizing Waypoint Positions with Polygons Effectively
Article: Bot Behavior
Article: On The Purpose of StringsSo you think you can waypoint?: FAQ / Guide for impatient waypointer wannabes
This guide targets fans who'd like to waypoint maps (even though the huge jumble of kindergarten-colored lines and bunches of boxes with smoothed corners look like a bewildering mess) and who have relatively more common sense than a n00b and are willing to tackle the job (I was there once
).
Q: What if I don't want to read through your tutorial, however n00b-friendly it is?
A: You don't have to;
I sure didn't read through
my FAQ when learning, or even anything else aside from the official manual and other maps (after skimming through it, Soap's looks really boring, for example—no offense! That's just how I found it). You just need literally
hours of free time and a willingness to wypt., playtest, move a wypt. over a few pixels, playtest, etc. Basically, if you're a perfectionist and you like Soldat, you'll love to wypt.
Q: You tryin' to start a new slang with that, shortening "waypointer" to "wypter?"
A: Maybe, indeed
I hadn't even originally noticed that "wypter" could actually be pronounced when I first thought of an abbreviation for it to use throughout this FAQ.
Q: So, what should I be doing first?
A: The best thing right now whether or not you have touched waypoints at all is to be playing and getting used to Windowed mode. I was terrible at wypting originally because I play in Fullscreen most of the time (to see grenades better, to concentrate more on the game, etc.).
Q: Whyzat?A: The 1337est waypoint-supporting map editors out there (
MapMaker Plus, the official editor, and PolyWorks at regular size) are fit to the exact same size as windowed Soldat, so if you vaguely memorize how far a bot moves in a forward jump, etc. you have a better chance of "wypt.-guessing" which you'll be doing a lot, especially if the map has bots use their jet boots frequently (as playtesting, wypting, playtesting, wypting, and so on and so forth even more than you'll already have to, for every area soldaten jet in, is very tedious although some hardcore perfectionists will probably want to do it that way).
Q: So what are the basics to waypointing?CQ: You know what the two paths are for, right?
AFQ: Of course I read through the map-editing manual. It says to place the first wypt. at a respawn point.ACA (Anti-Counter-Answer): Of course. Also make sure that if you're gonna be placing a spawn point, get out of the Waypoints tab on MM at least (maybe MM+ too); you can't work with anything in the Waypoints tab but waypoints. PolyWorks has more interlacing tools, thankfully.
Q: Okay, so present the lecture we've all been waiting for.A: *launches right into it, even though that technically wasn't a question*
Here is an old version of Boxo's inf_Aardvark, wypted by semagae. This is all constructive criticism, now; no one is perfect.
In areas where the soldaten are supposed to drop and just plain fall, he selected Down. Why is that? I should like to know as well; the bots already know that gravity pulls you down, and I especially don't know why when the manual specifically said "blue - crouch" (the lines turn blue when Down is checked)! How could attempting to crouch in mid-air let you fall any faster?
Therefore if all you want the bot to do is fall down, don't check anything and establish the wypt. for the next one where it should, usually at the ground.
Yellow indicates jump. These two wypts. from the left connecting to the one to the right are indicating to jump rightwards. Why shouldn't that be done? Bots coming from the top will jump over the wypt., missing it and continuously acting as if they were soldaten holding W & D (until they stumble into an enemy, at least). Besides, they dash on their own; if all you have a bot do is go right or left it will automatically dash (the most efficient way of moving that most players do), when going up a steep hill (actually, just when the bot's not moving at its max. speed), so don't put a bunch of wypts. telling him to jump forward, run, jump forward, run, etc. like that. They will automatically dash up a hill so you don't need to do that unless it is really steep (and in that case you want the bot to jet or jump plain vertically anyways). You only want to specifically place a forward-jump wypt. right in front of a run wypt. if you're planning on having the bot jet (so he runs, jumps off a cliff or somethin', and then jets).
So for those two the Up commands can be removed.
The color just shows the terrain for exaggeration, and the white indicates passable area. We don't have to put many wypts. there; if all the bot's going to be doing is running to the right all the time during that area we can even have the wypt. line pass through a polygon or three as long as the bot reach the necessary positions.
However!!, there is a problem with this. What if the bot encounters enemies while on this string (the line connecting two wypts.)? If he defeats them and there is no wypt. nearby to get back on track the bot will just freeze and sit there. So unless you are certain the bot will never encounter any enemies along a trail (a.k.a. never),
don't do this. If you've looked at ctf_Nuubia's official waypoints, tho', that's being way too cautious. ctf_Kampf, even (middle path), could be spaced out more; bots aren't
that stupid xD
So yeah. You decide how long you want to put stretches of waypoints. If the map is really big this could help avoid the waypoint limit, but if waypoints on flat plains are stretched too far apart bots won't know where to go after combat because there is no waypoint near! Remember, connections are invisible to bots; they only see the central dot inside those transparent, smooth-cornered boxes (more later).
Now this is a tad more advanced wypt. technique. This example itself is easy to do, but we can use it to larger extents (we'll cover that in a bit). Here, the highlighted wypt. in the image shows the soldat running left, but ending right there. When a bot follows a wypt. trail to its end it'll just go along with whatever's nearby, so we can connect wypt. paths... without connecting them. Why would we want to do that? Well, the bot has to touch a wypt., not a string, to trigger it or else he'll keep performing the same movement. What if he misses that one? Why not just let him judge for himself which wypt. to take? And besides sometimes we get lazy and don't want to be constantly connecting
This shortcut technique is useful for having soldaten jet over some areas and quickly righting them back on track.
back of Alpha's base, starting from bottom & jetting upwards
This is quite an advanced wypt. task to do. Unless the space is almost nothing to have a soldat jet, this is nearly impossible to do perfectly without any playtesting whatsoever. Here is where we usually have to wypt.-guess and place wypts. where we think a soldat will reach by a time (since the wypts. are small and the soldat must strike them to activate the next wypt.'s action). I just created these wypts. so I myself haven't even tested this on the actual map; a wypt.'s probably off even though they look like they're in good positions to me. Memorization of the distances a soldat covers in Windowed mode is especially useful for troublesome sections like this, so you don't have to guess as much at the correct wypt. locations.
Bravo team heading left
Again, here is where you can cut down on wypts. All the bot is doing is just running left all the time so unless it doesn't manage to get over that pit in the bottom-right in the first place this is all I have to do; it will automatically dash over the hill and keep going 'til it hits the wypt. and change action accordingly. That is only to cut down on wypts., tho'; if they encounter and defeat or pass the line-of-sight of enemies there, they have no nearby wypts. to get back on track, however many strings there may be (in fact, the strings are only to show which wypts. are linked together; bots don't see strings at all).
northern front of Bravo base
Once more this is another wypt. guess-&-playtest trouble area. The highlighted wypt. has soldaten jet leftwards. If they miss that by even one pixel they will continue jetting leftwards as much as possible until they either encounter an enemy (in which case, until they are killed or defeat the enemy, they will resume bot movement in a manner similar to having ended a trail and randomly picking the next closest one) or run out of jet fuel, in which they would simply continue to run left until striking another wypt.
bottom-left of Boxo's ctf_Xenonia
Another guess-&-playtest wypt. zone that I had to playtest through several times. Notice how just in case the Bravo bots miss the upper wypts. I put emergency jet wypts. right next to the bridge in the bottom-left; don't be hesitant to put extra guards like that.
Another hint: just put a makeshift spawn point right there in front of the testing ground, so you don't have to follow the bots all the way to it (especially since they travel all over a map in DeathMatch, etc.).
mid-eastern side of Boxo's ctf_Xenonia
Taking the northern path from the middle, a bot will run to the right, and then vertical-jump and jet straight up. See how I made the Up wypt. (highlighted with yellow path from below) a bit more to the right than directly above where it should be? You haven't forgotten that straight vertical jumps are a bit diagonal if you jump right after having moved forward or back, have you? Bots are exactly the same, and even more so, as they perform the next step as soon as they complete a wypt. In fact, because bots perform the next wypt. action right away I should've put that highlighted wypt. more to the right. If you don't want to do that then I guess you can go with the Special function "wait 1 second" or "wait 5 seconds," etc.
Q: Wow, that's crazy. What other tips have you?
A: Remember that no human is perfect. Soldat = soldier ~ human (lol), so be aware that bots sometimes deviate a little in movement and/or initial positioning and prepare to make multiple, slightly differing pathways for bots to reach the same area if you find bots going off during wypt.-playtesting. Master the memory of how much distance a bot covers horizontally and vertically in jumping forward then jetting straight up, and other complex moves like that, and you will be the Yoda of wypts.
Q: Is it possible to put jetting safeguards like this?:A: No; can't see why? Unless those two middle are not jet*, how do you expect a bot to jet downward when you can't tell a bot to prone (that is, to perform the Superman, as that's the only way to jet downwards)? A bot will stick to a path once it's chosen it so you could make even 10 of those "safeguards" and if they're in the wrong positions, even by a hair, and if a bot just barely misses the wypt. it randomly selected for its path, it's not about to switch to another nearby wypt. it may have scraped; there are seldom other reasons for a bot to deviate from its original path other than combat, or of course reaching a trail's end. Might as well just focus on a 100%-accurate wypt. path to playtest numerous times (to find correct wypt. locations like I did for ctf_Xenonia's bridge gap). Besides, it looks more professional and less cluttered.
* - In that particular diagram none of them will work without severing two paths and adding a seventh wypt. You
could make the middle "jump right" and the bottom "run right" but then you'd have to set the finishing wypt. on the other side as "jet right" & the topmost wypt. wouldn't work with that.
Oh, and because bots are at least semi-human, bots forget stuff too. They don't even need to get into combat; if a string is long enough, even if the action is just "move left," they might forget the path and freeze there and stop moving. Place wypts. along a trail to keep 'em on track.
Q: Why aren't the bots taking a particular path I set even though I think the wypts. are in good spots?
A: This happens to myself all the time in fact. Perhaps they aren't? If they are, realize that multiple paths are completely determined randomly and bots will just choose to their liking. However, bots like gravity and are more prone to take paths closer to the bottom of the level so keep playing. I test with 5 to 8 bots on one team, usually, and if they don't take a path I want to check, I immediately end the match and restart and keep restarting until they do.
Example: the waypointing of ctf_Aamu from beginning to end
So perhaps the above is too abrupt a start for the incoming waypointer. So, I'll work with Boxo's ctf_Aamu. I will be hiding the texture and scenery.
I had accidentally started working with Path 1 for Bravo, which is incorrect; I had to select the entire path and convert it to Path 2 before playtesting, which in turn, once I was able to start doing so, showed a lot of errors I had made in position, particularly right in front of the spawn zone and the northern central area. Keep playtesting!
Article: M4d Sk1llz - Advanced Bot Movement
Alas, if only you could tell bots to go prone...
Well, they do prone by themselves (some hardcoded behavior thing I guess), but only literally 1 out of every 100 matches you play. Snipers tend to prone and camp a tiny bit more often. It's cool when you see them proning and jetting, especially right at you
There are only so many 1337 movements bots can perform. The most obvious & simplest is having bots roll; play with Bravo only on inf_Iceberg by The Geologist and check out the defense team's wypts. Then there's the other obvious but difficult task: backflipping. This method totally pwnz if only you can find a nice C-shaped path for bots to take. Good examples are Bravo bots who take the bottom path of Boxo's inf_Aardvark, or the top path of inf_Argy.
Bots always actively face the next wypt. they are trying to reach, so if you can have 'em go one way but face the other, you might get interesting bot movement.
The bot will stop at the highlighted wypt. and sit there for 5 seconds before continuing on. It will
not stop at the first wypt. and wait before going to the middle; special actions apply directly to the wypt. they are on, whereas actual move actions (e.g. jump, move left) are determined by the next wypt. to which they are connected.
Article: Pathing - joining Paths 1 & 2, and trail splits
In DeathMatch, TeamMatch, RamboMatch, and PointMatch, unless you force bots to take Path 2 by putting only Path 2 wypts. around a spawn pt. and nothing from Path 1, they will always take Path 1 upon spawning. Find appropriate places to join paths; e.g. if there is a big drop and a bot can go either left or right, and your history of wypts. on the map has Path 1 going left at the bottom of the pit and Path 2 going right, connect the falling wypt. path to both left and right (the other path would presumably be used for bots to jet upwards; you can join Paths 1 & 2 to that as well). A nice hands-on example of this would be Demonic's Niebelung.
HTF wypts. are exactly like CTF; the only difference is that you have to keep the bots circulating, or have them camp at enemy spawns. If the map is circular and chaotic, like htf_Nuclear or The Geologist's htf_Muck, where spawn points for teams are scattered everywhere, waypointing may get very tricky.
Section: PathingIn CTF, Inf., and HTF, bots will always be loyal to their respective path. Connecting Path 1 to Path 2 on a particular route in a map is
useless on CTF, Inf., and HTF. If you chain a Path 1 wypt. to a Path 2 wypt., and then go on for Path 2 wypts. all the way when the bot was originally on Alpha (or was a Bravo flag-carrier), it would only follow the first Path 2 wypt. Then it'd ignore all other Path 2 wypts., even on a trail, and locate the nearest Path 1 wypt. and continue from there. Connecting to different paths from which to continue only works in DM, PM, RM, or TM.
In other words, I pretty much screwed up htf_Muck since I didn't understand that important fact at first
Let's hope The Geologist doesn't read this... oO'
Section: Probability - Path DivisionI'm sure you all know that if there is more than one path to take (e.g. every single map except Lagrange), you simply connect two wypts. at one where it is appropriate to break off, etc. But here's something interesting I've found in my own experimenting; bots tend to take particular paths more than others. Here are my findings (some might be inaccurate), with the lowest number being the most likely path a bot will take when forced to choose:
1. up (yes, they actually like to jump more often than just run left/right)
2. move left/right
3. jet straight
3½. jet while moving left / right
4. move left / right + up (leap forward)
5. move left / right + down (roll)The probability of a bot picking a particular trail also depends on how far the next wypt. is; bots are more likely to choose a more complex but closer trail than a simpler yet farther one -
this is very important! Even just a few pixels farther away will make bots almost always 100% take one path and not another. If you want to make sure bots take all possible trails in a place on a map where you can go up or down, etc. (like ctf_Run), extensive playtesting is needed.
Eh? What's that you say? Out of two trail divisions, bots 75%+ chose one path? You're sure proximity of the wypts. (see The Invisible Circle) isn't interfering? If a wypt. is very close and bots are
still taking the other, common path, just create 2+ wypt. trails leading to the same area so they're more likely to take the one that lacks bots since if they miss the first one they still have a chance of getting to the desired trail through the second, third, etc.
Alpha side of The Geologist's inf_Iceberg (don't mind the bad wypt. trail at the bottom)If you want them to take the northern route more, just add an extra wypt. branch (here an Up and Jet Right) leading to the same trail, as mentioned above.
What? What now?... You say they
still take the lesser route and even sometimes they screw up in taking the desired path and fall to the inferior one? Perfect; time to cut down on their stubbornness. Sever the string leading to the lesser route to force them to take the greater path, but leave the wypt. trail alone; you said they falter and fall to the lower one occasionally so just leave it for security.
You should always want to aim for equal distribution of bots among trails. In some cases spawn points play a crucial role in that, especially in HTF, but everything can be solved by playtesting.
Section: The Invisible CircleOkay, so say there comes a section in a path where the bots can take more than one path. The graphic below is a simple one with only two paths (three is even heavier), but shows the point. The point is that out of two possible waypoints to follow, a bot will follow the closer one. So you want to make sure the two waypoints are, as much as possible, at the same distance away from the initial waypoint, so there is an even probability of bots taking either path.
(The picture is actually hypocritical; it positions the wypts. in the completely opposite positions
I've fixed that in my actual reworking of the map.)
Envisioning a circle like this is the best way to achieve this evenly distributed effect. If you need to use a temporary circle scenery, go ahead, but keep in mind the list above in the "Probability - Path Division" section: even if two waypoints are exactly the same distance away from the central one, a bot may be more inclined to take one over the other due to the raw action to perform.
For this reason my jump waypoint in the circle-graphic above is on the outer edge of the circle, while the running waypoint is a bit closer to the center, since bots tend to jump more than run (sad, but true
).
Article: On Waypointing Formats for Various Game Modes
Section: CTF MapsCTF maps are the easiest to waypoint; just make sure the bots can take all trails in getting to the enemy flag. Do this for both teams. But don't forget to leave waypoints from the base flag, too; think of ctf_Kampf. No one actually spawns in the flag bases, but you still need to lay waypoints there so non-flagcarriers can escape those dreaded grenade-dumpsters should they accidentally fall in due to combat or powerups.
It's fun to have the remainder of bots on a team camp at the enemy respawn zone if they already have a flagcarrier returning to cap; use Special functions and have them face the enemy.
Subsection: Inf. MapsInfiltration is slightly more difficult to waypoint than CTF, but only because you have to locate good spots for Bravo troops at which to stop and camp. Just fiddle around with Special functions at nice chokepoints for Path 2; according to the manual, Bravo troops and the Alpha flagcarrier disobey them when the black flag is loose.
Like CTF, it's cool to have Bravo bots camp close to Alpha respawns. Crouch finally comes to use on its own!
Section: DM Maps-> DM, PM, RM, and TM shall all be classified as DM.
All right! DM is by far the trickiest of all map layouts, which is why I have reserved it for the second-to-end, and why I can't go into it right now.
Section: HTF Maps 
Uh, same. oO' HTF is
nowhere near the same as DM, tho'. You could say it's like... hm... well, put simply, CTF, but with a single time-based flag and no bases—you have to keep both teams circulating. It's technically not
harder than DM-waypointing, but I put HTF last since waypointing HTF maps is somewhat easier if you know how to waypoint a DM map well.
And, uh... I'll go into this later. In a month, or something. (Skool sucks.
) Bah, might as well mention a little now.
There are two types of HTF-waypointing methods: CTF and DM. The CTF method is basically something like htf_Futura; waypoint it how you would a CTF map, this method is fun because if you continue the waypoint trail and have a team camp at the enemy base (if they hypothetically missed the HTF flag on the way), you end up basically telling the HTF flagcarrying bot to return to base to assume a defensive stance. It's brilliant
Connecting: Food for ThoughtIn probability, a bot will only take paths into which a wypt. splits off. But that's not where the main emphasis of the sentence should be, for something a bit invisible to the mapper's naked eye; it should be the sole fact that a bot
will take paths into which a wypt. splits off. Do you want bots to take a particular path where some trail splits into 2+ trails, but the area is too congested to make more wypt. trails go more towards one of those trails (lest The Proximity Factor starts disrupting) or the wypt. locations are just plain inappropriate / too lazy to make more? Simply connect a wypt. to a wypt.... twice. Or even more. It doesn't look like anything happened, but now there are two strings between the same wypts., which means that bots are 2X, 3X, or however many strings you set much more likely to take that particular path. Pwn.
To send bots even more accurately along, say, two different trails, you can set two strings for one, and three for another, to get 3/2s-probability for even more accuracy.
Article: The Proximity Factor
You already know that as soon as a soldat strikes a wypt. it performs the next wypt's. action, right? And you now know, thanks to yours truly's guide (
), that the strings connecting wypts. are totally invisible to bots and serve little purpose other than guiding the wypter. like j00 and j00rs truly and making wypts. active (it's true; if you set a wypt. blankly in space, even if it has a set action to perform, as long as it has no strings its existence is meaningless).
A bot will change its actions according to
any wypt. it next strikes, even if that wypt's. on a different path than the bot's original trail; the bot will also change paths accordingly.
This becomes a big problem when path-splitting in a certain area on a map causes one trail deviation to roll or continue to move right and fall through a hole, and another to jump over the fall, to become likeable. If you set the wypts. close enough in a particular manner that seems all right the bots will always take one path; that's the closer one, because they are nicking maybe even just one or two pixels of a wypt. which is on a completely different trail than the intended.
For a safeguard, I have them break at different wypts. which are far away from each other.
The Proximity Factor: Simple Example
Bravo side of Boxo's ctf_Struggle
Well, now. That is an
enormously open space. How can you be so sure of setting only one trail of wypts. to hit on the dot exactly? Well, you can still keep mapping out one trail, but just in case your bot quickly gets into and out of combat or simply reveals its imperfect nature as in all of our kind, take advantage of the proximity factor and set other guards around, in case the bot misses the initial one.
Section: To Have Bots Camp EfficientlySo your map is a flat line like Lagrange? What if you want some bots to camp at a sandbag or somethin' but others move ahead? Here is what the n00b would do:
Lovely swamp trees, aren't they? Now here is what I'm sure you 1337 wypters. would do:
Reason for the difference is in the image. Reason for the SP difference is because if they spawn and start moving east right away, that close, they might come into contact too soon with the S&C wypt. and not be able to avoid it. Therefore I moved it back (or you could place a wypt. with no action under it and not have any bots from it do anything until they hit the ground).
Section: Waypoint InterferenceHere's a graphic from the left side of Wraithlike's purposely misspelled htf_Minotour, which shows even more advanced possibiltiies in taking advantage of the proximity factor:
Here we see a clear intersection of these waypoints. So what if Bravo bots are approaching from the second level, and jump? Of course they'll first jet a tiny bit to the right due to the small red line, but then the wypts. above dictate that they'll fly straight. However, the waypoint in the way for bots approaching from the third story has
those fly up AND right, and upon striking this, the bots who came from the second story will do likewise. But also due to the proximity factor, the bots from the second floor who are now heading up-right from having struck the jump wypt. originally intended for third-story troops will still stop jetting at the middle highlighted wypt., which allows for interesting techniques.
Subsection—Back to Pathing's The Invisible Circle: Advanced TheoryHere's another snapshot from the left side of Wraithlike's htf_Minotour—as you can see, I did not rework the original wypts.' layout. The highlighted waypoint east of the flag looks weird, no? There is a waypoint above the Bravo flag with no preceding connection, and there is a string linking the east one to a jump waypoint going through layers of normal-type polygons. Why would I do this? Think of the invisible circle, and combine this with your knowledge of the proximity factor; I am making the lengths of the next strings of that east wypt. the same length, so there is an equal chance of any bot taking it to run left or jump up the shaft of the palace. Connecting the waypoint east of the flag to the one above the flag won't do, since that would obviously make the bots take that route every time, and we want them to have a 50% chance of running left.
(To avoid so much calculation, I could also simply connect the wypt. to the regular jump one right above the flag and lay an extra "run-left" wypt. correspondingly closer, but I decided to simply take advantage of the already-existent jump wypt. in the top-right, which would be a better move if you're getting close to the map's 500-wypt. limit.)
Section: Similar Actions in Path Division
Eastern side of ctf_Laos
You do not need to pay attention to the adjacent proximity of the selected waypoints; they both direct bots to head left afterwards, so it does not matter if the bot touches one when it was performing the action according to the other (although you'll need to playtest in watching them take either one of the straight run-left routes or the upper path, which requires its own gauged distances from the others since its subsequent wypt. is jet-left, not only run-).
Western side of htf_SuperPants
(Wireframed because the actual level is virtually impossible to see, being so dark)
Look at that crucial waypoint on the pillar in the center. You want to make absolutely sure the bots can get that or else they'll always just fall down past the pillar and never reach the higher area after the jump. If they always drop down that'll be boring. If you stop holding right-click after having jetted for a while, you'll still move up for a bit. Same with bots. That's why the highlighted "jet straight-up" waypoint is so low; the kinetic energy will keep the bot moving upwards as it heads eastwards for the pillar.
Okay, so the screenshot was taken while it was still being waypointed. Point? What I mean is that normally one would set the highlighted waypoint here to "jet right," not just "right." There's still some space to clear, tho'. However,
watch the gravity! Leaping and running in mid-air doesn't last too long on the same line of the X-axis. When you establish the next waypoint, which I've no doubt in that scenario you'd put "jet right" (or even just "jet" from the kinetic energy of the soldat still moving rightwards due to the speed of the initial leap & run), make sure you take the gravity and the bot's current position after it strikes the "run right" waypoint into account.
And BTW, that "jump right" waypoint from the pillar is so high up as compared to a normal one because of the darned Proximity Factor; if it is too low those who crouch will get ensared into the other trail, and we don't want that, now do we?
Thankfully, the gostek is so humongous all you need to do is make sure one pixel of a soldat's head clips the center of that wypt. to keep him on trail (but I usually lower it to keep things simple and easy to see).
PW is basically the exact same as MM+... just different commands on triggering properties and stuff. The functions are just like PW in all its other functions; hold Alt to select, CTRL to drag, click to create...
Here are the main features PW has over MM & MM+:
→ you can make a chain of waypoints with the same property, useful for long stretches of bots just running; automatically strings new wypts. as you go via right-clicking and setting the future property of the next waypoint you place
→ you can sever connections between multiple waypoints by highlighting them
→ you can grab multiple waypoints and move/delete them all at once (with the vertex-selection tool)
→ if the map is symmetrical you can just grab one path and horizontally flip it over and set it as the other; cuts workload in half (tho' make
ABSOLUTELY sure the first path is
PERFECT, or else mistakes will also be duplicated)
→ PW has safeguards (you cannot check both Run Left and Run Right boxes or Jump and Crouch boxes simultaneously)
NOTE: PW is very tool-interactive!! If you're going to be working with waypoints it's best to turn scenery and objects invisible, as if you're selecting waypoints you might select something else that's not a waypoint at all and accidentally delete that, or whatnot (although there's always undo, heh). The tools' functions combine into each other so make-visible only what you are working with to be completely safe (and also to view other sections of another person's map not familiar to you).
Killing the texture and maybe BG colors also helps with the eyes somewhat for various maps
Article: Known Wypt. Bugs in Map Editors
MapMakerIf you're using MM, try not to mash wypts. from Path 1 and Path 2 too close to each other, literally pixel-wise. MapMaker seems to glitch when this happens, and you might falsely connect a wypt. from Path 1 to a wypt. from Path 2 later on, and that gets very pretty
If you place a wypt. and can't select it after you place it unless you click around for a few times, it might be conflicting space with another from the opposing Path, so view All from time to time.
MM is also buggy with waypoint deletion; see below.
MapMaker PlusMark.jp fixed the bugs above in his brainchild, MapMaker Plus, but both MM & MM+ are slightly buggy when it comes to waypoint deletion. If you delete too many too fast, a second one—not random, but related to the order in which you initially created them—becomes deleted with every next one you delete. Sometimes upon deleting, creating, and connecting quickly: a waypoint will disappear, leaving behind a ghost in which the string attached to it seems to be connecting to nothing. To avoid either of these time-wasting glitches, wait at least 2 seconds between deletions of multiple waypoints.
Soldat PolyWorksThere used to be numerous compilation-related bugs in PW, before v1.4 (some waypoints disappeared and left ghosts of themselves; strings connected to nothing, waypoints stringed up with others miles away, etc.), but I helped Anna weed them all out.
Still, beware of loading extremely old maps in PolyWorks! Sometimes for some reason the waypoints render the map unmodifiable outside of the MapMakers above. Another problem in PW is the severing of existing connections. Beware when using this! If you try to Backspace while selecting waypoints, you may get a popup error and result in other waypoints across the map losing their strings while the one you selected still has its own. To bypass this persistent glitch, simply delete the wypt., recreate it, and reconnect it as it ideally should've been.
(for Vltava)
Article: Synchronizing Waypoint Positions with Polygons Effectively
Now why on earth is the highlighted waypoint positioned
before the polygon which the sandbag is on instead of at the very edge? Remember, gravity in Soldat is very weak. The polygon curves up sharply, so if you have bots just run over it, even this tiny hill and the game's super-weak gravity will cause the bots to literally "hover" over the waypoint in their innocent running before they start to fall into that evil abyss (well, it actually leads to just another opening in ctf_Xenonia's Bravo base
But we want to distribute bots throughout all paths evenly for 1337 gameplay, eh?). So if the polygonal terrain you're working with is very narrow such as this area, put key waypoints where you're absolutely sure the bots are still running perfectly on a polygon (this almost always is the case; i.e., a small polygon curving uphill steeply and the following one downhill leading into a cliff)
Article: On Bot Behavior
I really don't know why I didn't go into this before.
Section: On the Influence of Grabbables & Co.This is the order of priority which bots take into account.
The bow is treated just like a flag, except that bots drop their weapon right in front of the bow. Very rarely this causes a strange jamming in which the bow is picked up ten times in one second by a bot forever until the bot is killed, but hey, the bot gets killed, and the game goes on. The PointMatch flag... just like CTF. The flags, just like grabbables.
Even... the inf. white flag for Bravo.
They act
SO moronic! They just run to it, and just keep running in place right where it's at. The only thing to keep them at bay is Special functions in Inf....
Just like the bow and the flag, grabbables are the most annoying and disruptive of all aspects of bot behavior.
This includes GrenadeKits, and MediKits (if a bot's not at 100%). As soon as they see a grabbable, they'll just run right for it even as they fire at any nearby enemies, even running backwards if necessary. They look totally moronic; they don't even face the powerup as they charge for it, and they don't jump for it; if it flies in the air (that is, perhaps a flag from an explosion or bonus from a LAN game), they jet for it. If it's in ctf_Voland's death pit, they'll just sit perpendicular to it at the top of the bridge until it disappears or they die.
SO stupid! Make sure you give the map good spawn point positioning for such powerups. I usually need to reposition the powerups on maps by expert mappers who can't or don't have the time to waypoint because bots disobey wypts. when blindly chasing grabbables.
When bots get into either combat or see and start running for a grabbable, they will remember the action of the last waypoint they were going to perform, so once they finish combat and/or (yes, "and/or"; they can be heading for a grabbable while firing back at an enemy) they pick up a power-up or it disappears on them, they will simply perform that last action and hope to get back onto the trail again.
Now, combat... all that crouching, running, leaping, jetting... it can drag a bot half a mapscreen or more from its original location, especially from explosive blasts, so that's why it's always crucial to test bots on a map not only on one team, but also to observe them in combat through Spectator Mode. They might reach places you never dreamed to be possibly accessible. As with grabbables: when finishing combat, bots continue performing the last action they were originally doing. If they for any reason can't relocate to the trail they were on before they rushed for that enemy bot or that grabbable... see the next Section just below for 30 minutes a month, free nights and weekends.
Stationary guns are of lowest priority in bot behavior. A bot will NEVER man a stationary gun unless it accidentally comes across it in its path.
This is very bad for bots! Although you may like to create a cool WWII bunker or whatever, it is not usually a good idea for maps which are meant to be played offline, or which may not get very popular online favor. Because of the blasted proximity factor (which really is the one major factor in all Soldat waypointing; it can be heaven or hell depending on what you're trying to accomplish), this kind of stat. gun placement, if you're trying to get a bot to man it, will almost always result in 2+ bots sitting there; one mans it while the rest stand next to it or even in front of it, and, effectively... ruin its effectiveness.
If you're going to do that, just don't set waypoints for such areas and have bots bypass them, or put stationary guns on mainstream paths like ctf_Kampf, ctf_Run, inf_Abel, or inf_Outpost where bots can just easily stumble into them on their way.
Subsection: GrenadesLive grenades are kind of like a powerup's photonegative to bots. They will run
away from them (even off a cliff, lol
) and stay away no farther than they would be attracted to them were they regular powerups.
Section: JettingYou know half-lives, right? Those graphs where the line on the XY chart looks kinda like the bottom fourth of a circle? Yeah, you wanna model wypts. kind of around that style if you're having bots vertically jump after having run in a direction and jet in that same direction. Don't put a Left/Right + Fly wypt. far away; from my experience you will need to lay multiple ones completely guiding their route for some reason (bots' attention spans don't last very long) - they seem to stop moving diagonally and simply fly directly up if the wypt. is too far away from the last one that told them to jump.
Section: Self-correctionIf a bot is given a waypoint, and it follows its orders perfectly but cannot reach a new waypoint, after roughly 5 seconds it will stop and check around for the nearest horizontally linear waypoint; it will proceed to run to that waypoint, and then pretend as if it "struck" it successfully and do whatever action that waypoint bore on it. It's quite ingenious coding Marcinkowski programmed, actually. It can only see about half a mapscreen, tho', so if there are no waypoints around, it will stand there until it enters combat and dies from it or shifts to a different location where there is a nearby waypoint to start following, or if there is a grabbable to pull it over (if there is no waypoint nearby, it will just stand there again; lather, rinse, repeat).
Subsection: The Longest Wypt.!This is the longest distance between two waypoints I've ever relied on for bots to be guided by self-correction if they enter combat while on the bridge. What's the point of this? Well, if you somehow lack Boxo's outstanding inf_Ahaggar, the Bravo flag is right beneath this bridge, and is also in the center of the map; Alpha spawns on both sides. So Alpha troops are bound to come on both sides of the bridge, and why ruin their horizontal momentum and have them fall into the pits opposite the bridge? But the proximity factor prevents us from placing any wypts. in the center of the bridge. If you don't understand that, picture this:
The hypothetical central wypt., which is what contrasts this graphic from the one above, is completely based on the assumption that bots who exit out of combat in the middle of the bridge will freeze due to no nearby waypoints, and is there to reguide them. Now, imagine (because this central wypt. is perceptibly tilted in the favor of Alpha coming from the east) that Alpha troops come from the left, onto the bridge. The proximity factor dictates (no democracy here
) that if a bot strikes a wypt., it will follow its new command even if that wypt. is not on the bot's original trail whatsoever. So all east-coming Alpha troops will go to the left, and none to the right. That's not fun! But what about Alpha bots potentially freezing on the bridge (which is why that very wypt. exists)?
The distance between those two end-bridge waypoints is
roughly ¾s of a map screen, and I've never given wypts. a greater distance than ½ a map screen—this is due to bot behavior and is why you do not want to stretch a waypoint across multiple screens. You can stretch them farther if the map is very flat like ctf_Kampf's center, but if the terrain you're working with is rather hilly, such as atop a boulder in ctf_Laos, it would probably be a better idea to use more wypts. As stated in the bot-behavior article above, bots stop moving and look for the nearest waypoint to resume movement if they do not come across a waypoint for a long time, so if they encounter a bunch of bumpy terrain which hinders quick movement, it will take them a while to reach another waypoint, or perhaps not at all before they start to readjust themselves.
See?, 1 literally avoids 2 as it heads for 4, and the 3s also literally avoid touching 4 as they charge for 2. Proxim. factor!
Section: Infiltration and Capture the Flag: Flagcarrier BehaviorFlagcarrying bots in CTF and inf. are insanely moronic. They will NOT fire back whatsoever (although I recently PMed Marcinkowski begging to have them retaliate in the next version
) when fired at. They will man stationary guns just as regular bots (but they won't use them, so they won't fire the stat. gun and just sit there until they are somehow knocked off, or until they die).
Also, remember!! The flag is STILL a grabbable even if it's being held by a teammate, so other friendly bots will flock to the flagcarrier... without facing him (yes, that means from an aesthetic sense stupidly running backwards as necessary, etc.), without obeying any nearby waypoints (in other words the best they can do is run and jet), et cetera, et cetera, et cetera!!
What's cool, however, is that they will crouch near if the FC stops moving, but even then they usually are useless as for some reason they will not fire until they come under fire themselves, not necessarily if they can see an enemy, so it really only serves for good screenshots.
Article: On the Purpose of Strings
Frankly, strings (connecting two waypoints together) are really only good for three functions:
- Literally activating them. If you have a waypoint lacking strings, even if it has a property like Run Right or something it won't cause bots who hit it to do anything differently.
- To assist you, the waypointer, in helping you keep track of which waypoints are for which trail. I mean, think about it; if bots followed waypoints just for their properties alone, I would get pretty messed up really easily without the aid of those bright connections. They also help in spacing out precise movement in some sections of particular maps.
- Bots face the next waypoint they're going to. (Jet-backflipping, anyone? )
Section: Back to the Proxim. Factor—Simple Trail Trick; "X-form"There is quite some usefulness in how bots ignore strings. Take this graphic of Rambo_6's inf_Lighthouse, for example:
(For the PW-illiterate, red polygons are regular, and green is doesn't-collide)
The terrain you're working with here is so small that there really is no point in having the Alpha bots, after climbing from their respective hills, continue on their same side. Bots do not always obey the wait-1-second command for some reason—it is unfortunately unreliable—and if you have them wait for 5 seconds just to make a simple jump like the one needed here, enemy Bravo bots may respawn by then and waste all the effort. So, just have the bots cross! So what if they overlap over a trail? They're invisible to 'em anyways, so it doesn't matter.
Center of Boxo's CTF_TrekHere is where the X-form trick can be put to more practical use. It kinda looks a bit messy here, but the highlighted waypoints indicate bots of the teams heading up, and the others around them, down. You can see how, given the way the waypoints here are positioned, bots on the northern path can roll through the hole to continue underneath, while bots coming from below can jet up, without any interference by the proximity factor, thanks to this simple x-form.
This graphic also illustrates quite clearly exactly how much momentum a simple forward leap can carry you when accompanied with jets.
Those soldaten are
BUFF.
Mini Glossary:"String" - connection, the line that connects two waypoints (I call connections strings)
"Trail" - a path, not necessarily the formal Path 1 or 2; just a generic route for a bot to take. For example Arena has many possible trails while ctf_Run has 3 trails.
"Freeze" - an action performed by a bot when it just stands there and has no nearby wypts. to refer to
