i still think this needs clarification, 'cause i still dont see how this exactly works.



assuming my bot is at the black position. if i move forward and then turn right, i end up at the red position. if i turn first and move forward later, i end up at the blue position...



[edited by - vogela on August 18, 2003 10:54:07 AM]

quote:

---

Original post by vogela
i still think this needs clarification, 'cause i still dont see how this exactly works.



assuming my bot is at the black position. if i move forward and then turn right, i end up at the blue position. if i turn first and move forward later, i end up at the blue position...

---

Assuming you turn and move in the same Update() cycle.. you end up at the blue position no matter what order you send the commands. If you do these things during different Update() cycles, then sure, order matters (i.e. Update() cycle 1 you move, Update() cycle 5 you turn, etc).

quote:

---

Original post by Khawk

quote:

---

Original post by vogela
i still think this needs clarification, 'cause i still dont see how this exactly works.



assuming my bot is at the black position. if i move forward and then turn right, i end up at the blue position. if i turn first and move forward later, i end up at the blue position...

---

Assuming you turn and move in the same Update() cycle.. you end up at the blue position no matter what order you send the commands. If you do these things during different Update() cycles, then sure, order matters (i.e. Update() cycle 1 you move, Update() cycle 5 you turn, etc).

---

Thanks for the info. What about strafing? Is strafing performed before or after forward/backward movement? (I assume that strafing is performed after turning.)

The order of move/strafe doesn't matter unless the bot collide with something, but if the bot does collide the order of move/strafe matters.

[edited by - dalleboy on August 18, 2003 11:38:29 AM]

quote:

---

Original post by Khawk

quote:

---

Original post by vogela
i still think this needs clarification, ''cause i still dont see how this exactly works.



assuming my bot is at the black position. if i move forward and then turn right, i end up at the blue position. if i turn first and move forward later, i end up at the blue position...

---

Assuming you turn and move in the same Update() cycle.. you end up at the blue position no matter what order you send the commands. If you do these things during different Update() cycles, then sure, order matters (i.e. Update() cycle 1 you move, Update() cycle 5 you turn, etc).

---

The point is, one HAS to happen before the other...

x += cosf(theta);

... but when is theta updated, before or after you add the value, that was the question. It HAS to be one or the other, it can''t be done at the same exact time, it either:

theta+=turn_angle;
x+= cosf(theta)*speed;

or it does this:
x+= cosf(theta)*speed;
theta+=turn_angle;

Both give DIFFERENT results, I was just wondering which way it happens in the code. The man with the diagram showed it pretty well... The first case (angle updated first) would result in the blue location, while the second case (angle updated after) would result in the red location. I was questioning which order it happens in the update function, not what happens between multiple updates.

quote:

---

Original post by Ready4Dis

quote:

---

Original post by Khawk
Assuming you turn and move in the same Update() cycle.. you end up at the blue position no matter what order you send the commands. If you do these things during different Update() cycles, then sure, order matters (i.e. Update() cycle 1 you move, Update() cycle 5 you turn, etc).

---

The point is, one HAS to happen before the other...

x += cosf(theta);

... but when is theta updated, before or after you add the value, that was the question. It HAS to be one or the other, it can''t be done at the same exact time, it either:

theta+=turn_angle;
x+= cosf(theta)*speed;

or it does this:
x+= cosf(theta)*speed;
theta+=turn_angle;

Both give DIFFERENT results, I was just wondering which way it happens in the code. The man with the diagram showed it pretty well... The first case (angle updated first) would result in the blue location, while the second case (angle updated after) would result in the red location. I was questioning which order it happens in the update function, not what happens between multiple updates.

---

Of course, the way you present it here, I could easily agree that it could work different ways, and I could give an answer. The way it was presented and asked originally, however, is rather vague.

Besides, if you do a turn, why in the hell would it not be calculated before the actual rotation?

We don''t know why it wouldn''t be, but we''d rather be sure before writing our code one way or another (prediction code could be effected by this along with many other things).

So to that point, how do stafing and firing fit in?

You''ve stated so far that it is

Turn
Move

Which makes sense... So I''m assuming strafing also follows turning (as this would also make sense), whether it goes before or after move doesn''t matter, so we can assume...

Turn
Move
Strafe

Hopefully firing happens either completely before or completely after all these steps. I''m going to go with AFTER based on the logic you have seemed to use in creating the arena.

But for satefy sake verification would be nice

quote:

---

Original post by Illumini
We don''t know why it wouldn''t be, but we''d rather be sure before writing our code one way or another (prediction code could be effected by this along with many other things).

So to that point, how do stafing and firing fit in?

You''ve stated so far that it is

Turn
Move

Which makes sense... So I''m assuming strafing also follows turning (as this would also make sense), whether it goes before or after move doesn''t matter, so we can assume...

Turn
Move
Strafe

Hopefully firing happens either completely before or completely after all these steps. I''m going to go with AFTER based on the logic you have seemed to use in creating the arena.

But for satefy sake verification would be nice

---

Strafing does follow turning. Firing is prior to all movement.

Ok, good, now it''s settled . thank you.

Hi,
I guess these comments more or less don''t apply to GDArena anymore since the readme states that you can send only one command each update cycle:

quote:

---

As you send commands to the GDArena, only the first time a command is sent will it be executed. This means that if you send a TurnLeft() command early on in your processing, and then later send a TurnRight() command, only the TurnLeft() command will be processed by the arena during that Update() cycle. These commands are processed for the current Update() cycle only, and do not persist once that cycle is over.

---

Am I right here?

quote:

---

Original post by Epidemi
Hi,
I guess these comments more or less don''t apply to GDArena anymore since the readme states that you can send only one command each update cycle:

quote:

---

As you send commands to the GDArena, only the first time a command is sent will it be executed. This means that if you send a TurnLeft() command early on in your processing, and then later send a TurnRight() command, only the TurnLeft() command will be processed by the arena during that Update() cycle. These commands are processed for the current Update() cycle only, and do not persist once that cycle is over.

---

Am I right here?

---

You can send more than one command per Update() cycle as long as the commands are not related. For instance, you can send a turn command, a speed command, and a fire command in one Update(), but you cannot send two turn commands, a speed command, and two fire commands - well, you can, but the result will be the same as the first case because the arena will ignore the second commands.