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.
Maybe you should change the thread title to something like "How to make bots more complicated so they can be updated more easily".
Because the current title is basically a lie.
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
still why are we overlooking the name-your-variables thing? Like den said... even though pretty sure koya said it... and then I said it and sorta did it... and ninja you yourself did it but now don't want to acknowledge it
If you centralize the "SDKLogic" so that it simply operates the conversion between names (like what den said) and the actual ID's, then any one developer can make all bots using the system compatible with the latest version.
Moreover, if the ee devs kept the naming system normal... then you might not even need a person to fix things...
Then all you have to do in your code to check if something is supported is just check if the EE protocol still includes the name. No? Then you can quietly fail in your own code. Do they no longer have the information you need? You can check for that in the protocol and fail properly. None of this .. whatever that was.
Atilla makes a good point. I guess you could try to specify default values in case a send requires new information. At that point, if you needed to legitimately add logic, you'd need some interchangeable code instead of just a protocol collection. However, that seems to be a smaller issue.
Offline
I don't know what do you want, but I was bored so I played with "if; else" this will detect if your bot is up to date, and if there is a new version of your bot. Note that you will have to keep updating your pastebin http://pastebin.com/ZnuCixv6
If you're asking for how to make an bot that will always have the latest EE version and users won't have to download the new one everytime EE updates, just do this, I will try to keep that pastebin version up to date, or you can just host your own one. http://pastebin.com/dk9eEBRD
Offline
I don't know what do you want, but I was bored so I played with "if; else" this will detect if your bot is up to date, and if there is a new version of your bot. Note that you will have to keep updating your pastebin http://pastebin.com/ZnuCixv6
If you're asking for how to make an bot that will always have the latest EE version and users won't have to download the new one everytime EE updates, just do this, I will try to keep that pastebin version up to date, or you can just host your own one. http://pastebin.com/dk9eEBRD
Also do you even know that this thread is for? They are not talking about EE Config version.
They are talking about a way to make the bot updated, when the owners of EE release newer Protocol.
They want a way to not break their bots because of a change in the EE protocol.
Do you understand now?
Instead of using:
con = cli.Multiplayer.CreateJoinRoom("world", EEversion, true, null, null);
You should use:
con = cli.Multiplayer.CreateJoinRoom("PW01", "world".StartsWith("PW") ? "Everybodyedits":"Beta" + cli.BigDB.Load("config","config")["version"], true, null, null);
Offline
Vitalijus wrote:I don't know what do you want, but I was bored so I played with "if; else" this will detect if your bot is up to date, and if there is a new version of your bot. Note that you will have to keep updating your pastebin http://pastebin.com/ZnuCixv6
If you're asking for how to make an bot that will always have the latest EE version and users won't have to download the new one everytime EE updates, just do this, I will try to keep that pastebin version up to date, or you can just host your own one. http://pastebin.com/dk9eEBRD
Also do you even know that this thread is for? They are not talking about EE Config version.
They are talking about a way to make the bot updated, when the owners of EE release newer Protocol.
They want a way to not break their bots because of a change in the EE protocol.Do you understand now?
Instead of using:
con = cli.Multiplayer.CreateJoinRoom("world", EEversion, true, null, null);
You should use:
con = cli.Multiplayer.CreateJoinRoom("world", cli.BigDB.Load("config","config")["version"], true, null, null);
Yeah, saw this "Hey guys, just wanted your opinion on my idea to make bots always work." and posted that post, whatever atleast I had something to do
Offline
capasha wrote:Vitalijus wrote:I don't know what do you want, but I was bored so I played with "if; else" this will detect if your bot is up to date, and if there is a new version of your bot. Note that you will have to keep updating your pastebin http://pastebin.com/ZnuCixv6
If you're asking for how to make an bot that will always have the latest EE version and users won't have to download the new one everytime EE updates, just do this, I will try to keep that pastebin version up to date, or you can just host your own one. http://pastebin.com/dk9eEBRD
Also do you even know that this thread is for? They are not talking about EE Config version.
They are talking about a way to make the bot updated, when the owners of EE release newer Protocol.
They want a way to not break their bots because of a change in the EE protocol.Do you understand now?
Instead of using:
con = cli.Multiplayer.CreateJoinRoom("world", EEversion, true, null, null);
You should use:
con = cli.Multiplayer.CreateJoinRoom("world", cli.BigDB.Load("config","config")["version"], true, null, null);
Yeah, saw this "Hey guys, just wanted your opinion on my idea to make bots always work." and posted that post, whatever atleast I had something to do
The most bot programmers already know that they should use the config database to get the newest EE version.
If you read this thread. You should understand that they are talking about the protocol changes.
Offline
Atilla makes a good point. I guess you could try to specify default values in case a send requires new information. At that point, if you needed to legitimately add logic, you'd need some interchangeable code instead of just a protocol collection. However, that seems to be a smaller issue.
I think it's best to start with the easy part, which would be the receiving part.
I personally think that's pretty much 90% of the reason bots get outdated, including the ones that break because stuff like potions were removed/replaced.
After that's flawlessly working (preferably automatically and not people still having to update an SDK or whatever, like BotBits), we can think of the more hard part of the sending portions.
This would be much harder since, as you said, you'd have to carefully think about either making the user catch errors (throw an error when he's missing an argument) or use default values (which might be hard to define automatically) and mention a warning in the console or whatever.
Aside from that you'd also have to think of a method to make send messages generate automatically.
Probably it's best to have a generic method which reads out the send message type and then just adds an array of given and ordered arguments (bit like how a Tuple works).
The above probably makes no sense and has terrible grammar... Not really feeling like fixing it...
Anyways, think imma just go and try and make something, cus I have spare time.
Offline
I use this in my bots. Maybe I could change it a little bit more. So it read from the correct protocol.
This code, which isn't the best. Would check if owner in "init" from parameter 0, is a string. If not it would write about it.
private static void Con_OnMessage(object sender, Message m)
{
/*
m = Message from the world
"init" = init, add or whatever
0 = Parameter
"System.String" the message type
*/
if (ParamNumbers(m, "init", 0, "System.String")) Console.WriteLine("Owner exist");
else Console.WriteLine("Owner Changed");
}
public static bool ParamNumbers(PlayerIOClient.Message m, string messag,int message, string type)
{
if (m.Type == messag)
{
if (m[(uint)message].GetType().ToString() == type) return true;
else return false;
}
else return false;
}
Offline
[ Started around 1732404684.3108 - Generated in 0.175 seconds, 12 queries executed - Memory usage: 1.51 MiB (Peak: 1.67 MiB) ]