Code center > Bugs and fixes

Ties in 2.4

(1/6) > >>

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...

Navigation

[0] Message Index

[#] Next page