Darwinbots Forum
Code center => Bugs and fixes => Topic started by: abyaly on April 02, 2008, 11:28:56 AM
-
As topic states.
Coincidentally, 820 is the memory location used by .mkslime and by .in10.
I don't know if .in9 has a similar collision.
-
Whoops. Good catch and exactly right on as to the issue. Made an error with the range on the new in/out sysvars.
Fixed in 2.43.1g.
Here are new numbers.
sysvar(163).Name = "out1"
sysvar(163).value = 800
sysvar(164).Name = "out2"
sysvar(164).value = 801
sysvar(165).Name = "out3"
sysvar(165).value = 802
sysvar(166).Name = "out4"
sysvar(166).value = 803
sysvar(167).Name = "out5"
sysvar(167).value = 804
sysvar(168).Name = "in1"
sysvar(168).value = 810
sysvar(169).Name = "in2"
sysvar(169).value = 811
sysvar(170).Name = "in3"
sysvar(170).value = 812
sysvar(171).Name = "in4"
sysvar(171).value = 813
sysvar(172).Name = "in5"
sysvar(172).value = 814
sysvar(218).Name = "out6"
sysvar(218).value = 805
sysvar(219).Name = "out7"
sysvar(219).value = 806
sysvar(220).Name = "out8"
sysvar(220).value = 807
sysvar(221).Name = "out9"
sysvar(221).value = 808
sysvar(222).Name = "out10"
sysvar(222).value = 809
sysvar(223).Name = "in6"
sysvar(223).value = 815
sysvar(224).Name = "in7"
sysvar(224).value = 816
sysvar(225).Name = "in8"
sysvar(225).value = 817
sysvar(226).Name = "in9"
sysvar(226).value = 818
sysvar(227).Name = "in10"
sysvar(227).value = 819
-
I should point out that this bug only impacts sysvar name to number mapping. The code to connect the actual underlying in/out mem locations as enumerated above should work correctly in 2.43.1f. So, if you want to test your code in 2.43.1f, you can use numeric addressing (using the locations as above) instead of the textual sysvar names and it should work correctly.
-
Ah. That makes sense.
Don't know if you also caught this while fixing that, but .out10 seems to be mapped to 815.
In an unrelated note, it really irks me that the .in sysvars start at a "10" and the .tin sysvars start at an "11."
-
Along that same train of thought:
It would be nice if (t)in1-10 were contigous, and (t)out 1-10 were contigous. It could be treated as an array then.
-
Unfortunatly, the first 5 in sysvars come right after the first 5 out sysvars, so I could not make them contigious when I added the new ones. For the tin/tout pairs, I followed the same patter as the in/out pairs under the assumption that consistency was preferred. I could of course change both the in/out and tin/tout to be contigious if people wanted. Happy to do this, but it will break backward compatability for the first 5 in/out pairs.
Please vote:
Option 1) Do nothing. They arn't contigous, but they are consistent and backward compatable.
Option 2) Only make the tin/tout pairs contigious. We lose consistency, but gain contigousy (sp?) for the tin/tout pairs and still preserve backward compatability
Option 3) Backward compatability be damned, I want them both contigious.
Ah. That makes sense.
Don't know if you also caught this while fixing that, but .out10 seems to be mapped to 815.
Yea, caught that. Was part of the typo.
In an unrelated note, it really irks me that the .in sysvars start at a "10" and the .tin sysvars start at an "11."
I would fix this too under option 2 or 3 above
-
Voting for 3. Won't break compatibility on bots that reference the vars by name. Most old bots are trashed by now anyway.
-
Backward compatibility be damned I would point out, though, that the only breaking changes would be to evo bots that use in/out pairs, since hand authored bots use .in and .out, which get parsed by the program however the program sees fit.
-
I vote 3. I dont see why I would want backwards anything. I'm mroe for forwardism thank you.
-
Yeah 3, all the old bots are already falling appart anyway, even excalibur fell appart in a recent drop.
Can't you outsource running the leagues or something So we can get some working bots in there...
And I hope you're working on the new bucket bug it keeps whiping my sims because the bot is simple and gets stuck while staring at ghosts...
Also it seems like the best way to prevent the bug is by having a very high veggy cap, lots of veggies and increased energy gain... it seems like whenever a veggy reproduces in a bucket the bucket gets cleared from ghosts... but if nothing is happening in the bucket the bots will eventualy die from trying to kill the ghosts... and obvisouly over enough time the bot is bound to get unlucky sooner or later and die out.
-
Yeah 3, all the old bots are already falling appart anyway, even excalibur fell appart in a recent drop.
In general, bots should not fall apart due to version differences unless they are explicit design choices such as making eye sight distance a function of eye width. If Excalibur used the omnieye, this could explian the change. If someone has a specific example of a bot that broke without reason due to a version change, I would be happy to investigate.
Also note that choice 3 was chosen and was implemented as of 2.43.1g.
And I hope you're working on the new bucket bug it keeps whiping my sims because the bot is simple and gets stuck while staring at ghosts...
I'm peddeling as fast as I can. It's a busy weekend, I'll try to get the next drop out Sunday night.