Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Pages: 1
MultiAlt
v 1.0.0.1
MultiAlt is a simple and easy tool to use, that provides an easy way to use multiple alts to join worlds, do one big task, or do multiple worlds and communicate with eachother.
It has a simple method of recieving messages, giving you the correct connection to use, the Alt that recieved it, and the object sender of the message.
Alts have the ability to do this["data"] = value; so you can store data within the alt, such as their id for when they recieve "init" or such.
MultiAlt also has the ability to bend into other PlayerIO games, so you can not only use it for EE but other games as well.
View it on github | View it on nuget
Note
You guys are good at criticizing my work, so I'm pretty sure you'll tear this to shreads as well
Offline
public class CircularList<T> : List<T>
{
private bool _loop;
private int _index;
public bool Loop { get { return _loop; } set { _loop = value; } }
public T Next => (_index >= Count && _loop) ? new Func<T>(() => { _index = 0; return this[_index++]; }).Invoke() : this[_index++];
public bool HasNext => (Count == 0 || (!_loop && _index >= Count)) ? false : true;
}
internal static CircularList<Connection> Connections = new CircularList<Connection>() { Loop = true };
internal static void Send(Message message) {
var next = Connections.Next;
if (next.Connected)
next.Send(message);
else
Send(message);
}
In only 20 relatively simplistic lines of code, compared to 603. Ta-da.
*u stinky*
Offline
In only 20 relatively simplistic lines of code, compared to 603.
I clearly see the full encapsulation of MultiAlt and it's simple nature encapsulated into 20 lines.
Oh clearly the ONLY purpose of multi alt is to make it so you can send a big wad of messages, and make sure it works in only .NET 6.0+
Offline
XxAtillaxX wrote:In only 20 relatively simplistic lines of code, compared to 603.
I clearly see the full encapsulation of MultiAlt and it's simple ability to have multiple alts join a world and talk to other alts clearcly encapsulated into 20 lines.
Oh clearly the ONLY purpose of multi alt is to make it so you can send a big wad of messages, and make sure it works in only .NET 6.0+
I'm glad to hear that you agree. Cheers!
In the case of sarcasm, would you be willing to demonstrate an example?
*u stinky*
Offline
A bit off-topic:
Would it perhaps be an idea to create a small batch of alts shared with a select (trusted) group?
The reason of that batch of alts would be that they have all blocks (or at least all energy blocks).
That would mean that the OP's functionality can also be used for drawing without everybody having to take ages to obtain all the blocks for all their alts (unless investing money to speed stuff up).
Offline
A bit off-topic:
Would it perhaps be an idea to create a small batch of alts shared with a select (trusted) group?
The reason of that batch of alts would be that they have all blocks (or at least all energy blocks).
That would mean that the OP's functionality can also be used for drawing without everybody having to take ages to obtain all the blocks for all their alts (unless investing money to speed stuff up).
Or, generate a new alternate account for every package available, load the account when necessary!
Offline
A bit off-topic:
Would it perhaps be an idea to create a small batch of alts shared with a select (trusted) group?
The reason of that batch of alts would be that they have all blocks (or at least all energy blocks).
That would mean that the OP's functionality can also be used for drawing without everybody having to take ages to obtain all the blocks for all their alts (unless investing money to speed stuff up).
Issues with access on different IPs - the same account cannot be connected to the game on more than 1 unique IP; if the group also shared a server it would work well.
Thank you eleizibeth ^
I stack my signatures rather than delete them so I don't lose them
Offline
In the case of sarcasm, would you be willing to demonstrate an example?
Actually, yea sure.
I'm pretty sure it's in MultiAlt_Demo, at the github repo.
There's one for filling a work (aka splitting work)
Then there's another one for multi-world chat rooms, a.k.a using one program to have two bots connected to one world, and when you say something, all the other bots say it on the world they're on as well, so that you can communicate with other worlds. It uses the built in Heard event that it uses.
As for more uses, that'd require unique ideas, or making an old idea a new one. e.g connect five alts to one world so each one can do an individual snake.
I also have a bot that can follow me to any world I goto if I leave it on, by having one of the accounts my friend and let it find me and stalk me for wherever I am.
Offline
XxAtillaxX wrote:In the case of sarcasm, would you be willing to demonstrate an example?
Actually, yea sure.
I'm pretty sure it's in MultiAlt_Demo, at the github repo.
There's one for filling a work (aka splitting work)
Then there's another one for multi-world chat rooms, a.k.a using one program to have two bots connected to one world, and when you say something, all the other bots say it on the world they're on as well, so that you can communicate with other worlds. It uses the built in Heard event that it uses.
As for more uses, that'd require unique ideas, or making an old idea a new one. e.g connect five alts to one world so each one can do an individual snake.
I also have a bot that can follow me to any world I goto if I leave it on, by having one of the accounts my friend and let it find me and stalk me for wherever I am.
With the 20 lines I provided, you can split work easily, for each packet, the next connection in the list is used.
Additionally, you can use one event handler for multiple connections, which means you can have multiple connections receive the same messages.
*u stinky*
Offline
With the 20 lines I provided, you can split work easily, for each packet, the next connection in the list is used.
Additionally, you can use one event handler for multiple connections, which means you can have multiple connections receive the same messages.
I just found a hotel world, with a bot, and used MultiAlt to claim multiple rooms and build a "super wide room" using each individual bot.
I find that using MultiAlt to manage multiple alts makes life easier, instead of having to do it "raw" with PlayerIOClient.
While you do prove that the 20 lines manages to do most of what MultiAlt can do, MultiAlt offers alt management.
tl;dr: MultiAlt offers alt management, to make life easier.
Offline
Isn't it enough with the spamming that already exist? Do we need more?
Offline
Isn't it enough with the spamming that already exist? Do we need more?
Spamming is easy enough, also without this tool.
Offline
*Comment hating on all SDKs*
*World-weary comment about yet another SDK by ninja*
*Comment about unnecessary functionality stored in a complicated and hence difficult-to-use wrapper, generally making life harder for the user*
*Suggestion that ninja consider the perspective of someone to whom this SDK was presented, and their unlikely willingness to learn to operate its functionality*
Actually, I'll expand on that last one: You wrote that code, so you're fine with using it. Why would someone else go to the trouble of muddling through the stack of methods and voids and learning what each does in order to create a bot feature that would be easier to code from scratch?
You're hooking a number of alts into the same handler and splitting a list of messages between them. Yay, but you don't need an SDK for that.
List<Connection> bots;
int rawr = 0;
...
void Send(Message m)
{
bots[rawr].Send(m);
Thread.Sleep(something_less_than_10ms); //Or more if two consecutive "say" messages are sent through the same connection
rawr = (rawr == bots.Count - 1) ? 0 : rawr++;
}
And voila, you're now sharing the output messages between your connections. Hooking all the connections onto a single handler is as simple as a for loop in your connection void.
I can't see the point of the alt-to-alt whisper thing, because you own all the alts! They all report to you in one handler, and you tell them what to do - why should they talk directly to each other?
There's no error checking in your connection code.
You guys are good at criticizing my work, so I'm pretty sure you'll tear this to shreads as well
It sounds like you expected some criticism, which maybe says something about your own opinion of what you release.
New and old botters benefit most from releases that are uniquely useful and compact enough to be copy/pasted without needing the entire dll. Like nubparse, for example. Or even better, code a unique public bal and release it. Bots need more exposure in EE.
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
It sounds like you expected some criticism, which maybe says something about your own opinion of what you release.
http://forums.everybodyedits.com/viewtopic.php?id=36122
http://forums.everybodyedits.com/viewtopic.php?id=35607
http://forums.everybodyedits.com/viewtopic.php?id=35704
http://forums.everybodyedits.com/viewtopic.php?id=34132
http://forums.everybodyedits.com/viewtopic.php?id=31243
http://forums.everybodyedits.com/viewtopic.php?id=31179
( But I admit http://forums.everybodyedits.com/viewtopic.php?id=36122 is one of the most successful things, but still gets hate comments )
( I'll also admit that some of those were a complete and utter failure, when at the time I thought it wasn't )
Of course I'd be completely and utterly ok with releasing another DLL and expecting positive results based on what I've done before!
*Comment hating on all SDKs*
*World-weary comment about yet another SDK by ninja*
*Comment about unnecessary functionality stored in a complicated and hence difficult-to-use wrapper, generally making life harder for the user*
*Suggestion that ninja consider the perspective of someone to whom this SDK was presented, and their unlikely willingness to learn to operate its functionality*
Actually, I'll expand on that last one: You wrote that code, so you're fine with using it. Why would someone else go to the trouble of muddling through the stack of methods and voids and learning what each does in order to create a bot feature that would be easier to code from scratch?
You're hooking a number of alts into the same handler and splitting a list of messages between them. Yay, but you don't need an SDK for that.
List<Connection> bots; int rawr = 0; ... void Send(Message m) { bots[rawr].Send(m); Thread.Sleep(something_less_than_10ms); //Or more if two consecutive "say" messages are sent through the same connection rawr = (rawr == bots.Count - 1) ? 0 : rawr++; }
And voila, you're now sharing the output messages between your connections. Hooking all the connections onto a single handler is as simple as a for loop in your connection void.
Wow your right! I should just quit this entire project because you could save a few lines of code, while adding
Connection a = stuff;
a.OnMessage += void_1;
Connection b = stuff;
b.OnMessage += void_2;
Connection c = stuff;
c.OnMessage += void_3;
void void_1(object sender, Message e)
{
//Ok we know to use connection "a" or index "0" in our Connection<List>
}
void void_2(object sender, Message e)
{
//Ok we know to use connection "b" or index "1" in our Connection<List>
}
void void_3(object sender, Message e)
{
//Ok we know to use connection "c" or index "2" in our Connection<List>
}
If you may argue that you could just determine the connection based on the sender,
taking the time to determine based on "sender" what connection to use and then use that for all of your code in OnMessage ( and storing external data in other data tables )
is a lot harder and more time consuming than doing
Install-Package MultiAlt
and then using your IDE to generate method stubs to do this:
static void alts_GotMessage(Message e, Connection con, Alt id)
{
//Look! A connection for us to use is right there!
//We can also do id["name"] = e.GetString(5); or whatever to store the alts name/player Id! That's nice.
}
Whilst I admit
static void AddAlt(string GameId, string Email, string Password, string AltId)
{
Client alt = PlayerIO.QuickConnect.SimpleConnect(GameId, Email, Password, null);
var alt_add = new Alt(AltId, alt, alts);
alt_add.Heard += alt_add_Heard;
alts.AddAlt(alt_add);
}
string GameId = "everybody-edits-su9rn58o40itdbnw69plyw";
string WorldId = "OW MultiAlt Test";
string WorldType = "Everybodyedits216";
//Add all the alts
AddAlt(GameId, "[email protected]", "alt1password", "alt1");
AddAlt(GameId, "[email protected]", "alt2password", "alt2");
AddAlt(GameId, "[email protected]", "alt3password", "alt3");
AddAlt(GameId, "[email protected]", "alt4password", "alt4");
AddAlt(GameId, "[email protected]", "alt5password", "alt5");
//Add event handler
alts.GotMessage += alts_GotMessage;
//Make all alts join a world
alts.CreateJoinRoom(WorldId, WorldType, true, null, null);
isn't exactly the best way in the world to go about adding alts, but it makes everything just a bit easier with the functionality it provides.
also i love how all of you guys instantly rush to the scene when ninja makes something just to trample on it :/
IIRC, there was something someone said along the lines of "I only came here because it was something ninja made" and pretty sure it implied that everything I make gets drama and trampled on
Offline
I don't see how that's any easier than reading the sender, nor do I see how your library provides any more functionality.
The entirety of your library could be simplified as a list of connections, and a dictionary.
*u stinky*
Offline
Wow your right! I should just quit this entire project because you could save a few lines of code
My issue is not with the fact you could make your code shorter. It's because (in a bot) the idea of adding hundreds of lines of someone else's code so that you write fewer visible lines of code is ridiculous. Your code isn't shorter, it's longer.
If your aim was to create a simple method of distributing certain message types between multiple connections, that would make a good dll. If you wanted to make chatbots that communicated between worlds, that would make another good dll or potentially grow into a full bot. If you even wanted to simplify the connection of multiple bots to a world, that would also make a small but tidy dll.
By grouping all three ideas together you've created something more complicated to use than each of its parts and given the user much less control over how they operate. You've incredibly overcomplicated the act of splitting a collection of messages between connections and sending them, and the whole thing revolves around actually having a list of messages to send beforehand.
If I'm looping through 3000 coordinates and I just want to erase the blocks in them, I don't want a list! The entire point of having a connection manager is that I can simply call a "Send" void 3000 times and off those messages go. The delay required between the messages becomes the dll's problem, as does the risk of any blocks not being placed. Your code can't do that.
Ah, but you've called it an alt manager, not a message-sending manager. It's not for maximising the efficiency of sending a large number of messages. It's not for connecting safely to a world. Judging by the following, which is example code you yourself provided to display the ease of use of your dll, it's not even for making alt management newb-friendly either:
static AltManager alts;
...
static void AddAlt(string GameId, string Email, string Password, string AltId)
{
Client alt = PlayerIO.QuickConnect.SimpleConnect(GameId, Email, Password, null);
var alt_add = new Alt(AltId, alt, alts);
alt_add.Heard += alt_add_Heard;
alts.AddAlt(alt_add);
}
So what is it for? To me, it's some code that shows it's fun to massively overcomplicate things, released to the public because bigger must equal better. You really need to brainstorm what it is you're actually trying to code, and fight hard to stop it bloating beyond its intended functionality. No, I'm not trying to make you stop releasing dlls. Call this constructive criticism.
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
Pages: 1
[ Started around 1732408134.1308 - Generated in 0.150 seconds, 13 queries executed - Memory usage: 1.74 MiB (Peak: 1.98 MiB) ]