This page attempts to capture items about a bot teleport glitch that is reported on Linux dedicated servers running RCBot2.

This will be a work in progress article and may change rapidly.

Please contact me if you have something to add.

Latest change:

• 12 April 2025 - New article made.
• 15 April 2025 - Some more tests with SourceMod plugins and dod_kalt also had a bot to map origin teleport.
• 6 June 2025 - more tests and videos

INDEX

Basic description	Basic description of the glitch. Test videos
Common factors in the incidents	What is common in testing and what is different
Map origin locations- where are they?	Images of the dod:s map origin location
A download of incidents captured	Files that may help others.
SourceMod plugins could help?	Perhaps a plugin could help? Details, tests.
dod_kalt incident	First incident on dod_kalt
Make a new version of dod_avalanche and test.
dod_colmar has this too	4 incidents in under 7 minutes.
dod_anzio also has this issue
Dev Zones plugin may help.	A set of two plugins, config files to help.
Test 18 - V Physics issues - grenades and bazookas	A set of tests to rule out more items.
Test 19 - rcbot_tele_glitch.smx	A plugin that gave some weird and good results
A further plugin that really helps.	Refined plugin that works after more tests.
Test - 22 dod_avalanche captured bots	Using a plugin SourceTV - what bots do on teleport.
Conclusion (so far)	Rule in and rule out items after testing.

Basic description

You can call this a "RCBot2 bot teleport glitch". This will only happen with bots (RCBot2) and so far, only noticed on a Linux dedicated server running the latest Linux files. Windows and Listenservers have no reports of this glitch... so far.

The most common report is a complaint that a allied bot is under the map ground on dod_avalanche near the center cap zone, from there you can only see a shadow of the bot and the bot can shoot you from there.

However, as more incidents came in it shows it can also be a Axis bot too and can also be above the ground near the center capture zone.

Also, this can be seen on dod_jagd, near the AA gun Detonation capture area.

This glitch can be best viewed on YouTube. I captured the glitch in 4 videos The "teleport incidents" happen so fast I had to make a special demo file with SourceTV so I could look at the source location where the bot disappears and the destination location.

1. In each of these videos read the video description for a timeline
2. Use the arrow keys (between M and / ? keys) to go frame by frame.
3. I used a special set of dod_avalanche waypoints to rule out waypoint types and radius issues. The are all normal waypoints.
4. Note the destination is ALWAYS the X and Y axis of the map origin X "0" and Y "0". However the Z axis that is height is ALWAYS different and matches the area they teleported from.

Video incident 1 - Allied bot, [RCB]w00tman teleports from waypoint 82 and goes to the map origin.

Video incident 2 - Allied bot, StuckPipe teleports from waypoint 52 and goes to the map origin.

Video incident 3 - Axis bot, teleports from the allied second flag and goes to the map origin.

Video incident 4 - Axis bot, CowBoy teleports from the archway down from the Axis first and goes to the map origin.

 

The randomness of this makes fault finding very time consuming, the more incidents captured the better.

Nothing in the server logs indicates a common issue when the bots teleport.

 

Common factors in the incidents

The only common factors in the 4 incidents I have managed to record in a .dem file and have seen (another 4 but the .dem file was broken) is...

1. The map origin is always the teleport destination, but... only the X and Y axis coordinates.
2. On arrival to the map origin the Z axis coordinates (height) always matches the area that the bot teleported from.
3. For now this is only Bots (RCBot2) able to do this glitch.
4. The map origin is also where a bot joins the server, suicides and joins a class and team.
5. This has only been noticed on a Linux dedicated server running RCBot2.
6. This is likely on TF2 as well its just that people are not noticing it.

That is it for now. No other common items have been noticed.

Here are some assumptions I had in testing so others can learn from my tests.

1. It could be a RCBot2 command? I have looked in the config.ini and disabled (-1 value) a lot of obvious ones. Obviously dod:s does not have teleport functions like TF2... but this bot program is also for TF2. Disabling "rcbot_move_tele_time 120" or "rcbot_move_tele_tpm 1" were two prime targets but that had no effect. I have not tried all commands yet (did do all HL2:DM and TF2 special commands) but have disabled a lot more less obvious ones as well... no luck yet.
2. Do a fresh server install and the bots stop glitching? I have and others too tried that and the glitch comes back. The randomness to reproduce a teleport glitch incident adds to what may stop the glitch.
3. Can a plugin stop this? Maybe, this is being explored in a SourceMod thread here. (edit so far the answer is no)
4. This only happens on dod_avalanche and dod_jagd? No, it looks like this coulds happen on other maps too. dod_kalt had a incident. It's just hard to detect  and people who are not looking for it get shot when the bot is under the map.
5. This only happens on Day of Defeat Source running RCBot2? I would say not, RussiaTails has seen this in TF2 as well. Only snipers he says.
6. This has to be a map issue? No, I have found some items (entities, clips and displacement issues) on dod_avalanche, I fixed those and made a map called dod_avalanche_botfix... the glitch did eventually happen after 20 minutes.
7. It's the waypoints ? No, tested a alternate simple set, tested other map versions of dod_avalanche other mappers made and they too have this teleport glitch.

 

Map origin locations- where are they?

Seeing one of the known common denominators is the bot (as far as i know) always goes to the map origin, it helps to know where they are so you can monitor them.

I opened up Hammer and got each one.

dod_anzio Known to occur
dod_argentan (Known to glitch)
dod_avalanche Known to glitch
dod_colmar Known to glitch
dod_donner Known to glitch
dod_flash Known to glitch
dod_jagd Known to glitch
dod_kalt known to glitch. 15th April 2025.
dod_palermo Known to glitch

 Update May 1st 2025: likely all maps have this glitch.

 

 

A download of incidents captured

During my captures I tried to document all I could.

Assembled a download 40MB of .dem files, notes and server logs.

 

SourceMod plugins could help?

First up... making a plugin to fix a glitch is a band-aid over something that needs surgery.

However, sometimes finding out what stops the glitch can lead to why the glitch occurs.

Listing ones I looked at...

• "The Void" that is supposed to remove weapons that are not in the map, however that didn't work because technically below the map on avalanche is inside the map. As mentioned before... this is being explored in a SourceMod thread here. That may produce something.
• EventInfo. If combined with Source or dod:s events you could get a report at least if a even has been fired. (Edit - so far nothing I added to the events in the .sp file (then complied a new plugin)  has come up with any events on multipule incidents. Is this related to bot player speed or gravity? Perhaps it's part of the glitch, running, jumping, friction or a combination of both.
• "SpeedUp" That you can set (in a config it makes) for bots only and you can alter the speed (sm_speedup_speed) and also the gravity (sm_speedup_weight) I tested that (speed change only, slower) and the teleport still occurred, I have not fully tested gravity (weight) yet.

None of theses helped uncover what the bots do when they glitch. In a lot of incidents it is clear the bots are having issues with deciding what to do while on a pathway (between waypoints) and some do some strange things like go forward, then backwards then... they teleport.

What "buttons" is the bot pressing and how they glitch to the map origin is similar to a glitch patched in CS2 a while back (use of binds and forward and back commands)

 

dod_kalt incident

RCBot2 map teleport incident # 13
Bot is “[RCB]Cheesehhhh” in this incident. Bot is an allied rifleman.

This one is interesting as this is the first teleport to a map origin on maps other than dod_avalanche or dod_jagd.
This map is dod_kalt.

The map origin is outside the map area and in between the map and the skybox. (see above image in the Map origin locations- where are they? section)

I found [RCB]Cheesehhhh in spectator view it was black. I put that on the bot’s view and this is what I got…

So it isn't just dod_avalanche and dod_jagd. This could happen on any map including the ones like dod_kalt where the map origin is actually outside the map area.

Now that is weird.

Make a new version of dod_avalanche and test.

I haven't mapped in 10 years, however I did make a version of dod_avalanche, changed a few things around the map origin...

1. The capture zone for flag 3 (center). This was on the orign, move it away.
2. A water_lod_control was on the map origin, moved it away.
3. Player clips of odd sizes around the map origin ground level, removed them.
4. Displacements on the ground were extended past the map origin ground level and edges improved around the rubble (its why the player clips were there.

I tested it after it complied. Made waypoints. The teleport incident happens like before.

 

 

dod_colmar has this too.

Just by knowing where the map origins are, you can sit there for a few minutes in spec' and if the (Linux) server is faulting on dod_avalanche it's likely other maps are doing this too.

Its just that the speed this happens at, blink and you miss it, dod_avalanche and dod_jagd are more noticeable as the bots are teleporting to the map origin and maintaining the height, in the case of dod_avalanche the allied bots coming from lower on the hill are seen under the map, axis drop down over the map origin as they come from a higher part of the hill.

Same on dod_jagd, the map origin is the highest part, most other areas are below that.

Here is a PDF report on those 4 incidents over 7 minutes on dod_colmar.

I would not be surprised if all maps running on a Linux dedicated server with RCBot2 are doing this, nor would I be surprised if TF2 Linux is doing this, or HL2:DM too.

That mod HL2:DM has Valve bots, I may look at that next, know where the map origins are, sit there are wait I suppose.

dod_anzio also has this issue

 I found a bot (2 actually) doing this on dod_anzio.

I would say this is all maps now... 5 or so minutes at a map origin with a video recording, you will see one eventually pop out of thin air.

It may be time to look at TF2 and HL2:DM as they have RCBot2 but also Valve bots.

Catching a Valve bot doing this in TF2 Linux Dedicated server would be very interesting.

 

Dev Zones plugin may help.

I assembled a set of plugins that at least help on dod_avalanche , Kalt and jagd. You can download that here, it has a readme.

Update: May 1st 2025... seeing all maps are now likely to do this, a plugin like the above that can filter bots and not humans and also their teams would be a good idea...

1. The map origin should have a teleport source cube around 128 X 128 and cope with heights of the entire map elevation.
2. The teleport source needs to filter bots and real players.
3. The teleport source needs to filter teams.
4. The target destination should be back to the spawn area for each team.
5. Maybe... the plugin can look at the elevation of the entire map (Z axis low and high) and find the map origin to place a cube of 128X128 (X and Y axis) based on the elevation. This way all maps are covered.
6. Perhaps a optional chat message with "0" / "1" to turn it off and on and also have a entry in the server log.

That is complex solution! However seeing we don't know how bots are doing this it may be the only way for now.

Or we just...put up with it.

 

 Test 18 - V Physics issues - grenades and bazookas

In this test I noted during some teleports I was seeing this error...

Ignoring unreasonable position (100.826164,-1522.819946,-94629.656250) from vphysics! (entity class C_PhysPropClientside)

Basically a entity like a prop_physics_multiplayer model (like a gun) maybe outside of the map and will not be spawn-able again or it can be some error with a map that a model without physics has been incorrectly set as one that does like prop_physics_multiplayer on a model that is really a prop_static (no physics).

If you go to that coordinate in Hammer editor on dod_avalanche you end up down in the very outer edges of Hammer… due to the Z axis value -94629.656250
Now if we edit the Z axis only to 0.0 and go to the X and Y …. 100.826164,-1522.819946,0.0 we get a position near the allied second flag. Some other locations are the lowest point of the allied spawn... outside the map by about 300 or so units.

Are there any map errors those areas? Yes, all sorts of displacements, func_detail, and models around the allied and axis spawns outside of the map not inside a skybox or “world geometry” with a nodraw texture.

But they are not the cause of teleports.

Perhaps it's a weapon attached to a bot as they teleport, either on joining the game and going to the map origin, then getting a team and class and finally ending up on a team spawn point.

 

The other Physics experiment was a server setting. sv_turbophysics 

Normally in all Source games the default is sv_turbophysics "0" (off). However on a VALVE WIKI page it says dod:s is the only game where this is a default of "1".

So I checked my Linux dedicated server as I have not changed that command, it was sv_turbophysics "1" (on).

OK...turned that off "0". Did the teleports stop?

NO difference.

In the end that test didn't show anything that stopped the teleports.

Maybe it's grenades or bazookas?

You can tell the bots via a command to just use knives, this will stop the use of grenades and bazookas.

It made no difference.

• sv_turbophysics “0” or “1” makes no difference in the bots teleporting, tests show no difference.
• More Plugins that fix the “VPhysics Mayhem Bug” were tested and didn’t have any effect on teleport frequency after further testing.
• The error… Ignoring unreasonable position (coordinates) from vphysics! (entity class C_PhysPropClientside) could be related however I have seen teleports occur without the error as well. 

 

Test 19 - rcbot_tele_glitch.smx

I started a plugin to do this...

1. Define and Build a thin teleport trigger of 8 X 8 units that starts way above and below the map origin.
2. Filter that trigger to only accept bots, it may pick up also pick up non-teleporting bots going in that area.
3. After the bot is detected, get the bots team and find a spawn point for that team...transport the bot back to spawn.
4. If the bot was doing this log a message.

What happened next I wasn't expecting. More weirdness but it did help. I have a download of what I found and a PDF report describing what I saw as I captured a video.

Not going info the depth of the PDF report, but basically the plugin altered this glitch...

(Read first... map origin is XYZ 0.0,0.0,0.0 Looking down on a map X and Y is what you see, looking sideways you see the height Z)

Old behavior - the destination after the glitch: The bots used to go to the map origin X and Y coordinates (0.0, 0.0) and the Z axis (height) was ALWAYS matching where they came FROM.

New behavior - the destination after the glitch: The bots are interrupted going to "0.0, 0.0, <height they came from>" and are denied access to coordinates 0.0,0.0,0.0 (map origin) there seems to be a collision with the trigger and after that the...

• Allied bots end up being pushed sideways (X and Y axis) about 160 units diagonally away from the map origin, they also cannot maintain the Z axis (height)  and are pushed up about 60 units from 0.0, their feet are now about 250 units off the ground (map origin height)
• Axis bots do not follow the same destination, they end up over the church broken wall but are pushed up about the same as the allied height.

Allied bots end up here... always if the plugin is active	Axis bots end up here... always if the plugin is active

That is strange and in tests was repeated multiple times. These "push away" from the origin coordinates are perhaps the games collision rules, pushing away (bouncing off) other entities, like a gun or other props with phyisics, it rebounds.

In the plugin I tried to make a second teleport to pick up the allied team "bouncing off" the first teleport trigger... it made no difference, the second teleport doesn't get them back to spawn.

However, no bots can escape this "trap", they cannot end up at the map origin anymore, their rules in flight during the glitch have changed as now the map origin has something there to collide with.

Can you or a bot be teleported by this trigger? 

No... it only affects bots teleporting glitching, I did record one incident where a bot was close to the map origin and therefore possibly affected by it. However, the bot jumped away from it, teleported to the origin. No incidents where a non glitching bot have been seen so far.   

Is that ideal as a fix?

No, however this one small plugin requires just to be installed and it will work on any map, no maintenance like others needing teleports set for each map.

The teleporting bots not going under the map is a huge help, they also get a bot of damage from the fall and are in a terrible place to be noticed and shot by other bots.

Other observations. Bots after a death flashing around their death spot just before re-spawning.

You see this all the time on the minimap. A bot or bots die, the skull icon is displayed. Then you don't see then but just before the spawn the "flash" on for a split second at the place they died. RCBot2 has a weird behavior and its like when they join unconnected or unassigned they don't have a destination so they end up at the map origin.

You also see this at certain point in Valve bots like CS, in fact it was a base for a CS:GO glitch combined with a forwards and backwards special bind. See that video here about half way through a interview with a exploiter explains how his glitch was done

 

A further plugin that really helps.

A friend helped get the spawn points located properly and also the plugin now reports (in chat only) messages that a bot has teleported.

The plugin can be downloaded here, it does have a cvar to turn on and off the messages but they are short and on average about 5 per a map occur but up 10 or so on dod_avalanche is possible.

Improvements, changes, bugs

1. You hardly notice the plugin working, messages can be turned off via a CVAR
2. It works on every map just install it.
3. The updated plugin now returns bots to the spawn.
4. A message is delivered to chat if a bot glitches. (controlled by a cvar and can be turned off)
5. Bug 1: Rare but if a bot is prone when glitching, they may stick in a wall if the spawns are tight (dod_argentan) 
6. Bug 2: Rare but Maps like dod_avalanche with huge elevation changes, a (allied) bot may get stuck in world geometry when glitching, however they cannot shoot players from there.
7.  Bug 3: If a bot walks over the exact map origin in game a teleport back to spawn can occur, it is very rare for a bot to hit that point with their model origin but it can happen.

For those that are interested, this is what happened after the test 19 above...

The plugin above in test 19 showed you can at least interrupt the bots on their way to the map origin and they seem to collide with it, then the...

• Allied bots end up in one place above a bolder near the map origin
• Axis bots at the same height but diagonally (45-degrees) opposite and somewhat further distance near the broken wall of the church.

So I looked at some videos and pinpointed the view from the side and top. Then in hammer put in three columns.

I saw they do indeed intersect the map origin at a 45-degree angle, the axis are pushed off a different amount.

The columns - Side View	The columns - Top View

.What does that mean? Not much for the glitch, it's more to do with the plugin in test 19 success in picking up the bots at the map origin, not allowing access to it and then ... failing in its task to transport the bot back to a spawn point and also not delivering a message to chat or a log that a teleport had occurred.

It is interesting to see the game engine an what happens to different entities "colliding" with other entities in the map.

The plugin was adjusted and the result was a spawn point for either team identified, then the bot would spawn 150 units above that, that worked OK for most maps but on dod_agentan one bot spawned in the ceiling of the allied house and got stuck.

That was then adjusted so the spawn points found the bots destination is the same but moved forward 16 units.

In testing this was better, the plugin was delivering messages in chat like this... "[Bot Teleport] bRurnie has been relocated to spawn!"

The bots where going to their correct team spawn points and retests on maps with tight spawn points were looking good but its not perfect.

• One bot was teleported on dod_argentan... while prone. The bot got stuck in the wall!
• On dod_anzio one bot got stuck way down into the map structure, the plugin failed that second teleport back to spawn.

These incidents are rare and instead of going further the plugin should stop there... the intent was get rid of the "bots under the map" and the plugin does that close to 100% of the time...good enough.

I also noted the messages...

Ignoring unreasonable position (coordinates) from vphysics! (entity class C_PhysPropClientside)

...stopped when this plugin is active.

 

Test - 22 dod_avalanche captured bots 

This is a series of tests to capture the bots in a first person view some 10 seconds or so before they teleport.

This was achieved with the help of a plugin from Ben.nav in a SourceMod forum topic where Ben.nav posted the plugin.

The plugin gives the last location just before the bot teleports to the center, using this data I made a few SourceTV .dem files.

With that file I could playback and lock on to a bot in first person view and observe with the bots actions are just before the teleport.

In YouTube you can run a video frame by frame, so when viewing the video just before a clip plays...

1. As the clip starts Press Pause,

2. Then use the "." full stop key to look at the bots moments frame by frame.

   Note how the bots in most clips "lock on" to the map origin.

3. In some cases it's like the bot is already at the map origin but we are seeing this in about 0.5 seconds behind whats really going on in the server.

4. They seem to detach from the waypoints, get confused and go to the map origin... its all on dod_avalanche, map origin is the allied side of the center rubble mound.

5. You can also use the "," key to go back frame by frame.

Did I learn much from that? Not really but you can see in each incident the bot does seen to lock on the map origin.

Also, in some incidents, it looks like what we are seeing in the video made from a .dem file, the bot does some actions, like targeting another bot, and it looks like the bots actions are some 0.5 seconds ahead of what we are seeing in the video.

This one clip involving "SnaKe" is interesting, look at what the bot does just before he teleports to the map origin...

1. 0:46 sec. SnaKe is down from Axis first flag, moving around looking down at the ground
2. 0.47 sec. SnaKe looks to the right, locks on to something.
3. 0.48 sec SnaKe has teleported, his view has not changed and it is now clear the bot was not looking at the ground, he was targeting a allied bot... as if he was already standing at the map origin?

All that might mean is when viewing the videos (.dem file playback), be aware the bots animations could be in a delay of about 0.5 sec from the data on the server.

The next clip of interest is the "CowBoy" incident.

Note the confusion of the route and the "fixation" of the bot looking at the map origin?

Also the reload and ammo drop indicating the bot may be using multiple direction and other commands, reload, ammo drop, jump, crouch and direction keys maybe... all at the same time? 

1. 1:44. CowBoy turns back and looks at something. Stares at it and looks right.
2. 1:48. CowBoy looks at the map origin.
3. 1:51. CowBoy is reloading.
4. 1:51. CowBoy throws down a ammo box (at the map origin) while reloading still.
5. 1:52. Cowboy teleports (still reloading)

 

The big take away here is just before the glitch...

1. The bots look confused 
2. The bots seem to lock on to the map origin 
3. Are the bots "spamming" multiple direction keys and glitch in the same way as the CS glitch was done? 

 

Conclusion (so far updated June 5th 2025)

In my tests I only have these “common denominators” in every teleport incident…

1. A Linux dedicated server running the post 19th Feb 2025 update.
2. RCBot2 of any version past RCBot2 v1.7 – beta 6
3. The teleport destination is always X “0” and Y “0” (map origin) in some cases the bot is running and may look to "overshoot" the X and Y axis.
4. The teleport destination height Z axis… ALWAYS varies and ALWAYS matches the height of the place that the bot teleported FROM.
5. Just before they teleport, the bots get confused on the waypoints, look at the map origin for a second or so, then teleport.

 

Ruled assumptions out from my tests…

1. It’s only on dod_avalanche and dod_jagd. FALSE… those two are just more noticeable as bots can shoot you from under the map. It can happen on any map.
2. Its only allied bots. FALSE, due to the more noticeable teleports on dod_avalanche under the map, people only notice Allied players as the are shot. Most of the Allied teleports are under the map as most allied areas the bots came FROM are below the map origin and ground surface.
3. It’s when the bot is on a waypoint/flag type. FALSE, in fact most are between waypoints and it isn’t any special waypoint flag that is doing this.
4. It happens when bots are near certain models, collision with other players, grenades and bazookas. FALSE, incidents occur near or far away from models, making bots only use knives takes away guns and grenades… the bots still teleport.Other bots / weapons can run through and touch teleporting bot players or not, the teleport still occurs.
5. It happens when an event occurs (like players getting killed with a certain weapon type or flag cap, round win) FALSE, nothing came of recording events around a teleport incident, events are always a different combination.

 

More testing required…

1. Is this only in DoD:S? RussiaTails (Plays TF2) says no, reported in TF2.
2. VPhysics errors in maps that sometimes are related to teleports… unlikely related… but possible bots have a weapon that goes with them outside the map.
3. Use more debug tools in RCBot2. Perhaps some of these may show alterations in waypoints like the “rcbot_debug_show_route” command.
4. Can a plugin solve this? Well in test 19 I came close but really... a patch from RCBot2 would be great.
5. Test 22... what are the bots inputs in the second or so before the teleport? Are they "spamming commands" like pressing direction controls rapidly and glitching that way e.g.: the CS glitch using binds? 

 

That is where I got to in tests, this is after hours of testing, normally the only way you can see these incidents is to have a Linux dedicated server, join it and sit in spec and watch the map origin.

I hope that helped the coders rule in and out what happens around the teleport incidents.