Darwinbots Forum
Code center => Suggestions => Topic started by: Botsareus on November 19, 2005, 04:38:19 PM
-
It's really unhealthy to make such a fuzz over a computer program. Sure, it'd be nice to see great results real fast, and real good. But this is no multi-million project, it is a program made by Volunteers, you know, people who do this for a hobby, for free.
So please stop mashing about, and start helping and giving constructive criticism...
Taking that into account; and what shvartz sayed about insolting people and then comming back. Sorry shvartz, I am too oppsest with this I cant help it.
Good news:
This forum's search engene finaly works! Thank you for your Input PY. IT FINALY WORKS YEAAA!!!
Bad news:
I still fail to understand why numsgil does not like the 'idea of circuler placment' (personaly I think it has nothing to do with my control, because the way I code is not much different from the way he codes... I did see that he insists upon using 'objects' for the control so I will leave it alone because I have a feeling there is a constructive reason behind it 'XD')
I am ready to provide a lot of constructive arguments to why we should have circuler placment. (atleast I cross my fingers XD)
I still fail to trust the new virsions saving all the .set and .sim files properly. Therefor, I would really like to try this method: "put it on low mutation rates and wait a very long time" but I simply cannot because A. or B. will happen id.e. the program will crash or I get fed up listining to my computer screach trough the night. Therefor, I need to save simulation, turn my computer off or Debug it in visual basic , load simulation. I really hope the 'autosave' is still part of the program.
Thank you for your coapiration.
-
Ok here is another XD far out XD idea:
Make seporate placment for each veg species stating position and repopulation possition.
/ :help: What can you do with a guy trying to make a tronsition to a grid less dromatic? I know: the "egrid idea is pedentic, therefor its unaddable"
/now with the 3D...
First of before we go totaly 3D crazy, we should learn to model 'turadial' accuratly.
I propose 'far out' oval and round arena to go nicly with my OPTIONAL circuler placment control /far out... No longer robots taking advantage of corners, a robot going out of bounds on one side does a direct 180 degree flip. XD never mind, If the above won't penatrade any firewalls of mind, this will never do it eather. But:
Thank you for your coapitation.
(http://img374.imageshack.us/img374/4493/no7sc.th.png) (http://img374.imageshack.us/my.php?image=no7sc.png)
-
I have no issues whatsoever with circular fields and/or robot placement. But it's really a brand new idea that needs to be suggested before it's implemented, not because some might not like it, but because some might have ways to make it better than any one single person could alone.
That is, new features should always always always be discussed first. I'm probably not the best at this myself, but the ideal still holds.
So: let's discuss circular and ovular robot placement and fields.
I have no conceptual issues with it.
As far as implementation, I'd need the following:
1. A way to find the coordinates to respawn a bot if it goes too far in one direction in a circular torroidal field. (As a side note, I believe a rectangular field and a circular field that are torroidal are isomorphic).
2. A way to find the distance of a bot to the nearest in bounds point, as well as what that point is.
3. A cool, frosty Cream Soda. XD
-
Oh, 2.4.A should have save files work 100%. The only thing save files don't save is shots. No reason why they don't, they just never have.
-
1. A way to find the coordinates to respawn a bot if it goes too far in one direction in a circular torroidal field. (As a side note, I believe a rectangular field and a circular field that are torroidal are isomorphic).
Simple, you need to measure the distance from the center of the feild to the robot, apply the esentrisity to that calculation and see if it is out of bounds.
I am sure you have to you sin or cos or tan to find the esentrisity so you will need to find the angle from the center to the robot as well.
Don't make me post code it can get ugly...
-
I can make my own code for it, It'd just be nice if you do the actual research for me.
Just post an equation.
You know, not code. Math.
I'm a math major, I read and think in math, not code. Don't post code. Post an equation. I'm being really really clear on this point because if you post code I won't be able to use it. I don't read code, I read equations. Am I being clear enough? Forgive me if this seems overboard, I'm just trying to be sure there's no misunderstanding.
-
To post gunior high level math I first how to write code to make sure it works, (thats how I do research XD)
meanwhile:
2. A way to find the distance of a bot to the nearest in bounds point, as well as what that point is.
What do you mean?
-
For the second point: in non torroidal modes, bots are pushed towards the nearest in bounds point.
For instance:
|
|
|
|_________
A
Pretend the A above is a point. The nearest in bounds point is that corner of the box. In an ovoid field, I'll need a way to find the nearest in bounds point as well.
You know, instead of reinventing the wheel you could just do some research on wikipedia into ellipses and their equations.
-
1. too far in one direction = ((feildwith/2 - X) ^ 2 + ((feildHeight / 2 - Y) / feildHeight * feildWidth) ^ 2) ^ 0.5 > feildwith/2
might need simplification!? hope not...
and since 2. is practicaly the same problem based on the 'info...' problem solved.
-
1. too far in one direction = ((feildwith/2 - X) ^ 2 + ((feildHeight / 2 - Y) / feildHeight * feildWidth) ^ 2) ^ 0.5 > feildwith/2
might need simplification!? hope not...
Could use some explanation.
Remember what I asked for. I need a way to determine if a point is out of bounds, and if it is, where to respawn it.
((feildwith/2 - X) ^ 2 + ((feildHeight / 2 - Y) / feildHeight * feildWidth) ^ 2) ^ 0.5 > feildwith/2
seems to be an inequality, and therefore may tell me if a point is out of bounds (haven't checked it yet) but can't tell me where to respawn it.
-
can't tell me where to respawn it
Think of it:
RespownX = feildwith /2 - X
RespownY = feildheight /2 - Y
-
I don't think that's right.
That looks somewhat similar to the respawn for a rectangular field. Somewhat, because if you use just that you're going to get negative values for Respawn X and Y half the time.
Here's what I need:- RespawnX = some function of the max length x ways of the ellipse and bot x position
- RespawnY = some function of the max length y ways of the ellipse and bot y position
- Domain for Bot's X and Y. That is, what are valid values for X and what are valid values for Y? In current rectangle, this looks like: x in [0, field width] y in [0, fieldheight].
-
I don't think that's right.
That looks somewhat similar to the respawn for a rectangular field. Somewhat, because if you use just that you're going to get negative values for Respawn X and Y half the time.
thought you were talking of the center of the field ...
be it retangular or circular ...
being (0,0).
doesn't it then work?
-
Maybe for rectangular, but circular should depend on X amd Y for X and Y.
That is, Respawn X = some function of current X and Y.
That's simple enough to see. Where you respawn on the other side of a circle depends not only on your X position but also your Y position.
-
Maybe for rectangular, but circular should depend on X amd Y for X and Y.
That is, Respawn X = some function of current X and Y.
That's simple enough to see. Where you respawn on the other side of a circle depends not only on your X position but also your Y position.
ok, I see what you are saying ...
in this case you have to tweak both x and y rather than one or the other.
but need it be complicated?
as soon as a bot reaches the 'border' or strays across it by some tiny amount
[the smaller interval the better] ...
ie ... (x^2)+y^2)>radius^2 by some small amount ...
do you not know it's exact position and can you not calculate the angle from the
center of the field at which this occurs?
having the angle, can you not add 180 degress, or whatever radians is used ...
and recalculate x and y ... ensuring the signs are correct for the new quadrant ...
their unchanged delta.v placing them inside the field again on the next cycle?
or something like that?
-
as soon as a bot reaches the 'border' or strays across it by some tiny amount
[the smaller interval the better] ...
ie ... (x^2)+(y^2)>radius^2 by some small amount ...
do you not know it's exact position and can you not calculate the angle from the
center of the field at which this occurs?
in fact ... no need to calculate the angle is there?
if the interval is small enough, (guess it would be the bots' velocity)
then why not simply swap x and y polarity ...
thereby placing the bot in the opposite quadrant ...
and allow the next velocity displacement to carry it back inside the field?
this make any sense?
is it too simple? ;)
-
NUM SAYED (MY TRANSLATION): YOU NEED TO CHANGE BOTH X AND Y. THEREFOR I SAY DO BOTH OF THE FOLLOWING EACH TIME OR DIE TRYING:
err... ok I goofed
RespownX = feildwith /2 + (feildwith /2 - X)
RespownY = feildheight /2 + (feildheight /2 - Y)
simplfy:
RespownX = feildwith - X
RespownY = feildheight - Y
I NEVER SAYED THIS CODE (EHM 'MATH') WAS CONSISTING OF TWO SEPORATE PARTS.
-
That is, Respawn X = some function of current X and Y.
Totaly wrong: see picky:
(http://img481.imageshack.us/img481/6765/picky3vr.th.gif) (http://img481.imageshack.us/my.php?image=picky3vr.gif)
-
as soon as a bot reaches the 'border' or strays across it by some tiny amount
[the smaller interval the better] ...
ie ... (x^2)+y^2)>radius^2 by some small amount ...
do you not know it's exact position and can you not calculate the angle from the
center of the field at which this occurs?
in fact ... no need to calculate the angle is there?
if the interval is small enough, (guess it would be the bots' velocity)
then why not simply swap x and y polarity ...
thereby placing the bot in the opposite quadrant ...
and allow the next velocity displacement to carry it back inside the field?
this make any sense?
is it too simple? ;)
That sounds right actually, assuming you're centered at 0,0 (and you're circular instead of elliptical, I think).
-
Bots, I don't think your math is right for the simple reason that:
suppose width and height = 200 (that is, a circle with radius 100)
Assume a point at 45 degrees on the cusp of out of bounds. It's coordinates are: (sqr(2)/2*100, sqr(2)/2*100) = (70.7, 70.7)
By your equation, this then becomes:
X = 200-70.7 = 129.3
Y = 200-70.7 = 129.3
When it's easy enough to see that it should instead be:
180 + 45 = 225
(cos(225)*100, sin(225) * 100) = (-70.7, -70.7)
Griz's proposed idea of simple flipping the sign works in this case.
-
Provided your coordinate system is set with 0,0 at the centre of the circle/elipse then simply switching the polarity of both X and Y is all you will ever need.
Sounds simple enough
-
Provided your coordinate system is set with 0,0 at the centre of the circle/elipse then simply switching the polarity of both X and Y is all you will ever need.
Sounds simple enough
yes ... with center at 0,0
thing is ...
we don't want the bot to stumble ... ie ... miss a step/cycle.
so if ...
wherever in the routine it is determined that a bot is going to be 'out of bounds'
in it's next position ...
BEFORE adding the deltaX and deltaY to it's position ...
swap the polarity the x, y posistion ...
THEN ... add the delta velocities ... and repopulate.
this should put them back within the field ... in the new quadrant ...
without having missed a step.
yes?
no?
-
as soon as a bot reaches the 'border' or strays across it by some tiny amount
[the smaller interval the better] ...
ie ... (x^2)+y^2)>radius^2 by some small amount ...
do you not know it's exact position and can you not calculate the angle from the
center of the field at which this occurs?
in fact ... no need to calculate the angle is there?
if the interval is small enough, (guess it would be the bots' velocity)
then why not simply swap x and y polarity ...
thereby placing the bot in the opposite quadrant ...
and allow the next velocity displacement to carry it back inside the field?
this make any sense?
is it too simple? ;)
That sounds right actually, assuming you're centered at 0,0 (and you're circular instead of elliptical, I think).
I don't see why would it differ.
a circle is an ellipse ...
only one that happens to have zero eccentricity.
-
Provided your coordinate system is set with 0,0 at the centre of the circle/elipse then simply switching the polarity of both X and Y is all you will ever need.
Sounds simple enough
yes ... with center at 0,0
thing is ...
we don't want the bot to stumble ... ie ... miss a step/cycle.
so if ...
wherever in the routine it is determined that a bot is going to be 'out of bounds'
in it's next position ...
BEFORE adding the deltaX and deltaY to it's position ...
swap the polarity the x, y posistion ...
THEN ... add the delta velocities ... and repopulate.
this should put them back within the field ... in the new quadrant ...
without having missed a step.
yes?
no?
a modification of the above:
this all depends upon the relative magnitude of bot velocity vs field width.
if the bot's delta v is small compared to the field width ...
it isn't going to ever be way 'out of bounds'.
so it really doesn't make much difference if we fudge a bit on exactly where we repopulate or if it 'misses a step'.
how-some-ever ...
if we have some bot screaming thru our enviro ...
then we will need to accurately calculate how far their delta x and y would have
taken them out of bounds ... and accruately calculate how far 'in bounds' we should
then repopulate them on the next cycle.
this can of course be done for every bot that transgresses ...
but it will take computing time.
so it all depends on how willing we are to trade off accuracy for speed ...
or if it is even neccessary to do so.
everything contains some sort of compromise, does it not? ;)
taking a look at priorities is always the first step ...
in establishing/embarking upon ... any plan of attack.
or so it seems to me.
-
as soon as a bot reaches the 'border' or strays across it by some tiny amount
[the smaller interval the better] ...
ie ... (x^2)+y^2)>radius^2 by some small amount ...
do you not know it's exact position and can you not calculate the angle from the
center of the field at which this occurs?
in fact ... no need to calculate the angle is there?
if the interval is small enough, (guess it would be the bots' velocity)
then why not simply swap x and y polarity ...
thereby placing the bot in the opposite quadrant ...
and allow the next velocity displacement to carry it back inside the field?
this make any sense?
is it too simple? ;)
That sounds right actually, assuming you're centered at 0,0 (and you're circular instead of elliptical, I think).
I don't see why would it differ.
a circle is an ellipse ...
only one that happens to have zero eccentricity.
I menat only that I agree with it for the case of a circle. An ellipse is less self-obvious to me. Now that I think about it a little more, I think certain ellipses would work this way and some wouldn't... I'm not entirely sure. Geometry isn't my strong suit.
-
There is no difference whatsoever between a circle and an elipse as far as these calculations go.
Like giz said, a circle is simply an elipse with zero ecentricity. Just like a square is a rectangle with 4 equal sides
-
I menat only that I agree with it for the case of a circle. An ellipse is less self-obvious to me. Now that I think about it a little more, I think certain ellipses would work this way and some wouldn't...
???
in what way?
an ellipse is a pretty simple/basic representation of a specific 2D spatial relationship.
what 'transformation' could you apply to one that you could not apply to another?
if you come up with it ...
please share, as it will be news to me ...
and I'm always interested in amending/adding to ...
what I think I already know.
-
Again, geometry isn't my strong suit.
-
Just think of a circle as plotting
X(centre) + X radius * sin(angle) against Y(centre) + Y radius * cos(angle)
All you have to do is apply a different radius in the X and Y directions to get an elipse
You could even use a circular (eliptical) coordinate system if you like. Might be a bit complex though.
-
is there really a need to go elliptical?
I understand we want to utilize as much of the screen as possible but ...
how about ...
using as large a circular field as will fit the vertical dimensions of the screen ...
and using the remainder, be it on the left, right or both ...
for the various buttons/sliders for the controls one might want to access.
also ... one could call up something like a graph or robot info ...
and not have them be on top of the field blocking the 'action'.
just a thought ....
as it's seems coding bot placement/movement/repopulating ...
will be less complicated using a simple circle than trying to compensate
for an elliptical field ... ie ... calculating out of bounds/repop, etc.
if you can visulize it ...
using an elliptical field vs a circular one ...
really doesn't utilize that much more of the retangular screen ...
so it becomes a matter of priorities again ...
is the small sacrifice in area worth the less complicated coding ...
or not?
just tossing our ideas for consideration before Nums/PY/whoever
wades into the code. ;)
-
fyi ...
using a screen with a 4/3 aspect ratio ...
an ellipse will give you a 'field size' that at best can utilize about 78% of it ...
a circle about ~ 59%
weigh that against the computing/coding complexity of bot movement
in an elliptical vs circular field and see how that plays out.
-
just a quick visualization of the screen as ellipse/circle ...
I used a 3D sphere, ellipsoid just 'cause I'm already set
up for that so it's actually easier to do.
even with the elliptical field, there is some 'wasted space'.
but whos to say we couldn't use that for the buttons/sliders/controls/graphs, etc?
in the circular one, we can use all the space on the left, or put it on the right ...
for these ... perhaps some useful 'real time' stats.
don't mind me ...
it's 35F and raining outside so I'm just playing around today.
-
Num I was refearing to point B not point A , sorry. I was one step ahead of you I beat.
(http://img358.imageshack.us/img358/8561/untitled0lo.gif) (http://imageshack.us)
-
Bots, if they were really on the circle's edge like that the distance between them would be the circle's diameter. Ie: 200
Their actual distance is sqr((129-70)^2 + (129-70)^2) = 84.
-
OK, I GIVE UP, I WILL GO HOME AND VB IT., THE WHOLE THING.
-
For the point 70, 70 perhaps. It doesn't work for other points on the circle, like (0,100) in your picture above.
-
EXACTLY. :idea: (I am in collage right now, and excel does not support a frendly enough lab for me to mess in)
-
Isn't the whole point that 0,0 should be in the middle of the circle