Title bot corpses handles as obstacles / crash: add_obstacle - Ran out of obstacle when killing bots positions
Priority release-blocker Status resolved
Assigned To fluzz Keywords
Linked issues Watchers fluzz

Submitted on 2012-07-08 21h01 by lunruj, last changed by fluzz.

File name Uploaded Type Edit Remove
Tux.sav.gz lunruj, 2012-07-08.21:01:46 application/x-gzip
Tux.shp lunruj, 2012-07-09.17:18:11 application/octet-stream
Author: lunruj Date: 2012-07-08   21h01
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 !

Attached Tux.sav.gz.
Author: matthiaskrgr Date: 2012-07-09   07h59
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.
Author: lunruj Date: 2012-07-09   17h19
file added
Author: matthiaskrgr Date: 2012-08-03   13h56
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.
Author: matthiaskrgr Date: 2012-08-03   13h58
One solution might be to have bot corpses automatically removed after a few
minutes even if the player is on that level.
Author: MichaelSM Date: 2012-08-03   22h27
Is there a reason you couldn't just increase 'MAX_OBSTACLES_ON_MAP' ? I think 
that, if feasible, could be the least complex solution.
Author: matthiaskrgr Date: 2012-08-03   22h29
Well, best solution would be to get rid of this limit entirely I suppose :P
Author: jesusalva Date: 2014-08-12   01h58
> 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.
Author: Christoph Date: 2014-10-31   21h07
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.
Author: jesusalva Date: 2014-11-02   19h11
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 :) )
Author: Christoph Date: 2014-11-03   13h36
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?
Author: matthiaskrgr Date: 2014-11-03   21h09
Are you sure that the bots do respawn? I'll have to check this
Author: Christoph Date: 2014-11-03   22h49
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.
Author: jesusalva Date: 2014-11-05   23h53
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

 > 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?
Author: Christoph Date: 2014-11-10   23h26
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:
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.
Author: Christoph Date: 2014-11-11   01h46
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
Author: jesusalva Date: 2014-11-11   22h50
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...
Author: fluzz Date: 2015-04-06   10h43
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

Is that an acceptable solution ? What do you think ?
Author: matthiaskrgr Date: 2015-04-06   20h53
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.
Author: fluzz Date: 2015-04-18   18h20
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.
Author: fluzz Date: 2015-04-25   21h35
Pushed in commits 772cc97..4d3ca90b4
Date User Action Args
2023-01-04 16:45:56jesusalvalinkissue804 linked
2015-04-25 21:35:29fluzzsetstatus: open -> resolved
messages: + msg3132
2015-04-18 18:20:00fluzzsetmessages: + msg3126
2015-04-06 20:53:10matthiaskrgrsetmessages: + msg3103
2015-04-06 10:43:21fluzzsetmessages: + msg3099
2014-11-11 22:50:09jesusalvasetmessages: + msg2960
2014-11-11 01:46:18Christophsetmessages: + msg2958
2014-11-10 23:26:20Christophsetmessages: + msg2953
2014-11-05 23:53:58jesusalvasetmessages: + msg2950
2014-11-03 22:49:45Christophsetmessages: + msg2944
2014-11-03 21:09:58matthiaskrgrsetmessages: + msg2938
2014-11-03 13:36:26Christophsetmessages: + msg2927
2014-11-02 19:11:53jesusalvasetmessages: + msg2925
2014-10-31 21:07:11Christophsetmessages: + msg2914
2014-09-17 07:33:55fluzzsetassignedto: fluzz
nosy: + fluzz
2014-08-12 01:58:45jesusalvasetmessages: + msg2869
2014-08-01 10:23:35Xenuxsetpriority: important -> release-blocker
2012-08-03 22:29:22matthiaskrgrsetmessages: + msg2323
2012-08-03 22:27:58MichaelSMsetmessages: + msg2322
2012-08-03 13:58:16matthiaskrgrsetmessages: + msg2319
2012-08-03 13:57:24matthiaskrgrsettitle: crash: add_obstacle - Ran out of obstacle positions -> bot corpses handles as obstacles / crash: add_obstacle - Ran out of obstacle when killing bots positions
2012-08-03 13:56:11matthiaskrgrsetmessages: + msg2318
2012-07-09 17:19:58lunrujsetmessages: + msg2314
2012-07-09 17:18:11lunrujsetfiles: + Tux.shp
2012-07-09 07:59:47matthiaskrgrsetmessages: + msg2310
2012-07-08 21:01:46lunrujcreate