I'd rather not have aiming (at where the target will theoretically be in the future) be even more difficult than it is now.
Do you think the ability to do that should be cost free?
Actually, I think the F1 (and other competitions) ruleset should be changed to have (small) costs for math operators. The cost amount could be balanced to remove the energy advantage that SG bots have over bots which actually use conventional conditions, without making the cost so high as to make SG bots unfeasible.
I rather expect this would cripple Guardian, too, since it uses a ridiculous amount of math, and quite a bit of repetition of identical DNA, to avoid doing any unnecessary* stores.
*unnecessary meaning temporary variables. At the moment using temporary variables costs energy and saves CPU time. I went the opposite direction with the version of Guardian that's in the league - energy efficiency at the cost of CPU efficiency.
Although Guardian is capable of predicting positions in the future (with semi-decent reliability), if it is tied to anything, accuracy goes right out the window thanks to the tie physics. I'm not suggesting that 'get predicted position of bot after N cycles' should be a command, though. That'd take all the challenge out of trying to give a bot better shooting accuracy.
Also, I have been working on a more CPU-efficient version of Guardian (much shorter DNA length, due to replacing a lot of the duplicated DNA with stores to temporary variables), but haven't entered it in the league yet because it turns out that neither version of Guardian can currently beat Rabidus reliably (and the faster version gets stomped by Rabidus more reliably than the version currently in the league does). Rabidus, Etch, and Guardian seem to have a rock-paper-scissors thing going.
I've also been trying to work on some multi-bots, but have been having a great deal of trouble with ties - fixlen and fixang aren't working reliably for me. They're either bugged, or I haven't figured out how to use them properly. What little documentation there is (about fixlen and fixang) is more or less useless for actually figuring out how to use them, so it's a little hard to tell whether I'm feeding them the correct input (e.g. angle relative to the eye? or to the bot's aim? or to 0?), and whether they're behaving the way they're supposed to be.
I'm trying to use fixlen to move a parent and child bot a short distance away from each other after the child is born*, but it doesn't do anything to them unless I drag them apart manually (at which point they snap to the specified (fixlen) distance).
* = I'm replacing the tie and waiting for it to harden first. That's all going fine, fixlen and/or the tie length just aren't doing anything to the bots' positions until something moves one of the bots. I'll probably try making them thrust apart a little next, to see if that engages the snapping-into-place.
The aforementioned bot forms a pair, with each having an eye which looks everywhere except at the other bot in the pair. I've been trying to set them up such that when one bot in the pair sees another bot, it will rotate their tie to spin the bots so that both bots can see it. So far I can't get it to rotate them towards the target, but if I try to move one of the bots manually, they snap back into the same angle they were at before. So, fixang is definitely doing *something* - just not what I would like it to do. I've moved the target around them and confirmed that they are seeing it, but they still snap back to the same (wrong) angle.
Attempting to transfer coordinates over ties seems to be rather a pain in the ass, too (easier to just rotate the tie to spin the bots - or it would be, if it was working).
I haven't finished exhaustively testing everything to make sure fixang really is the problem, though, which is why I haven't posted a bug report on it yet (plus I prefer to know why something is doing what it is before I post a report).
As for bots having multiple ties, multi-bot internal communication is hampered significantly by the fact that you can only write one value through one tie per cycle, and if you want to read a value through a tie, you can also only read one per cycle (except for tref* vars). One thing that might help would be having tin1-tin5 which read from out1-5 on one tied bot (same bot that tref*/tmem* etc would work on).
Getting back to multiple ties, Guardian, for example, uses multiple ties in two situations:
1. If you are tied to another bot, and it is a friendly (or tiepres is 0), you can still tie to an enemy or veggie to kill or feed on them.
2. If you are tied to another bot, and it is a veggie, you can still tie to an enemy to kill them.
Being restricted to one self-made tie at a time would be rather a pain, since you would have to deltie your existing tie in order to make another, and you can't deltie a birth tie (so you would have to replace it with a regular one first). (Can you even delete a tie to one bot while tying to a different bot in the same cycle? I've determined that you can't send values through a tie on the same cycle that you form it, although the version of Guardian in the league tries anyways)