Darwinbots Forum
Code center => Suggestions => Dead-End and Solved Suggestion Requests => Topic started by: Numsgil on February 20, 2005, 04:11:47 AM
-
I'd like to propose splitting the 1000 memory locations into 20 arrays of 50 elements each.
Arrays 1,2 are for custom labels and bot specific memory locations
Arrays 3-11 are for eyes 1 through 9
Array 12 is for Internal Self Information
Array 13 is for External Self Information
Array 14 is for Self Commands
Array 15 is for tierefs
Array 16 is for tiecommands
That leaves 4 arrays for future developments. Every sysvar would be put into one of these arrays.
The advantage lies in the fact that now we can look at more than just what's in front of us.
Something like:
cond
*.eye3(.refeye) *.myeye !=
start
blah...
stop
The sysvars could be arranged so that *.myeye refers to InternalInfo(.myeye), so the arrays could be transparent to the bot programmer if they like.
This is mostly a way to organize the sysvars. Understanding which sysvars are for reading data from and which are for writing data too can be confusing some times.
-
I like it. But how is this going to affect the sysvars text?
EDIT: also, you'd need to give people a crash course in handling arrays. It's fine for programmers, but what about some poor schmuck Who hasn't got a clue about what an array is.
-
The sysvars would need to be rewritten, but once done I don't suppose they should mean anything different to the bot programmers than they did before.
Aye, a crash course in arrays would be needed. I think basic programming should be a required course in elementary school.
-
Dim memory(1000) as Intager 'this actualy already Exists in the program
Do '<--- this loop is the robot stack loop itself
memory(0) = 0
Do
memory(memory(0) + 100) = 999 - memory(0)*2 '<--- inpossible in the current virsion
If memory(0) > 100 Then Exit Do
Loop
Loop
***Can you later add the ability for the DNA to store values in arrays , not in memory one by one
***And Robots will be able to mutate all this stuff naturaly
-
If you add arrays, it could, and probably would, make some bots obsolete.
Especially mutated bots...!
And as a related result, mathematics will be much different.
Especially if you use that format.
For example, what if you wanna make super-advanced, super-efficient genes.
And if you're still dead for using arrays, then I suggest we keep to the current system, and simply add a new stack option.
So instead of -1 7 store, it'd be -1 14 12 store. (Just as a random example. Of course, a programmer would more likely use -1 .shoot store, but I see no major advantage of having an array with such a simple programming language. The only real advantage is that each eye would be able to get information, which might make bots too deadly.
And even that advantage could be simulated with the current system.)
Though if you mean to simply organize all the system variables, by all means do so if you really want to.
And that'd only leave three arrays, to he who started this topic. Remember racial information? For most bots, those system variables are completely untouched, but without them, it's a real pain to make bots that're based on origin and family rather then species.
-
A.G.P. whats wrong with complexity , array complexity is what makes it possible to design programs like DB in the first place.
As for -1 20 63 store , I dont use thouse I even dont know what you are talking about
If I would want to store 20 into memory 10 based on information in memory 6 were memory(6) = 10 I will write
20
*.*6 'pointer from memory6 to memory10
store
somthing like that ; all we did in this example was add a new "*.*" command
What does "rasial information" have to do with anything? what does that have to do with arrays? (Am I being Rasist?)
make bots too deadly
there is no sutch thing as a too deadly bot, the only way a bot becomes unbeatable is if takes up all the DNA space possible with considaration of energy and uses ever letter of it perfictly
-
Ahem. I said "might make bots too deadly".
That "might" is very important. Without it, I seem very clear that that'll happen, with it, it's simply very probably that that'll happen.
And by racial information, I mean the system variables 971-990.
(Though they are racial memory, but that's besides the point....)
And it's -1 14 12 store. I was basing it on the very first post, and I assumed that .shoot would be placed in the 14th array, and randomly picked 12 for it's location in that array.
-
very probably that that'll happen.
I dont think so , I already explained: There are always going to be stronger bots until and only until the limits of the program are reached. , If that happens we eather remove somthing or add on somthing to the program to make further insanity possible :D
-1 14 12 store
will make a lot of bots no longer able to function because they use "-1 76 store" if say 76 was a .shoot
if we have -1 14 12 store the program will go: "WTH DOES 12 MEAN WHEN THERE IS SUPPOSED TO BE A STORE THERE"
if we say to the program read the 12 next time it will go:
ex: -1 76 store
It will go "OK WERE IS THAT NUMBER 12 BEFORE ThE STORE"
(I love writing replys :) )
-
I suppose so. Though any bot that uses viruses, or .delgene as a weapon is rather close to that limit.
Which is why the programmers're making better defenses against viruses (I hope!), and are probably gonna remove an evil little trick my superpowered bot of underpopulated doom uses as a primary weapon.
And -1 14 12 store would work, even in the current system!
It's store 14 in the memory location 12, and leave the -1 on the stack. :P
*Loves to argue, buahaa.
Even though he's not very good at it. <_<*
-
This is a qustion for PY and NUM not for AGP
***Can you later add the ability for the DNA to store values in arrays , not in memory one by one
***And Robots will be able to mutate all this stuff naturaly
-
I suppose so. Though any bot that uses viruses, or .delgene as a weapon is rather close to that limit.
Which is why the programmers're making better defenses against viruses (I hope!),
I've seen your bot, that nasty little .delgene .tieloc store. Yuck. Had Ymir up the wall till I added slime to his adult form. Nice work.
Some slime (alot of it actually) renders that weapon invalid, so I don't think it's too much of a problem. The other illegal delgene weapons should all now have a counter. Except the venom one. I may need to rethink the venom defenses.
In the next version, venom is traded with poison. That is, the venom is accepted and a poison shot is released as well. Maybe I need to make this like how energy shots work instead.
Then we could reallow all delgene weapons, as they move from unstoppable to annoying.
-
You could make robots return poison when certain memory locations are set.
Or perhaps, if it's not already in, make it so that shots and ties change memory locations BEFORE it reads all the DNA.
Though if it doesn't already work that way, that could prove very difficult to do.
But if it already works that way, .delgene defenses could be really easy to set up.
-
All good points.
- Old Bots may become invalid.
- The sysvars will be sorted (it's kind of a mess right now, if you didn't' notice)
- There will be designated memeory ranges that sysvars will never invade. Currently bots have to find a spot to store their own variables amidst the mess of sysvars. Having an actual range that is guarenteed is definately a good thing.
- Refvars for different eyeX's would be a major leap forward for bots. Currently there isn't really room in the sysvars to do this without shoe horning it all over the place. Also, their names would become very long. eye4refvelscalar certainly is a mouthful. Arrays should help make this more readable
- Memory location in array 5 subscript 3 could be also reffered to as 253 (50 * 5 + 3). This way the arrays are nearly transparent to the users if they like.
---------------
An alternate idea would be to create a seperate area for the eyes, outside of the usual 1000 memory locations.
---------------
Bots that use this new eye stuff could be alot stronger than current bots. But I don't think it gives an unfair advantage. New bots can use this new eye stuff too.
-
You could make robots return poison when certain memory locations are set.
Or perhaps, if it's not already in, make it so that shots and ties change memory locations BEFORE it reads all the DNA.
Though if it doesn't already work that way, that could prove very difficult to do.
But if it already works that way, .delgene defenses could be really easy to set up.
Currently it seems that shots and ties change values after the execution of the DNA. I'm not sure, I haven't really looked into it. PY would never better than I.
I like the idea of the info shots and tie locs being hard to defend against except with external defenses.
-
True. And there are almost too many defenses already. It's not that difficult to have a super defense bot which is nearly impossible to harm!
And also, I think that all the system variables should be reorganized.
This will take a LOT of work, but it may be worth it.
And perhaps we can say variables from 991 to 1000 are user variables?
Or perhaps 20-100?
-
I'm working on a system to power up shots. Should mean that there are neither invincible bots or unbeatable weapons. Then we can remove the limits on shell and slime.
-
You could make robots return poison when certain memory locations are set.
Or perhaps, if it's not already in, make it so that shots and ties change memory locations BEFORE it reads all the DNA.
Though if it doesn't already work that way, that could prove very difficult to do.
But if it already works that way, .delgene defenses could be really easy to set up.
Currently it seems that shots and ties change values after the execution of the DNA. I'm not sure, I haven't really looked into it. PY would never better than I.
I like the idea of the info shots and tie locs being hard to defend against except with external defenses.
Shots and ties change memory values AFTER regular internal DNA commands are processed.
It has to be this way or else it would be completely impossible for any kind of tie or shot weapon to work at all. It would also make the design of MBs next to impossible.
I spent a considerable amount of time sorting it out so that it works this way. For example it used to work such that bot number hierarchy allowed older bots to influence younger bots but not vice versa. That was a real headache. Had to build in an entire new routine to scan all robot's ties for comunications prior to running the rest of the processes.
:D PY :D
-
And perhaps we can say variables from 991 to 1000 are user variables?
Or perhaps 20-100?
I don't favor limiting user variables to a specific area of memory.
Reason?
It would be too easy for another robot to scan those memory areas and find one to screw the robot up with.
:D PY :D
-
Gah. I posted, and accidently went back instead of pressing "Add Reply."
Somehow.
But yeah.
Anyway, I meant as a field of memory locations/variables which the programmers agree never to turn into a system variable.
'Cause you could use 510, only for it to be one day be the equivilance of .eye1(.refvelup).
Or something.
Oh, and I suppose having .ref vars is useful in the other eyes. But rather then being in the other eyes, I think that they should be rather limited, only showing physical information. However, as a bonus/con, they're very dynamic, allowing the programmers to have a few .eye5 ref variables that aren't stored in memory after what you see vanishes.
And if you need to remember something that you only saw out of the corner of your eye, then it's not hard to make a gene that does that....
Though that's just my oppinion. Especially the dynamic part.
But the whole physical information-only part makes sense in my oppinion, if only because it's similar to how humans (and other animals?) see.
Sure, you can see that there's an object out of the corner of your eye, and sure you can tell the shape. But unless you look at it, or are really good at looking out the corner of your eye, you won't be able to examine it very well.
-
OK Here's is a thought.
I was just considering how much extra processing time it might mean for robots to gain this much information from all their eyes. (probably not too much)
Then I thought of this possible solution.
We could allow the robot to get detailed information from just one eye at a time but allow the DNA to define which of the 9 eyes will produce it. All other eyes will just see distance as they do now.
This way the robot can scan from side to side in different game cycles without either costing processing time or giving him too much advantage.
This could also be extended to give an array of 3 eyes at a time the ability to give detail. A robot looking straight ahead would get detail from eye4 through ey6. If he looks left, he will get it from eye1 through eye3 etc.
This is just a very tentative thought right now. I just want to see what others think of it.
:D PY :D
-
That sounds good, I guess.
Especially if it's changable via inc or dec. (As in, doesn't reset to zero after being set.)
That way you can scan the area without too much energy, but if you want to quickly focus from, say, .eye7 to .eye1, then you'll have to expend some energy.
And if you do use this system, I suggest you also put in something like .eye, or .eyesel, or something, which acts at the .eye# that you're currently focusing in.
-
Haha, sounds like the Cylons on Battlestar Galactica. Their eyes seem to scan from one eye position to another too :P