Almost, I think. Anything like that references whatever tie(s) is(are) pointed to by .tienum, I'm pretty sure, and tienum gets set when a tie is formed... But that would seem to lead to problems, wouldn't it? Hmm...
My understanding is that .tiepres is read-only and gets set when ties get formed, but never .tienum. .tienum is write only, always explicitly set by the bot itself and is not sticky. It gets reset to 0 every cycle and bots must set it again each cycle if they wish to direct the tie sysvars to something other than than the tie indicated by the value of .tiepres.
I've got it working right now such that if .tienum is 0, everything defaults to the tie with the port indicated by .tiepres. Everything, all tie operations, even those which use to only work if .tienum was set. This seems to work fairly well and has the nice side effect of lowering the bar to evolving sucessful tie behaviour. Tie operations which used to do nothing (because .tienum was 0) now default to operating on the last tie created or connected.
I think the tie ports are supposed to be the same for both bots. But again, I'm not entirely sure.
That is indeed is the way it has been in the code since I came along I.e. same port number at both ends. This is nice for multibots as they can contian genes which address specific tie ports without regard to when and if and in what order ties are created and avoid having to capture the tie connection event for ties they did not initiate.
But here is my problem with this. Multiple ties can happen in a single cycle, either multiple other bots tying to you in the same cycle or a bot tying to you in the same cycle you initiate a tie to another bot. There is only one .tiepres, so in situations where the two bots are not part of a multibot, it's quite possible a bot could initiate a tie to you and you would have no way to know the tie port and no way to address the specific tie. By making the tieports different at each end, the tied bot can be certain that the tieports of any new ties which connected to it in the last cycle lie in a narrow range between the value of .numties last cycle and .numties this cycle, allowing it to address the tie, find out about who conencted to it, etc.
Multibots have other means of corrdinating during morphogenisis. The cell which initated the tie can obviously address it and poke something into the memory of the other cell and so on. I think it makes senss to help the tie victim address the tie feeding off it...
There's a thread here, split from another topic, where PY and I discuss ties. Honestly, it sort of seemed to me like a complicated mess, so I started exploring different ideas of unifying the ideas in a more elegant framework, I just never got far enough into it to implement.
The whole tie scheme needs to be reworked; at the moment it's extremely ad hoc.
Agreed There are indeed a whole bunch of problems, some large some small. One small one for example is that there's no way to determine how stiff a tie is. I should probably add
.tiestiffness ASAP to go alnong with .tielen and .tieang.
More broadly, as has been widly dicussed, we need a paradym for addressing multiple ties with different tieports in the same cycle. I may spend some time in this area in coming weeks. I think I may expand ties to encompass spikes (ties to nowhere which are part of the bot morph which allow you for exampel, to fend off a rival and keep them out of shot or tie range - will require bot/tie collision detection) and ties to shapes as means for bots to manipulate them...
