Darwinbots Forum
General => Announcements => Topic started by: EricL on June 14, 2006, 04:57:30 PM
-
Version 2.42.6 is now available!
Direct Download Link. (http://www.darwinbots.com/FTP/DarwinBots2.42.6.zip)
Major Changes / Features (in no particular order):
Perf: Poff shots now ignored for collision detection purposes
Shots now bounce off field edges
Postive values of shootval are now Mod 1000
Negative values of shootval are now Mod 7
Graph readability improved
Several bugs and usability issues with high fluid density sims addressed
New Incoming Energy Management features
New Dynamic Cost Adjustment features
New Feature - option to disable shot decay
New Feature - option to disable dynamic bot radii
New autosave features for stipping mutation details and re-using old files to prevent filling up the drive
.delgene now works
Touch senses (.hitdx, etc.) now work
Postive shots now only cost the shot cost instead of the .shootval amount
Perf: Shot collision detection now uses quadratic equation algorithym
Perf: Additional improvements in shot array manipulation
Several fixes for crashing bugs
Numerous fit and finish improvements.
A detailed list of the changes from version 2.42.5 can be found here (http://www.darwinbots.com/Forum/index.php?showtopic=1369).
A few words about 2.42.6.
This is a significant release with many new features focused on evo sims. All of the bugs identified here (http://www.darwinbots.com/Forum/index.php?showtopic=1370) should be fixed except for the virus related issues which will be addressed in the next release. Many thanks to Elite, Testlund and others for their help in identifying bugs and their comprehensive bug reports.
The new features on energy management should provide good control over the energy coming into a sim via autotrophs as a function of the total sim energy. The total sim energy as reported in the tray includes all nrg and body in bots as well as nrg in -2 shots. It does not include energy that has been converted to shell, venom, etc. The nrg ratio displayed in the tray shows the net energy which enterred or left the sim in the previous cycle and should give you a good feel for the rate that energy is enterring or leaving the simulation.
Nrg enters a sim smoothly via autotrophs or discontiniously via new bot creation events, such as autotroph repopulation or when the user manually inserts bots. If you want to avoid large jumps in energy inflow from one cycle to the next, you will want to set the starting energy for your autotrofs low or design yoru sim so that repopulation events are rare. Otherwise, each repopulation event will result in large, discontinious injections of energy.
Nrg leaves a sim through a wide variety of means, the largest being decay of -2 shots which fail to impact a bot. If you wish to run an evo sim where energy is mostly conserved, the new Disable Shot Decay feature is for you. It prevents decay of all shots, making them last until they impact a bot. This also results in a "messy medium", in some ways more representative of biological protozoic organism environments. This will plug the largest vehicle for energy leaving the simulation, but may result is a large number of shots (see the shot counter in the tray) and have an adverse impact on cycles/sec. Using no decay corpose mode will further limit energy loss (in the form of energy converted to body decaying or disappearing from the sim). Note that energy will still leave the sim via costs, bots dying with positive amounts of resources origiginally requiring nrg to produce (such as shell or venom) decay of resources such as slime over time, and several other sources of built in internal energy conversion losses. With the new featrures, these should be quite manageable however for those seeking energy balance in evo sims.
The new dynamic costs features are another new feature area focused on evo sims. There are really two features here that can work independently or together. The first turns off all costs if the bot population (all bots, autotrophs and hetertrophs and corpses and even walls I think) drops below a user defined threshold. The costs stay 0 until the population climbs back above the threshold. This safty net feature can be used to prevent massive extiction and save a delicate sim from going extinct in the middle of the night.
The second feature is more exciting. It dynamically adjusts the costs based upon a user specified target bot population. This can be very useful if you wish to incerase the selection pressure over time as bots evolve for example. The algorithym is a little complex, but basically, a cost multiplier is applied to all costs and this multipler is ratcheted up if the bot population remains over the target population by more than 10% and rachets down if it remains below the target by more than 10%. The sensitivity slider impacts how aggressively the costs are adjusted. Check out the Auto Costs Graph to see how this changes over time.
The two can be used to gether for null evo sims where for example, the 0 cost threshold can be set above the starting population so that costs remain 0 while the population has yet to evolve a replicator, but once the population starts climbing, costs can slowly and automatically be increased, providing selection pressure to evolve say, feeding behaviour or some other energy aquisition adaptation. Combine this with incoming energy management and you can provide selection pressure for evolving better means for competing for a limited resource.
The entire subject of energy and populatuion management w.r.t. evo sims deserves a separate write up which I may get around to some day.
Enjoy!
-
Wow, great!
I'm totally obsessed with Darwinbots now. Work suffers
How do the day/night cycles interact with pond mode light gradients & nrg/cycle? Is there a description of this somewhere?
-
I'm totally obsessed with Darwinbots now. Work suffers
Yea..... tell me about it...
How do the day/night cycles interact with pond mode light gradients & nrg/cycle? Is there a description of this somewhere?
No description on the recent features, so here you go. I need to put a lot of stuff on the wiki...
So, the way the new stuff works is as follows: day/night cycles (which isn't new) causes the sun to come up and the sun to go down, with a frequency of 2X what you specify, right? (I.e. Day lasts X cycles, Night last X cycles). When the sun is up, each autotroph gets the energy specified per cycle (or whatever other method your using). If your using pond mode, then the energy each veggy receives each cycle the sun is up is proportional to the Intensity you specify and inversly proportional to the bot's depth and the sendiment level you specify. The two new features override the sun. If the sim energy falls below the threshold you specify, it forces the sun up even if it is night, until the energy of the sim gets above the threshold again. Vice versa for forcing the sun down even if it is daytime. Note the sun will be forced down even if you are not using day/night cycles. Note also that if you are using day/night cycles, then the spinning of the planet is stopped and "put on hold" while the override is in effect. I.e. if you have 100 cycles left to go before dawn and the override forces the sun up because the sim energy fell below the threshold, then once it brings the sim energy back up, it will go night again and you will still have 100 cycles to go before the normal dawn.
Oh, and the nrg delta is just the difference between the nrg in the sim this cycle and the average of the past 10. It doesn't care how the energy came in or how it left. It just shows what changed. So for example, you can make the delta go up a lot just by manually adding a whole bunch of bots, autotrophs or not, and the delta will show positive that cycle even if it is night time becuase the total sim energy when up compared to the average of the past 10.
-
This version is brilliant
The new features are very interesting. Allow for much more control over evosim dynamics.
Well done Eric
-
This version is brilliant
The new features are very interesting. Allow for much more control over evosim dynamics.
Well done Eric
Thanks Elite. I can't tell you how nice it is to be able to write some new code for a change instead of just fixing bugs...
-
I should probably explain the autocost multiplier adjustment algorithym.
All costs you specify get multiplied by the autocost multiplier as they are applied. This multiplier is the number displayed in the tray as CostX. It is also grpahed in the Auto Costs Stats graph. All prior program versions can be thought of as always applying a multiplier of 1. Similarly, if the 'Enable Dynamic Cost Adjustment' checkbox is unckecked, the multiplier is fixed at 1.
The multipler can change cycle to cycle. If the total bot population (including vegs, corpses, walls - we may want to change this to only extant hetertrophs in subsequent releses) is within 10% of the target specified in a given cycle, no change is made. The multiplier stays at whatever it was the last cycle.
If the bot population is above the target by more than 10 % then the multiplier is increased if
1) The bot populatuion this cycle is greater than it was last cycle
or 2) The bot population has remained the same for 10 cycles.
Note that if the population is falling, it is moving towards the target and thus in the direction we want. So, even if it is above 10% of the target, the multiplier will not be further increased as long as the population continues to move towards the target at a reasonable pace.
The converse happens when the population is more than 10% below the target number. Namely,
If the bot population is below the target by more than 10 % then the multiplier is decreased if
1) The bot populatuion this cycle is less than it was last cycle
or 2) The bot population has remained the same for 10 cycles.
The amount the multipler is adjusted is a function of two things:
1) Tthe sensitivty slider. The slider is a value from 1 to 1000.
2) How far out of the target range the current population is.
Specifically, the multiplier is adjusted usign the following formula:
(0.0000001 * (Abs(AmountOff) - TenPercent) * sensitivity
Where
AmountOff = the difference between the current population and the target number
TenPercent is 10% of the target value.
An example is called for. Lets say the target population is 1000. Then the "target range" is 900 - 1100. If the population is in this range, no changes will be made to the multipler.
Lets say the multipler is currenty at 0.5 and the sensitivity slider is in the middle at 500. This means that all the costs are currently being multplied by 1/2. Life is easier in the sim then it would be if you were not using Dynamic Cost Adjustment.
Now lets assume some new adaptation occurs and the population grows to 1200 in a single cycle (unrealistic, but lets go with it for the purposes of this example).
Then AmountOff = 1200 - 1000 = 200
The multiplier would be increased by 0.0000001 * (200 - 100) * 500 = 0.005 that cycle.
The new mutplier would be 0.505, increasing costs slightly, providing pressure for the poipulation to come down over time.
The last thing that needs explaining is what happens to the multiplier if the populatiuon falls below the "No Costs" threshold. If you have this checkbox enabled, adn the population falls below the indicated level, then the multipler gets set to 0 and it will stay at 0 until the bot population comes back up and rises above 10% over the target number at which point it will start increasing as above. Ramping the costs up slowly like this allows for evo sims to apply costs slowly as populations build or let populations recover after a mass extinction. Can you say "Adaptive Radiation?"
It is an interesting question as to whether the multiplier should be allowed to go negative. Right now, it is prevented from doing so, but I'm open to input here.
-
OK I give up. Where have you put the control that enables bouyancy in pond mode?
My Alga Stratificus (http://www.darwinbots.com/Forum/index.php?showtopic=1036) doesn't float up and down with day and night cycles any more.
-
And corpses no longer shoot in random directions or sink to the bottom.
-
OK I give up. Where have you put the control that enables bouyancy in pond mode?
My Alga Stratificus (http://www.darwinbots.com/Forum/index.php?showtopic=1036) doesn't float up and down with day and night cycles any more.
I don't think 2.4X has ever had such a control.
-
WHAAAA.....????
How many more fundamental things were not ported over from 2.37?
I think you should go take a look at 2.37 and play with it for a while to see the things it has that apparently 2.4 doesn't.
The entire concept of pondmode is rather meaningless unless stuff can float in the water. I implemented it as a side-on view into a watery world like a pond or a fish tank. Many of my robots use the .setboy controls to use the *.depth to their advantage.
Alga Stratificus floats to the surface in the day time and sinks to a depth of about 4000 at night so that robot shoals have to adapt to this in order to feed efectively.
Corpses have a bouyancy value of -2000 so that they sink to the bottom of the pond and make a rich organic ooze layer in which other robots (particularly bottom dwelling veggies) can grow. That is the reason for the corpses to be able to select decay mode. The waste feeds the bottom veggies.
You are doing a great job with 2.4 but the number of things that have been lost in the transition from 2.37 just make me sad.
And there is one more weird thing that I discovered in a sim with Alga Stratificus and Anon Terrifica. When Anon feeds (very small bot) it sucks energy from the veggie very slowly, giving the tie time to contract to what appears to be zero length. Anon ends up right inside the veggie almost every time.
-
Hey PY, set the collision elasticity all the way to 'marbles' so that bots don't pass through each other, and check the 'disable dynamic radii' to remove the dynamic sizes. It should look a lot like 2.37.6
And I agree, buoyancy should be ported over
-
Hey PY, set the collision elasticity all the way to 'marbles' so that bots don't pass through each other, and check the 'disable dynamic radii' to remove the dynamic sizes. It should look a lot like 2.37.6
Yeah I know that.
The issue I'm referring to is that the tie seems to be shrinking rather than staying the same length.
Eric said the ties should stay at the length they started out at but that isn't what is happening. They get steadily shorter in this sim.
-
They are probably trying to change to the "default length" when they harden. Should I make ties harden at the length they were initally created at?
-
Nope. that isn't what's happening.
Anon terrifica is way too primitive to try that. It was designed as a straight forward, slow moving, slow feeding tutorial bot that I made up on the spur of the moment to demonstrate a few features in 2.3 something.
It just fires 'em and sucks though 'em with nothing fancy like changing lengths.
-
Right, but after 20 cycles, the tie hardens and the bot becomes multi. I hope I undertand this and got it right.
At that point, I think my code is changing the tie length to 200. The "they" in my post above refers to the ties, not the bots, refering to my tie code adn what I think it is doing wrong, not to the bot's use of .tielen.
-
In 2.4 I made bouyancy a function of volume, as you would expect in real life. The problem is the only thing bots have that effect their density, and hence bouyancy, is shell and body.
If there isn't any fluid density, there won't be any fluid bouyancy.
-
In 2.4 I made bouyancy a function of volume, as you would expect in real life.
I wouldn't expect that at all.
Whales are huge and have neutral bouyancy at the surface and somewhat negative bouyancy as they dive to great depths as the air in their lungs gets compressed.
Tiny little crabs sink like a rock.
Fishes of all sizes are able to float up and down at will by the use of swim bladders. That is what bouyancy is supposed to represent
The problem is the only thing bots have that effect their density, and hence bouyancy, is shell and body.
Not true. I gave them swim bladders in the form of the .setboy sysvar.
If there isn't any fluid density, there won't be any fluid bouyancy.
Fluid density in pond mode is assumed to be that of water. It is a fixed and completely irrelevent value and is constant with depth. We don't need it to be defined beyond that.
The default position of all bots of any size is neutral bouyancy but this can be changed by internal adjustments (swim bladder) or external adjustments like the addition of shell which would obviously make them more dense.
Where exactly is the problem. This was completely working in 2.37.6 and what's more it was very simple and elegent.
-
I wouldn't expect that at all.
Whales are huge and have neutral bouyancy at the surface and somewhat negative bouyancy as they dive to great depths as the air in their lungs gets compressed.
Tiny little crabs sink like a rock.
Fishes of all sizes are able to float up and down at will by the use of swim bladders. That is what bouyancy is supposed to represent
All those things are on Earth and hence are also being acted upon by gravity. The net movement in a liquid is a function of bouyancy and weight of the object (although bouyancy wouldn't exist in a zero G environment either).
Hence, the net movement of an object is actually dependant upon density. Bouyancy, however, is strictly dependant on volume. (Force of Bouyancy = Volume * density of liquid * gravity, ie: Archimedean Principle)
Not true. I gave them swim bladders in the form of the .setboy sysvar.
Which I couldn't figure exactly what to do with when I remade bouyancy. I mentioned this at one point when I talked about adding a new constructable unit which would be massless but take up volume, to help counter shell which can be used as a balast (no volume, but adds mass), but I couldn't reach a concensus, so I put it on hold and apparently forgot about it.
Fluid density in pond mode is assumed to be that of water. It is a fixed and completely irrelevent value and is constant with depth. We don't need it to be defined beyond that.
1. Liquid can't be compressed, so it's density is constant at all depths. Pressure, however, is not, which I assume is what you're confusing it with. Since bots are assumed to be implosion-proof, pressure obviously doesn't matter.
2. It should be fairly obvious that you can define the density of the liquid since the advanced physics tab has a field where you can specify the density of the liquid. In fact, if you read the toolbar in the advanced physics tab it tells you that density effects the force of bouyancy. It also tells you the density of an average bot for comparison purposes.
3. "water" has no correlation with the bot universe because we have nothing to compare any of the metrics between the two environments with. Density in real life is (kilo)grams / meter^3. Density in DB is mass / twip^3. It's comparing apples and oranges.
The default position of all bots of any size is neutral bouyancy but this can be changed by internal adjustments (swim bladder) or external adjustments like the addition of shell which would obviously make them more dense.
Assuming a density of 1E-6 (which advanced physics tab suggests), this is true (minus the swim bladder, which I explained above). 1E-6 should be the density of body. Adding shell would make you sink. There's nothing you can add to decrease density, which is the problem I explained above.
Where exactly is the problem. This was completely working in 2.37.6 and what's more it was very simple and elegent.
It was perhaps simple but it did not correlate well with the rest of the physics. By redoing all the physics, I tied all forces in together to create a central and stable way to integrate them. By tying bouyancy in to fluid density, I correlated drag forces, bouyancy, etc. into a few parameters which correspond very well with real life.
-
All those things are on Earth and hence are also being acted upon by gravity. The net movement in a liquid is a function of bouyancy and weight of the object (although bouyancy wouldn't exist in a zero G environment either).
And so is "pond" mode. It represents a pond after all. You cann't have a pond unless you have gravity so the concept of a pond automatically assumes its presence.
Hence, the net movement of an object is actually dependant upon density. Bouyancy, however, is strictly dependant on volume. (Force of Bouyancy = Volume * density of liquid * gravity, ie: Archimedean Principle)
Except that archimedies principle is irrelevent when it is applied to aquatic creatures which swim in the water column. Their density is identical to the medium through which they swim as a default. They can change it with the addition of more dense stuff like shells or less dense stuff like swim bladders..
Which I couldn't figure exactly what to do with when I remade bouyancy. I mentioned this at one point when I talked about adding a new constructable unit which would be massless but take up volume, to help counter shell which can be used as a balast (no volume, but adds mass), but I couldn't reach a concensus, so I put it on hold and apparently forgot about it.
I don't even remember this but then I really didn't have a great deal to do with 2.4 most of the time
1. Liquid can't be compressed, so it's density is constant at all depths. Pressure, however, is not, which I assume is what you're confusing it with. Since bots are assumed to be implosion-proof, pressure obviously doesn't matter.
I'm not confusing anything. I stated that density of water is constant with depth and it is. I didn't mention pressure since any creature living at any depth will take on the density of its surrounding water. It is irrelevent as I said.
In fact, if you read the toolbar in the advanced physics tab it tells you that density effects the force of bouyancy. It also tells you the density of an average bot for comparison purposes.
That's all very fine and dandy except that in "Pond Mode" all that stuff should be totally over-ridden such that bot density == water density. Otherwise the concept of "Pond Mode" is a waste of space. Gravity is also a meaningless concept in "Pond Mode". All you need to know is that it exists. Any change in its magnitude will only serve to change the pressure acting throughout the whole system and since the robots and the water exist in a complete balance, nothing will change at all.
3. "water" has no correlation with the bot universe because we have nothing to compare any of the metrics between the two environments with. Density in real life is (kilo)grams / meter^3. Density in DB is mass / twip^3. It's comparing apples and oranges.
The exact density is utterly irrelevent. The math to calculate it is utterly irrelevent. The differences between the DB world and the real world are also utterly irrelevent.
There is only one thing here that is an issue of any kind.
"Pond Mode" was created to simulate a POND or TANK with all assumptions relating to water and bot density automatically implied. Equally, in "Pond Mode" the Y axis of the screen can only be equated to up and down in the vertical plane so many other assumptions are implied also.
Assuming a density of 1E-6 (which advanced physics tab suggests), this is true (minus the swim bladder, which I explained above). 1E-6 should be the density of body. Adding shell would make you sink.
Yup. That's right.
There's nothing you can add to decrease density, which is the problem I explained above.
Except that there quite obviously IS.
Fish do it all the time.
It's called a SWIM BLADDER. Fish are able to manipulate their density to float up or sink down at will. Plankton do it too. As do krill and many other aquatic creatures.
It was perhaps simple but it did not correlate well with the rest of the physics. By redoing all the physics, I tied all forces in together to create a central and stable way to integrate them. By tying bouyancy in to fluid density, I correlated drag forces, bouyancy, etc. into a few parameters which correspond very well with real life.
It didn't need to correlate with much of the other physics. It was designed to override them.
Frankly I have never really liked the physics of 2.4 much. That's another reason why I have still not made the switch.
The fact is that in almost every way that matters to me, 3.37.6 is still superior. 2.4 is getting better but it just lacks all the things that make DB fun for me.
-
Except that archimedies principle is irrelevent when it is applied to aquatic creatures which swim in the water column. Their density is identical to the medium through which they swim as a default. They can change it with the addition of more dense stuff like shells or less dense stuff like swim bladders..
This is not exactly true. Most fish are not in equilibrium density with their environment.
Swim bladders are not found in all fish. Many cartilaginous fish, such as sharks, can control their depth only by swimming; others store fats or oils for this purpose.
I'm not confusing anything. I stated that density of water is constant with depth and it is. I didn't mention pressure since any creature living at any depth will take on the density of its surrounding water. It is irrelevent as I said.
I'm sorry, I read consistant instead of constant. Changed the meaning of the whole sentence.
That's all very fine and dandy except that in "Pond Mode" all that stuff should be totally over-ridden such that bot density == water density. Otherwise the concept of "Pond Mode" is a waste of space.
At present pond mode implies only the way in which light is distributed in the sim. What if I want to run a sim with a gradient for the vegs in a total vacuum? I'm certain I mentioned this when I split corpse mode and pond mode apart into their most core features. I removed the hooks to the other concepts (such as gravity) in order to allow the end user greater freedom in simulation parameters.
Gravity is also a meaningless concept in "Pond Mode". All you need to know is that it exists. Any change in its magnitude will only serve to change the pressure acting throughout the whole system and since the robots and the water exist in a complete balance, nothing will change at all.
No. Net forces acting on a body in a liquid = Force of Bouyancy - Force of Gravity = Volume of object * density of liquid * gravity - mass * gravity = gravity * (Volume * density - mass)
Gravity doesn't cancel out. Having more gravity will increase the magnitude of the resulting force. Objects that float upwards at X meters per second on Earth will float X/6 meters per second on the moon.
It's called a SWIM BLADDER. Fish are able to manipulate their density to float up or sink down at will. Plankton do it too. As do krill and many other aquatic creatures.
I meant in the DB universe there's nothing to construct to make you less dense. And while we're on the subject, swim bladders have a whole set of gotchas and consequences fish have to deal with. Among them they'd explode if they tried to rise too quickly.
It didn't need to correlate with much of the other physics. It was designed to override them.
Override the physics system or override the physics constants? Those are two very different things.
Frankly I have never really liked the physics of 2.4 much. That's another reason why I have still not made the switch.
I'm sorry you feel like this, but most everyone else I've heard comment on them feels they are a step in the right direction. The problem is that they're almost realistic, so people are better able spot discrepancies with real life. The older physics was so absolutely unrealistic you could never really compare it with real life so its flaws were a little better masked.
Do various stress test comparisons between 2.4 and 2.37. 1000 veggies with some gravity for instance. Or several bots that tie to everything they can. I think you'll see my point.
-
addendum: I seperated Pond Mode for version 2.36.
-
This is not exactly true. Most fish are not in equilibrium density with their environment.
Swim bladders are not found in all fish. Many cartilaginous fish, such as sharks, can control their depth only by swimming; others store fats or oils for this purpose.
OK it is true that some fish such as sharks do not have bouancy control, I wouldn't go so far as to say most fish are not in equilibrium with their environment. All open water species of boney fish and a large proportion of reef fish are able to control their bouyancy. Whether they use fats and oils or swim bladders or whatever, they still have methods to control their mean internal density such that they can control their bouyancy.
At present pond mode implies only the way in which light is distributed in the sim. What if I want to run a sim with a gradient for the vegs in a total vacuum? I'm certain I mentioned this when I split corpse mode and pond mode apart into their most core features. I removed the hooks to the other concepts (such as gravity) in order to allow the end user greater freedom in simulation parameters.
If you want to simulate a light gradient in a vacuum then you could just click the nice handy toggle that disables Bouyancy in 2.37.6. You know, the one that isn't there in 2.4X
You may well have mentioned it but if you did then I was probably too busy with something else to pay much attention. I definitely don't remember it.
Gravity doesn't cancel out. Having more gravity will increase the magnitude of the resulting force. Objects that float upwards at X meters per second on Earth will float X/6 meters per second on the moon.
Yes you are right that gravity would have an effect on the magnitude[/b] of acceleration forces caused by bouyancy but for a robot that has neutral bouyancy w.r.t. its environment the net change in acceleration due to a change in gravity would be zero.
I meant in the DB universe there's nothing to construct to make you less dense. And while we're on the subject, swim bladders have a whole set of gotchas and consequences fish have to deal with. Among them they'd explode if they tried to rise too quickly.
In all 2.3 versions of DB there IS something to construct which can make a robot less dense. I put it there. It doesn't matter what it is. Maybe robots are more dense than the surroundings by default and ned to actively spend enrgy to become neutral. Doesn't matter what the mechanism is any more than it matters what mechanism is used to rotate or accelerate or fire shots. The mechanism is simpy there.
In 2.4 you just removed it.
If you want to simulate exploding because of rapid rising through the medium then fine. Do that. That wouldn't bother me. I don't really see the point but it wouldn't bother me. Just arbitrarily removing a whole chunk of pond mode is another matter though.
Override the physics system or override the physics constants? Those are two very different things.
Yes they are though from my point of view it doesn't make a bit of difference so long as the sim does what I want it to do. I need my robots to be able to control their bouyancy. That's all. they have a sysvar to set it and another to read it. in 2.4x they simply don't work. What more do I need to say?
I'm sorry you feel like this, but most everyone else I've heard comment on them feels they are a step in the right direction.
It isn't a case of not being a step in the right direction. I can see that a lot of the underlying physics are becoming more accurate. It is just that so much of the system is just "missing". I know you kind of left 2.4 as a half unfinished project and that (most of) the stuff that you actually did made those finished bits better, but the missing stuff just makes it unusable to me.
The older physics was so absolutely unrealistic you could never really compare it with real life so its flaws were a little better masked.
Yes this is true.
Possibly the entire allure of DB (at least to me) has always been its differentness to reality. If we go 100% realistic, then how do we reconcile the way they move, turn, shoot to feed, fire ties, read each other's minds.
There really isn't much about DB that is technically realistic when it comes right down to it.
Why should the physics have to be a mock up of the reality that we know?
-
If you want to simulate a light gradient in a vacuum then you could just click the nice handy toggle that disables Bouyancy in 2.37.6. You know, the one that isn't there in 2.4X
You may well have mentioned it but if you did then I was probably too busy with something else to pay much attention. I definitely don't remember it.
There's no such toggle because Bouyancy is assumed to be an emergent property of liquid properties. To disable bouyancy you'd have to either disable gravity or turn fluid density to 0.
Yes you are right that gravity would have an effect on the magnitude of acceleration forces caused by bouyancy but for a robot that has neutral bouyancy w.r.t. its environment the net change in acceleration due to a change in gravity would be zero.
What I'm saying is that staying at exactly neutral bouyancy is difficult, even in real life. If you were in a sea in Jupiter and were 1% off, your acceleration would be quite different from the same scenario on Earth. My point is that the magnitude of gravity changes the margin for error.
In all 2.3 versions of DB there IS something to construct which can make a robot less dense. I put it there. It doesn't matter what it is. Maybe robots are more dense than the surroundings by default and ned to actively spend enrgy to become neutral. Doesn't matter what the mechanism is any more than it matters what mechanism is used to rotate or accelerate or fire shots. The mechanism is simpy there.
In 2.4 you just removed it.
I didn't remove it as much as pull the rug out from under it. My real point is that when we reintroduce it, we should treat it as a constructable unit, and so have hooks on the cost page for changing the cost per unit, same as with shell and slime. I'd prefer it had another use, so it wasn't just for bouyancy control, in the same way that shell isn't just for balast.
A simple solution would be to change the properties of slime to serve this purpose. Slime would either be zero volume (as it is right now) with negative mass (which makes about 0 sense in any realistic setting) or give slime some volume and 0 mass (slime has 0 mass right now).
You could reason the latter as a kind of "air bubble" made from mucous. Sort of like what lungfish create underwater.
There really isn't much about DB that is technically realistic when it comes right down to it.
Why should the physics have to be a mock up of the reality that we know?
If you really understand the internals, it makes no difference at all. What it comes down to is learning curve. The easier it is for lay users to figure out what's going on in a sim, the more likely they are to pick it up and continue playing with it.
-
I'm going to have to agree with PY here. I liked buoyancy too
How hard would it be to just have .setboy increase and decrease the buoyancy of a bot? If you really want to be realistic with it you could have it control the size of an air bubble, so setting it high increases the size of the bot but keeps the mass the same, decreasing density, while decreasing it makes the air bubble smaller, increasing density. You could also use it to change the size of a bot when buoyancy is disabled.
How about that?
Removing .setboy will cause backwards compatabiltiy problems, like with PY's Alga Stratificus (which I qiute liked), so if you're aiming for complete backwards compatability for 2.4 from 2.37.6 (which Eric is) then reincluding it would be a good idea.
How a special option to 'enable buoyant pond mode', which will overide all your environmental settings to give you an environment similar to 2.37.6's pond mode with buoyancy enabled, setting y-axis gravity and fluid density automatically?
-
There's no such toggle because Bouyancy is assumed to be an emergent property of liquid properties. To disable bouyancy you'd have to either disable gravity or turn fluid density to 0.
Absolutely no problems with this.
That is exactly why I said that pond mode over-rides other aspects of the physics and that for the purposes of pond mode, Gravity is irrelevent as bots are assumed to have neutral bouyancy.
You are just over complicating a very simple concept.
What I'm saying is that staying at exactly neutral bouyancy is difficult, even in real life. If you were in a sea in Jupiter and were 1% off, your acceleration would be quite different from the same scenario on Earth. My point is that the magnitude of gravity changes the margin for error.
And my point is who the hell cares?
As long as the bouyancy controls work the way they are supposed to, I couldn't give a crap what real life says about it.
I didn't remove it as much as pull the rug out from under it. My real point is that when we reintroduce it, we should treat it as a constructable unit, and so have hooks on the cost page for changing the cost per unit, same as with shell and slime. I'd prefer it had another use, so it wasn't just for bouyancy control, in the same way that shell isn't just for balast.
Yes that would work. I still think this is just overcomplicating things though.
If you really understand the internals, it makes no difference at all. What it comes down to is learning curve. The easier it is for lay users to figure out what's going on in a sim, the more likely they are to pick it up and continue playing with it.
I really do not agree with you here and maybe this is why I don't really like 2.4 all that much.
Frankly I don't care about mirroring real physics so lang as the game plays well and does what you would expect it to.
The physics controls in 2.4 are over complicated and confusing. Heck if I was new to the game I would take one look at all those settings and run a mile.
Most of the time I simply can't figure out how to make the bloody things work at all. It's more guess work than anything else unless you really understand every litle detail. I much preferred a simple slider for gravity and for friction. 2.4 is impossibly over complicated. I just don't like it.
-
How a special option to 'enable buoyant pond mode', which will overide all your environmental settings to give you an environment similar to 2.37.6's pond mode with buoyancy enabled, setting y-axis gravity and fluid density automatically?
Good idea Elite....
Oh wait a minute...
Didn't we already have that once before?
-
You seem a little combative PY
And my point is who the hell cares?
As long as the bouyancy controls work the way they are supposed to, I couldn't give a crap what real life says about it.
The smaller the margin for error, the more precise any evolution has to be to make a bot that can both sink and swim. It changes the fitness landscape. It creates more seperation between any populations of sinkers and floaters. It amplifies extremes.
If you don't really care, you can just set gravity to any value you like.
I really do not agree with you here and maybe this is why I don't really like 2.4 all that much.
Frankly I don't care about mirroring real physics so lang as the game plays well and does what you would expect it to.
The physics controls in 2.4 are over complicated and confusing. Heck if I was new to the game I would take one look at all those settings and run a mile.
Most of the time I simply can't figure out how to make the bloody things work at all. It's more guess work than anything else unless you really understand every litle detail. I much preferred a simple slider for gravity and for friction. 2.4 is impossibly over complicated. I just don't like it.
The problem isn't the core physics. That's controlled by very few parameters. The problem comes in the disconnect between the physics tab and the advanced physics tab. Friction is also a little confusing, I'll probably combine z axis gravity and the coefficients into two sliders.
Physics basically comes down to 7 choices for physics in 2.37 and 9 essential choices for physics in 2.4 (2 for friction, 2 for fluid properties, 1 for planet eaters, 1 for Zero Momentum, 1 for Brownian, 1 for bang efficiency, and 1 for gravity).
Probably the physics tab needs to dissappear and have the advanced physics controls replace it.
However, I think you're exagerating to say that physics made more sense in 2.37. How many people had any idea what swimming factor did? You had to look in the source code to figure it out.
I think you're being a little neophobic. You were intimately familiar with the older version's physics and code, and you find it discomforting to find yourself essentially a newbie again in some areas.
-------------------------------
How hard would it be to just have .setboy increase and decrease the buoyancy of a bot?
My only concern is in the "automatic" nature of the old version. Shell decreases bouyancy, yet its effects are effortlessly removed by setting bouyancy to 0. Ideally I'd like to see some consequences that have to be weighed. Having setboy be a air bubble or something similar, as you describe, so that it effects final bouyancy instead of overriding it, would be acceptable to me. I'd also like to see some costs involved in increasing bouyancy the same way cost is involved in decreasing it (constructing shell).
How a special option to 'enable buoyant pond mode', which will overide all your environmental settings to give you an environment similar to 2.37.6's pond mode with buoyancy enabled, setting y-axis gravity and fluid density automatically?
Which brings up a new point/idea: Several preset default settings you can select. Old school pond mode, F1 default, etc. that automatically set various options to the proper value for you.
-
You seem a little combative PY
Sorry bout that. I've been spending too much time debating at EVC Forums (http://www.evcforum.net/cgi-bin/dBoard.cgi)
The problem isn't the core physics. That's controlled by very few parameters.
You are right about that. The problem really has very little to do with the actual physics engine. it is all about how intuitive the controls are. I just don't like them in 2.4. I find the controls have little or no meaning until I go into the advanced tab. then they are a littl more like the old stuff.
Probably the physics tab needs to dissappear and have the advanced physics controls replace it.
I would definately prefer that.
However, I think you're exagerating to say that physics made more sense in 2.37. How many people had any idea what swimming factor did? You had to look in the source code to figure it out.
It didn't really do anything much at all. Supposedly it enabled wiggly things to provide locomotion by wiggling but somewhere down the line they lost the ability to do so. I could never really get my head round Carlo's code that made them do it so I never really managed to re-introduce it.
I think you're being a little neophobic. You were intimately familiar with the older version's physics and code, and you find it discomforting to find yourself essentially a newbie again in some areas.
I won't argue with this.
My only concern is in the "automatic" nature of the old version. Shell decreases bouyancy, yet its effects are effortlessly removed by setting bouyancy to 0.
Shell was never part of the bouyancy equation. That wasn't by design. It should have been part of it. Increase in shell should undoubtedly cause negative bouyancy which would have to be countered by raising the value in .setboy. Maintaining a non-zero setboy value should in turn cost energy proportional to the difference between it and zero. that too was never implemented but probably should be.
You just have to think of .setboy as a universal all inclusive method of modifying bouyancy. It's one of those things that has no correlation in reality. Bit like shots, ties and so on. It doesn't need a correlation. if we force bots to be realistic then we have to redesign the entire game from the ground up.
Which brings up a new point/idea: Several preset default settings you can select. Old school pond mode, F1 default, etc. that automatically set various options to the proper value for you.
That would work just fine provided that the new physics is able to generate a world that mimics traditional pond mode.
I don't know whether the physics are just buggy but I can't make them do anything much at all. Sometimes I change a setting then change it back and it refuses to go back at all. often the only way to get it back is to turn of DB and restart it. I seem to recal Testlund reporting something similar a while back.