Author Topic: New tie interface idea  (Read 2448 times)

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
New tie interface idea
« on: May 31, 2005, 01:07:53 AM »
We'll also need a way to figure out what the tie number is for the Xth tie, so we can address it using the other tie functions.

Or perhaps the entire tie system needs to be reworked?  I've figured out a way to more or less make any drastic changes in how stuff works backwards compatible, so you don't have to worry about that. (we treat obsolete sysvars as macros for a new system during DNA execution.)

Maybe instead of the tie numbers we're using now (which have 32000 possible numbers) we just have 4 (1,2,3,4).  If a tie attaches to you now, you can find it's number using tiepres (with a delay of 1), so in a new system with only 4 tie numbers, it'd still take a cycle for you to discover the presence of the tie unless you fired it (don't display ties with age less than two full cycles unless you're the initiator).

That would make tie commands more likely to evolve, since picking a number from 4 is much easier than picking one from 32000.

Maybe we have one memory set (tielen, tieang, etc.) for all the ties, and to switch the target of the memory set, you do "number tiefocus" as a command.  Then all your memory locations are updated for the new tie mid DNA execution (would be similar to how *.thisgene works).

Then again it wouldn't work for commands unless you create some kind of command stack or add a section to the tie structure for holding commands.
« Last Edit: May 31, 2005, 01:10:58 AM by Numsgil »

Offline PurpleYouko

  • Bot God
  • *****
  • Posts: 2556
    • View Profile
New tie interface idea
« Reply #1 on: May 31, 2005, 11:28:27 AM »
Quote
Maybe instead of the tie numbers we're using now (which have 32000 possible numbers) we just have 4 (1,2,3,4). If a tie attaches to you now, you can find it's number using tiepres (with a delay of 1), so in a new system with only 4 tie numbers, it'd still take a cycle for you to discover the presence of the tie unless you fired it (don't display ties with age less than two full cycles unless you're the initiator).

No I don't like that idea very much. For tie feeders, the system should stay the way it is so that it is difficult to detect and counter a tie feeder. *.tiepres is the only way.
I have some robots that constantly shift phases  to avoid leaches.

My new system is designed to make four tie angles and four tie lengths addressable based on the robot's own internal id system. They are also all addressable in the same cycle. Some form of comunication could be set up this way also but it should exclude any cell that isn't part of the MB (tie not hardened yet)

The internal address system may need to be revised a little to make this work better but I am still working on that.
There are 10 kinds of people in the world
Those who understand binary.
and those who don't

:D PY :D

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
New tie interface idea
« Reply #2 on: May 31, 2005, 11:50:39 AM »
I'm mostly thinking out loud on this one, and from the point of view of mutation sims.

Fact is ties are really complicated to use compared to other functions.  It requires alot of data manipulation (remember tie number is a huge one for a mutation sim).  If we can figure out a system that could likely evolve, we might actually start seeing some tie feeders, etc. evolving.

Currently tie feeders get 1 good cycle of feeding before their victim can cut the cord.  So if we just don't all the victim to see the feeder's tie for one cycle, we get the same net effect.

Imagine if all 4 ties are manipulated by the same set of commands, and the commands' target tie can be changed by a command.

Then imagine your DNA looks like this:

lock onto tie 1

manipulate tie

Then imagine it mutates (a very simple mutation really) into

lock onto tie 1

lock onto tie 2

manipulate tie

Suddenly our manipulations are all pointing to a different tie, one that has a fairly good chance of existing.  All our manipulations are still pointing to the same tie, so the combined effect is the same, just for a new tie.

The benefit is mainly in not having to remember your tie number.  In fact, you can even guess and have a pretty good shot at getting it right.

When you change the focus of the tie commands, it acts like a carriage return, sending all the data in memory to the corresponding tie and loading up the new tie's data.
« Last Edit: May 31, 2005, 11:53:15 AM by Numsgil »