quote: Original post by liquidAir
I think there''s a problem with the field of view. The bot doesn''t tend to see objects which are directly in front of it, but the objects need to be detected from either of the edges of the FOV before it sees it, and if another object is detected at the FOV-edge, it stops seeing the former object. Well, my bot''s obstacle avoidance is just horrible due to this, and ends up getting stuck in a corner or a cluster of objects most of the time. Anyone else having this problem?

[edited by - liquidAir on August 10, 2003 3:39:19 PM]

Here''s the reason it was implemented the way it is (with perpendiculars) - GetObjectsInSight() returns the direction and distance to an object. Well, a wall is a long object with no center. Distance can be any value of distance from your left FOV to your right FOV. Direction can be any angle in that range as well. So what do you pick? You can''t do center of your FOV, because then you are stuck in an even worse situation than you currently have as you can''t see a wall unless it''s forwardly visible.

The only other option I came up with, while also sticking to the same object data retrieval method (GetObjectsInSight) for consistency, was to reference a vector from the bot that intersects the wall perpendicularly. While not fool-proof, it is fair and does provide a reasonable way for you to detect a wall.

The other option, and one that the interface will probably evolve into, is to create another function that is strictly for wall detection. This is more reasonable, IMO, because walls have different attributes and properties than your run-of-the-mill object.

BTW, let''s keep this thread to reporting of defects for v0.2. I appreciate the discussion of ideas and everything, but it gets difficult to filter out the defects that I need to track. Thanks,

Kevin

ok let the thread only be for bugs, here are 3of them (but i dont know if they are real bugs...)

-first bot can get a "bot took to long" in debug mode
-grenades sometimes dissapear from GetObjectsInSight for one or more update calls (should be still visible)
-grenades accelerate !? (there is no wind or gravity field in grenade fly direction?)


T2k

-Bots sometimes get stuck in a rock
-GD Box is sometimes outside of the arena
-Bots don''t see something that they are touching although it is in front of them.

I think that everything that is closer than objradius+1 to the bot should be detected by the bot. Even from behind because the bot is sort of touching it.
Small rocks and big rocks should be different objects.

"C lets you shoot yourself in the foot rather easily. C++ allows you to reuse the bullet!"

quote: Original post by ShlomiSteinberg
-Bots sometimes get stuck in a rock
-GD Box is sometimes outside of the arena
-Bots don''t see something that they are touching although it is in front of them.

I think that everything that is closer than objradius+1 to the bot should be detected by the bot. Even from behind because the bot is sort of touching it.
Small rocks and big rocks should be different objects.

"C lets you shoot yourself in the foot rather easily. C++ allows you to reuse the bullet!"

good idea! i second this.
i think khawk mentioned that he was thinking of including a small circle around the bot in the object visibility check, so this would also accomplish the same sort of thing.


A headache, ancillary; an hourglass auxiliary.

"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)

Small and big rocks should definitely be different objects. They present different tactics.


I like pie.

One decent solution for the walls is to always report them every frame, whether they''re in your FOV or not. That would also help the annoying problem of "did I move last frame? Was I caught on something I can''t see?" If you can key your position off the walls, all would be well.

The wall issue would be helped by having a 90 degree FOV, rather than 80. Then the corners would always report at leat one wall. But my first action is to scan around first anyway, so I don''t really mind the walls as they are now.




I like pie.

quote: Original post by RenderTarget
One decent solution for the walls is to always report them every frame, whether they''re in your FOV or not. That would also help the annoying problem of "did I move last frame? Was I caught on something I can''t see?" If you can key your position off the walls, all would be well.

The wall issue would be helped by having a 90 degree FOV, rather than 80. Then the corners would always report at leat one wall. But my first action is to scan around first anyway, so I don''t really mind the walls as they are now.

If they are reported every frame, then there might as well be a GetMyPosition() function - that''s not going to happen. I will consider the 90 degree FOV..

This is my own checklist..I'm trying to get these fixed/implemented before I go on vacation tomorrow..

quote:
1. first bot can get a "bot took to long" in debug mode
2. grenades sometimes dissapear from GetObjectsInSight for one or more update calls (should be still visible)
3. grenades accelerate !? (there is no wind or gravity field in grenade fly direction?)
4. Bots sometimes get stuck in a rock
5. GD Box is sometimes outside of the arena
6. Bots don't see something that they are touching although it is in front of them.
7. Big/small rocks
8. Visibility radius around bot
9. 90 degree FOV for walls
10. Make objects with radii within FOV visible instead of relying on center of object for visibility
11. Bot health == 0, but continues execution
12. Bot Update() still called after end of match

1. Could not reproduce, but found another defect while searching for it that might be related.
2. Could not reproduce, but found another defect while searching for it that might be related.
3. Fixed for v0.03.
4. Fixed for v0.03.
5. Fixed for v0.03.
6. Fixed for v0.03.
7. Done for v0.03.
8. Done for v0.03.
9. Done for v0.03.
10. On hold. To be fixed in v0.04.
11. Fixed for v0.03.
12. Fixed for v0.03.

Now you''ve changed the calling convention to _cdelc (or whatever it is) The BotGen generates broken code - we have to add the _cdelc specifier to the virtual methods update(), init() and so on in the bot class header file. It only takes a few seconds to fix but I fear qute a few people would have no experience of this (like me who just realised the base class didn''t match the derived one).