Game.map.describeExits does not work near respawn area edge
-
Running (at shard #2):
JSON.stringify(Game.map.describeExits('W14S53'))
returns:
{"1":"W14S52","3":"W13S53","5":"W14S54","7":"W15S53"}
, which indicates that there should be open exits at every 4 sides of the room. But the room doesn't have 'open' exits at the left side. This makes my creeps hard time finding paths near this room.
The room looks like this:
What should I do, or more exact, how should I modify
Game.map.findRoute
function routeCallback to fix this situation? Or is it possible to fix this at server side?
-
I resolved this temporary by avoiding rooms, which my scouts haven't explored. (I made the room callback return
Infinity
if so). But I would really appreciate if this could be fixed at the server side
-
This is not a bug. The exit still exists, it's just temporarily closed.
-
@o4kapuk Ok, I thought so. But could it be possible to add
excludeTempClosedExits
option toGame.map.describeExits
andGame.map.findRoute
functions and other ones which needs to know the real status of exit tiles?
-
@hattu I don't see an easy way to do that, these functions are terrain-based while these walls are room objects.
-
@o4kapuk Ok, thanks anyways
The avoid strategy with my scout data seems to work pretty well. My scouts test if they have path to the exit tiles, if they don't (in this case) then they will not try to enter that room. And all rooms where these scouts haven't been in, are being avoided in path finding...
-
@o4kapuk said in Game.map.describeExits does not work near respawn area edge:
@hattu I don't see an easy way to do that, these functions are terrain-based while these walls are room objects.
Another reason to finally make use of the lava constant so that those are not walls anymore...
With the lava terrain it should be easier to fix that if a fix is in need at all for it...
-
Would it be possible to expose some additional room APIs to handle this? For example, checking whether an arbitrary room is a novice/respawn area, and whether it has a room controller. If you're in a novice area, you can travel to any room with a controller if (and only if) it is part of the same novice area, and any room without a controller if (and only if) it is adjacent, possibly diagonally, to the same novice area.
-
@hattu the temporary walls look different to real walls - IIRC the maxHits value is undefined.
So if you have vision on the room you could do a test where you search for a constructed wall at some random position within an exit, and if you find a wall there with undefined maxHits (in fact the only constructed wall that can exist on an edge tile is a respawn area wall), then you mark the exit closed.
Maybe not ideal. But it's the best we've got at the moment!
-
@wtfrank Thx, but the room (callback parameter) is never visible to me. The room will be the room which is behind that wall. If I don't have database of accessible rooms (my scout data), then I would need to have one adjacent rooms visible and process the exit/wall information. It wouldn't be so simple and efficient.
Btw, it's
wall.hits
which is undefined in those tmp walls. And in my case I'm not reading the wall data, I'm just testing if a path is found on top of the exit tiles (a wall will block the path).Thanks anyways for helping me out
-
@jbyoshi this is not about how to represent these data, it's about how to collect and pre-process them without risk of significant performance degrade.