Code center > Suggestions
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:
--- Quote from: 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.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
This seems like a good idea. Generally I think it's wise to move away from sysvars which give simple yes/no answers.
--- Quote ---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.
--- End quote ---
Your welcome
Light:
--- Quote from: Anonomous Guest Person ---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.
--- End quote ---
Isn't this similar to *.numties?
Anonomous Guest Person:
--- Quote from: Numsgil ---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.
--- End quote ---
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?
--- Quote from: Light ---Isn't this similar to *.numties?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version