Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Anonomous Guest Person

Pages: [1] 2 3 ... 6
1
Suggestions / Gestation and Maturity
« on: October 29, 2006, 04:29:31 PM »
How 'bout we force bots to reserve energy torwards reproducing. The more cycles they do this, the less mutations will occur... however each cycle they spend on this will also decrease the amount of energy stored that'll actually go to the bot.

Perhaps while they're doing this, they're more suspectible to damage as well... or maybe shots will merely damage the amount of energy/body that's already stored for the offspring as well as the parent.

This allows some bots to hastily spit out offspring, while other bots can spend cycles and cycles working on their children. The latter would of course be more convenient for multibots or bots with a lot of DNA.

Alternatively, we could just weaken a bot temporarily right after giving birth/being born, making them more suspectible to shots and tie drainage, plus reducing the effectiveness of any materials they have boosting their abilities (such as body, shell, slime, etc)

2
Suggestions / Muscles, Fat, and Chloroplasts
« on: October 24, 2006, 12:01:20 PM »
I personally like the idea, but have a few major questions:

What'll happen with -6 shots?
Will bots still die if they have 0 of all three body methods?
What values would an average bot we see today have? (That is, what level of muscle would an average bot start with, and what amount of cellulose would a plant have? 1000?)
How useful will muscle be? What about cellulose?

Also...

Zinc: Basically to regulate high levels of energy. 32000 energy isn't a wild dream for all bots. Not to mention -1 shots won't steal fat, so it provides some additional defense against -1 shots.

Eric: Unless I'm mistaken, I think muscle efficiency would mean that it would merely increase the output of how much energy is inputted. For example, I'd imagine a bot with 20 muscle would have to output a lot energy to be a devestating combatant, while a bot with 32000 muscle would have to spend much less. And your example does indeed have flaws; spending energy into muscle is far more specialization then just having energy, and would be an additional upkeep for the whole multibot. This could allow for some unusual multibots, as well... imagine a musclebot lugging around a fatbot and using it to just store energy! And take shots from behind that it'd otherwise suffer.

Additionally, if we go with muscles, may I add a suggestion into the mix?
Anywhere from three to five sysvars. Maybe even one. Perhaps we could limit this as a simulation option, because having just one of these would allow for more specialization and thus increase the usefulness of being part of a multibot, while five would definately lean torwards singlebots.
Basically, it'd direct the focus of your muscle torwards one action, basically giving that action slightly more benefit from the muscle, but everything else a bit less. Of course I haven't quite worked it out yet, so it might not be all that feasible, but I still like the idea.

3
Suggestions / What should vegs not be allowed to do?
« on: October 24, 2006, 11:41:38 AM »
Quote from: Numsgil
Also, you could add a cost field that charges bots nrg every cycle that their eyes are turned on.  This would encourage bots to remain blind if they don't use their eyes.

I like that idea a lot. The cost could be based on WHICH eyes are turned on, giving programmers more of a reason to limit the number of eyes they used as opposed to just using all nine, which will hopefully result in more performance. It's like social evolution! Sort of.

Eye5 might be additionally expensive, and I propose that it have an additional cost (ref vars) if it's turned on... just because I want to see someone make a bot that's entire design purpose is to avoid this extra cost.

4
Suggestions / What should vegs not be allowed to do?
« on: October 23, 2006, 04:10:58 PM »
Quote from: EricL
How's this.  There's a restricted "built-in" veggy.  It can't see, it' can't move on it's own, it doesn't evolve, it doesn't even have DNA and the veggy repopulation and population control only works for this built-in species.  Maybe it's even always fixed or at a minimum the fixed option checkbox only applies to them.  (Any other bot that wants to be fixed has to have a gene to fix themselves.)  Being fixed helps performance since fixed bots don't move, don't collide with other fixed bots, don't friction or fluid resistance, etc.   The restricted veggy is a bot - it can be seen, eaten, tied to, etc. - but it's there mostly as an artifact of the landscape to bootstrap the ecosystem, provide food for other bots and as a doorway for energy to enter the sim.   People who don't care above evolving veggies can use these for the veggies in their sim and reap the performance enefits.  People who want the full flexability to evolve autotrophic bots or autotrpoh/non-autotrpoh hybrids can use full blown autotrophs that have the potential to evolve, see, move, etc.

I like that idea to some level... but it has a few major problems.
What happens when other bots change it's sysvals from outside? Or virus it up?
Also, if this is added I'd suggest that it's not ALWAYS fixed but rather that whether it's fixed or not remains unique to each bot, with an added exception that it gives birth to bots that're fixed based on species preference as opposed to the bot's own preference.

Also, to Numsgil, may I request that you take your idea of muscle, fat, and cellulose to a new topic so we can discuss it without getting too far off topic in this topic?  I know it probably has a few topics devoted to it but they're probably at least a year old... by now.

5
Suggestions / What should vegs not be allowed to do?
« on: October 22, 2006, 10:28:33 PM »
I like the cellulose idea too (but want a *.photo sysvar for SOMETHING darn it!) It's... almost exactly the same as my idea, really, with the main difference being that mine was just to emulate body in matters of mass and volume and stuff like that.

And, if not for the fact that it wouldn't allow for bots to hide their eyes, I'd be all for keeping it so that in order to see, you have to have a definate *.eye5 (or some other number) in your bot's DNA.

Also, if it's possible to do so without actually be MORE taxing on performance, I'd like it if it checked each eye usage individually, with ref sysvars also accounting for .eye5.
That is, if .refeye is used, then it'll calculate .eye5 even if no .eye5 is actually used. (Don't diss the possibilities of a robot that could do this! It'd be seen as blind but wouldn't be if done well!  Now I just have to figure out how to mathematically calculate where a bot will be in one cycle of movement using only ref vars, and calculate the angle distance that'll occur... if someone knows that freaky trigonometry stuff (I probably even spelled the word wrong! that's how little I know of it!) please teach me!)

Anyway, sorry for rambling  My point is, there'd be a lot less system tax because plenty of bots out there don't use at least one or two of their eyes, and some neglect as much as half of them.

6
Suggestions / What should vegs not be allowed to do?
« on: October 22, 2006, 02:54:34 PM »
Quote from: Numsgil
We could add an idleness check.  If a bot doesn't reference an eye in X many cycles, the eyes turn off again.

I'm mostly interested in the idea I've had of a veggy "mask".  A bot would tie to a veggy and have the veggy perform all its actions, including seeing, feeding, moving, etc. while it looks in the opposite direction and protects the backside.  Most bots it would hunt wouldn't be prepared for a predatory veggy.

So long as veggies can have various skills "switched on" I'm okay if they "atrophy" over time.

Ah, how I think of it is that if a bot doesn't reference to any eyes, it doesn't have eyes to look through, and thus the only way to bypass that would be to build eyes.
Aka inject the bot with some virus.
How long can a virus that's just cond start *.eye5 stop cost anyway?

Quote from: Testlund
It whould be bad for evosims if veggies were limited and can't evolve into heterotrophs. What about just decreasing the sight radius for them all. I think they have too good vision anyway. It should be more like they sense when they are very close to something, like real organisms.

Mm, unless the VB code is already using a grid system for eyes, that won't help much.
I'm not 100% sure but I think that how eyes work now is that they cycle through every other bot and see if the bot should be in sight. Which is why a lot of bots can get really laggy sometimes!

7
Bugs and fixes / 2.42.9 Changes
« on: October 22, 2006, 02:49:01 PM »
Quote from: EricL
I don't understand.  Limit bots how?


I think in the same flat manner veggies can be limited in, which I believe disables reproduction if there're more then x bots, x of course being the limit set for the number of bots possible in the simulation.

8
Suggestions / What should vegs not be allowed to do?
« on: October 21, 2006, 09:04:50 PM »
I personally want to blur the lines between veggies and nonveggies.

How I want it to work is... well basically veggies'll be able to create a new substance that'll gather nrg for them.

I'd like this new substance to add to mass, and it'd basically be used instead of the bot's Body as far as gathering nrg would be concerned.

We could call it photo!

Er, but anyway... this new substance would basically be an alternative Body for plants. Preferably, death checks that occur when Body reaches 0 will be changed so that only when the bot has 0 Body and Photo will it die.

And of course the current system can be changed so that plants get a small amount of nrg put into Photo automatically, and plants would start with 1000 photo instead of 1000 body.

The benefit of Photo or Body would decrease if the bot doesn't have a pure amount of either, though by what amount I'm unsure... possibly the amount could be multiplied by the percent... for example if you have 1000 Photo and 1000 Body, it'd be closer to like having 500 of each, and thus would be 1/4th as cost efficient then specializing. I think we should be pretty cruel to bots who like to be jack of all trades like that, else they could too easily become superbots and basically pwn everything.

Of course, this also means pure plants would SUCK at combat that relies on body for effectiveness, which would balance out certain things, especially bots that transcend their flat limitations by reproducing through viruses.

But that's all just my off-topic oppinion, perhaps I should make a new topic for it all!

Anyway back to on-topic... isn't there a currently used system which checks to see if the bot is using any of it's eyes at all, and if not then it simply doesn't calculate that information? If not I say implement that. It'll be a very small bit more memory taxing, but if done in a nice, complicated boolean bitwise level type way it wouldn't cost that much... just ten boolean variables: one for each eye, and one to see if anything's being used. Of course, ref variables will be counted into eye5.

And if anyone complains about blind bots incapable of having their sight being read by other bots, we could just say that the presence or lack of .eye# sysvars are a flat way of determining whether the bot actually HAS eyes or not.

9
Bugs and fixes / 2.42.9 Changes
« on: October 20, 2006, 09:14:15 PM »
Ah, now it works!

However I do notice that viruses don't seem to want to be placed before first gene... I'm not sure if that's a bug or not though!

[Edit]
I'll probably look at the source code (again) tomorrow. Or monday. Or whenever I feel like it and have enough system resources left.
I'm planning on making a mod of DarwinBots showing an approximate of how I wanted muscles and such to work. I say approximate since it's been over a year since I though the idea up.
But then again I might get lazy and not do that.
oh well!

10
Bugs and fixes / 2.42.9 Changes
« on: October 20, 2006, 08:27:37 PM »
Quote from: EricL
You can regress the virus insertion bug for me.  I.e. confirm that my fix actually fixes it.

Gh... actually as of testing it I don't think it does.

But you can test yourself via this sim if you'd like. It's all poised up for a bunch of simple virus-shootin' bots to infect a bunch of veggies! (here's a hint; victims of the virus spin around rapidly!)

[Edit to fix my grammar ]

11
Suggestions / Two new cost ideas
« on: October 20, 2006, 07:47:22 PM »
Ah.. when I meant body cost I was thinking more like dissipation in the environment.
Not really a cost as much as a constant threat, really. It's a mix of "yet another thing to model evolution" and another somewhat flat way to give the world in DarwinBots a somewhat more 'realistic' world.

Not that this world has to be our's or even look like it at all.

Though I do admit it seems to really overlap with Body Upkeep.  Except in this case it transfers the job of actually upkeeping body from the system to the bot.

12
Suggestions / New Operator Ideas
« on: October 20, 2006, 05:02:27 PM »
It's already possible to do indirectly, but I figured why not suggest it anyway?

I don't know what it'd be called but it would check to see if there's a value on the stack. If so then it'll replace this value with 1, if not it'll add 0 to the stack.

However I don't know how the stack works... if the stack automatically has all zeroes in it at all times and has no means of telling whether a value in a stack is a 0 or is supposed to be nonexistant, then please tell me and forget the idea (sgn abs would work just as well if that's the case!)

(If you don't quite fully understand what I mean, then my love for writing examples forces me to show you the following:
0 checkstack
would return 1
while, assuming the stack doesn't have any garbage in it, simply
checkstack
would return 0.)

Additionally, a swap operator, which would basically reverse the top of the stack.
(For example:
1 2 swap
would have 1 on the top of the stack and 2 right below it.
Though this probably won't be a very good reason to use it, it would allow:
.shoot -1 swap store
to put -1 in the .shoot sysvar.)

And my final suggestion: A delete-the-top-of-the-stack operator. Which basically just gets rid of the top of the stack.

(In example:
-1 .shoot 25 del store
would put -1 into .shoot.)

Thanks for reading this, and sorry for posting so many suggestions.

[Edit]
Another idea I forgot!

The halt operation. I'm not quite sure how it'll work, but it'll skip the gene as soon as it's called with a certain value.
Perhaps if the value is 0 it'll halt. Or maybe non-zero. Or maybe positive, or negative.

Personally I prefer the "if the value is 0" bit though!

Adding this in would probably be yet another step torwards making genes merely illusions, though. And adding... almost any of these operators would be yet another step torwards making the bots closer to nanobots then organisms.

Whether those are good things or bad are up to you to decide, I guess!

13
Suggestions / Two new cost ideas
« on: October 20, 2006, 04:29:51 PM »
Cost for existing: A standard, constant cost every single bot has to pay just to exist.

Body Cost: Loss of Body (think like how slime dissipates). It'll be reduced by shell or slime (though shell will grant much more resistance then slime, while slime will just more or less take it's place.)

Both of these will, as of version 2.42.8, hopefully be usable to reduce the impact cancerous veggies have on a simulation.

14
Bugs and fixes / 2.42.9 Changes
« on: October 20, 2006, 03:48:18 PM »
Quote from: EricL
Bump.  2.42.8a buddy drop released.  Perf stuff and a fix to virus insertion.

Woot, keep up the good work!

If you need any help, just ask...though I doubt I'm a much better programmer then you.

15
Suggestions / Send-all Tie Communication
« on: October 20, 2006, 10:36:42 AM »
Simplistic hivemind colonies could use it. (basically a lot of bots tied together that would share orders) This could be done without .sendall but the addition of a new command allows for two communication methods, which could improve the bot's effectiveness. Imagine a lump of bots haphazzardly connected being controlled by one brain bot (which any of the bots could become if orders stopped coming in some manner I can't think of). Now normally the brain has little means to communicate orders because it only can send one thing out at a time but if it can send two out, it can send a command and the command's "version number" (higher commands would replace lower commands, as would different commands of the same version, but these're technicalities.)

Plus, what I considered developing: (and can still do so pretty easily if I figure out how the heck I can get a bot to turn freely when part of a multibot without tie physics throwing every other bot around...mostly for cellular regeneration)

A giant multicellular bot that's built to act like a single bot, but built up of 5 bots (in a + formation).
Each part of the bot would use basic math to interpret some orders differently (for example the order to turn left may be read as going up for the right bot but it'll also be read as going down for the left bot.)

Plus it'd make communication to several other bots possible without making it impossible to communicate to them individually.

And I'm sure there'll be a few ways to abuse it for combat purposes.  

Of course with the new tie functions in that link Numsgil posted, all of this and more will be quite possible.

Pages: [1] 2 3 ... 6