Code center > Dead-End and Solved Suggestion Requests
Arrays
Numsgil:
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.
PurpleYouko:
--- Quote ---
--- Quote --- 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.
--- End quote ---
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.
--- End quote ---
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
PurpleYouko:
--- Quote ---And perhaps we can say variables from 991 to 1000 are user variables?
Or perhaps 20-100?
--- End quote ---
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
Anonomous Guest Person:
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.
PurpleYouko:
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version