Messages

2221

DNA - General / Tie question (2.4A)

« on: March 20, 2006, 10:56:30 AM »

What, you mean do some actual work?  But asking random questions of the cloud is just so much easier...

2.37.6 exhibits the same behaviour I.e. fire a tie in cycle n and numties and all the tref sysvars arn't available to the bot until the n+2 cycle.

I won't try to do anything about this in 2.4.

2222

DNA - General / Tie question (2.4A)

« on: March 20, 2006, 01:49:41 AM »

Understood, but did this change in 2.4 or has it always been this way?  I.e. have people been coding their bots knowing that ties take a few cycles to form, knowing they can't rely on .numties, etc. the cycle after they fire a tie or is this delayed reaction a new thing?

2223

DNA - General / Tie question (2.4A)

« on: March 19, 2006, 10:30:06 PM »

If I sucessfully shoot a tie during the execution of my DNA on cycle n, should *.numties and the *.tref sysvars be updated and able to figure into cond statements during the n+1 cycle?

I'm seeing behaviour in 2.4A where I shoot a tie, it suceeds, but *.numties, etc. don't get updated in time to be used in the following cycle.  They update for the n+2 cycle.  This makes my tie shooting gene which is conditional on numties fire twice.  

Looking through the code, I see that FireTies() is called pretty late in the cycle, after readtie(), which updates the tref sysvars and Update_Ties(), which updartes .numties.  So, at the end of a cycle, new ties may have been sucessfully created during that cycle, but that information is not yet reflected in the bot's memory arrays.  

Then, on the next cycle, ExecRobs() (which executes the robot DNA and evaluates the gene cond statements) is called pretty early, before readtie and Update_Ties get a chance to update the bot's memory with the tie results of the previous cycle.  This means that it takes 2 cycles before .numties, etc. read correctly.

Bug?

-E

2224

Bugs and fixes / Fixed Console Crash in 2.4A

« on: March 19, 2006, 03:01:04 PM »

Griz:  Yes, this robots.bas includes the gene activation fix.  You can cut and paste fixes individually if you want, they are pretty independent of one another -  or it might just be easier to drop the entire file over the other and build, unless you have made private fixes yourself in which case you will need to merge by hand.

Cheers,

-E

2225

Bugs and fixes / Fixed Console Crash in 2.4A

« on: March 19, 2006, 02:56:40 PM »

Thanks Nums.  I was planning on sending you some mail to see how I could best be of help.

If the C++ version isn't imminient, then I think maybe for the next few weeks, I'll keep patching 2.4 as I come up to speed on DB, drop a 2.4B, fixing the things that were broken since 2.37.6 and working towards that being the stable VB platform so people can get off of 2.37.6.  With one exception, I've no inclination to do any new feature work in VB, just maybe fix leagues and internet sharing.  Maybe.  I'm thinking a few weeks max as I explore and come up to speed.  (The one exception is maybe some experimentation on codon-level encoidng for in-genome mutation probability.  Still owe a proposal on that.)

After that, I'll switch over to helping out on the C++ fork and ping you for some work items at that time.  I have it building now, but have some link errors I need to dig into.  I'll send separate mail on that.

-E

2226

Bugs and fixes / Fixed Console Crash in 2.4A

« on: March 19, 2006, 02:23:41 PM »

This was bugging me so I fixed it.  2.4A crashes with an error '91' if you attempt to execute a command in a console window that was opened on a bot that has since died.  The routine evnt_textentered() in console.frm did not check whether the robot's console was still valid.  I added a check (line 173 in console.frm).

Additionally, I added a line in KillRobot() in robots.bas to indicate in the console window when the robot for that console has died.   (line 1461 in robots.bas).

Source modules attached.  To find changes, search for the string 'EricL'.

-E

2227

DNA - General / Venom impact on .fixed

« on: March 18, 2006, 01:41:22 PM »

My $0.02.  Warning, opinion spewage below.
/Soapbox on

Venom doesn't affect conspects: is this too artificial?

I would say yes.  I changed my little learning bot to use info shots to fix prey instead of venom after the discussion above and quickly found they were fixing each other occasionally with all those fixing info shots flying around until I added the .fixed checking/resetting gene.  So, I'm already coding my bots against a sort of anti-venom from conspecs.  I'd (perhaps naively he says) state venom should indeed impact conspecs and that if a species needs to avoid venom from conspecs, either they grow a sufficient shell, aim better or code around the impacted location (e.g. if they shoot *.myeye venom, use *.refshoot for conspec recognition instead of *.refeye.

Should bots be able to evolve venom resistance? How should resistance to venom be controlled?

I'd say sure, bots can evolve venom resistance, but not in anyway that the engine is aware of, which is essentially saying no to what I think is the essence of your question.  Bots can evolve whatever ways they want to work around the impacted memory location or evolve ways to prevent it from getting overwriten in the first place - thicker shells, etc. but I'm kind of naturally resistant to adding more n^2 feature-specific state for the engine to carry around for each bot.  The engine would need to track each bots resistance to each type of venom, we would need to add some sort of *.mkvenres sysvar, etc. or whatever the point being the engine has special case code for this functionality.  

Now, this is where a personal philosphy of mine rears it's ugly head.  Gack, how do I say this clearly?  I think a highlevel design philosophy for DB should be for the DB engine to focus as much as possibile on general physics, on simulating and providing data about artifacts of the bot's world and that it should try to remain out of low level features where possible and be as stateless as possible with respect to how much bot specific, feature specific state it carries around.  That is, to a reasonable extent, my preference is for the engine to provide the environment and let specific features such as venom resistance evolve within the DNA.  That's not very clear I know, but perhaps using an example....

Say we wanted to provide the ability for bots to dodge shots.  On the one hand, we could provide all sorts of special case capabilities for this one feature: *.mkdodge and *.refdodge sysvars, etc. and let the engine do all the work of maintaining state about each bot's shot dodging ability, how that wears off over time, figuring out if and when bots successfully dodge shots, maybe shots with higher .shootvals are harder to dodge, etc.  This is what I would term a whole bunch of feature specific code in the engine, a whole bunch of feature-specific state.   In this design, the engine would be intemently aware of all the nuances of this specific feature.  

But my preference would be to instead enhace the engine to make shots tangable and visable I.e. make them part of the world physics in a general way.  Any shot dodging ability would have to evolve or be coded for in a bot's DNA, but so could potentially lots of other features without the engine being explicitly revved e.g. hiding behind veggies, shooting waste as a protective screen, anti-shot shots, child sacrifice, perhaps tieing to a shot? and so on.   The engine remains as general as posssible - all it does is calculate who sees what shots and handle the physics of that (yea I know, not trivial) but the point is it remains focused on the physics of the world, providing the environment for specific capabilties/features to evolve or be coded for, but not getting bogged down in feature specifics.  

Whew.  I needed that.

/Soapbox off

2228

Bugs and fixes / Sysvar Documentation bug

« on: March 18, 2006, 10:43:03 AM »

Sorry, I should have been more specific.  

.paralyzed is included in the sysvars2.21.txt that you get when you unzip the latest 2.4A download.  

It is not included in the download location where most people get it when they follow the instructions to install 2.37.6.
-E

2229

DNA - General / Venom impact on .fixed

« on: March 17, 2006, 06:42:22 PM »

Random thought:  I might be happy to restrict bots to one kind of venom.  That way if you want to shoot multiple kinds of venom, you have to be a multi-bot.  Simple way to keep the venom sacs and costs separate and one more reason to evolve MB level complexity.

-E

2230

DNA - General / Venom impact on .fixed

« on: March 17, 2006, 06:38:02 PM »

FYI, that is preciesly what led me to this thread. My my first bot uses venom for exactly that: conspec confusion to avoid attacks then fixing in place to prevent the prey from running away.  I also shoot different venom at differnt bots I.e. conspec confusion for attackers, .fixed venom for veggies in motion.  The latter is useful for dumb bots like mine that don't have sophisticed vision, trajectory plotting or shot aiming (yet).  Eating stationary salad is just easier.

-E

2231

DNA - General / Venom impact on .fixed

« on: March 17, 2006, 03:47:25 PM »

Ah.  The subtlty that one design point for venom was that the venomized bot is prevented from changing the impacted location back until it wears off escaped me.  Also, I have not looked at info shots yet.  Had I done so, I would have perhaps saved us all some typing.  Please hang on a moment while I remove foot from mouth.

So, yup, my propsal is akin to getting rid of venom completly.  Let's not.  To prevent bots from changing the impacted location until the venom wears off, which sounds like a fine feature of the world to me, the engine [you]must[/you][/I] maintain the state.  I humbly withdraw my proposal.

Perhaps I'll look through the code at all the toggles and propose something on expiring all types of venom... but not today...   :banghead:

-E

2232

DNA - General / Venom impact on .fixed

« on: March 17, 2006, 03:05:45 PM »

FYI, one reason I like the idea of venom replacing the actual location in the actual memory array is that the bot's memory is then the same for both the venomized bot and other bots around it who may look at it's memory.  The engien doesn't have to "fake it out."

For example, when playing around with venom, I think I saw that even after bot A used venom to change bot B's *.myeye, *.refeye for bot A still returned the old value.  Might be a bug, but I think what a bot sees when it looks at itslef and what other bots see should be the same.
-E

2233

DNA - General / Venom impact on .fixed

« on: March 17, 2006, 02:42:11 PM »

It's not completly thought through.  For example, it may end up being just too difficult for bots to code for policing their own memory, selection might favor having a super thick shell, etc. but here's he idea:

The engine would retain all the present code for deciding if venom makes it to a bot, .mkshell would work the way it does today in impacting venom shots, etc.  But if the venom shot was successful, instead of the new value being 'asscoiated' with the specific memory location in the victum and used as that value by the engine if the bot is still paralyzed, the new value would actually overwrite the location in the bots' memory.  The engine would no longer need to remember the previous "real" value becuase it would no longer be the engine's responsibility to put the "real" value back.  The engine would no longer maintain a count for how long venom lasts.  The .paralyzed sysvar would go away.  Venom would last forever unless the bot heals' itself by detecting the change and rewriting the venomized location back to an appropriate value (or another bot of the same species helps perhaps - can you say 'anti-venom venom'?).  How does a bot know what the 'real' value is?  That would be entirely the resposibility of the bot.  The engine would NOT remember this.  It's stateless here.  The bot would have to code for that in it's own DNA.  Think of the way it works for .Fixed today, but for all memory locations.  Venom wearing off becomes totally the resposibility of the bot, not the engine.  Don't want to wory about policing your own memory?  Grow a really thick shell!

The .shootval for a -3 shot would be used not for determining how long the venom lasts but instead perhaps imapcting the distance of the venom shot or the probability of it getting through the victum's shell (like it does for -6 shots I think).   The more venom you used, the farther it goes, the higher the probability of it getting through the shell, the more it costs you.  .mkvenom works the same way it does today.

-E

2234

DNA - General / Venom impact on .fixed

« on: March 17, 2006, 01:44:43 PM »

Got it.  My question was less about coding for anti-venom and more about generating discussion on the  philosphy of the DB design in this area I.e. more about the question of what should be handled by the engine as part of the world's physics and what should be handled by the bot.  Let me try to explain.  I think of venom as three main things 1) the ability for a bot to semi-persistantly (I.e. longer than a single cycle) overwrite a mem location in another bot 2) the fact that the DB engine maintains state about this for how long it lasts and 3) the fact that the engine, not the bot, is generally resposible for putting things right when it wears off (else, why maintain the state?).

Now, 1) makes perfect sense to me because without the ability for bot A to potentially impact bot B's memory for longer than a single cycle, the world would be smaller, the scope of possible bot variation would be less.  But a question I pose is why should the engine be resposible for making it wear off?  Should venom wearing off be world chemistry or bot genetics?

2) is a design decision IMHO.  We could decide that the engine should maintain absolutely no state what so ever about venom I.e. that it is entirely the responsibility of the bot to check for venom effects and code for anti-venom via DNA self-checking approaches for all types of venom.  This raises the bar for coding for anti-venom, puts more stuff into the DNA, simplifies the engine but I don't think it has an impact on diversity I.e. it does not reduce the size of the space of all possible organisms or adaptations.  Personally, I think I favor this approach.  I like simplifying the engine and putting more into the DNA as long as it maintains maximum diversity potential.  Besides, there are problems with the engine maintaining state about venomized bots.  What if a bot shoots multiple kinds of venom?  What it a bot gets venomized by multiple bots with different venoms?  Should the engine maintain separate venom countdown state about each and every memory location for every bot I.e. have a separate .paralyzed sysvar and maintain separate countdown timers for all the different possible ways to get venomized?  Today this is kind of broken in my opinion as there is only a single paracount for each bot.

3)  Okay, so, we can decide (as the DB powers that be have in fact done) that venom wearing off is in fact chemstry, not genetics, that it is an artifact of the world physics and that it should be the responsibility of the engine to maintain state and track this.  Okay, I'm fine with this, but then lets be consistant.  If venom wearing off is the resposibility of the the engine, then all venom should wear off without the bot having to do anything.  A bot might and should be able to make it wear off faster by adding anti-venom code to it's DNA, but IMHO this should not be a necessary condition for any and all venom wearing off eventually.   If we are going to have the engine maintain venom state and make venom wear off, then it should do so regardless of what kind of venom it was.  Personal opinion.

Now, I fully realize that there is a lot of code history and that the engine, design and sysvars/mem have evolved over time (pun intended).  There will always be inconsistances like this in any version.  I just wanted to generate some discussion as to whether in future versions, we want to address this in some way.  The two possibilties I see are

a. Getting rid of all venom state in the engine and making it entirely the responsibility of the bot to code for anti-venom.  Bots can use venom to write to another bots memory, most thigns work liek they do today I.e. the size of the victum's shell and the size of the venom shot dictate whether or not it gets through, etc. but how long it lasts if it does get through is completely the resposibility of the venomized bot.  If the bot has no anti-venom DNA, the venom lasts forever.

b. Enhancing the engine to handle multiple types of venom and enhancing the state maintained by the engine so that it remembers the value of toggles before they were venomized and puts them back when the specific venom that impacted that memory location wears off.

Hey, if a newbie isn't good for stirring things up a little, what the hell good are they for anyway? :)
-E

2235

Bugs and fixes / Sysvar Documentation bug

« on: March 17, 2006, 10:33:41 AM »

It's in the actual sysvars2.21.txt file in the download (#837), just not in the online copy at the link you mention.

Thanks for the Wiki education.  You learn something new everyday.  I'll edit the entries.

-E