Why aren't you using 2.42?

[EricL]

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.

[EricL]

- 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.

[EricL]

(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.

[Numsgil]

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.).

[PurpleYouko]

That pretty much sums it up Num.

Couldn't have put it better myself  

[Elite]

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.

[Numsgil]

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.

[Elite]

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?

[Numsgil]

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.

[PurpleYouko]

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.  

[Endy]

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.

[abyaly]

Obviously I don't want to call it Darwinbots Extreme, hence the problem.

The easiest solution would be calling it DarwinBots++ 0.5

[Numsgil]

That's actually not to bad.

[PurpleYouko]

Yeah I kind of like that too.

[EricL]

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.