Darwinbots Forum
Code center => Bugs and fixes => Topic started by: EricL on April 18, 2006, 11:53:23 AM
-
Is there anyone out there still on 2.37.6? I want to know why you havn't moved and I want to address any issues which prevent you from moving to 2.4X in the next release (2.42.3). Unforseen issues aside, 2.42.3 may be the last VB release (at least from me) as I want to move over to the C++ fork and start working with Nums on the next generation code. So this next release needs to be great for everyone.
Tell me what you need, what you miss, etc. I will try to make it work. A can't really entertain new features of any significant size, but tweaks and bug fixes and making anything that worked in 2.37.6 work in 2.42.3 are all fair game. A couple of things:
I'm pretty pleased by the stability of 2.42.2. I have several million cycles on my various sims on this release and I've yet to hit a run-time crash. So if you do hit a run-time crash in 2.42.2, don't just shrug it off! Please please please let me know and send me the error.sim. I wantto fix any remaining mainline crashing bugs in 2.42.3.
Internet Organism Sharing will be working in 2.42.3. I have added authenticated FTP support, so now so we can share via password protected FTP sites. I will be offering up an FTP location for this on my own site if we don't want to provide one on the main server, but it will work with any FTP site.
I also plan to take a hard run at getting leagues working in 2.43.3. No gaurentees, but I have scheduled some time for working on it.
If there are other things besides these which prevent you from moving, let me know now please. I plan to drop the release at the end of the month or the first week of May.
Edit: 2.36->2.37.6
-
I don't get it either. I think you could as well remove all those old buggy versions from the server to save space and prevent anyone from downloading a bad version by misstake. The only thing wich I think worked better in 2.36 was those latest issues I've mensioned, with the numbers on the bottom of the screen getting changed when clicking change in the GUI, and day/night cycles seemd a little more stable in 2.36. Eh...wasn't that 2.37? Anyway, everything else is better in the latest version. I think there is very little left to fix.
-
I think it's good to provide access to older versions as a kind of history archive. In 100 years people will want to know that there were a dozen releases of 2.4
-
OK, here's what I want to see fixed:
(1) Viruses don't seem to work at all
(2) Collision detection doesn't work at medium to high speeds
(3) .fixang, .fixlen and .tielen1-3 don't work
Sharing doesn't seem to work either
Here's an example to demstrate bug (3):
I've attached a simple SG batterybot that is supposed to grab a veggy that you put in front of it and drain it's energy using sharing. It doesn't move or fight etc. - all it does is grab veggies that come near to it's eye5, unfix them and put them behind it using fixang.
In practice, in 2.42.2, it grabs the veggie, unfixes it, but can't move it behind itself, change the length of the tie, or share with the veg.
Other than those 2.4 seems to be a very stable release (much more stable than 2.37 where mutations are concerned) with some great new features. Fix the above and I will transfer across permenantly
-
Strange that sharing doesn't work for you. I got a successfull population with shvarz herbivore. They sucked the veggies dry and reach a huge population.
-
Collision response might be a little hard to fix without transfering 2.5's physics into 2.4. Possible, but might be alot of work.
for(int x = 0; x <= MaxRobs; x++)
{
if(rob[x] != NULL && rob[x]->AbsNum < this->AbsNum)
{
Vector4 normal = rob[x]->pos - this->pos;
float mindist = this->radius + rob[x]->radius;
mindist *= mindist;
float currdist = LengthSquared3(normal);
if(currdist < mindist)
{
//UPDATE CHANGES IN VELOCITY
const float e = SimOpts.ElasticCoefficient = 0.5f;
const float M1 = this->mass;
const float M2 = rob[x]->mass;
normal /= sqrtf(currdist); //normalize normal vector
Vector4 V1 = (this->vel * normal) * normal;
Vector4 V2 = (rob[x]->vel * normal) * normal;
Vector4 V1f = ((e + 1.0f) * M2 * V2 + V1 * (M1 - e * M2))/
(M1 + M2);
Vector4 V2f = ((e + 1.0f) * M1 * V1 + V2 * (M2 - e * M1))/
(M1 + M2);
this->vel = V1f + (this->vel - V1);
rob[x]->vel = V2f + (rob[x]->vel - V2);
}
}
}
There's the function that handles the velocity changes of collisions. You might be able to put it directly into the VB source (you'll need to change syntax obviosuly, and handle vector math iwht functions instead of operators).
-
If it's going to be a lot of work, then I'll settle for (1) and (3)
-
OK, I said this before and I'll repeat it now. I have been against 2.4 VB version from the very beginning (Nums knows this, but he does not care). It is very different from 2.37.6 version and does not represent an upgrade, but rather a totally different program. It does not comply with backword-compatibility required for a version to be called an update. Bots from one version don't work well in the other. So by having a 2.4 version on the server we are confusing people into beleiving that 2.4 is a valid update, while in fact it is not. Most of discussions on this board (especially the old ones) are related to 2.37 version and don't necessarily apply to 2.4. We've seen people come and get confused by this.
In my view 2.37 is a more or less finished product and should be presented as such, while the new stuff should be explicitly called new stuff and be distinguished from anything that was done before.
I am using 2.37.6 and I will be using it until the new C version of DB comes out (maybe even after that). And I think everyone should do that. So I would say: Why don't we delete the 2.4 version from the server?
-
I am still using 2.37.6 as it is now the most stable version available. We all went to a whole lot of trouble getting it that way.
I tend to agree with Shvarz that 2.4 isn't so much an upgrade as a whole new program without much in the way of backward compatability.
The leagues are still officially run in 2.37.6 ( when they get run at all) although if anyone wants to start up a new league for 2.4 then they should feel free to do so.
Generally I don't really like 2.4 very much. It's difficult to pinpoint all the things I don't like specifically but I just get a general feeling of it not being quite complete in the way that 2.37.6 is. Loads of stuff isn't working properly still and I don't really like the little diddy bots very much.
I also intend to stay with 2.37.6 and maybe even continue to build on it in parallel to the C++ version. (I am not now and probably never will be a C++ programmer. It's like an alien language to me)
I think of 2.4 as an unfinished and mostly abandoned project that quite frankly isn't worth spending time on.
If you all want to carry on and use it then that's up to you but I won't be doing so unless it gets a whole lot better.
-
It's not that I don't care, I do care. I just disagree.
A couple of minor things cause older bots to behave oddly, but that's hardly the first time it's happened in updates. When PY changed the eyes from being 45 degree scanning range to 90, most bots broke.
But 2.4 is still essentially in the same spirit as 2.3.
Compare that to what I'd like 2.5 to be when it's really done (and is given the 3.0 monicer). Most sysvars will be upgraded or discarded. Ties will work entirely different. -6 shots will be replaced with phagocytosis. Metabolism will be working at least a little bit. In every concievable way everything will have been taken one at a time and examined and changed. That's far more fitting for a 3.0 title than 2.4, where really the only major changes are DNA flow (being made less strict) and Phsyics.
-
The new C++ version 3.0 is definitely something that I am looking forward to seeing in a big way.
I just feel that 2.4 never really had the bugs ironed out before the C++ project was started.
Admittedly I haven't tried using the latest 2.4 versions that are being worked on right now. Then again I probably only get to run a DB sim about once a month lately. It is probably much better now than it was with all the recent work that has been done.
My issues are that most of the bots I work on these days use very complex behaviours such as my ant bots and various MBs. Those are the ones that don't work so well in 2.4 so rather than redesign them all from the ground up for what is effectively only a temporary stopgap between 2.37.6 and 3.0, I will continue to use the version that works the best with them until 3.0 comes along.
-
2.42.2
All versions before that.
-
-
I agree that 2.42 is quite buggy and the whole waste and body issue makes it harder fo bots to evolve from scratch, however the new commands for calculation like angle, distance, mod, and abs are something I really do not want to forego.
Note: does racial memory work in any of the versions?
-
I could never get racial memory to work or figure out where in the code it lurks, to be perfectly honest.
-
Wow. This is so... disillusioning. I suppose I should have done my homework before investing time and energy on something people are so strongly divided on. As a newbie, I assumed that there had been consensus (or at least tremendous community input) on the direction taken in 2.4 and that people lingered on 2.37 today only because 2.4 functionality was buggy or incomplete. That given sufficient stability, functionality and active, technical investment in bug fixing and feature parity by an enthusastic and technicaly capable party, the community would converge on a 2.4 derritive. I assumed there was a plan. I now stand corrected.
I had likewise assumed that there had been considerable community input into the feature set of the C++ version and that it was a no brainer that people would similarly move to that once it also acheived an acceptable level of feature parity and robustness. But given this thread, how can I not but question whether that is indeed the case?
Hmmm....
I have no interest in spending time on something people care nothing about. Yet, there are features I have strong personal interest in implementing, if only for my own enjoyment. Doing that off the 2.37 code base seems silly (to me) given the investment I have made in 2.42.X. I, for one, certainly do not consider 2.4 'abandoned' having spent the better part of the past month working on it. Those who do are welcome to continue to live in the past on a stagnent code base.
Similarly, while I assume Nums is a brilliant individual with tremendous vision, until it has gained significant community support (or someone can demonstrate to me that it has a high probability of doing so) I find my motivation for investment on the C++ code base at the present time highly diminished.
So for my part, I plan to continue to work on the 2.4 code base if for no other reason than my own edification until such time I get bored or the C++ fork is far enough along to attract my attention. If there is interest, I will continue to post releases and source code. I will also entertain and solicit bug reports and feature requests, including feature parity with 2.37.6. Any substative input people wish to give me towards this goal is of course, welcome.
-E
-
Well... I had expected more people to be interested in 2.42 now when so many bugs have been fixed. 2.42 has more features like costs for instance. I like that. I don't see why anyone whould like to use 2.37 where you can't load a saved sim. I know some of you have more than one computer where you can use one to run a sim endlessly. I only have one computer and I need to quit the program from time to time to do other stuff. It's not fun to run a long sim and then it will be gone just because you had to quit the program. PY said he didn't think that was important to fix.
I'm glad that you want to continue to work on 2.42, Eric. I'm also interested in trying out 2.5. I'm happy with the features that have been put into DB over time. Seems like most of us agrees with what should be in DB and not. I have allways thought that DB should assemble real cells living in a water as much as possible. I think DB behaves like that more than any other a-life program I've seen.
-
So for my part, I plan to continue to work on the 2.4 code base if for no other reason than my own edification
hi eric.'
I would have liked to see 2.37.6 be the program that continued to evolve ...
rather than the 2.4X ...
but ... I got no say and gotta play with what is dealt.
PY did a lot of work on 2.37.6 ... cleaning up many bugs. great.
and I appreciate all your work on 2.42.2 as well ...
so I continue to use both ... as tools to assist me in learing VB
programming more than anything else.
so I hope you do continue to evolve 2.42.X ...
and continue to allow me and others to benefit from your work.
great stuff you are doing. imo. thanks.
IF you are going to tweak it ...
how about taking a look at the King Bot feature ...
and how it determines King Bot.
Form1 function fittest and Function score Line 1241
Nums had a InvestedEnergy thing in there but had problems with it
and ended up setting InvestedEnergy to 1, elsewhere.
Form1 Function InvestedEnergy line 1300.
had some discussion with Nums in this thread:
Survival-of-the-fittest (http://www.darwinbots.com/Forum/index.php?showtopic=1127&hl=Invested%20Energy&st=15#)
messages # 18, 27, 28, 30, 34, 36,
I put it back in and it seemed to work for me.
see messages #41, 43, 45
and I was hoping to end up with a User Defined Selection Criteria window.
messages #47, 48, 49
in case you're interested.
thanks again for all the work ...
I for one do ineed appreciate the effort ...
and it is due to this that my interest in DB has been revived ...
as it seemed to have become rather stalled in place.
I had pretty much lost interest.
still great potential here.
thanks again eric.
-
PY said he didn't think that was important to fix.
Not exactly Testlund. I think you may be misremembering our conversations a little.
As I recall the problem was that I could never manage to reproduce your problem. 2.37.6 saves and loads absolutely perfectly for me. I do it all the time with absolutely no problems.
For some reason I have had a lot of trouble reproducing the errors that you reported while we were debugging 2.37.6. In general I couldn't make any of them fail and still haven't to this day.
As it stands right now I am unaware of any issues with 2.37.6 that would cause it to malfunction in any way. I understood that it was working for everybody now. (with the possible exception of Testlund)
-
Testlund is a magic bug finder. It's his gift
As I understand it the major issue with 2.4 is older bots not working because of the dynamic sizes. In reality, that was such a minor, one day effort it boggles my mind at the number of issues it raised. Sorry, I thought it would be neat
The fix I posted in the Bugs and Fixes forum for making bots see better in 2.4 should actually fix it so older bots work like they always did. Really and for truly.
The only other thing is ties, which are apparently broken because too much had been stashed in the tie physics routines which were discarded. That's not a simple fix but it's definately doable.
The only other issue I can think of is psychological barriers. Having so many buggy versions of 2.4 makes people subconciously assume any 2.4 derivative is buggy. That's part of the reason I stopped working on 2.4.
-
My thoughts:
What I like about 2.4:
- New mutations code. It is orders of magnitude less buggy than the mutations in 2.37.6 (which were the only slightly dodgy area of 2.37.6), and gives more options. Love the new 'point mutations'.
- New cost options
- New DNA features, commands and structure
- The bit that EricL added that shows how much shell/slime/body your bot has when you click on it to bring up the 'bot stats' window
What I dislike about 2.4:
- Some of the physics seems rather odd/different
- Ties are dead buggy
- Viruses don't work at all
- The new bot sizes are annoying. All my bots end up tiny and don't work well
- The 'bot sight' feature that shows you what the eyes see is annoying, but at the same time useful. If only you could turn it on and off ...
- Many of the bots I programmed in 2.37.6 die in 2.5, or don't seem to work as well (especially the ones that use ties)
At the moment, when testing combat bots, or bots I have programmed, I use 2.37.6. When doing evosims, I will usually use the latest 2.4, because I can't load saved evosims in 2.37.6 or else I loose all my mutations and the sim gets buggy, and also because I love the new mutations options, structure etc.
For programmed bots: designing them in theory is fine - the crunch is in testing them, and seen as 2.37.6 makes my bots act more like they're supposed to act than 2.4 does, I use that.
******
How long until the C++ version Num?
-
See, EricL, you fell the victim of the 2.4 name - just like I said some people would. Let me explain a bit more the situation with 2.4. When the program reached the level of 2.3something it was quite buggy. So at that point everyone got sick of bugs, but still wanted to get some new features. Which was not possible as you understand - new features always cause new bugs to appear. So the consensus was more or less to stop adding new features to 2.36 and concentrate on fixing bugs first.
Meanwhile Nums decided that he got sick of old code written by many different people and carrying tons of useless and un-understandable luggage from previous versions. So he decided to re-write the whole program from scratch, add major new features and at the same time switch to C. While he was doing some basics of coding the backbone of the program, he decided to make a test version based on 2.36 containing some of these newly proposed features, the idea being that some people would use it and give feedback and he'd learn from that and code these features into the C version. Why he decided to call it 2.4 I'll never understand. From the very beginning that version was meant to be just a testing playground with no future. And at first things were fine and most people knew about the status of 2.4. But then a bunch of new people showed up (you and some others) and they assumed that 2.4 is the version where things were headed. I tried to warn them, but I can only do so much. Besides, some people did not listen (I'm sure I warned testlund at some point).
So, here we are.
Now, almost everyone is for the new C version. But I see it not as an upgrade, but as a new product. So it will not cancel the existence or meant to replace the 2.36 version. Think of it in this way: I used to play Half-Life a lot, but some time ago Half-Life 2 came out. I play it, but I still keep the original Half-Life, because I still like that game and many mods that were made for it. So these two games co-exist quite happily on my hard-drive and in my heart. I see the same thing for 2.36, at least for some time.
-
2.4 I still argue is in the same class as 2.X, but it is quite different from 2.3X. That's what you get when it's several months between upgrades.
The C++ version at the moment is not in the same class at all, but it's nomenclature is misleading. It's not 2.5 as much as it's:
Darwinbots Extreme 0.5
Obviously I don't want to call it Darwinbots Extreme, hence the problem.
-
The only other thing is ties, which are apparently broken because too much had been stashed in the tie physics routines which were discarded. That's not a simple fix but it's definately doable.
I'm sure it is doable.
When it gets done to the point where my complex MBs can run in 2.4 then I might consider moving over.
Ties are a highly complex subject in DB. I have spent the vast majority of my time in programming DB, working with these pesky things in some form or other. Do you remember how the worked (or didn't work) in 2.11?
To Eric L
Wow. This is so... disillusioning. I suppose I should have done my homework before investing time and energy on something people are so strongly divided on. As a newbie, I assumed that there had been consensus (or at least tremendous community input) on the direction taken in 2.4 and that people lingered on 2.37 today only because 2.4 functionality was buggy or incomplete. That given sufficient stability, functionality and active, technical investment in bug fixing and feature parity by an enthusastic and technicaly capable party, the community would converge on a 2.4 derritive. I assumed there was a plan. I now stand corrected.
Yes there was a plan that was generally accepted. It was primarily to make 2.37.6 the default platform until the C++ version was completed. 2.4 was considered to be too buggy to make it a viable competitor for the default platform.
That doesn't mean that your efforts have been wasted on debugging 2.4. If you can manage to incorporate all the fixes and improvements that have been made to 2.37.6 since the inception of 2.4 along with the new stuff that 2.4 brought along. of course some of that new stuff is what is actually causing the problems
Don't get disillusioned by the whole thing. Your work on 2.4 is greatly appreciated. Believe me, I would have advised you to drop it much sooner if I believed that you weren't going anywhere useful with it.
Similarly, while I assume Nums is a brilliant individual with tremendous vision, until it has gained significant community support (or someone can demonstrate to me that it has a high probability of doing so) I find my motivation for investment on the C++ code base at the present time highly diminished.
Since Nums joined the programming team about a year ago (previously the team consisted of me only), he has injected a whole new level of enthusiasm to the project. Frankly it has been a bit hard to keep up with all his little projects within the DB framework during that time.
One of the unfortunate side effects of this explosion of new ideas is that DarwinBots has splintered somewhat over the last few months. 2.4 was his first shot at giving the existing program a major overhaul and during his involvement with that project, 2.3 progressed through several more stages of development in parallel with it such that 2.37.6 is most definitely NOT a platform from which 2.4 was created. The two programs have diverged in several areas which is going to make your job of integrating 2.4 into the DB stable of "accepted" releases, a little difficult. Not impossible but tricky.
The C++ version of DarwinBots is a MAJOR overhaul of DB and is most likely going to produce a program that is only marginally compatible with old robots.
That is not to say that it won't be a massive improvement over 2.36.7 in many areas. I fully support the development of the C++ version even though I do see it as possibly a whole new sim with only loose ties to earlier versions. What it will offer (probably) is such a big performance increase that it will be worthwhile to redesign older bots to take advantage of it. 2.4 does NOT offer such a quantum leap forward in technology to make it worthwhile IMO.
I view 2.4 as part of the process that Nums had to go through in order to get the inspiration and confidence to launch the C++ conversion. It was a stepping stone but never quite made it as a complete and stand-alone version.
If you can bring it up to scratch then great. If it still doesn't get to replace 2.37.x then no great loss. At least you have developed an intimate familiarity with DB which is going to be useful at some point.
As I said before, I intend to keep developing and supporting the VB versions of DB which will run alongside the C++ version. At present my chosen platform is 2.37.6. If you think it should be 2.4.x then convince me sufficiently to make me switch.
It will have to either be 100% backward and sideways compatible with all 2.37 versions.
OR
It will have to be so much better than 2.37.x that it will be worthwhile to assign 3 + years of complex robot developments to the garbage can and start over from nothing.
Keep up the good work and good luck.
2.4 I still argue is in the same class as 2.X, but it is quite different from 2.3X. That's what you get when it's several months between upgrades.
The C++ version at the moment is not in the same class at all, but it's nomenclature is misleading. It's not 2.5 as much as it's:
Darwinbots Extreme 0.5
Obviously I don't want to call it Darwinbots Extreme, hence the problem.
So call it DarwinBots C V0.5
or how about DarwinBots(The Next Generation)
or DarwinBots TNG V0.5 if you prefer.
I think DarwinBots 3.0 really won't do it justice.
-
Darwinbots: Electric Boogaloo
Darwinbots: The Motion Picture
DB3: Darwinbots United
Darwinbots: The Return of the Darwinbot
Darwinbots: The Revenge of the Darwinbots
Darwinbots: Judgement Day
Darwinbots: Return to Oz
-
Seriously though, it might not be a bad idea to think about a new type of nomenclature for the C++ version rather than just continuing on with the present number system.
Anyone else have any thoughts?
-
I'm open for a new title, but heck if I can think of one.
-
How about:
Darwinbots II 0.5
Darwinbots vC.1.0
Darwinbots C++ v0.5
Or even:
Darwinbots: Now with extra monkey
-
Not exactly Testlund. I think you may be misremembering our conversations a little.
As I recall the problem was that I could never manage to reproduce your problem. 2.37.6 saves and loads absolutely perfectly for me. I do it all the time with absolutely no problems.
For some reason I have had a lot of trouble reproducing the errors that you reported while we were debugging 2.37.6. In general I couldn't make any of them fail and still haven't to this day.
As it stands right now I am unaware of any issues with 2.37.6 that would cause it to malfunction in any way. I understood that it was working for everybody now. (with the possible exception of Testlund)
Yeah, I remember that now. My memory had gotten a little rusty. But because of this problem it felt hopeless to use 2.37 and 2.4 was too buggy at that time, so I gave up on darwinbots. Then Eric came along starting to fixing the bugs in 2.42 wich got me interested again. So IMO DB 2.42 has surpassed 2.37. If I understand it correctly those fixes will be implemented in the C++ version PLUS new features.
As Shvarz mensioned it was confusing with the difference between these two versions. It took a little while before I understood they were very different from each other. Now I have learned to master my sims a little better in 2.42 and it works fine.
-
My favorite neo-darwinist is probably Theodore Dobzhansky (http://en.wikipedia.org/wiki/Theodosius_Dobzhansky). How about calling the program DobzhanskyBots?
-
How about DarwinBots 2006 Plus?
-
Like the new Battlestar galactica we could just confuse the heck out of everyone and call it:
Darwinbots
My favorite neo-darwinist is probably Theodore Dobzhansky (http://en.wikipedia.org/wiki/Theodosius_Dobzhansky). How about calling the program DobzhanskyBots?
Now that's catchy.
We could call it:
LimarckianBots
-
Now that's catchy.
We could call it:
LimarckianBots
Except that we would then have to pre-select the traits that we want to select for
on another subject, doncha just love the way that this new forum software combines your posts tother when you post twice in a row?
-
Yeah, it's real nifty.
-
Erm ...
We should have some sort of notice to newbies on advice as to which version to install, which versions are in progress, possible stability issues etc.
One of the times I first care across DB I installed 2.4.A, thinking that a newer version would be better more stable. Of course, it was disorientating and full of bugs (especially bugs in viruses, which I happened to be dabbling in at the time) and I threw it into the recycle bin. I later realised my mistake and installed 2.37.6 and found it much easier to use as a total newbie.
I don't have anything against 2.4 but I think we should inform newcomers of the issues. 2.37.6 might be easier to begin on? Also, one newcomer was trying to make a tiefeeder, and ties are notoriously unstable in 2.4.
We should really have some sort of a notice to avoid confusion.
-
I had a notice up until about a week ago when 2.42 came out. No one seemed to read any of the little notes I have on the FTP
-
On a more serious note, I think DarwinBots 3 is a good well-descriptive name. DarwinBots 2006 is good as well, but it's more difficult to add numbers for updates to that (2006.2.12? Sounds like a date of release).
-
I don't have anything against 2.4 but I think we should inform newcomers of the issues. 2.37.6 might be easier to begin on? Also, one newcomer was trying to make a tiefeeder, and ties are notoriously unstable in 2.4.
The instructions are readily available and can be found in the "How do I get Darwinbots for myself" thread in the "What is DarwinBots?" forum
Here is a link to the threadhttp://www.darwinbots.com/Forum/index.php?...st=0#entry49485 (http://www.darwinbots.com/Forum/index.php?act=ST&f=12&t=12&st=0#entry49485)
I have just edited it very slightly. Most of it has been exactly this way for 6 months or more.
Obviously people aren't reading the introductory parts of the forum the way I expected them to.
Do we need to make it even more prominent?
-
Trim the FTP Wiki. Provide downloads for only the latest 2.3X, 2.4X and C++ releases with a paragraph for each (and the version with the installer). Put all the rest on a "older releases" page one link away.
-
Trim the FTP Wiki. Provide downloads for only the latest 2.3X, 2.4X and C++ releases with a paragraph for each (and the version with the installer). Put all the rest on a "older releases" page one link away.
Nice idea. Working on it ...
-
How's this:
New FTP (http://www.darwinbots.com/WikiManual/index.php?title=New_FTP)
-
I'm not seeing a link to older versions and tools, which would be nice.
-
I'm not seeing a link to older versions and tools, which would be nice.
Done
-
Hmm, now it doesn't feel any better than before when they were all on there at once.
How about a seperate page for tools and a seperate page for older versions and a seperate page for source code.
And go ahead and remove the links to the C+ version until I get something up and working, that should help it look cleaner.
-
I've neatened it up a bit. How about now?
Maybe we should move the source code onto a defferent page, and the older versions, tools and misc stuff onto entirely different pages?
-
Yeah, I agree Elite.
-
OK, I've revamped everything. You can get a link to my new FTP (http://www.darwinbots.com/WikiManual/index.php?title=Main_FTP) from the main page and can link to the sources (http://www.darwinbots.com/WikiManual/index.php?title=Source_Code) and previous versions (http://www.darwinbots.com/WikiManual/index.php?title=Previous_Versions) from there.
-
I modified it a bit, but it's good.
-
(3) .fixang, .fixlen and .tielen1-3 don't work
Sharing doesn't seem to work either
Here's an example to demstrate bug (3):
I've attached a simple SG batterybot that is supposed to grab a veggy that you put in front of it and drain it's energy using sharing. It doesn't move or fight etc. - all it does is grab veggies that come near to it's eye5, unfix them and put them behind it using fixang.
In practice, in 2.42.2, it grabs the veggie, unfixes it, but can't move it behind itself, change the length of the tie, or share with the veg.
I'm digging into this. Here are some questions that would help me better understand how ties are supposed to work.
Q) Should tmemloc and tmemval be reset to zero if the bot attempts to read from a tie and there are either no ties at all or no value specifed in .tienum? 2.4 does this today.
Q) If there is only one tie, should the tref sysvars be automatically populated or should the bot have to set a tienum and explicitly read from the tie before the tref sysvars get populated?
-
Q) Should tmemloc and tmemval be reset to zero if the bot attempts to read from a tie and there are either no ties at all or no value specifed in .tienum? 2.4 does this today.
No, I think you should keep .tmemloc set until changed by the bot. That way you don't have to keep setting it if you accidently read from a nonexistant tie. Maybe that's one of the reasons why symbioticus has been playing up in 2.4
Q) If there is only one tie, should the tref sysvars be automatically populated or should the bot have to set a tienum and explicitly read from the tie before the tref sysvars get populated?
Yes, populating the trefvars automatically with the first tie formed would be a very, very good idea as you could then use:
cond
*.trefeye *.myeye =
start
*.tiepres .deltie store
stop
With ease Without loosing a cycle storing the tie phase into .readtie
-
I'm with Elite on this one.
-
Okey Dokey. 2.4 exhibits the opposite of what you recommend in both cases, which is in part (but only in part) why the gene Elite posted is not behaving as expected. But this is just the tip of the iceberg I fear....
Does anyone know what the 2.37.6 behaviour is? Elite, if your gene works on 2.37.6 then I assume that version behaves as you both indicate in both cases.
-
Yep, in 2.37.6, .tmemloc is set until set again by the bot
However, the trefvars aren't automatically populated in 2.37.6, but making them so will be an improvement
-
Yep, in 2.37.6, .tmemloc is set until set again by the bot
However, the trefvars aren't automatically populated in 2.37.6, but making them so will be an improvement
If the trefvars arn't populated automatically, then I don't understand how this gene works in that version. Maybe I'm slow today, but .tienum won't ever get set unless *.treffixed has a non-zero value. See this line in the gene
55 .tienum *.numties sgn mult *.treffixed mult store
Am I on drugs?
-
Am I on drugs?
If you're working on Darwinbots you have to be:
Hehehe. Hahaha. (http://www.walkonthegrass.ca/smiles/icon_naughty.gif)
-
If you're working on Darwinbots you have to be:
Ain't that the truth.
Okay, the trefvars now get magically populated when a bot initiates a tie. Exact specifics are here (http://www.darwinbots.com/Forum/index.php?act=ST&f=10&t=1240&st=0) (#10 first post).
-
In 2.37.6 you set .readtie to populate the trefvars, rather than using .tienum but if they got populated automatically the instant a tie is initiated it would be a minor improvement over 2.37.6, since you could then use this gene:
cond
*.trefeye *.myeye =
start
*.tiepres .deltie store
stop
To delete accidental ties to conspecs, without wasting a cycle setting *.readtie
It would just make it slightly easier to work out who you're tied to so you don't go sucking the energy out of your own species
-
In 2.37.6 you set .readtie to populate the trefvars,
Right. Muddled brain. Late night. Not enough drugs...
-
How does this apply to the .tmemloc/.tmemval couplet?
-
Not enough drugs...
How does this apply to the .tmemloc/.tmemval couplet?
That was a seperate question - whether .memloc/val should reset when there are no ties currently set or the bot attempts to read from a tie that doesn't exist.
I voted no - that .memloc should stay as it is until the bot changes it
-
Sorry, the DNA parse stuff in 2.4 still drops certain sysvar strings, so I was reading sysvar numbers late at night and confused .readtie and .tienum.
The only change I have made that impacts tmemloc/tmemval is that putting something in .tmemloc now stays there like I think it does in 2.37.6, even when ties come and go or the bot puts something in .tienum. Before .tmemloc was getting set to 0 if .numties went 0 or .tienum went 0 (or hadn't yet been set).
-
I think memloc stays put, but tmemloc didn't in 2.37. I could be wrong but I'm pretty certain.
-
I think memloc stays put, but tmemloc didn't in 2.37. I could be wrong but I'm pretty certain.
If tmemloc does not stay put in 2.37 then I don't understand how this line in Elite's posted bot can work since it appears (to me at least) to set .tmemloc at age 0 and then never again. The 2.4 code resets it back to 0 right away since .numties is still 0 :
.numties .tmemloc *.robage -1 mult 1 add sgn mult store
-
By the way, I now know what is going on with .fixang and perhaps othertie sysvars that arn't working. Bascially, there is no code in 2.4 that cares. The routine named Momenti() in 2.37 which handles fixing tie angles was just never ported over to 2.4. It's called TieTorque() in 2.4, but is completely commented out and the systax is still 2.37, referencing structures which no longer exist such as the robot node list, etc. No wonder certain bots that fix tie angles just don;t work in 2.4. I'll port it over.
Is Software Archeologist a viable profession?
-
By the way, I now know what is going on with .fixang and perhaps othertie sysvars that arn't working. Bascially, there is no code in 2.4 that cares.
Oops, hehe.
-
Just a thought but could robage in 2.3 count age like in 2.4? its really annoying if you try to make bots you want to test in both versions.
-
They don't count age the same way?
How does each version count age?
-
2.37 counts age in steps of 100 cyles, so age 3 means between 300 and 400 cylces
2.4 counts age in single cyles, so age 3 means cycle 3
-
I'm pretty certain that 2.37 also counts single cycles. The robot info page, however, displays age in 100s of cycles.
-
I'm pretty certain that 2.37 also counts single cycles
100% certain, otherwise the classic antibirthtie genes would take 100 cycles to cut the cord
cond
*.robage 0 =
start
.tie inc
stop
cond
*.robage 1 =
start
.deltie inc
stop
-
I'm pretty certain that 2.37 also counts single cycles. The robot info page, however, displays age in 100s of cycles.
Right. I changed this in 2.42.2. The age sysvar works THE SAME in both versions. It counts single cycles and caps out at 32000. However, 2.42.2 and beyond now maintain an internal age counter that goes beyond 32000. It is this that is displayed in the robot properties dialog (in cycles, not 100's of cycles as it was previously) and is also used for a few other things such as the logrythmic per cycle aging cost calculation. That is, the logrythmic aging cost will continue to increase even after a bot reaches 32000 cycles of age. See #24 and #25 here. (http://www.darwinbots.com/Forum/index.php?showtopic=1211)
-
Sorry, somehow I always end up with finding the wrong reasons why certain genes do not work :/.
-
That's alright, it keeps us on our toes.
-
FYI, I have finished porting over the TieTorque() routine from 2.37.6 to 2.42.3. Elite's battery bot gene posted earlier in this discussion now runs correctly in 2.42.3. See #11 here (http://www.darwinbots.com/Forum/index.php?act=ST&f=10&t=1240&st=0).
-
Yay!
-
FYI, a related change I made was to change the code such that .tienum no longer gets set to 0 after using the tmemloc/tmemval combo. tieportcomm() in 2.4 was doing this. It seems to me that the proper behaviour should be that .tienum, like .tmemloc and .memloc should be sticky. Let me know if there are objections to this behavioural change.
-
- The 'bot sight' feature that shows you what the eyes see is annoying, but at the same time useful. If only you could turn it on and off ...
FYI, I've added a new menu item on the Robot Options menu in 2.42.3 that allows you to turn this on and off.
-
(3) .fixang, .fixlen and .tielen1-3 don't work
Sharing doesn't seem to work either
I am fairly confident that .fixang and .fixlen are now working as expected in 2.42.3. Sharing also appears to work at least in the runs I have done.
I am not sure about .tieang1-4 and .tielen1-4. Are these used or are they defunct? If anybody actively uses them, I would very much love a sample gene, preferably one which demostrates what doesn't work in 2.4... The wiki isn't very helpful about how they are supposed to work.
-
PY added them relatively recently so he'd know for sure, but I think they're just variables that let you access ties directly instead of using tie ports.
Exactly similar to the other tie commands that handle length and angles, but it accesses the internal tie array directly (tie 1, tie 2, etc.).
-
That pretty much sums it up Num.
Couldn't have put it better myself
-
In 2.37.6, .tielen1 affects the birth tie. It can be used as a kind of anti birth tie gene:
cond
*.robage 0 =
start
32000 .tielen1 store
stop
Do we want this behavior to be 'fixed' or left as it is?
I find the tie ports much easier to use than tie phases myself. They're more compact and you can manipulate two ties at once rather than having to set .tienum for each tie you want to alter.
-
I think birth ties should be totally inaccessible to the bots. The birth ties aren't representing actual ties as much as they're representing the incomplete seperation of parent and child.
That you can get rid of them with anti birth tie genes is itself somewhat of a problem, but it's such a legacy part of the program I would never dream of changing it.
-
How about, for reproduction, rather than having bots spawn with a birth tie having them slowly divide instead, like real microorganisms do. Or have some sort of yeast-like budding system.
How about having the centre of the child bot start at the centre of the parent and slowly migrate outward until the two circles separate.
How hard would that be do do graphics-wise?
-
I don't really know how to draw anything that's not a regular polyhedron, but since the new graphics are in OpenGL anything is technically possible. I just don't know how to do any of it
What gets difficult is the collision detection and vision algorithms. Having bots be spherical makes so many things more managable.
What about if the birth tie isn't stretchy, but behaves like a sturdy rod? That would look and behave rather similar to an elliptical cell dividing.
-
In 2.37.6, .tielen1 affects the birth tie. It can be used as a kind of anti birth tie gene:
EEP!!
That was never supposed to happen. It isn't even supposed to work on non-hardened ties.
I'm with Num on this. Birth ties should never be accessable to the DNA.
I find the tie ports much easier to use than tie phases myself. They're more compact and you can manipulate two ties at once rather than having to set .tienum for each tie you want to alter.
That was rather the point. Glad you like the concept.
-
I kind of like the ability myself. Since it's the first tie the bots ever see it makes sense that they'll use it when evolving to move their children away from themselves. I actually found it that way to begin with. In "nature" they'll typically not delete the tie with it. It's more used for distancing a bot and it's child.
I finally got VB to work properly. Modified 2.37.6 so that the absolute value is found for any storage location. Mutations should be approximatly twice as successful as before. Still not great since that's still a 3% probability of a viewable(1-999) memory location being changed.
(999/64001) normally; about 1.5%
(999/32001) mine; about 3%
(total numbers in DB are all negative numbers plus all positve numbers plus zero, 64001)
Want to upgrade add/sub/mult/div store likewise, once I understand them better.
Eventually I want to modify it so it's just the 0-999 locations that are being stored to. Already evolution seems to run better, hopefully it'll improve even more once all the locations a bot can store to are real locations.
Also fixed the venom and poison bugs. Using the code for mkshell/mkslime works best. I'm planning to add in energy retrieval from a resource later today. That'll be something, a bot would be able to venom feed from ties, or use the ability to regain nrg in times of need.
I'll see about back-incorporating some of the additions made to DB. Not anywhere vaguely near great at programming, so it'll probably be the basic stuff first.
-
Obviously I don't want to call it Darwinbots Extreme, hence the problem.
The easiest solution would be calling it DarwinBots++ 0.5
-
That's actually not to bad.
-
Yeah I kind of like that too.
-
Collision response might be a little hard to fix without transfering 2.5's physics into 2.4. Possible, but might be alot of work.
There's the function that handles the velocity changes of collisions. You might be able to put it directly into the VB source (you'll need to change syntax obviosuly, and handle vector math iwht functions instead of operators).
I have completed this for 2.42.3. Collision detection is now much more satisfactory. See #19 here (http://www.darwinbots.com/Forum/index.php?act=ST&f=10&t=1240&st=0).
-
Can't wait to see it in action
-
Can't wait to see it in action
Yea, it's time. I'm just finishing some stress runs and seeing how the collision stuff looks in different sims. I think it's okay though the collision physics for rigidly tied bots impacting a third bot can be a little strange since the forces on the two tied bots from the collision can be transferred to tension in the tie. I'm not sure this is being handled appropriatly....
I'll drop it later today. Fixing viruses will have to wait untilt 2.42.4 I guess.
-
Collision response is somethign I've been working on and off with since last summer. It can fill all your time all by itself
Physics in 2.5 are rather slow, especially with more bots on the screen, but definately solid. However I should be able to optimize it to run at least as fast as 2.4.
Point is it's a terribly bottomless pit that I wouldn't recommend tinkering with if you value your sanity