Darwinbots Forum
Code center => Suggestions => Topic started by: EricL on March 24, 2008, 02:13:27 PM
-
Previous versions support 12 field sizes, the largest being 96000 X 72000.
2.43.1e supports 100 different field sizes. The first 12 are the same as before. The largest field now has dimensions of 800000 X 600000.
Very large fields are interesting for many reasons not the least of which is that they can provide a degree of geographic isolation for evo sims.
-
That's a large field.... Any reason for providing a user with 100 different options for a field size? Sounds intimidating and unnecessary. I'm actually more interested in non-regular field sizes - with one dimension being much larger than the other. Those could be used to create very large and shallow ponds or very deep wells. That would be more interesting for different ecosystems.
-
It was pretty easy to do it this way and I wanted to keep the current field size options, but perhaps I'll change it so as to drop the number of choices but increase the size non-linearly beyond size 12...
Custom aspect ratios adds another degree of complexity. Shouldn't be too hard to do. That's next.
-
Okay, I changed it. Only 25 field size options now. First 12 are same as always but they double every size increase beyond that.
Largest field is now 2496000 X 1872000
-
Could that cause problems with the xpos and ypos variables, seeing they are restricted to 32000?
-
Could that cause problems with the xpos and ypos variables, seeing they are restricted to 32000?
Nope. They don't actually give absolute position. They give you your position in 1/32000ths of the total field width/height.
EDIT: For fields with dimensions > 32000 that is. I've thought about changing this so that even for small fields, they range from 0 to 32000 instead of givcing the actual position, but that would break backward compatability in the leagues I suppose...
-
They give you your position in 1/32000ths of the total field width/height.
Does it use floating-point variables, or is it just accurate to the nearest 32000 units?
-
All vars use integers. I presume it's rounded.
-
All vars use integers. I presume it's rounded.
You presume correctly.
-
You might also consider allowing the user to directly edit a single dimension. Like click on the X dimension and you can type in to it to change the field size.
-
You might also consider allowing the user to directly edit a single dimension. Like click on the X dimension and you can type in to it to change the field size.
That's my plan, but there's a test burden I'm not ready to bite off just yet. One step at a time...
-
You've just destroyed my faith in the .xpos and .ypos variables.
Maybe a better way to go is to have nested global and local locations, so that the global position returns a grid with 32000x32000 per square, which is then subdivided into the local coords.
-
You've just destroyed my faith in the .xpos and .ypos variables.
Maybe a better way to go is to have nested global and local locations, so that the global position returns a grid with 32000x32000 per square, which is then subdivided into the local coords.
This behaviour of .xpos and .ypos is not new. It has worked this way for larger fields for a while now. Adding yet larger fields doesn't change anything except make it more obvious that the granularity of these change with field size. Many various options were discussed in detail at the time this was addressed including your suggestion and the current behaviour was settled upon for various reasons not the least of which is a general aversion to providing bots non-local information. The decsiion not to remove them entirely was made msotly for backward compatability reasons.
As it is, it still allows ant bots to rendevuez, F1 leagues to use exact positioning, etc. I have no plans to change this. I would however, be very happy to remove .xpos and .ypos all together if peopel would let me...
-
With the far larger fields, having sims with infinite shots turned on is going to be a HUGE problem as there's so much space to fill. And sometimes having them decay the distance just might not be enough. I did a quick scan to see if you can control shot decay distance but I don't think I saw anything. Might be a good idea to have that option if it isn't already around.
-
With the far larger fields, having sims with infinite shots turned on is going to be a HUGE problem as there's so much space to fill. And sometimes having them decay the distance just might not be enough. I did a quick scan to see if you can control shot decay distance but I don't think I saw anything. Might be a good idea to have that option if it isn't already around.
Good point. I'll put that on the list.
-
Nope. They don't actually give absolute position. They give you your position in 1/32000ths of the total field width/height.
EDIT: For fields with dimensions > 32000 that is.
If ever an intelligent species evolves in DB, it will be fun watching them trying to figure out the physical rules of their universe and of their own perception Mwa-ha-ha-ha-ha
-
I get "Overflow" errors when I use the largest sim sizes, usually sooner (in cycles) for bigger maps.
-
I get "Overflow" errors when I use the largest sim sizes, usually sooner (in cycles) for bigger maps.
Already bugged. Working on it...