.:: Bots United ::.

.:: Bots United ::. (http://forums.bots-united.com/index.php)

- FritzBot (http://forums.bots-united.com/forumdisplay.php?f=53)

- - Rail Gun (http://forums.bots-united.com/showthread.php?t=6651)

I know that this map is not FritzBot compatible. Will it ever be compatible, or has development on it stopped altogether? Just kind of curious because I see lots of custom maps that are compatible but Rail Gun isn't.

In the FAQ, Mal states that he had worked on train support but does not say how far along it had got. Basically unless Mal finds time to work on FritzBot again or transfers the code development flag to somebody else then No. :no:

To sum up, this is what vehicle behavior FritzBots have;

1) Only one vehicle has active focus at any one time.
2) Vehicles are assumed to be vulnerable to damage
3) Only one team owns the vehicle (can move it) at any one time
4) Only the team that owns the vehicle mans the mounted gun (if any)
5) Vehicles are assumed to be high priority to game objectives.
6) The team that does not own it will use grenades, satchel, panzers and air cans to destroy it when near enough.
7) The bots that own it, try to get to the vehicle's script trigger to move it from the node nearest to it (or is that nearest to the script_mover?).

Now waypointers like Crapshoot et.al. have found ways to partially adapt to these limitations by;

7a) Moving the vehicle one stop at a time along its sometimes 100-200 splines/markers so that the nodes and connections are optimally placed so the bots approach only from the right direction, to trigger movement, do repairs etc. This approach might also be used to direct bots into a restriction like a cab BUT ONLY WHEN THE VEHICLE IS STOPPED. Bots can't calculate how to get inside a moving vehicle.
7b) Re-scripting (if possible) a new movement trigger to change its location and trigger area. In this way for instance, bots may move a vehicle just by getting close enough to the to outside (like the trains in __Bridges__)

Now it might be possible to figure some way to swap the bot ownership behavior in Railgun but it would be arbitrary (like who owns the CP, or which team last got close enough to trigger movement). And I suspect that the team that got to the train first would likely "own" it for the whole game. The other problem is that the attacking team would try to damage the train and since it is invulnerable, waste grenades, satchels, air cans and do lots of team kills (like in my Supply Depot 2 and 3 waypoints).

So with current behavior waypointing Railgun would be a lot of work for a less than mediocre result (the challenge would be interesting though). If you want to play with trains, Bobots can operate the train in Railgun but even then they are nowhere near as good as humans.

As to non-objective script_mover (trams, skycars, monorails, blimps) as well as gliders I have had some success not declaring them as vehicles and inducing the bots to use them by path restrictions in combination with fake toi-func_construct interactions between the aiscript and the map script. But even here (see glider 3.02, eagles2ways, northpole, airassfp1) the bots are never as efficient as humans.

That's pretty sad :( I can understand the difficulty in coding the bots. I'll stick around with what I have though. I believe I'd someday be able to play this map on FritzBot.

On the point of getting the bots inside.

I am trying out how to get the bots inside the cab on railgun. It is just an academic waypointing problem that interests me. There are 80 splines for the two tugs (i.e. places that the tugs can stop) And it seems just possible to do (maybe). It looks like a herring bone pattern because the script mover location is embedded in the engine wall of the cab. So the trick seems to be to place the center node at that point and adding connections out the cab doors at a slight angle to nodes that run beside the tugs. But 2 problems then crop up. The nodes beside the tug can't be that close or the bot may try to move/repair the tug from there. The second problem is that connecting the central nodes creates a shorter path that the bot may try to use leading to the bots climbing on top of the tug's engine. So I am trying out adding an extra central node in between the others, placed in the tug ceiling with the aim to make the side paths shorter than the central path.

So the key then would seem to be to ensure the center node is always closest to the script mover (and closer than the side nodes) but that the path beside the tug is shorter than the parallel path in the center.

Talk about a finicky placement and it takes 320 nodes! just along the 2 tracks. After some more testing I might do some screencaps and compare them to the bindlestiff's __bridges__ in a wiki article discussing vehicle movement. (BTW there are no defined tags on the tugs so I don't know if the triggers could be changed in Railgun)

Here's a script that lets players escort the trains from the sides. You might have to play around with the mins/maxs of the trigger_multiples I added to make the area a bit bigger. The problem is when the 1st tug gets around the corner the angle of the bounding box might be off a bit causing the bots to miss it.

Thanks 420Blunt, the 4 creates work well. I hadn't tried creating my own yet, thinking I needed to remove the originals like Crapshoot helped me do in supplydepot2. The herring bone pathing does not look feasible in narrow spots like near the axis wall through to the axis spawn tower. I might try changing the box slightly (taller and maybe slightly narrower TBD). It might be interesting to see if there is some way to timeshare tug ownership and see how bots would respond. Fortunately there are few tois in the original map.

You could use the set command to adjust the min/max of the box based on the tug's spline. That should take care of it theoretically and the mods should be on the .script file only for this.

For the timesharing using it as a tank may not be possible. Maybe having roam actions every 10 splines or so along teh tug's path could force the bots to concentrate there. The actions can be enabled or disabled based on the spline the tug is so not all roam actions are active at all times but only 1 or 2. Using action groups we could shift the focus to different locations.

BTW is there a test .nav file available for the map or it needs to be done?

Nice work 420Blunt

CK-Chaos

That should not be necessary. The issue was with the herringbone pattern when the side nodes got too close to the script mover such that the bot would try to reach it through the engine sides. I tried 420Blunts stuff and narrowed the limits. It is good, but any waypoints of Railgun will suffer some of the same problems as supply depot. Specifically the team attacking suffers loss of ammo, charge bars and teamkills because the bots do not understand that the train is invulnerable.

The train support camps/roams will require a system of fake toi-construct communication because unlike other maps the train can be pushed back. There are already up to 8 tois used but I think 2 can be re-used. Now two are needed for the track switch (and a fake action helper), leaving say 4-6 tois for other things. The first tug could use say 4 toi-constructs for its position, and the the second tug would need the rest if available. Event expire or fake func_explosives could be used for the ammo state (loaded, transferring, delivered).

Moving the train by roams and an enlarged trigger as a non-objective script-mover would IMO reduce the map to almost deathmatch style. While it would free the engineers to focus on the CP, mineplants, controls and mgconstruct (if left in), it would give an advantage to the human player.

Anyway this discussion just reinforces the conclusion that while an interesting challenge, we will not create release-quality waypoints for railgun unless Mal releases a newer version of FritzBot ET

Quote:

Originally Posted by TomTom (Post 57863)

Anyway this discussion just reinforces the conclusion that while an interesting challenge, we will not create release-quality waypoints for railgun unless Mal releases a newer version of FritzBot ET

I'm another one who would love to see this. Railgun support with a couple more of the etpro features (client scripting options for class/spawns etc) would make this mod very close to perfect :)

Correct me if I am wrong but I don't think an etpro client can currently be connected to a FritzBot ET server. However we should be able to support some of the tower spawns...
Your etpro class stuff if it is what I think it is means more work for Mal. Alas I don't think Mal will finish FritzBot while he works at Id software. So the only question for waypointers is should we do a lower quality Railgun waypoint?

(BTW I counted wrong there are 7 TOIs in the original railgun script and it might be possible to exceed 16 total TOIs by one or two max)

correct, etpro client cannot connect to a fritzbot server

v2.60b et clients can connect to v2.60 and v2.60b fritzbot servers (if fritzbot mod installed)
edit: thought i was in a dif thread lol - v2.60b info good to know anyway

Hi,

I have created playable waypoints for railgun and railgun_eu. The difference between the two waypoints isn't much. The railgun_eu version has the tower spawns for axis and the command post spawns for both teams, but the bots are only set up to spawn at the tower.

I'm posting it to get some thoughts and suggestions while I continue working on it.

You can get the railgun_eu map here.

Yah the challenges are so tempting aren't they? Getting inside the cab might be more challenging with the larger trigger area, And it will be interesting to see what transpires when both team movement triggers are firing away at the same time (poor little Thomas ;)). But the final question remains will the bot focus enough on the cab when they don't see it as a vehicle, I can't wait to find out...

Congrats 420Blunt, it is certainly good enough for government work, though I suspect without a human player the Axis won't get the ammo delivered often. The obvious exploit of riding in uniform inside the cab (the bots AI won't extend to "why is the train going in the wrong direction") is counter balanced by the need to clear the other team away from the tug to start moving again (poor little Thomas). I think this will be best played with one-two humans per team with axis having the equal or larger number.

Some suggestions:
-The current team size works well enough getting out of the axis cabin spawn but that could change. So I suggest you take a look at this idea I got from Omnibot. I would also suggest pathing and routing a few bots to go around the back in case of a Human doing the classic block-spawn kill strategy (of course the block won't work as well now).

- Even out of uniform I can lie down in the cab at length and watch the other team go by. Not certain what to do but a zig-zag path might make them turn enough to see me (hopefully they are not seeing me through the model and wasting bullets). At the same time I would love a better focus on raising the track switch when the tug is next to it. Making mixed spawns (part CP spawn) might help.

- Axis spawn mg could be given a type 1 mg action jic. A point to ponder is should the mg beside the CP be self repairing and when. or how fast

- fall damage coming down from the tower can be minimized by directing the bots taking nodes 380-> 17 to take a slightly different path so as to hit the switch signal pylon. This might be useful say in a later rev., if there were any camps on the tower (nudge nudge).

- going over the railgun could probably be handled by Allied bots (i.e. using the railing to get up) but won't be needed unless axis get better at getting to the controls.

- the tug trigger is a little big for my taste, but I would leave it be till you are otherwise done as it will greatly affect bot performance.

- So far I have not seen bots trapped between the trestles near the axis spawn mg, a problem I have generally had waypointing this map with a couple of bot mods.

Oh and one of the fake entities must have as origin the wall of the axis cabin cause a hint is appearing at -1460 4820 370 ( 178 ). It disappears after the tug moves (helper_ent_obj2 maybe)?
- - -
Bot only balance is acceptable in testing IF you give Axis a man(bot) advantage (wins are 12:7 Allies:Axis on teams of 7 plus one extra bot for axis). Better than I anticipated.

A few things of note:

Action 30 the Axis mg camp at the CP was being manned when the ammo was delivered to the gun and the CP was in Allied hands. was never fired offhand cause the only bots going down the hill at that point went over the track switch mg nest and were not seen.

Allied engr bots building the CP when the mg was manned would attack the Axis bot manning the mg. However from their position the bullets were obscured by the handrail I guess. Funny really cause the Axis bot (medium skill) totally ignored the Allied bot until it got knifed in the back when the engr. ran out of all bullets. Your action radius is already at maximum size at the CP, maybe it should go off center? (if only the bot would stand and fire...)

Two suggestions at the gun controls. Put a medic classed camp looking out from the controls at the end of the match when axis need to rebuild them. And when the controls are built either path it so the engineer should enter the controls before descending or add an engr camp at the built controls to draw them in. Hopefully that might bring even bot teams nearer to balance.

You could also adjust the nodes near the heath and ammo cabinets near the CP so that some of the bots passing brush them, otherwise the humans will gorge themselves there...

thanks for this!

will give it a run with a few this week :)

One exploit of sorts to watch for; A human playing Allied medic or field-op can crouch on the tug engine's right side and keep the tug and ammo in the depot yard for long periods of time and see little to no fighting. A couple of suggestions: 1) Consider adding an aircan action ( To get an axis field-op to toss an aircan over the tug to force out the hiding human, say when the allies have the depot) 2. When the axis have the depot, route 25-50% of the bots to go around the tug on the right side. 3. Maybe roam an axis class to the bridge top and turn them to see the right side of the tug (when the tug is in the sector with the ammo).

As 420Blunt is not working on ET these days I have created a branch of his railgun waypoints so they can be added to the next waypoint pack. Of my previous observations I have mainly addressed a couple of team balance issues and making it harder for an Allied human player to hold the tug at the depot yard (flag) by hiding on the far side of the tug.

My Geocities link for the waypoints is here while it lasts.

BTW IMO I feel this map is important enough for inclusion in a waypoint pak that its current balance 3:1 Allies:Axis will be good enough.

Thanks!

perfect timing, I've come to the site to make sure I have all of the latest files for the maps I run on my test server

cheers
nedd

This pack is great! I just gave it few rounds with no issues that I could see. If another update is released, have a look at the default etpro mapscript for railgin... it has an exploit fix to do with the watertank. I have no idea how prevalent it is, just thought it may be worth adding to a futre update.

cheers
nedd