Talk:.edge

Example:

'this will turn a bot a random number of degrees upon hitting an edge.
314 rnd .aimdx *.edge mult store

This will turn the bot by a rnd amount between 0 an 90 degrees ... clockwise, yes?
and 314 rnd .aimsx *.edge mult store, 0-90 degress CCW?

If one wished to have the bot turn either CW or CCW ...
what would be the best way to do so?
will this work?:

628 rnd .aimdx *.edge mult store
-314 .aimdx store

resulting in the bot rotating 0-90 degress to the left or right?

or:

314 rnd .aimdx *.edge mult store
-314 rnd .aimdx *.edge mult store

or:

314 rnd .aimdx *.edge mult store
314 rnd .aimsx *.edge mult store

resulting in smaller values near 0 degrees being more probable,
ie ... the distribution being more closely centered around zero?
Assuming any of the above would work ...
Which of these would be more costly for the bot?

Also ... perhaps the above is moot, eh?
How much of this is taken care of by the new physics of 2.4.X?
where the velocity and momentum is used to simply 'bounce' the bot
off of the 'edges'?
IOW ... do the physics take care of the bot's heading as part of
the bot's velocity vector, including the direction it is facing ...
or just it's delta x and delta y?
ie ... is it any longer necessary to rotate the bot?
[haven't had time to actually experiment and gather empirical data yet. i will.]
tanks.
Griz^talk

---

If you're talking about rotating either left or right 90 random degrees upon sensing something, the best suggestion I could make would be to use something like:

' rotate either left or right 90 degrees upon hitting edge
314 rnd 5 *.edge mult 1 rnd add store

ok. i don't get what you are doing here ...

what are the 5 and 1 and extra rnd doing?

did you mean 0.5? or perhaps -0.5?

i don't see how you get a value in the range of -157 to _157 from this ...

which is what i am looking for.

i'm thinking how i would do it with other programming ...

ie ... x=int(rnd(seed)*315-157) to give me an integer result between -157 and +157.

if your above is doing that, i don't see it ...

as i haven't yet figured out how all these commands/programming work.

that's what i'm trying to learn, and why i am asking those who do know.

mow i can see how using only one store would use less energy ...

and that is what i am looking for ... the most efficient way to do this ...

but i don't see how your above results in a bot altering course by

the range of -45 to +45 degrees upon sensing an edge.

Not really sure why you'd want to though. The turning CW and then CCW would likely be inefficent, one rotation largely canceling out another.

i am not looking to have it turn CW and then CCW ...

but to have it randomly turn somewhere between 45 degrees CW and 45 degrees CCW.

letting a bot go where it needs to without imposing either a CW or CCW

rotation on it but allowing it to do either.

iow ... coming straight on to an edge ...

to allow the bot to rnd rotate either left or right ... -45 to +45 degrees ...

or whatever range ... not forcing it one direction or the other.

what i'm looking for is the most efficeint way to have the rnd change be

-45 to +45 degrees (-157 to +157) from the current heading. Griz^talk

You'll have to ask Nums about the vector addition, not my strong suit I'm afraid. --Endy^chat 20:55, 25 Dec 2005 (MST)

The edges are set up to be springy, so as a result correct vector collision math will work. Note that it's not directly programmed in that way, but is mroe a natural consequence of how the forces interact. --Numsgil 01:01, 26 Dec 2005 (MST)

yes. understood as far as delta x and delta y goes.

and i like how the physics in 2.4.X works ... very realistic esp with some

gravity as a little rebound energy seems to be lost with each bounce ...

so a bot will eventually come to gradually settle on the bottom.

but my question is, does your physics reflect the bot's heading ...

ie ... does it rotate it, or just bounce the bot?

iow ... will a bot facing and moving straight ahead at say, 30 degrees

before encountering an edge ...

still be facing 30 degrees, and attempting to move in that direction

after the bounce?

i would think so but thought i would come to the source. ;)

still haven't had time to experiment ... maybe in the next day or two.

can you steer me towards an existing bot that just moves straight ahead

that i can then experiment with?

most of them are already spinning and i would like to see the effects of

just this edge turn gene at work.

i just haven't had a lot of time to study bot DNA and how the commands

work yet ... but all the stuff being added here at the wiki is great ...

so i'm trying to incorporate it into a bot so i can see first hand

the results. starting very, very simply ... nothing flash yet ...

just a simple bot moving one direction and figuring out to enable it

to rotate ... when/where/how/why and all that. thanks. Griz^talk 10:23, 26 Dec 2005 (MST)

No, the bot's orientation isn't changed after a collision. There are unfortunately no rolling forces. A bot must turn itself away from a wall after a collision, the collision won't do it automatically. --Numsgil 22:24, 26 Dec 2005 (MST)

ok. figured so. thanks. Griz

L/R 45

The 1 rnd add switches it between rotating left or right upon hitting the edge. Basically 5 and 6 translate to left and right. I don't exactly remember which is which but I do recall the numbers. 157 rnd to the left would become 157 rnd to the right. I think this is what you're wanting, not sure, let me know. I think you could do a 314 rnd 157 sub .aimdx *.edge mult store also, no real difference.

yes. that makes sense to me ... the 5 and 6 thing didn't.

Mostly this dna is useful to bots that move continously even when eye5 is zero. This is kind of a good/bad trait since it will kill a bot that hits an edge, since it wouldn't realize it's never going to see anything trying to travel in that direction. For a good example load The One and turn off torroidal, there'll be a build up starting at the edges since the bot doesn't realize it needs to turn.--Endy^chat 14:42, 26 Dec 2005 (MST)

right. that's why i was asking Nums about the new 2.4 physics ...

if it does a rotation as well as reversing the x and/or y velocities.

ok. so will take a look at The One ... although thats one big gene isn't it?

i'd like to just have a simply bot doing nothing but moving in a straight line

so i can then use the various turning methods and see what does what.

that's how i learn ... keep it simple, make ONE change, see what happens.

here's part of a gene from one of bots that makes it move.

will this just have it move forward ... wherever it's aimed?

or is .up actually Up?

cond
  *.eye2 -1 != start
 -4 .dn store
  4 .up store
stop

and ... what's the purpose of the *.eye2 -1 != start?

is this needed to have it move?

then for the edge turn add:

cond
314 rnd 157 sub .aimdx *.edge mult store
stop

thanks for the help. Griz^talk 18:11, 26 Dec 2005 (MST)

Weird gene you have there. Looks mutated or something. Gene would be continously on storing 4 in up, since the cond is always true and the -4 .dn store has the same effect as storing 4 in up.--Endy^chat 22:59, 26 Dec 2005 (MST)

came from C_Circumgirans ... and is always moving forward 8, yes? ...

PY said it may have been done in this way as the .up and .dn didn't occur costs.

how about giving me an example ... one gene that has the bot move straight ahead ...

no other frills or bells or whistles ...

so i can have just that basic bot to begin to experiment with?

Griz^talk

Vel Gene

cond
*.vel 20 <
start
20 *.vel sub .up store
stop

This'll do the trick. Whenever current velocity is less than desired(20), current velocity is subtracted from desired velocity and bot is made to accelerate by that much.--Endy^chat 22:56, 27 Dec 2005 (MST)

great. thanks. Griz^talk