Ties not working for some reason

[Bluchrome]

Ive been using DB for about 2 days now and I have a couple of questions and requests


1. Would anyone find time to post a list of all 'static' sysvariables. I need to know which ones change
2. Can anyone tell me why this bot refuses to shoot ties(it's not complete by the way)
3. if nrg is not maxed but the bot recieves nrg that will exceed the maxium is the difference converted to
    body. Or is excess nrg only converted to body when nrg = 32000 thus rendering the difference lost.


[div class=\'codetop\']CODE[div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\']' binary dormite
' Designed and refined by Bluchrome
' Atempt at a linear 2nd degree multibot
' the head feeds and the tail produces venom
' and poison and reproduces


' --------------------constants------------------

' types
def head 1003
def tail 1002
def notype 989
'not implemented as of yet

'conspec id
def conspec 230


'---------------memory locations----------------
def type 100
def tie 120
' unused right now
def hibernate 121
' 0 = not hibernating
' 1 = hibernating
' unused right now
def rotate 122
' 0 = rotate
' 1 = not to rotate
' set by the tie gene to prevent rotating before ties are formed




' -----------------initialize---------------------
'store initial bot type
cond
*.robage 0 =
start
.notype .type store
.conspec dup .out5 store
.tout5 store
stop


' -----------------body regulation------------------

' keeps the body at 1/3 of nrg as long as more than 900 body is there
' found this gene in the forums pretty neat modified it a bit

cond
*.body 900 >
*.nrg 32000 !=
start
*.nrg 3 div *.body sub .strbody store
stop


cond
*.body 900 <=
*.nrg 20000 >
start
100 .strbody store
stop

' ---------------- tie counter----------------------


cond
*.numties *.out10 !=
start
*.numties .out10 dup store .tout10 store
stop

'---------------despecialize-------------------------
cond
*.numties 0=
*.type .notype !=
start
.notype .type store
stop

' -----------------tie shooter---------------------
'disables rotating so that ties dont miss
cond
*.rotate 0 !=
start
0 .rotate store
stop


cond
*.numties 0 =
*.in5 *.out5 =
*.eye5 30 >
*.in10 0 =
start
.tie inc
.readtie inc
.rotate inc
stop

' --------------food finding---------------
'food finder

'only unspeciated or heads can find food
cond
 *.eye5 0 >
*.eye5 70 <
*.in5 *.out5 !=
*.type .notype =
*.type .head = or
start
*.refxpos *.refypos angle .setaim store
 *.refveldx .dx store
 *.refvelup 30 add .up store
stop

'--------------feeding----------------------
cond
*.eye5 70 >=
*.in5 *.out5 !=
*.type .notype =
*.type .head = or
start
4 .shootval store
*.refxpos *.refypos angle .setaim store
-1 .shoot store
*.refvelup .up store
stop



' -----------------idling--------------------
' aka search and destroy

cond
*.eye5 0 =
*.in5 *.out5 = or
*.robage 1 >
*.hibernate 0 =
*.rotate 0 =
start
*.aim 400 rnd 200 sub add .setaim store
30 *.vel sub 2 div rnd .up store
stop

'if hibernating dont roam just rotate
cond
*.eye5 0 =
*.in5 *.out5 = or
*.hibernate 1 =
*.rotate 0 =
start
140 rnd .aimsx store
stop


' ------------------counter(anti) tie------------------




'-----------------counter tie feed------------------
cond
*.tin5 *.out5 !=
*.trefnrg 0 >
start
-1 .tieloc store
-1000 .tieval store
stop

'-----------------hibernate genes----------------------
'bots cant hibernate till there 30 to prevent newborns from immediately hibernating
'because of lack of resources.
' Hibernated bots still look for food but they dont move anymore

cond
*.nrg 2700 <
*.hibernate 0 =
*.robage 29 >
start
.hibernate inc
stop

cond
*.nrg 9000 >
*.hibernate 1 =
start
.hibernate dec
stop

end



ive made a couple of tie feeders and they shoot just fine so what is the problem with him

[EricL]

Hi and welcome.

1. Would anyone find time to post a list of all 'static' sysvariables. I need to know which ones change

There are several recent topics in the Newbie forum with links to the official sysvar list topic.  The Wiki is also up to date as far as I know.

2. Can anyone tell me why this bot refuses to shoot ties(it's not complete by the way)

You have redefined the string "tie" to a location different from that used for creating ties, thus with the DNA is parsed, your tie code stores to location 120 instead of location 330.  Stores to location 120 don't do anything and will not cause a tie to be created.

3. if nrg is not maxed but the bot recieves nrg that will exceed the maxium is the difference converted to
    body. Or is excess nrg only converted to body when nrg = 32000 thus rendering the difference lost.

The difference is converted to body.  No nrg is lost.  BTW, excess nrg overflowing to body only works for nrg shots.  Tie feeding nrg or sunlight nrg for veggies for example does not currently overflow to body.  In these cases, the nrg is lost.

[Bluchrome]

Ah I see strangly when I first began coding I realized the alias and made a mental note to change it to ties must have slipped my mind.

I think you misunderstand what I said. What I mean is a list of sysvars which are persistent as far as I know the wiki doesnt explicitly state )for many vars) whether a var is maintained across cycles.

Thank you for the help!!!

[EricL]

Hmmm.  I don't think an exhaustive list exists as such currently.  It depends on the sysvar and the wiki documentation should tell you whether a sysvar gets reset or not, but it is probably not as clear or forthcoming as it should be.  (Feel free to improve it!!!!!)

Any mem location not explicitly reset by the simulator should persist across cycles.  This includes all the user-defined locations for sure.   All the sysvars that tell the simulator to do something for a single cycle like all the movement sysvars, .tie, .shoot, .backshoot, .repro, .mrepro, .fixpos and so on obviously get reset.  All the ones that are essentially informational and read only like all the .eyeX sysvars, .hit, .fixed, .numties, .fertilized, .poison, .shell, .body, .tiepres, all the refvars and trefvars and so on will contain a value written by the simulator for that cycle and thus will nuke any DNA written value each cycle.  Sticky control sysvars like the .eyeXdir and .eyeXwidth and .readtie (I think) should not get reset.  The rest are case by case.  It should be easy to tell by looking at the bot's memory using the bot properties dialog or the console.

[Bluchrome]

I will check out the memory consistency in my spare time with the console (I was trying to avoid that) and possibly update the wiki in my spare time. I was asking because somewhere I saw that the eye reference values are persistent even when the current focus eye 'sees' nothing causing basically a phantom bot.


Thanks for the help/suggestions (its so hard to spot coding errors sometimes when you program )

[EricL]

I saw that the eye reference values are persistent even when the current focus eye 'sees' nothing causing basically a phantom bot.

This would be a very bad bug that I imagine many people would scream about in short order.    Awhile back, there was an issue with some bucket-based perf improvements that caused some phatom bot issues, but that is long fixed.    The eye values should be and to my knowledge, are indeed all zeroed when nothing is in the focus eye.

Glad your having fun...  

[Numsgil]

I will check out the memory consistency in my spare time with the console (I was trying to avoid that) and possibly update the wiki in my spare time. I was asking because somewhere I saw that the eye reference values are persistent even when the current focus eye 'sees' nothing causing basically a phantom bot.

This has been fixed as far as I know.

Thanks for the help/suggestions (its so hard to spot coding errors sometimes when you program )

At some point it would be nice to have a DNA compiler, that checked for syntax errors and warned you about naming conflicts.  I'm not holding my breath, though

[Bluchrome]

That would be well appreciated. And again (It seems as of late my expressive skill have declined) what I meant was I saw somewhere that .refeye etc are persistent.

Also one quick question can bots delete ties they did not create and how would they address the tie. If they use the same ID as the creating bot then collisons(multiple ID aliased ties) would be a problem

And yeah I am having fun. I enjoy problem solving

[EricL]

The refvars should get reset if nothing is in the focus eye.  They didn't use to but I fixed that in recent versions.

Bots can delete ties they did not create.  Their tie number for the tie is different that that used at the other end by the tie creator.  They can gleam it through .tiepres or intuit it as the the tie port for the last tie attached to them that they did not create is essentially *.numties.

[Bluchrome]

I see...

They can gleam it through .tiepres or intuit it as the the tie port for the last tie attached to them that they did not create is essentially *.numties.

I know you can use tiepres but what if you also fired a tie in that cycle which would it refer to, and would numties still be usable if I also have ties.

[EricL]

Things get a little unpredictable when more than a single tie forms to/from a given bot in a given cycle.   In the case where you create a tie and one other bot ties to you in the same cycle, *.tiepres will either refer to the tie port you used to create your tie or hold a value equal to *.numties.  Which depends on the internal order of the bots in the internal bot array, which means which way it ends up is basically random for all intents and purposes from the bot's point of view.   In either case, the tie number for the tie you created will always be whatever number you choose (it can be addressed using whatever number you used).  

In the case where *.tiepres equals *.numties, then the tie the other bot created happened to be created last and *.numties is the tie port you can use to address the tie the other bot created.  If *.tiepres equals your tie port (or does not equal *.numties) then your tie was created last and *.numties - 1 is the tie port of the other bot's tie.

If you always use tie numbers greater than 10 say to address your own ties, then when *.numties is not what you expect, you can do

*.numties
*.tiepres *.numties !=
1 sub
clearbool
.deltie store

and be coverred excpet for the case where more than one bot tied to you in the same cycle.  If more than one other bot tied to you in that same cycle, things get more complicated.   Suffice it to say that the tie numbers of any ties you did not create will always lie in the range of 1 to *.numties.

I'm open to suggestions in this area.  Our tie system is lacking in many areas, not the least of which is feedback for bots to know what tie(s) went away in the last cycle.

In thinking about this, I could make a change so that ties you did not create always had contigious tie ports from yuour point of view starting at 1.  Thus, if there were N ties you know you created and still exist, then when *.numties was greater than N, you could do .deltie inc until *.numties equaled N.  If you always used high numberred tie ports for you own ties, you could safly do .deltie inc every cycle regardless of the value of *.tiepres or *.numties as an effective tie feeding defense.  I think I'll make this change in a forthcoming version barring better suggestions.

[Bluchrome]

I agree the tie system is a little convoluted for my tastes here are my suggestions:

perhaps the tie system could be implemented with a tie ID stack where the system resets the stack to reflect all the current ties each cycle. Thus tie IDs can be popped until the stack is empty, and new ties are formed by pushing tie IDs unto the tie stack. For this to work obviously some new operands would need to be introduced to manipulate the tie stack. (tiepop, tiepush perhaps).Also backward compatibility would be maintained.

Since I havent viewed the source files im not aware of how feasible(programming wise) this would be for DB

Oh forgot. The stack could also implement a overflow push out policy where new ties push the bottom ties out thus breaking them or a overflow blocking policy where overflow blocks new ties.

[Bluchrome]

One other question why is the degree system in DB equivalent to radians multiplied by ~200.

[Numsgil]

One other question why is the degree system in DB equivalent to radians multiplied by ~200.

I'm not sure of the original reasoning, but I'll bet it was to get a system that was approximately +- 1000.  1000 pops up in a lot of different places (size of memory array, body points, etc.)  Using degrees / 3 instead (so a range of +- 1080) was suggested once, but it's hard to adopt since it wouldn't be backwards compatible.