Ties in 2.4

[Elite]

Here's what's working:
.tie
.deltie
.tienum
.fixlen
.sharenrg and other sharing commands
.tieloc
.tieval
.fixang

Here's what's not working:
.tielen1-4
.tielen
.tieang1-4
.tieang

But the sysvars .tieang1-4 are really useful for organising MBs

Also, the vision grid doesn't show ties underneath it, which is kinda annoying

There also seems to be no limit to the number of ties a bot can have, which might pose a problem for fixing the tie ports

EDIT: In fact, the limit is 9 ties

[EricL]

.tielen and .fixang should be working - I tested them pretty well a couple of versions back - but they won't work until you have multi status which doesn't happen until you've had a tie for 20 cycles.  This is how it should work as PY explained it to me so thats what I did.

The 1-4 sysvars have been on my list for a few versions, just haven't got to them.  Note that they also won;t work until you are multi.  I honestly don't know if they work today or not.  If you have a bot which uses them, that would help me test.

[Elite]

Yeah, you're right, .fixang does work

But .tieang1-4 and .tielen1-4 should work on soft ties too, shouldn't they?

As I see it, for the length and angle fixing sysvars you only need:

.tieang1-4
.tieang

.tielen1-4
.tielen

These would fix ties in particular angles and lengths, setting them to zero would cancel the effect, making the ties flexible again. If you want to set a tie angle to 0 just use 1256

And I think they should work on soft ties too, since then you can ready MB structures faster

[Elite]

What do you think of this for a revised tie system:

.tie

.deltie
.delport

.tiepres
.tiepres1-4

.numties

.tienum
.readtie

.tieloc
.tieloc1-4

.tieval
.tieval1-4

.sharenrg
.sharenrg1-4

.shareslime
.shareslime1-4

.shareshell
.shareshell1-4

.sharewaste
.sharewaste1-4

.tieang1-4
.tieang

.tielen1-4
.tielen

New sysvars are in bold. I'll explain:

.delport allows you to delete a tie port, so 1 .delport store would delete the tie in tie port 1

.tiepres1-4 allows you to read back to tie phase of the tie on each tie port

.tieval1-4 and .tieloc1-4 are tieportized versions of the originals, allowing for easier tie-feeding and better manipulation of MBs

There are also tieportized versions of the sharevars so that you can share independantly rather than with all, but keeping the originals, which affect all tie ports

What do you think?

[EricL]

I worry about

1) Adding tons of new highly specific sysvars
2) Only being able to address 4 ties rather than all 10 or N in a given cycle
3) Mechanisms for mapping ties to tieports to the 1-4 sysvars and the genome complexity of this
4) The future when there may be more than 10 ties allowed *See footnote
5) Future morphological features which may also require similar addressing of N possible components

Hows this for an idea.  There are special vector sysvars for which the behaviour of .store, .inc and other operators change.  Instead of storing a single value off the stack in a single mem location for example, they store N values off the stack into a vector of N "virtual mem locations".

Instead of

10 .tielen1 .store
20 .tielne2 .store
30 .tielen3 .store
40 .tielen4 .store

we do

10 20 30 40 4 .tielenV .store  'V for Virtual or Vector

we could also do

10 20 30 40 50 60 70 80 90 9 .tielenV .store

The number on the top of the stack indicates the number of locations to store I.e.  If you wanted to change some tielens but not others, maybe we use a negative number to indicate no change.  I.e.

-1 20 -1 40 -1 60 -1 80 -1 9 .tielenV .store

only changes ties with IDs 2,4,6 and 8  

If we follow this route, we only need add one new sysvar for each sysvar for which we want to have vector addressing:

.tielenV
.tielocV
.tievalV
.sharenrgV
.
.

This has the advantage that if we decide to increase the maximum nubber of ties for example, no new sysvars need be added.  We continue to support the current 1-4 sysvars for compatability, but these superset them.

Thoughts?

*I want to allow ties to nowhere in some future version.  Think of them as spikes or spines.  We need to implement tie collision detection first, but you can imagine a bot growing long spines to keep shot bot preditators out of range...

[PurpleYouko]

I like this a lot Eric.
You might need to increase the size of the stack though if we go this route. I can see some pretty complex stuff around the corner where 30 or 4 numbers could be stacked with mathematical operators to acheive some pretty spectacular dynamic combinations of effects.

[Elite]

You've got some great ideas Eric  

Generally, there has to be some way of manipulating multiple ties at once. For example, if I want to change the length of four ties I shouldn't have to:

1 .tienum store
10 .tielen store

then next cycle

2 .tienum store
20 .tielen store

Instead, it should be something simple like (using your idea):

10 20 .tielenV store

That way you can quickly and simply manipulate multiple ties

*********

Another thing, could we have a sysvar .birthtie that reads back 1 when a bot is attached to another bot via a birth tie

[Numsgil]

You can check out the New Tie Paradigm for the C++ version.  We should try bringing the two versions (2.4 and C++) together.  I'm open to entirely scrapping the system I have there for a new one.  I'm just saying let's be careful about creating a new system if it's just going to be supplanted a little later.

[PurpleYouko]

However, I don't see the point of .tieang, as it's just the same as .fixang, isn't it?

Just noticed this while re-reading the thread.

I have to point out that the two are definitely NOT the same. They serve an entirely different purpose.

Tieang was actually the first command that changed the angle of a tie just as Tielen was the first to change its length. The difference is that both these commands act on a temporary basis and will spring right back again as soon as they are able to.

Use of these commands allow a worm structure to "wiggle" and thus propel itself along. Check out Carlo's Vermis_P.

Also this

These would fix ties in particular angles and lengths, setting them to zero would cancel the effect, making the ties flexible again. If you want to set a tie angle to 0 just use 1256

And I think they should work on soft ties too, since then you can ready MB structures faster

If they work on soft ties then the ties aren't soft any more are they?
I don't have an objection to allowing ties to become hard faster at the expense of some energy perhaps.
Maybe .stifftie can be redesigned somewhat to fill this role. it never worked that well for its intended purpose anyway.

in summary, Fixang and Fixlen permanently change the default angle and length of a tie while Tieang and Tielen temporarily change the length and angle of the tie.
All tie commands can only work on a hardened tie since prior to that the whole system is soft, squishy and deformable. Additionally angles are free to be changed as much as you like during the initial non-hardened time.

[Elite]

Just noticed this while re-reading the thread.

I have to point out that the two are definitely NOT the same. They serve an entirely different purpose.

Tieang was actually the first command that changed the angle of a tie just as Tielen was the first to change its length. The difference is that both these commands act on a temporary basis and will spring right back again as soon as they are able to.

Use of these commands allow a worm structure to "wiggle" and thus propel itself along. Check out Carlo's Vermis_P.

Ah right, I get it, thanks for clearing that up  

.fixang and .fixlen = permanent
.tielen and .tieang = temporary

.tieang1-4 act more like .fixang though, and likewise with .tielen1-4 ... I think that what's happening is that they're not getting reset and so are permanently forcing the tie to the value stored in them

Also this

If they work on soft ties then the ties aren't soft any more are they?
I don't have an objection to allowing ties to become hard faster at the expense of some energy perhaps.
Maybe .stifftie can be redesigned somewhat to fill this role. it never worked that well for its intended purpose anyway.

in summary, Fixang and Fixlen permanently change the default angle and length of a tie while Tieang and Tielen temporarily change the length and angle of the tie.
All tie commands can only work on a hardened tie since prior to that the whole system is soft, squishy and deformable. Additionally angles are free to be changed as much as you like during the initial non-hardened time.

Ok, so hardened ties only for setting permanent angles and lengths

Hold on, Endy's Alga Tier uses .tielen1 to violently fling other bots away from it, and it does this while the tie is soft, so you can change the length of soft ties?

I'm confused  

I've got to do some experimenting in 2.37.6 ...

[Elite]

Yep PY, you're correct, .tielen .tieang .fixang and .fixlen only work once a tie is hardened, which takes 20 cycles

And the tie fixing commands are noticably different to the tie changing commands, the tie changing commands like .tieang spring back quickly, allowing for wriggling motions

[Numsgil]

I think the .tielen1 was an unexpected consequence, and PY really meant them not to work on birth ties.

[Elite]

On Tie Lengths and Angles
Replacing .tielen1-4 and .tieang1-4 in 2.4

I've had an idea inspired by Nums' use of commands in his new 2.5 tie paradigm

The problem with re-implementing the tie port commands like .tielen1 into 2.4 is that such a system is unmanagable when there is lots of ties
So how about these four commands to replace the sysvars .tielen1-4 and .tieang1-4

settielen
settieang

tielen
tieang

They affect the tie port on the top of the stack, so:
50 2 settielen
Would permanently set the length of the tie on tie port 2 to 50

And tielen and tieang would temporarily change the length for 'wiggling' motions, like the .tielen and .tieang sysvars

Alternatively, you could have positive numbers specify tie phases (number in .tie) and negative numbers specify tie ports (again, taken directly from Num's new tie paradigm)

What do you think?

[PurpleYouko]

.tieang1-4 act more like .fixang though, and likewise with .tielen1-4 ... I think that what's happening is that they're not getting reset and so are permanently forcing the tie to the value stored in them

Yeah .tieang1-4 does change the tie angles permanently as does .tielen1-4
maybe that was bad planning on my part to use this nomenclature instead of using .fixang1-4 but it's a little late to change it now.

I think the .tielen1 was an unexpected consequence, and PY really meant them not to work on birth ties.

Extremely unexpected. I thought I had applied all the safeguards to specifically prevent these controls working on birth ties.

[PurpleYouko]

They affect the tie port on the top of the stack, so:
50 2 settielen
Would permanently set the length of the tie on tie port 2 to 50

Numsgil and I actually had a discussion along these lines once before.
The general consensus was that making the system work with two numbers on top of the stack would be detrimental to evolutionary advances since it makes the chances of evolving a specific sequence a lot lower.
I could be wrong though. It was quite a while ago but as far as I remember that was the reason I used the tie controls the way they are now.

I would have no objection to switching them to the method you suggest as long as we can get a consensus decision among DB users.

Very few robots (probably all my own) have really utilized the tieport controls anyway.