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.


Topics - Anonomous Guest Person

Pages: [1] 2
1
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!

2
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.

3
Bug reports / Minor glitch
« on: October 19, 2006, 10:32:26 PM »
When in Custom Cost Simulation (the button in the Physics and Costs part of Simulation Settings), pressing F1 Defaults temporarily grays out the "Enable Dynamic Costs" checkbox. It's no big deal at all however, as closing and reopening that screen/menu/thing ungrays it out.

4
Newbie / Zooming out
« on: October 19, 2006, 07:01:33 PM »
Er.. how do you zoom out? I always accidentally zoom in (don't ask how >_> ) and have to go to New Simulation and press Change just to fix it.

Also, aside from the third mouse button, is there another way to zoom in? (just out of curiosity)

[Edit] AGH! one second after posting this I see it! EXACTLY one second! Two at the very most! Seriously! Sorry!

5
Bug reports / Virus insertion
« on: October 19, 2006, 11:04:42 AM »
For some reason, every single virus I've looked at in the victim's DNA seems to be inserted BEFORE a stop as opposed to AFTER a stop (making it, from cond to stop, technically apart of another gene)

For theoretical example, say you have a virus like:
cond
start
0 .aimdx store
0 .aimsx store
stop

And it gets inserted into a bot like:
cond
*.nrg 1000 >
start
15 .repro store
100 .strbody store
15 .aimdx store
stop

Then the result seems to become:
cond
*.nrg 1000 >
start
15 .repro store
100 .strbody store
15 .aimdx store
cond
start
0 .aimdx store
0 .aimsx store
stop
stop

This bug occurs in v2.42.8 by the way.

6
Suggestions / Just a small minor suggestion
« on: October 18, 2006, 04:55:05 PM »
Well, it's always bugged me how almost exactly the same yellow and orange look (by orange and yellow, I mean the default colors.)

Could it be possible to make it more...redish orange? Like... 220, 150, 60 (RGB)?

If anyone does this, thanks! As it stands orange doesn't seem like much of a good color choice if you want to easily distinguish between two bots.

7
Suggestions / Send-all Tie Communication
« on: October 16, 2006, 04:31:22 PM »
How 'bout a method of communicating with all bots you're tied to? This would not directly allow for tie feeding and would only send through ties in which you're connected to as a multibot. It, additionally, would be sent prior to direct communication methods.

If this seems like it'd give tiefeeders too much of an advantage, you could limit to just sending to one memory location... aka .tievalall and .tierecall (30 .tievalall store would make any bots you're connected with have 30 *.tierecall = basically)

Additionally, could .multi perhaps return the number of bots you're connected to that way? Aka if you're tied with 3 bots and have been for so and so cycles (I forget how long it takes exactly... somewhere between 20-50 cycles!) then *.multi will return 3.

Thanks for reading this. Additionally, if I haven't said this in the past a looong time ago, thank you so very much, Numsgil (I think he's the one that added this! if not then I redirect my thanks to whoever did!), for allowing mathematic functions to work in conditions.

8
I dunno how the actual metabolism will work; this is an idea of implementing the metabolism to a bot.

First, you have to set up to ten enzymes. These can change via mutations, and are set after the genetic code.
Each enzyme'll probably be one line.

Once the enzymes're set up, you can use them via a bunch of sysvars.
EnzA, EnzB, EnzC, etc.
The more you store in the system variable, the more it'll digest.
There could be a method to alter enzymes, but I doubt PY would accept such a system. <_< :P

9
Dead-End and Solved Suggestion Requests / Bitwise Functions
« on: March 18, 2005, 10:47:16 AM »
Like AND, OR, and XOR.
Infact, just AND, OR, and XOR.

(And not just in the conditions, in the actual gene itself too, darnit.)

(For those who don't understand how they work, you hafta look at the number in binary to fully understand.
AND checks each bit of two values, and unless both are 1, the result will be 0.
I.E.
10100101 AND
00101101 equals
00100101.

OR checks each bit of the two values, but unlike AND, only one of the two bits have to be 1 for the result to be 1.
I.E.
10100101 OR
00101101 equals
10101101.

And XOR checks each bit of two values, but unlike AND and OR, it only results in 1 if ONE (and no more then one) of the bits is 1. (They basically have to be different. The bits, that is.)
I.E.
10100101 XOR
00101101 equals
10001000.)

10
Off Topic / Evolution
« on: March 13, 2005, 05:21:42 PM »
New features are usually great, right..?
The only problem is they add up over time, turning something simple into something complex.
And complex things can become complicated.
And unfortunately, with the current mutation system, which is pretty much totally random as far as I know, only bad mutations seem to sprout.
Now, this will hopefully be fixed in version 3.0, but even so....
As a mere oppinion, I think that if someone decided to run an older version of DarwinBots, before Poison, and Venom, and such were added, as well as the current version of DarwinBots, the older version would have more good mutations then the newer.
So, for more "good" mutations, we either need a better mutation system which has more of a chance to make smaller, more related changes more frequently then larger, more drastic changes....
Or we need to make less commands. Which could be very difficult.
Or, on a third hand, we could consider it blessing that good mutations are rare. (Though, if you read another point I recently made, then hopefully you've figured out that good mutations can die off before they even start, thus making a mess of the whole natural selection idea.)
As yet another option, we could consider it a curse, and do nothing about it at all, and hope that programming methods will evolve in such a way that actual genetic mutations won't be needed for a species to "evolve."

11
Off Topic / A point on movement in Darwin Bots
« on: March 13, 2005, 05:11:10 PM »
I've often seen an arguement being used.
That arguement just happens to be that most organisms can't go from one point to another quickly. If their food source vanishes, the organisms that feed off of that food source most often should die along with it.
However, if you watch any Darwin Bots simulation, that isn't the case. Most bots can survive a trip across the field. Even if it's a very large field!
And also, most bots can generally do this rather quickly.
In fact, some energy efficient bots that convert body to and from energy efficiently enough could survive for generations!

It's my belief that this is one of the reasons that stable ecosystems only consist of an omnivoric predator, and a plant that unfortunately usually depends on the system for survival in more ways then one. (Approximately two to be precise.)

In fact, I think that the next challenge will be making a bot that can actually remember things, and pass such knowledge off to children, to the point where in mere generations, the species will have mapped out the entire field.

I'm not technically saying this is all bad, but it does make it less of a life sim. (Though the last paragraph means that there're more forms of evolution, which is good. By the time you read this, I should hopefully have written a point about evolution in Darwin Bots.)

I'm simply saying that, in Darwin Bots, most life forms can, and DO, go from food source to food source plenty of times.
I'm also saying that the advantage to this is that we can develop smart bots, that can map the environment, and gain an intelligence advantage over other bots.
Unfortunately, the consequences to this might make such an advantage useless in practice, since powerful bots can often make short work of everything else.
(Though I suspect that once permanent waste is fixed, powerful bots will be rather inefficient.)

12
Short bots / Duo Minimalis (5G)(Anonymous Guest Person)-23.02.05
« on: February 23, 2005, 05:17:27 PM »
Code: [Select]
' Duo Minimalis
'Not the best bot. But once maths can be done in conditions, it might work a bit better!
'By the Anonomous Guest Person a.k.a. Roara.

cond
start
  *.body *.nrg 5 div
  *.eye5 50 sub dup abs div 1 add dup div *.refeye *.myeye div 1000 mult 1000 sub dup div mult *.shup add *.numties add 0
  *.eye1 *.eye3 add *.eye7 add *.eye9 add *.eye5 5 mult sub *.numties 100 mult add *.refeye *.myeye div 1000 mult 1000 sub dup div 1 sub abs 200 mult add 0
  *.maxvel 10 sub *.numties dup div 1 sub abs mult *.vel
  .deltie *.waste dup div 1 sub abs mult inc
  .strpoison *.pleas dup abs div mult inc
  .ploc inc
  .ploc *.ploc .tieval sub dup abs div mult dec
stop
cond
  >
start
  *.maxvel *.vel sub .up store
stop

cond
  >
start
  *.eye9 *.eye7 3 mult add *.eye3 3 mult *.eye1 add sub *.refeye *.myeye div 1000 mult 1000 sub dup div 1 sub abs 600 mult *.eye5 *.eye5 div mult add *.numties 1 sub abs dup div -100 mult *.eye5 *.eye5 div mult add .aimdx store
stop

cond
  >
start
  -6 *.shup 893 mult .shoot add store
  .tie *.shup -2 mult 1 add mult *.waste dup div mult inc
  .sharewaste *.waste dup div mult inc
stop

cond
  !%=
start
  *.body *.nrg 5 div sub abs .strbody *.body *.nrg 5 div sub dup abs div 1 add dup div sub store
stop

cond
  *.nrg 10000 >
start
  50 .repro store
stop
end

13
Specialization, Metabolism, Digestions and Env Grid / Waste Conversion
« on: February 23, 2005, 10:51:23 AM »
The "basic" idea (which is funny to say, since the last three things I posted were all complicated, and all programmer-y-like, without actually speaking in a programming language) is that bots can turn waste into energy for a rather large amount of permanent waste.
This way, unless it's that bot's niche, or the bot reproduces insanely, it's much better to just shoot the waste, or give it to an unsuspecting victim.

To convert waste into energy, it'd be by setting a simple gene to how much waste you want to convert, which might be limited by something like (Body/50). Or just a flat out 25.

Like with photosynthesis, the program'll let you expend more energy then needed, allowing as a submethod for energy to vanish from the simulation, so there can be an addition of energy to the simulation.

Unlike most methods of conversion, which I suggested in the photosynthesis topic, waste conversion won't generate waste.
But it is pretty good energy, considering how much darned waste some bots can generate. You could hijack them, and steal it all! Or maybe harvest it from the enviroment, or something!
Anyway, to get back on the subject, you should gain 1 energy per waste. Not very efficient.
Considering it'll also get you 0.05 pwaste per waste!
But in the programming language, you'd actually gain 2 energy per waste, and lose 1 energy per waste that you attempt to convert.
So if every cycle, you try to turn 100 waste into 100 energy, and all you really get is 1 waste per cycle, that's 99 energy you're losing. Per cycle, even!
That means that you have to be smart about converting waste. Which also means that not every bot can do it successfully, and only a specialized bot should attempt such a lifestyle.

14
Specialization, Metabolism, Digestions and Env Grid / Photosynthesis
« on: February 23, 2005, 10:39:19 AM »
(We need longer topic descriptions.)

Ahem.

Photosynthesis would be a method of spending some energy, to get some energy back for converting things.
You could have to specifically choose what you're going to convert, or maybe not.

(By converting things, I mean converting body, waste, or anything else that can be turned into energy.)

Before I go on, I assume that converting something into energy would cost a number of energy equal to the amount you're converting. (10 body into energy would cost 10 energy.) (As another assumption, unless you're converting waste (which will generate plenty of permanent waste for you), you should gain this much in waste as well.)
But with this method, you can, provided you receive enough sunlight, expend even less energy.
To use photosynthesis, you'd basically set a variable called .photo.
This would be deleted after use. I'm not sure how this would work programming-wise, but it might require the use of a variable in which conversion costs would be added to this, and then later on in the cycle, it would be taken from .photo and then from energy.
Of course, you don't simply gain the energy you put in .photo.
Actually, the program'll read the value stored in .photo, and take this much energy from you.
Only afterwards would it limit it to (Body/50) or something like that.
After THAT, it would then be multiplied by how much light you're receiving (or something.)
Of course, rather then strength, once multiple types of energy storage are in, it would use a size-type number. (That way bigger bots can photosynthesis better, while smaller bots can fight better.)


If I'm wrong about photosynthesis, please tell me. But as far as I know, this is the basis of how it works. (And we shouldn't make DarwinBots TOO complicated. :P )

15
Bugs and fixes / "Toggle Video Display" bug
« on: February 22, 2005, 11:53:57 PM »
When you have the video display turned off, and you start a new simulation, it'll turn back on.
But the button'll look as though it was still off.
It's mostly just, however, a graphical glitch. Nothing too major.

Pages: [1] 2