the game crashes every time i try to kill bot

FreedroidRPG 0.15rc2 encountered a problem in function:  add_obstacle 
	    Ran out of obstacle positions (4000) in level 59 !

Hi, thanks for the report!

Can you please also attache the matching .shp file? :)
This is the map of the savegame and without this one I won't be able to
reproduce your problem.

file added

Ok, I was able to reproduce the problem.

This should really has to get fixed.

It seems like bot corpses are simply obstacles without collision rectangles and
since there are already a lot of obstacles on this map, we are likely to reach
the limit.

One solution might be to have bot corpses automatically removed after a few
minutes even if the player is on that level.

Is there a reason you couldn't just increase 'MAX_OBSTACLES_ON_MAP' ? I think 
that, if feasible, could be the least complex solution.

Well, best solution would be to get rid of this limit entirely I suppose :P

> Well, best solution would be to get rid of this limit entirely I suppose :P
No, the limit is important. Removing it, we could risk SIGSEGVs, extreme lag,
and other problems. However making the error non-fatal seems much better imo.

Now, aren't there the 'volatile' obstacle? When level is respawned, these
obstacles are deleted. Why don't - if we detect the error - we force a volatile
deletion first and after that see if we really need to show the warning?

The best solution, obviously, would make dead bots run a timer and when the
timer finishes (after, like, 30 seconds), delete the dead bot obstacle and
respawn that one bot.

Still happens here with cirrent gti version. However, it is NOT A GOOD IDEA to
respawn dead bots while the player is still on the map! The map 59 has red
trigger platforms; when the player steps onto one of them, a few robots appear
on other such platforms nearby. Stepping on enough platforms while getting rid
of the enemies triggers eventually this bug. The game would obviously become
unwinnable if those would respawn after a given time. Success would depend on
not stepping onto too many platforms.

Cristoph: You're right. I've thought a bit more and I think that we should
respawn the level every 600 seconds, and if the player is on a level that is
beign respawned print on console: 'MS starships dock on your level and replaces
all dead bots!'

Respawn count per level, naturally, depends when the player visited that level.

Now, back to original subject.
If you want to pass the 59 triggers, getting invisible will be enough, unless if
you spawn a 999 bot, on this case things get's black. (As will be explained
later on, hopefully :) )

Why not let the corpses "rot away" after 2 or 3 minutes? Agreed regarding
invisibility, but you must already have a high level character for this
approach. Now youv'e also a problem if you leave the level for a while (teleport
home to upgrade stuff for example), and return finding all bots having
respawned. Could it happen, by the way, that the number of obstacles can be
exceeded also by living bots, or do only dead objects count?

Are you sure that the bots do respawn? I'll have to check this

Definitely, load any of my currently submitted saved games with Tux in town:
teleportation destination should be level 59. Let Tux wait in town, teleport
back, and all bots previously "teleported in" by stepping on triggers will have
respawned, their corpses will be removed as expected. This seems to be a way to
create an unlimited number of enemies, or are there limitations in place? I've
seen that common bots retain their names given after hacking when respawning, so
those seem to be "individuals". Are the randomly created bots also taken from a
pre-created limited set, or truly random? If the number of robots there can only
increase, this will likely lead to problems.

I had an idea. What if, instead of saying that we couldn't add a new obstacle
and quitting, we just refuse to add the obstacle and print it on console? We
should, however, see if the new obstacle is named. Named obstacles could cause
problems...

 > Are the randomly created bots also taken from a pre-created limited set, or
truly random? If the number of robots there can only increase, this will likely
lead to problems.

Hmm... New bots always follows patterns, hacked bots that were respawned don't.
By example, the only way to have a hostile 999 droid on Temple Wood is hacking
one and leaving it forgotten there. By default, only 123 and 139 will appear,
besides two 302.

Now, I'm not sure if hacked bots reviving are taken in consideration when
reviving. I remember some errors about running out of waypoints because it tried
to respawn *all* hacked bots, which came from other levels.

The problem is: The original idea was to prevent too many bots. Did it really
prevented this problem?

Well, on some levels this message is printed on my console, probably indicating
that too many dead/hacked bots to be respawned are present:
---------------------------------------------------------------------------------
FreedroidRPG 0.15-1281-gec9895a_mod encountered a problem in function:
teleport_to_random_waypoint
There was no free waypoint found on level 53 to place another random bot.

The problem mentioned above is not fatal, we continue the execution.
---------------------------------------------------------------------------------

This did not happen on level 59, however, probably because you cannot easily
place too many robots there. You could possibly leave them hacked and alive,
causing a respawn as hostiles while Tux is absent. When killing them, the "too
many obstacles" problem occurs first. Perhaps I should invisibly run around,
triggering more teleportations, and see what happens.

Living robots obviously don't count as obstacles.

When you level up, you can make your way even through an already overcrowded
level, but if you don't actively avoid it, you can hit this obstacle problem.

This should simply be made non-fatal, I think. The message printed indicates
that it is already intended as non-fatal, but in fact it is not, and leads
unevitably to a crash.

Confirmed assumption about having too many living robots: ran around invisibly
without a weapon equipped, triggering the creation of many robots, teleported to
the town, waited until respawn => 5 messages: "There was no free waypoint found
on level 53 to place another random bot." So there is no way to "overcrowd" a
level so heavily that winning the game would become impossible, if the "obstacle
issue" is also solved: the game should not crash when that happens. Then you can
always level up / buy books/enhancements, and clear the level slowly out as a
last resort if you have made the mistake to trigger the creation of too many
opponents.

Well, the bot placing function always takes in consideration waypoint numbers.
This is in map.c and/or enemy.c, if I'm not mistaken.

The problem with living bots is simple: Bot stains (or blood) *are* obstacles,
as well their dead bodies.

I'm still not sure why the limit, probably to avoid too much lag. Maybe showing
a warning on the ingame (or not) console or something...

I would not like to have to create a list of bloods so that they are not part of
the obstacles list.

So, here is a proposition: 'attach' blood to died bots.
That is: when a died bot is rendered, also render blood (roughly).

There is however a consequence: when a level is re-spawned, blood marks will
disappear.

Is that an acceptable solution ? What do you think ?

Sound fine to me.
We also don't want to have a literal flood of blood on a levelground, after some
time, because the bot/human-models despawn, but the blood is kept.

Attaching blood to bots is not a solution.
A bot can spread blood when it is hit but not yet dead.
If blood is attached to the bot, the blood print moves with the bot !

RR2187 introduces vanishing volatile obstacles to solve this reported bug.

Pushed in commits 772cc97..4d3ca90b4