quote: Original post by Khawk

quote: Original post by Hedos

quote: Original post by Khawk
Ah ok... I''ll have to look more into this one, because it should be positive/negative. My tests always gave me correct values, so I''ll have to take more time to find this one...

Damn, I found that was strange...
So I made a special algorithm to detect if the bot was turning in the good direction for nothing :
It is the same thing for the ObjDirection...
It start from 0 to 180 and when it reach 180 it go down to 0...
For exemple, if an object is looking at 90 degrees, we don''t know if it is 90 degrees at the UP or DOWN direction...

Well in that case, I''ll leave it and say it''s another thing you have to figure out.

(not really, I''d rather have it +/-, but if I don''t have time... this might be worth having another challenge)

OK, I made up my mind. I''m loving the fact that you came up with an algorithm, because that is _exactly_ the point of this contest - think. Therefore, I''m not going to fix that defect.

Sorry everyone. As I said at the beginning, this contest is meant to be difficult and to make you think. If I can make it difficult, I will.

Are you kidding? The angles (0-180) are going to be left the way they are? In my opinion this is just plain ridiculous.

Other than this little gripe, I think the platform is perfect!

I really like how the limited information (EXCEPT for the angle situation) mimics the information that a human player of a fps might have at their disposal. Khawk, you have even justified leaving out information (i think you were referring to the absolute turning/movement rates) on these same grounds! But come on! I promise you that when I play Quake3, i can tell which side of my cursor (positive angle vs. negative angle) some object in the environment is!

So far, to deal with this situation i''ve just been using an ugly hack:

if i am trying to orient towards an object for example, my bot will arbitrarily pick i direction to start turning in. every update i check the currently queried angle and the angle from that object last update. if the current angle is larger than the old one (presumably because the bot started turning the wrong way) the bot switches directions. However if the angle is getting smaller, he keeps turning the way he was.

this is ugly. and it isn''t foolproof.

for example, if an enemy is running tangentially to your bot''s heading, your bot might start turning the right way to track it, but since the enemy is moving so fast relative to your heading, it might appear as if your bot is turning the wrong way (to the ugly algorithm i described above).

i am probably just going about this the wrong way (i am quite the newb, after all), but still...this limitation seems arbitrary and ridiculous to me.

what does everyone else think? am i going about this the wrong way? is this actually an easy problem??? i mean, my bot works *ok*, he just sometimes doesn''t home in on a target quite as fast as i''d like (oscillates back and forth for a bit, trying to make up his mind, sometimes when trying to track a moving object), and i think it would work fine if we had +/- angles!



A headache, ancillary; an hourglass auxiliary.

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

quote: Original post by Hedos

quote: Original post by smart_idiot
In MinGW the DLL, is being loaded, so the problem has nothing to do with name mangling.

The crash happens sometime after IPlayer::Init() returns from being called.

I have no idea what the problem is. I thought maybe the vtable was being handled differently between MinGW and MSVC, but if that was the case it never would have been able to invoke IPlayer::Init in the first place.

I wish it worked. I really want to try it.

Why don''t you get a trial version of MSVC ?

I shouldn''t have to.

quote: Original post by smart_idiot
In MinGW the DLL, is being loaded, so the problem has nothing to do with name mangling.

The crash happens sometime after IPlayer::Init() returns from being called.

I have no idea what the problem is. I thought maybe the vtable was being handled differently between MinGW and MSVC, but if that was the case it never would have been able to invoke IPlayer::Init in the first place.

I wish it worked. I really want to try it.

What is the crash that occurs? What is the error message? I have no idea where to start if I don''t know what it says. Sometimes it can be very useful..

quote:
If you want the contest to be accessible to everyone, make it accessible to people who don''t have MSVC 6.

Apparently it isn''t the lack of COM that is causing the problems with non-MSVC compilers. If it is reaching the Init(), then it''s made it past the part of the DLL that would be COM specific.

My suggestion is that if you want me to even consider helping those with non-MSVC, that you take a step back with the attitude. I''m willing to work through the problems, but not if it''s going to be a "you idiot, it would work if you had used COM" type of attitude. I have my reasons for not using COM, and whether those reasons are good enough for people or not is certainly not a concern of mine.

The contest will be accessible to everyone by the time it is official. These issues are the exact reasons we are having a beta phase - I don''t have the resources to do more "real world" testing, so with everyone finding these problems with other compilers, the angles issues, and the walls issues, we can get closer and closer to an official contest.

quote: Original post by drreagan

quote: Original post by Khawk

quote: Original post by Hedos

quote: Original post by Khawk
Ah ok... I''ll have to look more into this one, because it should be positive/negative. My tests always gave me correct values, so I''ll have to take more time to find this one...

Damn, I found that was strange...
So I made a special algorithm to detect if the bot was turning in the good direction for nothing :
It is the same thing for the ObjDirection...
It start from 0 to 180 and when it reach 180 it go down to 0...
For exemple, if an object is looking at 90 degrees, we don''t know if it is 90 degrees at the UP or DOWN direction...

Well in that case, I''ll leave it and say it''s another thing you have to figure out.

(not really, I''d rather have it +/-, but if I don''t have time... this might be worth having another challenge)

OK, I made up my mind. I''m loving the fact that you came up with an algorithm, because that is _exactly_ the point of this contest - think. Therefore, I''m not going to fix that defect.

Sorry everyone. As I said at the beginning, this contest is meant to be difficult and to make you think. If I can make it difficult, I will.

Are you kidding? The angles (0-180) are going to be left the way they are? In my opinion this is just plain ridiculous.

Other than this little gripe, I think the platform is perfect!

I really like how the limited information (EXCEPT for the angle situation) mimics the information that a human player of a fps might have at their disposal. Khawk, you have even justified leaving out information (i think you were referring to the absolute turning/movement rates) on these same grounds! But come on! I promise you that when I play Quake3, i can tell which side of my cursor (positive angle vs. negative angle) some object in the environment is!

So far, to deal with this situation i''ve just been using an ugly hack:

if i am trying to orient towards an object for example, my bot will arbitrarily pick i direction to start turning in. every update i check the currently queried angle and the angle from that object last update. if the current angle is larger than the old one (presumably because the bot started turning the wrong way) the bot switches directions. However if the angle is getting smaller, he keeps turning the way he was.

this is ugly. and it isn''t foolproof.

for example, if an enemy is running tangentially to your bot''s heading, your bot might start turning the right way to track it, but since the enemy is moving so fast relative to your heading, it might appear as if your bot is turning the wrong way (to the ugly algorithm i described above).

i am probably just going about this the wrong way (i am quite the newb, after all), but still...this limitation seems arbitrary and ridiculous to me.

what does everyone else think? am i going about this the wrong way? is this actually an easy problem??? i mean, my bot works *ok*, he just sometimes doesn''t home in on a target quite as fast as i''d like (oscillates back and forth for a bit, trying to make up his mind, sometimes when trying to track a moving object), and i think it would work fine if we had +/- angles!



A headache, ancillary; an hourglass auxiliary.

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

I''m actually working on the angles issue. The only thing I can figure is that data is getting mixed up somewhere. I remember testing when I implemented the objects in sight functionality, and I was getting perfect positive and negative angles relative to the bot''s direction. Since then I''ve added more functionality (at the request of users here), so it''s possible this new functionality is mixing up the object sight functionality. This is why it could take a while to find the problem..

I''m working on it though.. it''s not as if I _like_ having this problem. I''m just willing to accept it for now given that there are possible workarounds.