2.43 Changes

[Numsgil]

There are two ways you could think of bot commands: kinematics or dynamics.

At first, when I was playing around with the new physics, I imagined bot commands to be dynamic: that is, specify a force and have the bot respond appropriately.

However, as I've played with it more, I think a kinematic approach is preferable.  That is, specify a desired action and have the amount of effort needed to arrive at that result be calculated.

Mass and radius for bots are highly variable, so having sysvars use forces means that evolution is going to have a harder time to accomplish a comparable task using kinematic controls.

So then, if you view aimdx and aimsx as being angular velocity requests, it becomes pretty easy to implement rotational costs even if you don't have a proper physical system up and running.  All you need to do is add another variable to the robot data structure to remember your old aim.

It may seem a little odd to do it like this, where storing, say, 5 into aimdx every cycle means you don't get charged anything, but I think it makes the most sense.

[EricL]

I do indeed find the kinimatic approach to be non intuitive.  A big problem I see is what to do about cases when the bot attempts to do something that cannot be done.  They attempt to turn but a tie with a fixed angle prevents them.  They attempt to accelerate to some velocity, but are against a shape or a fixed bot.  A fixed bot attempts to pivot a hardened tie with another fixed bot on the other end and so on.

There will be many such cases where the action cannot be completed or can only be completed partially or where completing the action in a single cycle would require enormous amounts of nrg, more than a bot should be able to expend in a single cycle.

Another problem I see with the kimimatic approach is the difficulty in calculating what amount of effort is required to achive some goal.  Imagine a bot tied to a large cluster of other bots that attempts to rotate.  Whiel it is relativly straight forward to take a specific applied force and calculate the effect translated to the bots in the cluster via the tie, it is rather difficult to do the reverse I.e. figure out what force needs to be applied to rotate the cluster about it's center of mass such that the bot rotates the requested amount.  Remember you have to integrate all the requests from all the bots in the cluster...

It may have shortcomings, but the dynamic approach seems to me to be more straight forward and intuitive.  Bot's apply forces, there are limits on the magnitudes of the forces they can apply per cycle, the resultant action is a consequence of the force applied and the world physics.  Results are not absolute.  If a bot applies a turning force with a fixed tie, the entire structure aquires some angular momentum but only an amount proportional to the force applied as a function of the mass and moment of the structure.  If a bot attempts to accelerate against a fixed object or torque a tie with a fixed bot on the other end when fixed himself, it still gets charged nrg proportional to the force applied even if no Work (capital W) is performed.

Bots may need to compensate for their mass and radius in the forces they evolve to apply.  But what's more, bots will need feedback logic to guage the results of their actions.  Matching velocity with another bot for example, will be an itertive process.  This seems immently intuitive to me.

The limits on the per cycle forces that are allowed to be applied per cycle should probably be a function of certain bot properties such as mass I.e. heavier bots can apply larger turning or acceleration forces per cycle than lighter bots can.  To deal with the issue you mention of differening mass and radius, I might suggest we change the paradym for the movement sysvars such that the value written represents a percentage of the max allowed or use some other scaling method such that the units of the force request take mass and moment into considertaion.  In this way, the same DNA works for small bots and large bots.

[Numsgil]

Yep, I agree that both kinematic and dynamic methods have advantages/disadvantages.  You briefly touch on it, but I think perhaps the answer is to use kinematic inputs and outputs to control dynamic forces.

After all, if you're scalaing .up by the mass of the bot, you really have a kinematic control controllong a dynamic process.  This would seem the best way to handle this to me.  Bots send information to sysvars in a way thats kinematic, but these are translated into forces which may or may not do what the bot expects.  As in your single bot as part of a multibot example, trying to go 5 .up may or may not accelerate you by 5 twips/cycle, but it does translate into the same acceleration for small and large bots, which avoids issues of scaling.

[EricL]

2.42.9u Buddy Drop Download

Okay, pound on this one.  It will be 2.43 unless something major comes up in the next couple of days.

I've seen a few posts related to league issues over the past week or two, but nothing actionable and thus I have made no changes in the area of leagues recently.  If you know of something that needs to be fixed for this release, for leagues or anything else, please bring it to my attention ASAP.  Thanks.

[EricL]

2.42.9v Buddy Drop Download

Changes in boolean stack behaviour and auto-costs this drop were significant enough to require one more buddy drop.  This will be 2.43 tomorrow unless someone finds a showstopper.

[Jez]

LOL. so much for the original week timeline for 2.43. You are a showstopper in your own right, thanks for all the time you have spent on this project. Respect.

[EricL]

Bump.

2.42.9w Buddy Drop Download

Addressed crash with venom shots and another with the mutation rates dialog.  Still on track to post as 2.43 late tonight or tomorrow morning PST.

[Numsgil]

After you post 2.43, don't make any source changes unless they're minor.   That'll give me time to find and set up a good source control system without you having to manually find and insert new changes into the system.

Ideally, I'd like the VB, C++, and C# sources to all be hosted by the same system, but physically seperate.  Sourceforge is always an option, even with the issues of GPL.

[EricL]

2.43 is released.   2.43 Download

Whew!!!!

I plan to take a few weeks away from DB coding and focus on other projects so the change rate should drop off to zero for a little while at least.  I will still be hanging around the forums and if any serious issues do crop up in 2.43, I'll take care of them and check any changes into the multiple forks once that is set up.

[Testlund]

Maybe you could update the link to this drop in the list of changes so it works to download from there too. It only seems to work downloading from the link here.

[EricL]

Maybe you could update the link to this drop in the list of changes so it works to download from there too. It only seems to work downloading from the link here.

Done.