Darwinbots Forum
Code center => Bugs and fixes => Topic started by: Greven on October 02, 2005, 06:17:23 AM
-
I cannot start a simulation, without all the bots die in a flash of second...???
It seems no stable population can be reached... This is tested with different bots.
-
I used Dominator invincibalis for my "okay, it's still workin, right?" tests.
And as always, check your settings in all the tabs. And what do you mean "no stable population"?
Specifics, specifics!
-
Really! I have tried numerous of different species, and I cannot get a sim working. The bots di out EXTREMELY fast!!?? Only when I put their start energy at 32000, they manage to stay alive a little longer. Even the top-notch tie-feeders cant live very long, even when I make fiction etc. as low as possible!
-
I'll double check the code I have to see if I can come up with a reason why. You have double checked using Dominator invincibals, right? Since I specifically said it was supposed to work?
-
I will just try with Dominator Invincibals again, I just at dinner with my "parents-in-law..."... so a little later!
-
I have checked, and it seems to work, although not very good, they just sits and spins on the spot...???
The gene activation screen doesnt work either.!
NO BOT with only the shooting capability can survive, even under the most farvorable conditions...
-
Also it seems, like Shvarz pointed out in the suggestion thread, that the default swimming factor is 0, which could be some of the reason, now Dominator is a little better, when it is changed to 80, but still not very efficient...
Also now only with ??? (around 250 I think, look at the attached image, which shows that the count of veggies and bots, and total objects is outly out of function.. ;)) I only get 1 (!!!!????) cycle/sec!!!! This is very slow, also compared to the old sim. It seems that you really have removed all optimization in DB now!
(REMOVED OLD ATTACHMENT AND ADDED NEW ONE, THE OLD ONE WERE IN GIF, NOT JPG)
-
"Insert bot" button does not work - there is nothing in the drop-down menu next to it.
-
I'll double check some other bots, see what I get. It could be something screwy with how I created the patch.
Given Greven's indications that interfacing with the DLL is too slow, I may just drop it all together, which would certainly make creating patches easier...
In the mean time, feel free to edit the source and shortcut the InvSqrt function with a regular old 1/sqrt, or whatever you please.
I did remove alot of the optimizations in DB. Originally, I had some quad tree things going on, which were supposed to be really fast. And they were. But they had a bug in them I couldn't sort out, so I commented them all out and replaced it with really simple, O(n^2) code.
-
I had a F1 settings sim with Dom Inv run just fine at home, so it may be the version everyone has. I'll double check it, probably post an upgrade today or tomorrow.
-
Are you sure DB is O(n^2)? Though I havnt checked it, but it would with a quick glance at the code be O(n^3) maybe?
-
Why O(n^3)?
I'm mainly talking about the vision code, which is the bulk of the processing of DB. In that, the simplest way is for every bot to check every other bot, which is O(n^2).
-
Yes thats right, but when using big O notation, you should write "the worst case scenario", which in my opionion is O(n^3).
-
I still don't see why it would be O(n^3).
If you have n bots, and add one more, you're adding n+1 new calculations to the mix (technically more like 2n, but either way...). That's O(n^2) I believe.
-
Havnt you studied Computer Science?? Well to my knowledge it is not so simple as you state. But wtf, it doesnt matter really. What matters is the actual speed, not some academic discussion on the topic.
Try google "optimization in Visual Basic", if you havnt done it already, you can find some interisting article to speed VB up. You can also find programs, which will help in optimizing the code further (something like VB WATCH) finding key areas which takes the most time etc.
-
Yeah, I have a profiler, so I can find what calls take what amount of time, etc. I didn't like VB watch much, so I went turbo powered and use Intel's VTune.
-
Just to beat a dead horse:
The simple, unoptimized algorithm is this:
For x = 1 to MaxRobs
For y = 1 to Maxrobs
check if bot x can see bot y.
Which is clearly O(n^2).
Computer Science is my minor. I've taken everything but the algorithms course. But don't think I don't know a thing or two about algorithms. Especially in this regard, since I've put in 100s of hours to streamlining this vision process.
Using kd-trees, you could make this into O(log n). Which is what I'm sorta looking into. Unfortunately, kd-trees must be balanced to operate correctly, and rebalancing a kd-tree can take O(n log n) time.
If such is the case, other methods might prove better, such as fixed size space partitioning Carlo suggested a while ago. Which is what I ws investingating in 2.4. You can still see the code I commented out. It's quite streamlined, and highly messy. But fast. You must admit it's fast.
Don't lecture me on theoretical computer science. I am all on top of that. Rather, it's the limitations and quirks of VB that are throwing me for loops.
-
Sounds to me like Greven is from cosmicrift...
-
Could someone please post the new sysvars flie up? It doesn't seem to be installing correctly for some reason...
Everything else is there, but the sysvars aren't making a showing.
-
I wonder if we could use some sort of external database for Bot X,Y coordinates then send a simple query to it that returns only those bots within a certain range.
Could work real well for collisions and vision.
I know some database queries can be slow though so it might not really help much.
-
Could someone please post the new sysvars flie up? It doesn't seem to be installing correctly for some reason...
Everything else is there, but the sysvars aren't making a showing.
No new sysvars. Just use your old sysvars file. I don't think there are anyway...
-
I wonder if we could use some sort of external database for Bot X,Y coordinates then send a simple query to it that returns only those bots within a certain range.
Could work real well for collisions and vision.
I know some database queries can be slow though so it might not really help much.
But you have to ask how the database is going to do that query search. At some point, you have to deal with the physical task of finding the neighbors within a certain range.
-
Yes I know that. I guess it just depends which program is able to perform the query faster. To be quite honest I don't really know how fast a database can actually do it.
-
Back to Greven's initial problem:
Turns out that Translocation mutations are broken. That was alot of the slowdown and problem with bots dying. Each time a bot reproed it's kid was having like 300 mutations. No wonder the bot was dying!
The only mutations I'm positive are working right are Point Mutations, Copy Error Mutations, Delta Mutations, and Insertions. Even then there might be some minor errors. But I think those are stable.
-
Turns out that Translocation mutations are broken. That was alot of the slowdown and problem with bots dying. Each time a bot reproed it's kid was having like 300 mutations. No wonder the bot was dying!
Yep, this was what I was seeing. Tons at once.
Had a major slowdown running Din and One in F1 mode. Not sure of where the problem lies...
On a positive note I saw that walls appeared to be working perfectly. I like how they don't appear to be oddball bots anymore, slowing down the program. I really like seeing different objects in the bots world, I think walls are a great start.
-
Hmm... I don't think I ever touched the walls code...
Now I'm going to have to give it a look see.
-
just tested 2.4 also was shocked when the bots diedlike flies ^^
-
It's a beta. Just to give you a taste :)
-
Try turning off mutations in the mutations panel. That should stop them from dying. If it doesn't, then it looks like I have some real bugs to hunt down.
-
Din seems to be relativly stable still there are some oddities with Tf but otherwise it's okay. Um... The One absolutly sucks now. It seems to move forward in a single direction doing nothing... I have no idea where the problem lies. I have trouble figuring out my own, let alone something like that. :)
-
Hmm, I don't know. The One is like a blob of incredibly tangled string, doused in urine.
I don't want to even touch it, let alone figure it out.
A thorough bug testing in 2.4 needs to be done. Things like checking poison, venom, etc, etc. This means both in code, and in the program.
-
hm is .sharenrg damaged? my sharefeeders do not feed
-
It shouldn't be (not working), but it isn't impossible (that it's not working).
I wonder if ties still harden...
I'll check it out.
-
Hmm, I don't know. The One is like a blob of incredibly tangled string, doused in urine.
I don't want to even touch it, let alone figure it out.
A thorough bug testing in 2.4 needs to be done. Things like checking poison, venom, etc, etc. This means both in code, and in the program.
Know how you feel about The One. :)
I can go through and check for bugs in the program.
-
That would be very helpful. I know viruses aren't working, along with delgene. But I'm not sure how shot and tie feeding are working anymore. Especially since I added that code where bots can fire a powerful shot and have it decimate another bot, then keep travelling...
-
Especially since I added that code where bots can fire a powerful shot and have it decimate another bot, then keep travelling...
That one is easy :) Already seen that working out pretty well. I'm going to have to keep my bots further away from the food though, they keep accidentally shooting their opposite number.
-
"Emperor" has been been spelt wrong, in case anyone hasn't noticed.
-
:P
OK I've changed it now.
Fussy sod <_<
-
A few bugs
1. when robots are hit by a -1/-6 shot they are not always shooting back nrg shots
2. the squigly line inside the bots doesn't seem to change size with the bots
3. the gene activation panel is broken, so you cant tell what genes are activating
4. angle is broken the program doesn't seem to interpret it in the dna
-
A few bugs
1. when robots are hit by a -1/-6 shot they are not always shooting back nrg shots
2. the squigly line inside the bots doesn't seem to change size with the bots
3. the gene activation panel is broken, so you cant tell what genes are activating
4. angle is broken the program doesn't seem to interpret it in the dna
1. Hmm... I'll look into it. Is the original -6/-1 shot disappearing?
2. Yeah, this is a tricky one I haven't been able to unravel.
3. Yeah, I was going to replace it with better bot debugging controls soon, so I was too lazy to fix it.
4. like *.aim? or the DNA command?
-
1 im not really sure what is going on sometimes it does seem to be working but most often its not
4 the function angle
so *.refxpos *.refypos angle .setaim storeis interpreted as *.refxpos *.refypos 0 .setaim storeit just doesn't seem to recognise angle anymore
-
The command angle... Let me look up the code and see what's happening...
-
This is not really a bug but: I cant find mutation rates for mutation rates. And were does it explain how to use the 95% things.
A real bug was indeed found, First Bots burth ties stratch like crazy , on a 800x600 if you actualy get a ruler it will be two inches.
-
Before The Program Ran out of memory , I had collisions that worked this way: A robot goes half way through the veg before the collision is registered; And I had Robots that were not getting any energy. Poor me with my 256 dumbass.
Yep that evil vb has ran out of memory bug happend.
-
Collisions work like this:
Imagine the bots are giant mashmallows. You can squeeze two marshmallows into the same space, but if you let go they'll unsqueeze and push apart. That's what the bots are doing. It's like each bot is a damped spring. Their collisions are quite "soft".
Mutation of Mutation rates are called Delta Mutations. (Delta after the greek letter that looks like a triangle, and is used in physics as notation for "change in".)
The 95% things require some basic understanding of statistics. Lots of data falls onto a bell shaped cuve. 95% of that data generally falls between 2 standard deviations from the mean (average).
Thus for length, if you had a mean of 5 and a standard deviation of 1, 95% of generated length values will be between 3 and 7, with more values clumping towards the 5 and less towards the 3 and 7.
A std dev of 0 produces all identical values around the mean.
Are you sure it's not that you need to buy a computer with mroe RAM? How much RAM are you running, anyway? When the env grid is added, it will take another 20 megs atleast. This is nothing on new computers, but if you're running a 486 with 40 megs of RAM...
I think I forgot to change ties to snap when they get too long.
-
There is somthing wrong with the collisions when the program runs out of memory, otherwise they work fine. Its the evil vb ran out of memory bug. its 256MB RAM (ram name is dumbus)
Otherwise the collision work perfict.
I love it when a robot only has 600 energy , it looks like a little dot, the only way I know its there is because its skin is sticking out ( witch is in a way another bug: the skin does not get resized), I prefer marking them with cross hairs better. If we don't mark them at all then no one can see them. They will be pixels on the screen, how the hell do you select that?
Delta mutations - I like that.
-
Delta mutations and Point Mutations occurr independantly of reproduction.
That is, there's a chance each cycle.
-
We still get ties stratching across the screen due to robots incorrectly jumping from one side of the screen to another. With big fat vegs you also see a lot of blinking on the sides for all the movment going on. That code needs a more realistic model in the future , we talked about this on its own thread somewere.
-
Yeah, it needs to be worked out so torroidal sims are really torroidal. But that invovles some ugly math in alot of places.
-
I pinned it down the program running out of memory after I restart a simulation twice... This might be a huge problem for me in the future, my ram is fine...
And don't forget to fix the skin and make small bots easyer to select...
I gtg.
-
You can always zoom in. In fact I'd encourage it.
Sounds like the program has a memory leak.
I can't figure out the skin bug. Any who wants to show their worth as a programmer should totally isolate the function and fix it.
-
hmm when I make changes like disabling mutation or gravity they simulation tends
with bots that do not move or anything else, even ,more if I restart the simulations.
Ah by the way is there a changelog what new in 2.4 ?
-
There was a changelog, but the changelog was getting so long I abandoned it.
Assume everything is new. Then ask specific questions somewhere and I can remember if I changed that or not :P
Or you can get The windiff ignore capitals program on the FTP and compare source code between 2.37.4 and 2.4. (Haha, have fun :P)
Your physics settings are probably causing bots not to be able to move. Open up the "advanced physics" panel and read me back all the sliders' values, etc.
-
^^ to know all the commands I can use would be good enough for the start.
I suppose if nothing is set, the settings are random?
Well cause I tried only with zero gravity.
with all kinds of fluid and all kinds of solids.
Is the rest random enough to szop movement in so many cases?
oh and when I said nothing I also meant the do not shot ties.
hmm I tried to use another bot, since I remembered that other bots behaved different and when I changed back the problematic bot coudl do something again.
Bye the way usally first the unlearn to tie before they unlearn to move.
-
Some values are inherited from the old 2.37.4 physics page, some are set to 0.
What's your fluid set at? I've noticed "thick fluid" is about impossible to move through.
I'm trying my best to get the wiki updated.
-
hmm strange different bots behave different on this matter.
Hunter seems to be immune against it while my bot niemand(currant test object for surrounding strategy) is quite weak against that effect:
Well I only wanted to show that in my eyes they programm behaves so random.
viscosity 0,01
bang efficeny 80%
all other 0 zero gravity
all other random
(just notice that mutations always seem reseted on enabled when I look into it,
mutation rates Button:all enabled-->all disabled right)
(just for the interested)
improved version moved to Bottavern multibot theories
-
I can't debug bot DNA, makes my head hurt. That's sort of funny, isn't it. :P
-
I did not want you to debug it ^^ just thought you might want to try the bot out for fun. Oh I edited the above post, put in my settings.
-
I'm in the library, but I'll bring a floppy later and copy it to see what it does...
I'll check the mutations page, I think I've noticed the thing you're talking about.
-
The Energy Proportional to robot size is nice and all. But in some ways it is too impractical and sertanly not realistic.
Lets say you have a robot with 32000 energy , and another one with 10 energy. The one with 10 energy ends up being a cell to another cell. We just did celluler strinking ^ 2. Zooming on that is just too impractical even if the zoom was to infinity (btw zoom is kinda week right now due to the limit witch needs to be adjusted too).
A real cell has tissues it has to sustain independent of its energy. A real cell can build up in pressure as well. So I prepose instead we use somthing like size = N + ScurveEquation were N is the tissue every cell has and ScurveEquation instead of liner is a pressure effect.
ex:
Private Sub Form_Load()
ScaleMode = 3
Show
For x = 0 To ScaleWidth
o = (ScaleHeight / ScaleWidth * x) * 0.2
Max = ScaleHeight * 0.2
'begin: shows you how mutch I hate plotting
y = (1 + 100 * 1.1 ^ -o / 10) / (1 + 50 * 1.1 ^ -o / 10) * ScaleHeight * 0.5
y = y * 2.1 - ScaleHeight - 30
'end
Line -(x, y)
Next
End Sub
Another serios problem (this it turns out has nothing to do with the momory overflow) is that the robots stop getting energy from the plants after a while. Run FB in F1 settings, see what I mean. dont forget high mutation rates.
I can't even find were the size of the robot gets related to the skin, I am pritty sure it's the problem with a memory leak because it is very rear.
-
It's not vegs get nrg proportional to their nrg. It's vegs get nrg proportional to their body. And body is the only thing that's effecting radius of a bot at the moment...
Uh, are you running it with high mutation rates? Cause that could be a good reason why it's not working.
I can't even find were the size of the robot gets related to the skin,
It probably doesn't, which is why skins aren't scaling to bots.
I am pritty sure it's the problem with a memory leak because it is very rear.
I doubt it's a memory leak problem, and what deoes "very rear" mean?
-
rear = not often
I don't care how its related , its just not realistic and a pain in the @$$ , run my curvy code when you have a chance. You will note that the values do not biggin at zero, thats the way I want it.
-
Yeah it's realistic! Plants gain nrg based on their surface area. In DB surface area is related to body.
And if you don't like it, you can just go back to the nrg/veg/cycle. That's an option too.
Lets say you have a robot with 32000 energy , and another one with 10 energy. The one with 10 energy ends up being a cell to another cell. We just did celluler strinking ^ 2. Zooming on that is just too impractical even if the zoom was to infinity (btw zoom is kinda week right now due to the limit witch needs to be adjusted too).
A real cell has tissues it has to sustain independent of its energy. A real cell can build up in pressure as well. So I prepose instead we use somthing like size = N + ScurveEquation were N is the tissue every cell has and ScurveEquation instead of liner is a pressure effect.
And here's why the above makes no sense to me:
"cell to anotehr cell"? What do you mean? Do you mean that the cell reproduces? Becomes part of a multibot?
"cellular strinking ^ 2"? What is strinking? Why are we squaring it?
"zooming in..." are we talking about the apparent size of the vegs or the nrg they're getting? Because the two aren't related, and I thought we were talking about the latter.
"A real cell has tissues..." first statement you've said yet that I understand and agree with. Which is why the 2.4 I'm releaseing later today will have a "cost per body" you can set.
"A real cell can build up pressure..." No, they can't. Well, not really. They do have a kind of osmotic pressure they have to contend with, but this is quite different from "pressure" in the normal sense of the word. In the normal sense of the word, we think of compression... Anyway, let's assume you mean osmotic pressure.
"size = N + ScurveEquation were N is the tissue every cell has and ScurveEquation instead of liner is a pressure effect."
1. I don't think you understand why bots have the radius they do. A bots radius works like this:
4/3 * pi * radius ^ 3 = volume of stuff contained in cell.
The volume of a single body point is defined to be 905 cubic twips. This was chosen because this way bots with 1000 body are the same size they were before.
2. "size" is ambigous! Do you mean: volume, radius, or diameter? Or maybe surface area?
3. "ScurveEquation instead of liner is a pressure effect." - instead of liner? What liner? What is a liner? Do you mean linear?
4. I don't understand what the code you quoted me is supposed to demonstrate. In fact, at this point, I'm not even sure what we're talking about anymore. I thought at first you were having issue with the nrg per body thing, then I thought maybe you were talking about the apparent size of a bot when you zoom in. Now I have no idea.
-
blablabla I just wait until other get sick of it, or not.
At any rate I hate it.
-
Hate what damnit! I don't even know what you're talking about anymore! (I said that at the end of my post. You're not even reading my posts anymore, are you???? ARE YOU?? No wonder we can't seem to communicate!)
Do you hate: (check all that apply)
1. That vegs can get energy based on their body points instead of just constant values for existing?
If so I'd like to point out that the first option, "nrg per veg per cycle" is IDENTICAL to how it worked in 2.37.4.
2. That all bots have a radius that's directly proportional to their body?
3. Something else?
-
Warning really really bad english, do not read:
I love the invisable dots floating arround on the map and taking up memory. The imanse pleasure a user gets when trying to deselect a robot and clicking on one of thouse dots by accesdent, its so mutch exsitment.
A cell is ONLY composed of energy, it is not composed of membrain, nucleos, and the other little stuff. All that makes up a cell is energy.
The mambrain is not stratchy - no - its nanothecknology, it expends directly proportinaly to how mutch stuff is inside the cell. Its the best matirial in town. A feder falls on it and it stratches with the feder.
Even an air ballon, the more air it has the harder it is to blow in it.
There is NO parant child relationship going on in smexe. Instead It really works like this:
Create Random Slab of code ----> Run the code.
Change Random Slab of code ----> Run the code.
The code can distroy stuff, but no nothing prevents the same slab from mutating further.
I call it the slab of death program. Yea I would be scared to run Numgils virson of smexe too.
-
You almost got it actually! The bots' membranes are infinitely stretchy.
A cell is ONLY composed of energy, it is not composed of membrain, nucleos, and the other little stuff. All that makes up a cell is energy.
Replace energy with body, and that'd be 100% correct. Or that's how the program is at the moment. I'm later going to add mass and volume for nrg, poison, shell, etc.
The mambrain is not stratchy - no - its nanothecknology, it expends directly proportinaly to how mutch stuff is inside the cell. Its the best matirial in town. A feder falls on it and it stratches with the feder.
exactly. Bots are "ideal" creatures in many ways. It keeps alot of the math simple.
So what you're really at issue with is being able to select a bot? Pause the simulation, zoom in, and you can select it quite easy.
-
I think you're right about the ties not snapping.
The giant MB blob plant I made would pass one edge, part would appear correctly at the other edge but also a group would remain connected at the bottom with ties across the whole screen. The two groups would spring back together again only to continue the same cycle. I'm guessing the larger group passing over the edge was about 50 bots, so the "large MB" splitting code was working correctly, the ties just weren't snapping.
-
Yeah, I forgot to fix that...
Eventually I want ties to cost something to form, and then have their maximum length be a function of their radius, which is a function of the total volume of stuff put in to construct them.
-
hmm I just noticed that when amoving bot reproduces both seem to have the same inertia, which leads to a building up of overall movement energy increasing flying around objects.
Oh it also seems I forgot "end" in the bot text that was weak against doing nothing
maybe that was one of the reasons
hmm are you guys able to see the gene activations? Cause its not working in 2.4 for me.
-
bots, dont you mean rare and not rear?
-
hmm I just noticed that when amoving bot reproduces both seem to have the same inertia, which leads to a building up of overall movement energy increasing flying around objects.
Oh it also seems I forgot "end" in the bot text that was weak against doing nothing
maybe that was one of the reasons
hmm are you guys able to see the gene activations? Cause its not working in 2.4 for me.
Well, they both have the same velocity. The total momentum of the one and then the two is constant.
Remember, when a bot reproduces the baby bots have less mass. Momentum = velocity * mass.
Gene activations are broken. I'm going to revamp Bot Debugging big time, so it seems sort of silly to add thm back in...
-
rare, yes.
I hate my life , I think the bots found another loop hole in my evolution methods , its been 3 bloody weeks, now this happens?
I am still ns , so hang on , nothing to post yet. Kinda Ironic is the fact that the robots in this problem behave like geeks.
-
has first bot even evolved any abilities at all?
-
Well, I am not sure because at one point it jumped from 70 max population to 80 max population and I got exsited. I however did not see any notecable differences. It makes quicker moves when it hits things thats about all for now.
-
Found a bug in how the Beta version processes dna. It might be just the commands: .tieval, .tieloc, .tienum, I ran out of time to test the rest of the commands. Did manage to get Tie feeding working properly with this so I know this method works for that much. (Honestly if I hadn't been trying at making this work again I never would have seen the pattern)
Here's what I found to work:
A a B store
A = stored value
B = storage location
a = "unused" value
The "a" appears to be un-used but it's hard to be sure. I had a -1 -4 .tieloc store and the buts "properly" fed on nrg.
In addition to this store doesn't appear to clear the stack properly instead the storage location could be re-used as a storage value latter on.
Strange :blink: :wacko:
I'm praying that it's been fixed already and this is a moot point.
Oh yeah, the plants whose waste is taken appear to gain straight permanent waste. Yes it all hurts my head too :wacko:
Warning Off Topic
Who the H%$# is this "Retard" over at the wiki?!! I go to check recent changes and it looks like he messed a bunch of stuff up making Nums redo them.
:shoot: :pokey:
-
Yeah, our board got vandalized! I don't know wether to celebrate or steel myself against worst. I mean, for someone to spend 5 minutes to vandalize something means they care, right?
I'll have to look into the DNA code to check that everything is cleared properly. It should be, since I just used the obvious stack operators pop and push.
-
I heard about wikipedia having these types of problems but thought it'd be awhile until we had to deal with anything like it. :blink:
Umm...wiki shutdown. Said something about exceeding maximum number of links(100). :sad2:
Got this also:
Fatal error: Call to a member function on a non-object in /home/content/D/a/r/Darwinbots/html/WikiManual/includes/ObjectCache.php on line 409
Ahh!!! I hope this is just a really odd coincidence. :help:
-
Damn. I hope you're right, and it's just coincidence.
-
Hello! Discovered the following in version 2.4 Alpha. First a crash that caused the following error message: 'Error. Division by zero. Saving sim in saves directory as
error.sim'.
Then I found out that lots of settings don't get saved when I try to save my settings. Don't know if it's a bug or if it just haven't been implemented. Also I found that sometimes the day/night cycles don't change as they have been set.
It also looks like the simulations all acts the same. I've tried simulations with the Triangularis bot and nomatter how many I start with allmost everyone dies until there is just a few of them left. That's what the number says anyway, though that seems like it doesn't give the right information. Most of the time I end up with a bundle of bots spinning at a fixed location while the 'Total bots' indicator only shows a few bots, like 2 or 4. Uaaaah! I want this program to work!! Sob-sob. :(
-
Multi-bots really don't work so well in 2.4 yet. A bunch of stuff simply isn't implemented yet and others kinda just uh, how can I put this? Don't work! :D
Stick with 2.36 or 2.37 to get an idea of what is possible in the game. 2.4 will kick ass when it's finished but there's a way to go yet.
-
I'm actually porting 2.4 to C++ right now, and uncovering all sorts of bugs and things that could be done better along the way.
Older bots don't work well in newer versions. Try something safe and simple as a "does my program work at all" bot. Animal Minimalis is a good choice. He's in the beastiary.
-
Hello! Discovered the following in version 2.4 Alpha. First a crash that caused the following error message: 'Error. Division by zero. Saving sim in saves directory as
error.sim'.
Then I found out that lots of settings don't get saved when I try to save my settings. Don't know if it's a bug or if it just haven't been implemented. Also I found that sometimes the day/night cycles don't change as they have been set.
It also looks like the simulations all acts the same. I've tried simulations with the Triangularis bot and nomatter how many I start with allmost everyone dies until there is just a few of them left. That's what the number says anyway, though that seems like it doesn't give the right information. Most of the time I end up with a bundle of bots spinning at a fixed location while the 'Total bots' indicator only shows a few bots, like 2 or 4. Uaaaah! I want this program to work!! Sob-sob. :(
Zip and add the error.sim as an attachment or mail it to me at Numsgil2002@yahoo.com.
Dollars to donuts you have your nrg/cycle that vegs get too high. It's in the second panel in options. Near the upper right hand corner. It should be set to like 3 or 10 or something like that. I bet you have it set to 1000000.
This is because what that value represents has changed over the development of the sim, so if you're doing 2.1 settings files, you're going to get really weird errors.
PLEASE PLEASE PLEASE check. Provide a screenshot if you wish that shows the second panel in options.
The settings should all save correctly if you're using 2.4.0. If you're using 2.4.Beta, then not all will save correctly.
-
1000000 = The veggie got a vitamin injection until it exploded
0 = The veggie was put in a black box with distilled water.
:P
-
I'll probably just make it so that the sim saves the nrg/cycle thing to another spot in the settings file. Every new user seems to have trouble on this point. I don't even know how many get disgusted and give up.