Send-all Tie Communication

[Anonomous Guest Person]

How 'bout a method of communicating with all bots you're tied to? This would not directly allow for tie feeding and would only send through ties in which you're connected to as a multibot. It, additionally, would be sent prior to direct communication methods.

If this seems like it'd give tiefeeders too much of an advantage, you could limit to just sending to one memory location... aka .tievalall and .tierecall (30 .tievalall store would make any bots you're connected with have 30 *.tierecall = basically)

Additionally, could .multi perhaps return the number of bots you're connected to that way? Aka if you're tied with 3 bots and have been for so and so cycles (I forget how long it takes exactly... somewhere between 20-50 cycles!) then *.multi will return 3.

Thanks for reading this. Additionally, if I haven't said this in the past a looong time ago, thank you so very much, Numsgil (I think he's the one that added this! if not then I redirect my thanks to whoever did!), for allowing mathematic functions to work in conditions.

[Numsgil]

How 'bout a method of communicating with all bots you're tied to? This would not directly allow for tie feeding and would only send through ties in which you're connected to as a multibot. It, additionally, would be sent prior to direct communication methods.

I think there's a way to sort of do this already.  Ties with the same phase can be written to at the same time (or so I was told, haven't tried it out).  In the C++ source (a little dead at the moment mind you) this should work even better, allowing multiple communication through multiple ties in a single cycle.

Additionally, could .multi perhaps return the number of bots  you're connected to that way? Aka if you're tied with 3 bots and have  been for so and so cycles (I forget how long it takes exactly...  somewhere between 20-50 cycles!) then *.multi will return 3.

This seems like a good idea.  Generally I think it's wise to move away from sysvars which give simple yes/no answers.

Thanks for reading this. Additionally, if I haven't said this in the past a looong time ago, thank you so very much, Numsgil (I think he's the one that added this! if not then I redirect my thanks to whoever did!), for allowing mathematic functions to work in conditions.

 Your welcome

[Light]

Additionally, could .multi perhaps return the number of bots you're connected to that way? Aka if you're tied with 3 bots and have been for so and so cycles (I forget how long it takes exactly... somewhere between 20-50 cycles!) then *.multi will return 3.

Isn't this similar to *.numties?

[Anonomous Guest Person]

I think there's a way to sort of do this already.  Ties with the same phase can be written to at the same time (or so I was told, haven't tried it out).  In the C++ source (a little dead at the moment mind you) this should work even better, allowing multiple communication through multiple ties in a single cycle.

Perhaps, but I still think a send-all would be useful, not only would it speed up communication as it currently stands but it would make really large blob multibots somewhat possible.
Plus I don't imagine how multiple communications would work with the basic idea of how sysvars work as it stands (aside from the obvious, which is to add more sysvars) Could you enlighten me on that?

Isn't this similar to *.numties?

Pretty much yeah, but not exactly the same.
It could be very useful for coordinating multibots, at the very least. >_>

[Numsgil]

numties returns the number of ties, right?  So wouldn't .multi then return the number of hardened ties?

In the present code, I believe it works like this (I think PY told me this):

Each tie has a phase number.  Phase numbers do not need to be unique.  If you try to send information through a tie phase that's not unique you end up sending information through all ties with that phase.

In the C++ code, I've fleshed out this idea and added functionality that should allow for more robust control of all ties at once.  Most of the communication code is already in place.  You can read up on the idea here.

At present I'm no longer developing the C++ code for two reasons, 1. The tie physics is beginning to become too complex for me to be comfortable with and 2. I'm working on another idea at present.  That said, most of the simulation code is done.

[PurpleYouko]

I n the code that I wrote (2.37.6) Numties reads the total number of ALL ties connected to the bot while multi is actually a boolean that returns yes or no. (0 or 1) depending on whether a tie is hardened or not.
It would be pretty easy to change it to be a mirror for numties though.

Nums has it completely right about tie communications. If every tie you make has the same phase then when you send a communication down that phase it will go to ALL connected bots.

Remember that tie communication is by phase and not by any unique internal identifier.

[Anonomous Guest Person]

I get how communicating to all currently works now (though didn't know the tie ID things were called phases), I meant how multiple communications through seperate, unique ties will work. Which reminds me, thanks for the link! Jeez though, tie physics look complicated... goodluck with that
The only problem with having all your ties be the same is that you can't send specific communication to just one bot... oh well, it can't be that difficult to get around it (as long as you're programming all the bots that you plan on being tied with.)

Thanks, though.

[PurpleYouko]

Tie phase is just a term that I started using after the discovery that ties could be used as weapons.
Tie fighting just reminded me of Star Trek where they are able to vary the phase of the shields in order to better deflect incoming phasor attacks.

The term just caught on and really does seem like the most convenient way to describe the unique number that each tie needs to be addressed by.

It would be simple enough to add a "sendall" (or something similar) sysvar if it is deamed to be useful in some way. I'm not actualy sure where to use such a thing though. Could you give us an example application?

[Anonomous Guest Person]

Simplistic hivemind colonies could use it. (basically a lot of bots tied together that would share orders) This could be done without .sendall but the addition of a new command allows for two communication methods, which could improve the bot's effectiveness. Imagine a lump of bots haphazzardly connected being controlled by one brain bot (which any of the bots could become if orders stopped coming in some manner I can't think of). Now normally the brain has little means to communicate orders because it only can send one thing out at a time but if it can send two out, it can send a command and the command's "version number" (higher commands would replace lower commands, as would different commands of the same version, but these're technicalities.)

Plus, what I considered developing: (and can still do so pretty easily if I figure out how the heck I can get a bot to turn freely when part of a multibot without tie physics throwing every other bot around...mostly for cellular regeneration)

A giant multicellular bot that's built to act like a single bot, but built up of 5 bots (in a + formation).
Each part of the bot would use basic math to interpret some orders differently (for example the order to turn left may be read as going up for the right bot but it'll also be read as going down for the left bot.)

Plus it'd make communication to several other bots possible without making it impossible to communicate to them individually.

And I'm sure there'll be a few ways to abuse it for combat purposes.  

Of course with the new tie functions in that link Numsgil posted, all of this and more will be quite possible.

[Numsgil]

I believe Endy had a bot evolve that could turn while tied.  I believe it used tieang or whatever the sysvar is called.  That would be a good place to start.