Rail Gun

[Riotlung]

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.

[TomTom]

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.

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.

[Riotlung]

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.

[TomTom]

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)

[420Blunt]

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.

[TomTom]

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.

[enigma1]

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

[TomTom]

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

[nedd3h]

Originally Posted by TomTom

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

[TomTom]

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)