some minor help

[Nitus]

I'm working on a movement script that makes the bot accelerate when it's going too slow and let itself drift once it gets going too fast - when its drifting it rotates 360 degrees once in awhile to scan for targets.
 
My question is what are the values for movement, I.e., how fast is 1, how fast is 2, etc.

[PurpleYouko]

The movements that you apply to .up, .dn, .sx, .dx are accelerations only.

As with any acceleration, the resultant change in velocity is proportional to the energy you spend and the mass of the robot.
If your robot's mass is exactly 1 then 1 .up store will result in a forward velocity change of 1. if it is less than 1 then you get more velocity and so on.
The final factor is friction. The velocity of your bot will be reduced by a value proportional to the physics setting for friction.

[Numsgil]

Also remember that the 'movement factor' in your physics page will change how effective acceleration is.  At best you'll only get about 80% of the energy you spend into accelleration.

[Shen]

Another tip. If your going to be drifting and spinning at the same time you will need to use *.velscalar not *.vel because vel is calculated by the direction your bot is facing, so if you turn your vel will decrease.

[Nitus]

I'm not thinking as far as energy cosumption. I just want a common-sense benchmark. Is there a way for the bot to get it's absolute position, or at least some kind of orienting point?
 
But that's too complex for this bot. I think I just need to test a bot with various values until it appears to move as I would like it to. I mean as long as it is speeding up and slowing down properly the dx and sx should suffice.

[PurpleYouko]

Is there a way for the bot to get it's absolute position, or at least some kind of orienting point?

Yes.

The easiest way is to use *.xpos and *.ypos to give a robot its exact position. Actually I am not quite certain that this works on all sim sizes any more. It used to cause crashes when larger sizes were used because *.xpos would attempt to return a number too large for a "single" variable as used in the memory locations.

*.depth is a mirror of *.ypos and is designed to be used in pondmode.

I conjuction with this, you can use the operator "angle" to return the precise facing needed to reach a specific point on the screen from your present location.

[Nitus]

It would be a lot simpler if there was like a "north" or something for bots to refer to, imo.
 
As for *velscaler yeah, that's what I mean, although my plan has been to have some kind of counter whereby the bot enacts different behaviors based on its mean velocity. Like accelerate up - spin until slow - move towards target if seen - if nothing than + or - 45 degrees from initial heading then accelerate up again, etc.
 
Like the bot always scans for targets before moving after going too slow. That's the basis of the "movmenet" part of my bot [and bear with a programming newbie], entirely seperate from the targeting or chasing part.
 
Since I want this bot to go through my evo sim, I'm also worried about seperating the "daemons" coz I don't want critical bits to be lost.
 
BTW, my previous evo'd sim uses its own weird memory locations that I can't quite figure out how they work, so don't expect my bot to be anything special.