Darwinbots Forum
General => Announcements => Topic started by: EricL on April 29, 2006, 05:10:15 PM
-
2.42.3b is now available. Major Changes since 2.42.2:
Genetic Memory is now working.
All Tie operations (except possibly .tieang1-4 and .tielen1-4) should now work. In particular, .fixang, .fixlen and energy sharing now work and have been tested with the battery bot gene on the wiki (http://www.darwinbots.com/WikiManual/index.php?title=Batterybot).
Collision Detection is now much improved and incorporates 2.5 behaviour.
Stores to location 0 once again cost no energy.
The Battery bot free energy hole is plugged.
trefvars are now populated immediatly and automatically.
The debugging robot "vision grid" can be turned on and off.
2.5 code backported for CompareRobots which helps big bots avoid going sumo.
Authenticated FTP support for Internet Organism Sharing added. Testing has been limited, but appears to work fine.
Some major and minor bug fixes including fixing a couple of runtime crashes.
Complete details of the changes in this release relative to 2.42.2 can be found here. (http://www.darwinbots.com/Forum/index.php?showtopic=1240)
Enjoy!
-Eric
-
Collisions seem to be able to generate kinetic energy. The coefficient of restitution probably needs to be dropped, or it might have something to do with kinematic and impulse based physics simulations interacting inappropriately.
Basically, try running a planet eaters sim. That should highlight the problem.
-
Collisions seem to be able to generate kinetic energy. The coefficient of restitution probably needs to be dropped, or it might have something to do with kinematic and impulse based physics simulations interacting inappropriately.
Basically, try running a planet eaters sim. That should highlight the problem.
It's the extra push I give deeply penetrating bots. I'll play some more.
-
In 2.5 the bots are physically projected away from each other (their positions are moved independant of some kind of impulse). Something like that might be necessary.
-
Nice work
Works much better
-
In 2.5 the bots are physically projected away from each other (their positions are moved independant of some kind of impulse). Something like that might be necessary.
Gotcha. I've just changed it to modify the velocity directly instead of piling on the impulse vector and you are correct, it works a ton better and I don't need my deep penetration hack. I want to work on it a little more then drop a 3a release later tonight.
-
It does seem like something of a dirty hack compared to the rather abstracted beauty of 2.4's "everything done through impulses" methodology. Seems the more I play with things the more every physical law requires its own ways of doing things.
-
I just put 2.42.3a up on the FTP. Tell me what you think.
Collisions are better I think unless you use a very high gravity Planet Eaters at which point I think the quantum nature of cycles starts to bite us and we get strange harmonics...
-
Much better.
-
hihi that is funny I starteda planet eater sim to test the new collission detection, and guess what happened all algas besides one were absorbed into the black hole which currently revolves around the black hole like a planet around the sun.
I really would like to show you the picture or send you the sim, but unfortunately there seems to be no atatch option in this post :/.
(note it seemed I saved shortly before the collapse of my star system)
-
Welwordion, that's the thing with Planet Eaters. (Why is it called Planet eaters anyway ) Try setting the values lower, like 0.025. Seems to work better for me. When the veggies grow bigger they start to form a bunch of colonies, and if they don't move (wich my primitive veggies don't do) they will eventually end up in one big colony on the screen. Looks better than the black hole thing anyway.
I'm going to check out 2.42.3a to see how it works. I didn't like the collisions in 2.42.3. A little too bouncy, like they bounce away with greater force than they are being hit. Right now I haven't been testing with Planet eaters in this sim I'm running, but I imagine the new collision function whould prevent my veggies to form colonies. Not sure. I'll check out 2.42.3a later.
-
Aha - found it
'Blocked' veggies don't have any collision detection. That's why my bots were going straight through them as if they weren't there.
Bot should bounce off fixed bots, but the fixed bot should stay rooted in one spot.
Hehehe ... with 2.42.3 the bots were bouncing away with so much energy that one veg hitting another could cause a chain reaction
-
BTW veggies no longer form black hoels in 2.5 with planet eaters. They now form a kind of weird atom with all the vegs orbitting around an invisible nucleus. Had to really jack up the planet eaters constant to get that though. Like 1000.
-
'Blocked' veggies don't have any collision detection. That's why my bots were going straight through them as if they weren't there.
Bot should bounce off fixed bots, but the fixed bot should stay rooted in one spot.
The code checks for each bot involved in a collision being fixed independently. A non-fixed bot hitting a fixed bot should bounce off just fine. Is this not happeneing?
-
After experimenting I've found that the presence of any blocked bots in a sim somehow disables collision detection.
In a sim with no blocked bots collision detection works fine
Hmm ... I wonder why that's happening.
Try it yourself - check the 'blocked' box for Alga Minimalis and test the collision detection
But wait ... it gets weirder
I am running a sim with:
Alga Minimalis (autotroph)
A bot that does nothing, just sits there
A bot that slowly moves forward
If Alga Minimalis is blocked, collision detection stops working. If another bot is blocked, collision detection works fine, but can sometimes be disabled for the blocked bot
This is really odd
-
I've did lots of testing with both fixed and nonfixed bots before I released. Here are some things to note:
Bots arrn't solid. Collison detection just applies forces to their velocities. The forces are scaled by their mass so this can result in some strange behaviour. For example, if a massive non-fixed bot hits a lightweight non-fixed bot, things appear like you expect - they penetrate some, the massive bot gets deflected a little, the less massive one gets deflected a lot. But if the less massive one is fixed, the amount the massive one gets deflected remains the same so it will appear as if the massive one moves through the smaller fixed one and only gets deflected a little.
(Hmmm. This gives me an idea. Maybe I should treat fixed bots as extremely massive for the purposes of calculating the forces on the non-fixed collider. I'll try this...)
Also, bots under their own power can thrust against collison repulsion forces and penetrate. As above, small mass bots won't have a lot of inertia. It they thrust each cycle, they can overcome the collision forces. Additionally, ties connect to a bots center so for very large bots, the length of the tie "pulls" the bots towards each other and provides forces opposite to the colision force.
Multibots present some other strange problems because the collison forces can be translated to tension forces on the tie so tied couples can sometimes appear to go through large bots since the forces on the bots can balance and the ties themselves are not currently part of collision detection.
-
Alot of issues stem from the way the program lets bots interpenetrate in 2.4.
-
(Hmmm. This gives me an idea. Maybe I should treat fixed bots as extremely massive for the purposes of calculating the forces on the non-fixed collider. I'll try this...)
Good thinking. I'd say making fixed bots infinitely massive for collision calculations would probably solve some of the problems
I've narrowed down my collision bug: If the first bot on the list is 'blocked' the collision detection for all bots is disabled.
-
Alot of issues stem from the way the program lets bots interpenetrate in 2.4.
A lot of issues stem from the quantum nature of cycles. Bots with high velocity can move a lot further than a pixel in a cycle, which means they can penetrate other bots before the code even gets to know there has been a collision. For fast moving, small diameter bots, they can even collide and pass their centers before the code gets a chance to do anything. I suppose we could move collision detection to be predictive in cycle n-1, but I'm not up for that today...
I've narrowed down my collision bug: If the first bot on the list is 'blocked' the collision detection for all bots is disabled.
Ah hah!!!!! Nice work.
-
To be fair, after compensating for my collision-detection-disabling bug by placing the blocked veggie after the unblocked bot, I was really impressed with the physics.
I think that bug is the reason why collision detection wasn't working for me in the earlier versions either.
-
A lot of issues stem from the quantum nature of cycles. Bots with high velocity can move a lot further than a pixel in a cycle, which means they can penetrate other bots before the code even gets to know there has been a collision. For fast moving, small diameter bots, they can even collide and pass their centers before the code gets a chance to do anything. I suppose we could move collision detection to be predictive in cycle n-1, but I'm not up for that today...
What we really need to do is a "sweep collision" test. Basically make a long cylinder which is the bot's continuous position between opos and pos. Test this against other bots' position cylinders.
If they intersect you need to find the point where the cylinders touch. This point gives you both the time at which they collide and the position.
Seems overkill to use the time from that collision (time steps are already rather fine), but it certainly would make sense to use that position in figuring out collision response.
Shots already do this when they test against bots, mostly because you have a line instead of a cylinder so it's alot easier.
-
I've narrowed down my collision bug: If the first bot on the list is 'blocked' the collision detection for all bots is disabled.
Any idea as to why it might be doing that?
-
Any idea as to why it might be doing that?
Yea, it's because I'm an idiot. I had a stupid bug: rob(1) instead of rob(rob1). Doh.
2.42.3b is posted. This bug is addressed and fixed bots are treated as if they mass 32000. I think we have it now.
-
Bots arrn't solid. Collison detection just applies forces to their velocities. The forces are scaled by their mass so this can result in some strange behaviour. For example, if a massive non-fixed bot hits a lightweight non-fixed bot, things appear like you expect - they penetrate some, the massive bot gets deflected a little, the less massive one gets deflected a lot. But if the less massive one is fixed, the amount the massive one gets deflected remains the same so it will appear as if the massive one moves through the smaller fixed one and only gets deflected a little.
Sounds realistic to me. I see the bots as living cells, not solid marbles.
Hmm... I'm not sure about trying 2.42.3b, because I'm not interested in using fixed bots anyway. 2.42.3a works nice I think.
-
Darwin2.42.3b.exe is corupted. It won't extract from the zip file
Anyone else notice this?
I think you may need to re-upload it
-
Darwin2.42.3b.exe is corupted. It won't extract from the zip file
Anyone else notice this?
I think you may need to re-upload it
thought I'd wait to see where this ends up first.
how about the source code?
http://www.darwinbots.com/FTP/Darwinsource2.42.3b.zip (http://www.darwinbots.com/FTP/Darwinsource2.42.3b.zip)
-
Darwin2.42.3b.exe is corupted. It won't extract from the zip file
Anyone else notice this?
I think you may need to re-upload it
I just uploaded it again and tested that it unzips correctly.
Hmm... I'm not sure about trying 2.42.3b, because I'm not interested in using fixed bots anyway. 2.42.3a works nice I think.
If it's not too much of a hassle, would appreciate it if you could move at some point. You're my #1 bug finder and I'd prefer to have you on the latest bits. No hurry. Thanks.
-
Bah, I've downloaded it again but when I try to extract the files from the zip it says "error extracting the file" and won't extract the executable.
Is this happening to anyone else or is it just me?
-
Bah, I've downloaded it again but when I try to extract the files from the zip it says "error extracting the file" and won't extract the executable.
Is this happening to anyone else or is it just me?
I just tried it again and now I get an error.... hmmm.
I uploaded an unzipped version. Try this.
Unzipped 2.42.3b (http://www.darwinbots.com/FTP/DarwinBots2.42.3b)
Not sure why the link isn't working... Hang on.
-
Internet exporore cannot download Unzipped 2.42.3b from www.darwinbots.com
The login request was denied
^ That's what it says when I try to downlod the file attached to your post
Can you download it?
-
Dang. I think it needs to be an executable, lile a zip file, for an http URL to work and you need permissions to get to the FTP share via FTP... And the Attach file option seems to have gone missing in this topic... Let me see if I can figure out why the zip is getting corrupted...
Okay, I just uploaded a zipped version again and this time it appears to unzip okay....
-
It works! Thanks Eric
And the collision detection is working brilliantly. Great job
-
It works! Thanks Eric
And the collision detection is working brilliantly. Great job
Thanks. I now have more empathy for women in the delivery room...
Viruses are still on my list to dig into for the next version and I need to look into .tielen1-4 and .tieang1-4, but please let me know if you find any other things that need attention.
-
Eric
Please bear in mind that when I designed the tielen1-4 and tiang1-4 controls, we only had a maximum of 4 ties available.
The number of these commands needs to be the same as the number of avaliable ties in whichever version you release.
Additionally there was always one problem that I had with these things.
When ties are made, the internal tie array fills up from the bottom so the first tie made can be addressed by tielen1 and so on. The problem I encountered is what happens when you have four ties then tie number 2 gets deleted for some reason?
There isn't any way to really know which slot you are filling up when you make a new one. We might need to address that issue in some way but I am not quite sure how.
This only really becomes an issue when designing complex MB structures but as long as we want DB to be a mixture of design (for some) and evolution (for others) then we need to think this through quite a bit and maybe even come up with a completely new system.
The requirements are - We need to be able to directly address a given tie with the absolute minimum of commands (no settie or tienum stuff)
- we need to be able to adjust or set multiple ties in a single cycle. Not possible with the current tienum system unless we change it in such a way as to make the DNA sequential rather than pseudo simultaineous.
Any thoughts on the issues?
-
I believe Nums has detailed a new system here - New Tie Paradigm (http://www.darwinbots.com/WikiManual/index.php?title=New_tie_paradigm)
Setting ties is done by commands rather than sysvars so multiple ties can be manipulated each cycle, and ties can be set by tie phase or by tie port
***
As for what could be done in 2.4, I've got an idea:
*.tiepres1-4
(or however many ties that there can be at one time)
Only problem is it doesn't allow the manipulation of multiple ties per cycle, but it's a start.
-
My new tie paradigm does address this issue, providing .recentphase and .recentport.
Feel free to read and comment, I've extracted it largely from the post where we talked about it PY.
-
I assume widespread use of 2.5 is not that far in the future, say a few months at most. Given that, I currently think it's beyond the scope of the VB fork to radically change DNA execution fundementals, in particular to make any fundemental changes to the two-step process of 1) execute all the DNA to load up the mem array and then and only then 2) do what the mem array says to do. Said another way, one could imagine creating new in-cycle execution artifacts which would allow for separate, per gene execution, shooting multiple types of shots in different genes per cycle, changing the value of tienum to address different ties in-cycle, etc. I don't want to make changes of this magnitude in 2.4 if 2.5 is only months away. If 2.5 slips out, then we can re-visit changes of this magnitude, but that is my assumption for now.
So, that means any operational parallelism in 2.4 will require specific sysvars. IMHO, this leaves several options for 2.4 regarding addressing multiple ties in a single cycle:
1) Do nothing. This is why I asked eariler whether anyone actually used .tielen1-4, etc. in 2.37.6 If no-one does, no big deal. I won't make them work and I won't have to deal with the issues you (PY) point out so well.
2) Make them work but don't deal with the issues with ties getting deleted, more than 4 ties, etc. This might be sufficient for designers moving from 2.36.7, but strikes me as hackish and incomplete.
3) Make them work, but limit them to 4 ties (you can have more, but you can't address them in parallel) but deal with tie deletions. I could do this by making some implicit rules that the first tie to fill a slot will be bound to the tie sysvars for that slot unitl it is deleted and maintaining a per-bot mapping from tie to tie sysvar and changing that as ties get added and deleted. If there are more than 4 ties and one gets deleted, maybe the least recent tie not mapped to a sysvar takes the slot or not... Or perhaps I could add a .settievar that would allow the bot to explicitly map ties (via tienum) to parallel tie sysvars for parallel addressing....
4) Add more sysvars for more than 4 ties (I think you can have 10 ties in 2.4). This would be 16 additional sysvars (.tielen5-10, .tieang5-10) plus still would need to be explicit about deleting/addition behaviour as in 3) above.
In my mind, 3) is the default plan but I'll noddle it for a a few days before I start. I am of course, very open to better suggestions...
-
2.5 is very close. I'm really terrible at estimating time required to finish but I see the Beta beeing done in another 2 months at the longest, 1 month at the shortest.
Most of what's left is hole filling and GUI building.