[Idea] Idea to make out-of-date bots always work

SirJosh3917 · 2016-11-09 20:40:35

Hey guys, just wanted your opinion on my idea to make bots always work.
I decided that since bots are hard coded to work one way, why don't you just make a seperate dll for the bot, that has all the logic inside of it!
That way, when your bot gets super old, you can just replace it's SDKLogic with a newer one so it still works!

What do you guys think about this idea?

Vinyl Melody, POLAK23P

drunkbnu · 2016-11-09 20:43:15

Propietary code.

hummerz5 · 2016-11-09 20:47:33

I don't know what to make of what HG said

I wonder why you didn't bring this up when I brought this up, but hey whatever I mean y'know

Replacing anything still says that there's someone out there doing all that stuff.

Oh and I think Koya had a solution too but it's been a while.. oh hey here it is https://forums.everybodyedits.com/viewt … p?id=35687

So if the ee admins kept their naming choices to a strict convention set... we could potentially grab some info from there... and we couldn't have to bother with your odd .dll thing. Speaking of which, didn't you just create a "ProtocolLookup" whatever happened to that idea?

ofc we have to assume that the EE devs don't remove certain data fields or that'd just end things there.

But I would say that using a .dll is a bad idea. Koya's thing with the JSON allows any user to stitch together what they need, no compilation.

SirJosh3917 · 2016-11-09 20:50:57

hummerz5 wrote:

I don't know what to make of what HG said
I wonder why you didn't bring this up when I brought this up, but hey whatever I mean y'know
Replacing anything still says that there's someone out there doing all that stuff.
Oh and I think Koya had a solution too but it's been a while.. oh hey here it is https://forums.everybodyedits.com/viewt … p?id=35687
So if the ee admins kept their naming choices to a strict convention set... we could potentially grab some info from there... and we couldn't have to bother with your odd .dll thing. Speaking of which, didn't you just create a "ProtocolLookup" whatever happened to that idea?
ofc we have to assume that the EE devs don't remove certain data fields or that'd just end things there.
But I would say that using a .dll is a bad idea. Koya's thing with the JSON allows any user to stitch together what they need, no compilation.

I mean my protocol lookup and koya's json idea is great and all, but what if EE just decides to flip the table on us for no reason whatsoever. This is where the interchangeable dll comes in - if ee flips the table on us and everything is different, we can just recode the dll ourselves and the bot will still work the exact same way (hopefully)

Tomahawk · 2016-11-09 20:53:20

If PIOClient messages were like little dictionaries, life would be great, but you can't future-proof init when they keep inserting new vars.

SirJosh3917 · 2016-11-09 20:55:10

Tomahawk wrote:

you can't future-proof init when they keep inserting new vars.

Entirely true! This is why bots break all the time. I'm simply suggesting that the bot just simply uses the SDKLogic. You could make your own sdklogic to replace the broken bot's sdklogic, and then whala it works because no logic is contained in the actual bot, it's all in the SDKLogic.

EDIT: I do not suggest that the SDKLogic is the exact same thing for every bot - every bot creator can have their own SDKLogic and make it their own way.

den3107 · 2016-11-09 23:23:03

Not much wrong with the idea, aside from the fundamental reason why the bots get outdated.

They get outdated because... Well... They're not updated timely.
There's no guarantee this dll won't suffer the same fate.

My personal suggestion would still be to read and parse the documentation.
It still wouldn't work flawlessly as something still would have to get updated (instead of the entire process going completely automatically), but since Thanel seems to actively update this (and people can fork it themselves too), I doubt it will ever be a real problem, unless you want a bot up the minute after an update.

hummerz5 · 2016-11-09 23:29:37

ninjasupeatsninja wrote:

Tomahawk wrote:
you can't future-proof init when they keep inserting new vars.
Entirely true! This is why bots break all the time. I'm simply suggesting that the bot just simply uses the SDKLogic. You could make your own sdklogic to replace the broken bot's sdklogic, and then whala it works because no logic is contained in the actual bot, it's all in the SDKLogic.
EDIT: I do not suggest that the SDKLogic is the exact same thing for every bot - every bot creator can have their own SDKLogic and make it their own way.

well that's where your idea runs out of merit IMO. If your idea involves interchangeable parts, then anyone could keep all bots on the service running. Expecting the creator of the bot to update their "SDK" may as well not have the system in place, because you're going to be getting off the metaphorical couch to up and do work on old things. If that wasn't an issue for you, then you wouldn't need to be making an SDK.

den3107 wrote:

My personal suggestion would still be to read and parse the documentation.

Two sides to this. One, the documentation seems pretty well updated.
Two, if it wasn't, you could take your parser and point it locally. Then the user could make whatever updates they needed to.

SirJosh3917 · 2016-11-09 23:50:05

Hopefully the owner of the bot puts out the source code for their SDKLogic dll, so users can make their own if they want to continue using the bot. Even if the owner doesn't do so, you can always decompile it, and export it into a visual studio project, and if the SDKLogic was obsfucated, there was no point to this at all because why encrypt it if you don't want users seeing it and making modifications so the bot continues to work.

XxAtillaxX · 2016-11-09 23:50:58

BotBits already exists.

den3107 · 2016-11-10 10:07:47

XxAtillaxX wrote:

BotBits already exists.

But that's so boring...
+ I imagine the documentation is faster updated than botbits.

XxAtillaxX · 2016-11-10 11:46:35

ninjasupeatsninja wrote:

Hey guys, just wanted your opinion on my idea to make bots always work.
I decided that since bots are hard coded to work one way, why don't you just make a seperate dll for the bot, that has all the logic inside of it!
That way, when your bot gets super old, you can just replace it's SDKLogic with a newer one so it still works!
What do you guys think about this idea?

Oh, they're hard-coded are they? What will your library be? Dynamically magically all-knowing about every change required? Don't be ridiculous.

What do you do about missing parameters, what do you do about different methods required to attain the same functionality?
For example, what if the bot depended on potions to work? They don't exist anymore.

The old deprecated tools of the past should remain deprecated.
It's a clear indicator that they are no longer supported. Stop using them.

den3107 wrote:

XxAtillaxX wrote:
BotBits already exists.
But that's so boring...
+ I imagine the documentation is faster updated than botbits.

The documentation is updated faster, however that does not mean your application will magically attain functionality from merely that.
"But that's so boring" -- Waaaah! I want to re-invent the wheel with an even worse wheel!

Vinyl Melody

Vinyl Melody · 2016-11-10 12:40:12

Ayy laziness

SirJosh3917 · 2016-11-10 19:45:02

XxAtillaxX wrote:

What will your library be?

Excuse me? I'm not going to make a library, I'm simply suggesting that the bot creator uses a dll to put all the logic in so it's easier to keep the bot alive.

XxAtillaxX wrote:

What do you do about missing parameters, what do you do about different methods required to attain the same functionality?
For example, what if the bot depended on potions to work? They don't exist anymore.

The answer is simple - you do absolutely nothing. If the bot requires potions to work, remove potions from the SDKLogic! If you can't remove potions, then just completely ignore them altogether!

XxAtillaxX wrote:

The old deprecated tools of the past should remain deprecated.
It's a clear indicator that they are no longer supported. Stop using them.

There were plenty of good public bots back in the day and I see you complain about modern public bots not being unique, so what makes you say this?

Tomahawk · 2016-11-10 22:30:43

But the concept contradicts itself! How can you have a bot that "always works" if you have to update this "SDKLogic" dll that it'll use??

Ninjasupeatsninja wrote:

I'm simply suggesting that the bot creator uses a dll to put all the logic in so it's easier to keep the bot alive.

Ah, so this changes nothing. The bot will still break if a part of it isn't updated. Hence my confusion.

den3107 · 2016-11-10 22:31:05

XxAtillaxX wrote:

The documentation is updated faster, however that does not mean your application will magically attain functionality from merely that.

Neither will BotBits, so stop using that as an argument, since nothing can prepare you for deprecated functionality aside from a nicely formatted error, which any of the mentioned methods are capable of doing.

XxAtillaxX wrote:

"But that's so boring" -- Waaaah! I want to re-invent the wheel with an even worse wheel!

I make bots because I find it fun to think of (for example) how to handle drawing with as much ease and extensiblility as I think is needed. I don't make this for work nor lose any money or whatever being so inefficient.
And about make the wheel worse... I don't care really. Part of the challenge is having to improve things when they break.
I can only learn from those mistakes and use what I learn there for college.

But let's end this discussion since it's mostly opinion based and kinda off-topic.

Vitalijus · 2016-11-10 23:20:30

If you have a site just upload a .txt file with your bot version and check if the .txt matches your bot version.

Here is a one of those sites, but it hosts your file for only 30 days and you can't edit it. Click here for the site

den3107 · 2016-11-10 23:28:26

Vitalijus wrote:

If you have a site just upload a .txt file with your bot version and check if the .txt matches your bot version.
Here is a one of those sites, but it hosts your file for only 30 days and you can't edit it. Click here for the site

Protocol has EE version.
Can also you pastebin to host that txt (which actually is editable).

Anyways: So we know if the bot is outdated or not automatically now... Then what? Just making a nice little popup instead of an application crash won't really change much, aside from a bit of feedback to the user which would only be important when it's a public bot.

XxAtillaxX · 2016-11-10 23:50:36

ninjasupeatsninja wrote:

XxAtillaxX wrote:
What will your library be?
Excuse me? I'm not going to make a library, I'm simply suggesting that the bot creator uses a dll to put all the logic in so it's easier to keep the bot alive.

How is this any different from hardcoding, and how is it any easier to keep the bot alive?
If you're going to make claims, back them up with working examples, or working detail about the implementation.

ninjasupeatsninja wrote:

XxAtillaxX wrote:
What do you do about missing parameters, what do you do about different methods required to attain the same functionality?
For example, what if the bot depended on potions to work? They don't exist anymore.
The answer is simple - you do absolutely nothing. If the bot requires potions to work, remove potions from the SDKLogic! If you can't remove potions, then just completely ignore them altogether!

You still haven't answered working proof of the provided example.
Again, what would you do if the bot required information from deprecated features, for example, potions?

ninjasupeatsninja wrote:

XxAtillaxX wrote:
The old deprecated tools of the past should remain deprecated.
It's a clear indicator that they are no longer supported. Stop using them.
There were plenty of good public bots back in the day and I see you complain about modern public bots not being unique, so what makes you say this?

I say this because old unsupported implementations should die out and be replaced with newer ones.
Why aren't you using Netscape? It was perfectly good back in the day, you should go make it work with the latest greatest HTTP spec!

den3107 wrote:

XxAtillaxX wrote:
The documentation is updated faster, however that does not mean your application will magically attain functionality from merely that.
Neither will BotBits, so stop using that as an argument, since nothing can prepare you for deprecated functionality aside from a nicely formatted error, which any of the mentioned methods are capable of doing.

I never made the claim that BotBits would solve the issue of deprecated functions, however it is precisely what this proposed idea would entail, except third-rate.

den3107 wrote:

XxAtillaxX wrote:
"But that's so boring" -- Waaaah! I want to re-invent the wheel with an even worse wheel!
I make bots because I find it fun to think of (for example) how to handle drawing with as much ease and extensiblility as I think is needed. I don't make this for work nor lose any money or whatever being so inefficient.
And about make the wheel worse... I don't care really. Part of the challenge is having to improve things when they break.
I can only learn from those mistakes and use what I learn there for college.
But let's end this discussion since it's mostly opinion based and kinda off-topic.

That's nice, dear.

It's fairly obvious you wouldn't get paid for programming bots, nor lose anything by being inefficient.
If you don't care about re-inventing the wheel with inferior quality, I'm rather glad you aren't being paid and saturating the otherwise well-standardised industry.

Alas, if you truly learn from mistakes, I'd recommend learning from this one.
You aren't going to get very far in college with programming if you outright renounce existing standards with an inferior alternative.

Tomahawk · 2016-11-11 01:05:46

Well this thread went about as well as expected given the OP and forum section.

And that's because you can't code a bot that doesn't break.

Vinyl Melody

SirJosh3917 · 2016-11-11 17:45:51

XxAtillaxX wrote:

How is this any different from hardcoding, and how is it any easier to keep the bot alive?
If you're going to make claims, back them up with working examples, or working detail about the implementation.

The maker of the bot would start his bot, and create the form/gui at first. Then, he would create an SDKLogic.dll, of which would be used to store all the stuff inside of the bot.
The original bot would call functions from the SDKLogic, and the form bot would do nothing, but display the graphical contents needed, while the SDKLogic does all the work.
This idea allows the bot creator to put documentation on how to make the SDKLogic, or rather just put the source of it up, and when the bot quits working, someone else may come along, look at the SDKLogic, modify, edit, recompile, and plug back into the old bot, and it works.
This is different from hardcoding because when you hardcode everything, you have all the GUI elements to work with, as well as the internal code, and putting it on github would require more code to be looked at, making finding it more complicated, and if you do make changes, you would have to work with the GUI elements, and there could be potential hard coded rot13 elements you'd have to delete, find all instances of, and eradicate the old stuff, and bring in the new code, which would be troublesome.

However, with an SDKLogic.dll, the programmer may simply create his form, add GUI elements, use delegates and events from the SDKLogic to tell the form what to put where as to display the correct contents, and then just call SDKLogic functions for joining the world, so the actual bot only handles GUI requests, and joining/connecting to worlds, and all GUI elements need only to call a function from the SDKLogic to do what the programmer wants, because the programmer made the SDKLogic their way.
This in turn, requires the updater to have an easier time updating the bot, because they don't have to deal with GUI clutter and elements, rather only with the PlayerIO related stuff in the bot. The new SDKLogic programmer can just simply tell the form that this element needs to say "Deprecated" if a feature gets deprecated, and the new SDKLogic programmer no longer has to deal with the GUI and many other things that might become hardcoded, he can just let the form take care of itself, such as an updater, and GUI elements, and let the SDKLogic contain all the bot code, and let that do all the work.

Now, you may be asking yourself "ok mr.ninja wtf is the point of all of this if you could just have a class inside of the actual bot named SDKLogic.cs do all the work", and the simple answer is - well, there is none basically. This would be perfectly fine to do! You could still do everything, maybe in a different manner, but it'd be fine. However by doing this, you miss the crucical part of SDKLogic - having to deal with GUI elements, and the plug 'n 'play ability of SDKLogic. You must remember that an idea always has it's ups and downs, may there be none or few. If you're still like "lol ok why dont i just still hardcode wtf is the point of all of this if i have to tango with events and gui elements", then simply don't do it, it's just a simple idea and you must imagine the possibilities and downs. As seen in this topic so far, as given Tomahawk's statement,

Tomahawk wrote:

Well this thread went about as well as expected given the OP and forum section.

I have quite a bad reputation and it's easy to see me as an enemy and someone to fight and not consider the possibilities of an idea due to my bad reputation, which is what we humans do, for none of us are perfect.

This is all merely an idea/possibility, such as BotBits is a possibility. You can choose to use it, or you can choose to not use it, and saying that hardcoding is better is like saying that why use botbits when we can implement a raw usage ( aka making a bot without any SDKs ).

XxAtillaxX wrote:

Again, what would you do if the bot required information from deprecated features, for example, potions?

What would you do if you had deprecated features, e.g. potions? Well, you might begin to find all instances of potion related stuff, and cut the cord on them. If this message at index 18 is supposed to be a potion, cut the cord on that, and let it die. If this function belongs to a GUI implementation of potions, for example that this button disables potions and this button enables potions, find the function that does the work and cut the cord on them. The buttons will become a button that has no wires. If the bot functions soley and the core of it is potions, and there are other features to save, you must cut the cords on potions entirely. Say for example, in the GUI you have a list of players and what potions they have. You also get to select and kick a player, with a programmable feature "if this player uses this potion, kick them.", then let's say that the GUI interacts like this

▼Dirty pseudo code

▼Cutting the cord

XxAtillaxX · 2016-11-11 18:20:21

ninjasupeatsninja wrote:

The maker of the bot would start his bot, and create the form/gui at first. Then, he would create an SDKLogic.dll, of which would be used to store all the stuff inside of the bot.
The original bot would call functions from the SDKLogic, and the form bot would do nothing, but display the graphical contents needed, while the SDKLogic does all the work.
This idea allows the bot creator to put documentation on how to make the SDKLogic, or rather just put the source of it up, and when the bot quits working, someone else may come along, look at the SDKLogic, modify, edit, recompile, and plug back into the old bot, and it works.

How is this any different than using BotBits?

ninjasupeatsninja wrote:

and putting it on github would require more code to be looked at, making finding it more complicated, and if you do make changes, you would have to work with the GUI elements, and there could be potential hard coded rot13 elements you'd have to delete, find all instances of, and eradicate the old stuff, and bring in the new code, which would be troublesome.

How would putting it on GitHub make it more complicated? Less code doesn't mean less complexity, especially if it's packaged in a form that limits it the functionality of the SDK.
Your idea essentially involves abstracting away the issue from the original source, and instead moving it into the SDK.

If you published it on GitHub, it would be incredibly easy to make it work again.
Even if it's closed source, assuming that it isn't obfuscated, it's still easy to modify it and make it work once again.

ninjasupeatsninja wrote:

What would you do if you had deprecated features, e.g. potions? Well, you might begin to find all instances of potion related stuff, and cut the cord on them. If this message at index 18 is supposed to be a potion, cut the cord on that, and let it die.

What if the value at index 18 was replaced, if it was previously potions and now it's crews? What if they needed crews and potions as well?
What if the entire point of the bot was to interact with potions? 'Cut the cord' on the entire bot? - If so, how is it any different than letting it die in the first place - or just rewriting it?
What if in order to make a feature work, they need to add a control to the GUI?

den3107 · 2016-11-11 18:27:16

It's very simple: if it used to use potions, it can't work. period. Unless you'd force the players to use your own version of EE that DOES have potions, but the idea of this topic is for main EE, not ee remakes or whatever.

Now the part where 18 became crew and (eg) 20 would become potions: That's the entire point of making such thing. So you use, for example, names (defined by developer of the, in this case, SDK). Now under the hood those names would the be converted into the actual required int values. In this case instead of using 18, using 20.

EDIT:
The entire point of this topic was to discuss any demand there could be for the bot, not how to implement it.
That's upto the actual developer to decide later (or said developer can create a new topic where he proposes a system and requests feedback)

hummerz5

abrar11 · 2016-11-11 18:59:02

From what I can understand from this post,
maybe a simple notepad file which contains the EE Version, editable by the user, and the ee-url thing not sure what to call it something like 'su9rn58o40itdbnw69plyw', maybe scrape the code and filter out the everybody-edits version, as for dll, not sure maybe have live code updates I guess? (maybe have the .dll on a local site & scrape that every few days via the bot or so, same with code maybe)

SirJosh3917 · 2016-11-11 19:35:14

Maybe we should just make a bot that auto compiles our code for us at runtime so we can easily modify it in a snap.

Official Everybody Edits Forums

#1 2016-11-09 20:40:35

[Idea] Idea to make out-of-date bots always work

#2 2016-11-09 20:43:15

Re: [Idea] Idea to make out-of-date bots always work

#3 2016-11-09 20:47:33

Re: [Idea] Idea to make out-of-date bots always work

#4 2016-11-09 20:50:57

Re: [Idea] Idea to make out-of-date bots always work

#5 2016-11-09 20:53:20

Re: [Idea] Idea to make out-of-date bots always work

#6 2016-11-09 20:55:10, last edited by SirJosh3917 (2016-11-09 20:55:57)

Re: [Idea] Idea to make out-of-date bots always work

#7 2016-11-09 23:23:03

Re: [Idea] Idea to make out-of-date bots always work

#8 2016-11-09 23:29:37

Re: [Idea] Idea to make out-of-date bots always work

#9 2016-11-09 23:50:05

Re: [Idea] Idea to make out-of-date bots always work

#10 2016-11-09 23:50:58

Re: [Idea] Idea to make out-of-date bots always work

#11 2016-11-10 10:07:47

Re: [Idea] Idea to make out-of-date bots always work

#12 2016-11-10 11:46:35

Re: [Idea] Idea to make out-of-date bots always work

#13 2016-11-10 12:40:12, last edited by Vinyl Melody (2016-11-10 12:45:33)

Re: [Idea] Idea to make out-of-date bots always work

#14 2016-11-10 19:45:02

Re: [Idea] Idea to make out-of-date bots always work

#15 2016-11-10 22:30:43, last edited by Tomahawk (2016-11-10 22:31:32)

Re: [Idea] Idea to make out-of-date bots always work

#16 2016-11-10 22:31:05

Re: [Idea] Idea to make out-of-date bots always work

#17 2016-11-10 23:20:30

Re: [Idea] Idea to make out-of-date bots always work

#18 2016-11-10 23:28:26

Re: [Idea] Idea to make out-of-date bots always work

#19 2016-11-10 23:50:36

Re: [Idea] Idea to make out-of-date bots always work

#20 2016-11-11 01:05:46

Re: [Idea] Idea to make out-of-date bots always work

#21 2016-11-11 17:45:51

Re: [Idea] Idea to make out-of-date bots always work

#22 2016-11-11 18:20:21

Re: [Idea] Idea to make out-of-date bots always work

#23 2016-11-11 18:27:16, last edited by den3107 (2016-11-11 18:29:03)

Re: [Idea] Idea to make out-of-date bots always work

#24 2016-11-11 18:59:02, last edited by abrar11 (2016-11-11 19:00:37)

Re: [Idea] Idea to make out-of-date bots always work

#25 2016-11-11 19:35:14

Re: [Idea] Idea to make out-of-date bots always work

Board footer