Maps Request
 

I would waypoint these but the tool is confusing, so could you guys try to waypoint these maps.

-goldrush2_wx
-beach(that's just the name)
-Atlantic_Wall_full
-ae_sniper_challenge

I think most of these can be found here: www.enemy-territory.4players.de
Cool thanks.

Re: Maps Request
 

When you don't have an exact name it would help if you could either provide a specific link to that map or the filename and date of the file in your etmain directory. Fritzbot already supports 2 maps that could be called "beach" (et_beach and mp_beach).

(Please be patient. All our waypointers are busy at the moment. To keep your position in the request queue please stay on-line. A waypointer will be with you shortly.....;)).

- - -

OK after flying Around IMHO;
(1) :thumbdown:ae_sniper_challenge:sleep1:
No objectives, nothing for engineers to do, the bots can't work the lever and are highly unlikely to cross the river on the high wire. Basically it is bot bored to suicide. If you want to try learning waypointing just learn how to do nodes, connections, roams and camps because that is all this map will support. Sorry.

(2) goldrush2_wx :unsure:
Another goldrush variation, some good maps changes, others just convoluted. Likely possible candidate but myself not having played this one I would personally prefer to do goldrush2_fk_b1 (fewer changes less convoluted). Goldrush is Crapshoot's map so he gets first refusal. If you really want to learn waypointing this project would give you the chance to see how goldrush works and learn from the Master :chef:(but work on something simpler first).

(3) atlantic_wall_full
Probably a candidate, but a bit bland. Good map for a beginner waypointer IMO. If more people vote for this one it could be done as beta in a long weekend I think.

(the opinions expressed in this post do not reflected those viewed by placig a mirror in front of your monitor ;))

(4) if beach.pk3 is the beach that you mean, you should realize that it is just the old old old map that mp_beach, et_beach ( and others 1944_beach...) were made from. It is blander than the newer maps but could likely be waypointed using the et_beach waypoints for an initial template ( assuming that the coordinates were not all shifted). It could be another good map for a beginner waypointer. The editor is not that hard and we would help you through the process.

Re: Maps Request
 

Ok. I do need help with the waypoints. The Nodes are for what again? And I the routes are just the way te bots move? I wish you could place the actions in-game, like you can with the omnibot tool.

Ae_Sniper_Challenge, that map was waypointed with omnibot, it's just a sniping map. Not suppose to have objectives. I have DSL so some maps will be hard for me to get.

Re: Maps Request
 

From what others have posted omni-bot must be basically roamers without objectives. You could try to turn fritzbots into roamers but it might take a lot of roam actions and tweaking.

There are 4 good sources for learning how to waypointing fritzbot;
(1) this community
(2) Denny's tutorial
(3) Hobbit's Tool tutorial
(4) The Wiki.

The basics. Bots are either navigating or they are fighting. If they are fighting they move about restricted by the clipping surfaces of the map, the position of the opponent, and the laws of physics implemented in the game (g_gravity...). But when there is no opponent the bots need to understand the location that they should to go to and valid safe paths to get there. This they understand by the waypointing system.

The nodes and connections are the core of waypointing. They can be seen (when the editor is on) as analogous to a state diagram. If you ever took some courses on programming or on data structures then you might have seen something on State Machines (A method of describing a machine or program as having a discrete limited number of mutually exclusive states. )

An example of a state machine could be the airport-airplane system. Gravity means that airplanes want to come down and in an ideal system they only come down at airports. So a plane has the state of being at airport X. It takes off when scheduled and conditions are right but only according to the airliners flight plans (which defines the possible next states).

Now the machine changes states where permitted when it gets a specific input for a given state. The way a state machine is graphically represented is as a drawing with a number of circles (the states) interconnected by arrows with an input (condition) written beside them. The diagram is somewhat similar to a flow chart, but much simplier.
Well imagine if such a diagram representing bots navigating the map was then laid so as to conform to the map surface. You would then see some spheres or balls with arrows going between them. And the bots would then want to be inside one of those balls (states) when they could, and with each input they would chose an arrow to use to get to the next state or ball. And being a real system the bots like the airplanes take time to change states/locations.
Now in the editor for Bobots you actually see hollow spheres and color coded connection, but this gets difficult when things overlap. So to make it simplier in fritzbot the spheres are represented by a vertical spindle with 8 equatorial radii spokes (when the editor is set to display the radii.). Red spindles for nodes, (and yellow for actions white for routes). And to represent the direction of the arrows rather than use colors fritzbot connections as it were flow in the 'downhill' direction of the connection.

But then what forms the inputs to the machine? Well the combination of the placement of action spheres (and their type, properties etc.), as well as well placed route spheres and the state of the game objectives all act as inputs on the bot. Then depending on the class of the bot it selects an End state for its goal then choses a next state in the path to get to that goal. The bot will always chose the highest priority goal, and shortest path, and that can make them very predictable. So to add a quasi-random element a route sphere can be considered as a single 6 sided die. The bot in the sphere having no current goal rolls the die and selects from the route properties the corresponding altroams defined for it (assuming the route has a valid action for that class of bot). the bot then makes the alt-roam its primary goal with the further intent to continue from that point to its ultimate end goal.

Re: Maps Request
 

I like both but I think Fritzbot is sightly better. I'm trying to waypoint Atlantic Wall, but do I place only one route on the other side of the node, as the secondary way they could go?

Re: Maps Request
 

I normally don't bother adding the routes until 90% of the nodes and connections are done, and the principle actions are in place and tested, Some small maps can be played with no routes since the bots can 'see' everything and normal roam actions (#12) are enough to get them to play the map thoroughly.
When you are at the point to add routes, identify the locations in the map that the bots will obey routes (spawn point, an alt roam for another route, or an objective task upon completion). In atlantic wall the allies spawn can have a route to direct some engineers to the dynamite wall location, some to the command post, and other bots to camp positions, fixed mg42 camps and the ladder opening. Once the wall is blown activate objectives inside the fort either using the goal_tracker or by using action_groupings activated in the aiscript. The goal tracker works well for largely linear play where no more than 2 dynamite objectives will have the same goal number and where there are no constructable impediments to navigation.


Anyway read the wiki page on The route system. It is a good piece of work. I am throwing together a brief links page on my site for those who don't like to go linearly through the manual and tutorials.


(If you are asking about adding a secondary route at the altroam end of a master route, you can add more than one route if there are so many directions and actions to support. I think the start of the secondary route should be overlapping a bit of the altroam of the master route. To be certain about your routes you need to do a bit of testing including isolated route testing.)

Re: Maps Request
 

Can I see a screenshot of a map, where the routes; nodes; actions are placed?

Re: Maps Request
 

OK
This link shows nodes, connections and radii for a jump down situation

Denny's tutorial has some shots
The basic and advanced node tutorials show you a lot
The actions tutorial show some applied dynamite, steal deliver and flag actions aircan and mg42 actions
The route tutorial just gives a basic shot of a route.

and i will upload some example shots to a directory on my website over the weekend that we can discuss.

And
btw I should apologize. beach.pk3 is the old old old map of fun
_beach and 1944_beach not et_beach or mp_beach and is a perfectly valid target for fritzbot (since nobody is working on the former 2 currently. I think I confused myself with some recent testing of bobot 3).

Re: Maps Request
 

I'll try to waypoint atlantic wall... Has the raingun been waypointed yet.

Re: Maps Request
 

Good for you. If you get stuck or just want another opinion feel free to post any work in progress. (Best to start a new map specific thread)

re:Railgun
Train support was not finished by Mal, so railgun is a poor candidate for fritxbot 0.7. Basically fritzbot can only support one team at any one time aiming to move a vehicule. If you want to play railgun I suggest installing Bobots 3.05. In many ways not yet as good as fritzbot, but much improved over rev 1.03. Railgun bobots do work the train in both directions and can lift the track switch (fritzbot can't do either). They do have some difficulty getting into the cab so Bobot is not perfect yet. Tank support (e.g. try goldrush) is good too in Bobot since the opposing team will make good use of the tank mounted mg42. The lack of Cvop uniform steal, mine laying and CP satcheling is however a definite minus in Bobot 3.05.