One method may be to update certain distance references based on %s of changes in current location. Say your bot sees no more food where it is, once the bot leaves 10% of the area around that point it first foudn the food, have it update its distance vars based on waypoints, and then compare only the distance vars. Also, if you organize the vars right, you could make a multiple cycle reader that checked say 10 nearest points or whatever. I'm guessing you don't use things like shapes, so its not entirely necessary for the bot to remember that much information, other than where food is, where a safe route is, and where enemies most likely are. For the most part, you should only be making very large memory scans when food resources go low, or when the population starts falling off, or when the bot is in real danger of death. Every cycle the bot should simply check to make sure it has some safety point within a set distance, which could be a SYSVAR set distance.
I've managed to produce a simple little waypoint counter, uses 40-50 to store 5 points using a single memloc inc and store
first, set your memloc to 40 or next free location, count by twos though because the 41st is the y-coordinate. you'll need to know the sysvar #s for xpos and ypos
cond
*bluh *bluh =/!=/?
?
start
40 .memloc store
stop
cond
'check for empty space
start
40 2 add .memloc store
stop
cond
'store waypoint for x
start
*.xpos .memval store
stop
cond
'store waypoint for y
start
.memloc inc
*.ypos .memval store
stop
We always know y will go right after the x var, so this works for an easy waypoint creater. TO read from it, its just the same functions only a different order. Start by adding an additional store we can compare locations easier, without messing with a memloc counter, but I still like these because it makes bot though automated, rather than conditional.
Anyways, to read you could do the following:
cond
'decide what to look for, some waypoint type, you should know these based on sysvars loc you used to store them
'I say create sysvars that reference each sysvar for easier access, I set up 10 buffers to make the bot have some RAM, prevents large memory searches using several other vars
'for a simple safety waypioint, using 40-50
start
40 .memloc store
*.memval .buffer1 store
stop
cond
'continue to search until internal swithc or other condition
start
.memloc inc
stop
cond
'compare (*.buffer1 *.memval dist *.d1 >)
Now the easiest way to continue is to use the tmemlocs to push information into another bot's RAM while continuing its own search routines, but that is a little more involve, so you would have to continue by hand storing to each buffer, but the benefit is that your memloc counter could be used for some other use to say update eyes or whatever. But this buffer system will let a single bot multitask after about 10 cycles, depending on how you set up the conditions for reading. Once you've done that, its a matter of running comparisons on each buffer until the bto finds what it is looking for. To make sure it doesnt try to find both the longest distance and shortest distance, it will require clever conditioning, overlaps make the memloc commands not work.
Yes the conditions I gave are vague and make the bots skip location 40, but I didn't want to muddle it with switches and locks, thats something that is left for the designer to decide, for me I'm using 1-3 conditions a gene, and getting genuine results. Currently the tie feed system is too limited and the bots tend to die off from so many stores, but I'm working on improving its basic survival genes. You could run comparisons using a seperate set of memloc counters that activated only once or when necessary, but I've gone with continuous update aproach for now. Again, its the same prinicple as before, only you would use *.memloc and 1 buffer such as the genes I posted above to make the comparison, you would need to use 2 add to count properly, or you might compare a x-coord with a y-coord, which isnt very helpful. Also, you will need to store distance results to actually make any useful comparison, and it would be simple to implement such a comparator. Anytime a distance was found that was shorter or longer, the previous d1 would be overwritten with the most preferred result, this process could be done once on all desired melocs and would produce a true result. Eventually it may be possible to build a bot that knows what and where within a few cycles, but at the moment it takes Slim Evo 4 1 waypoint/2cycles, and the comparisons take about 1 waypoint/cycle, so a decision about food or safety can be made in roughly 15 cycles.
