Official Everybody Edits Forums

den3107

Member

From: Netherlands

Joined: 2015-04-24

Posts: 1,025

[ALPHA] EEProtocol - Keep your bots from breaking due to updates.

Long story short... But you didn't even give us the long version :c
Bots tend to break after new functionality is put in Everybody Edits... This library is supposed to help prevent that from happening.

The Github page contains the dll, examples of how to use the library and the source code. For anybody interested.

▼Reason this is still alpha

Currently the dll only supports receiving messages, to prevent id shifting from breaking your bots.

The library probably also lacks some user friendliness, so this topic is also made to request suggestions to improve the functionality.

I attempted to document the library best I could. I never documented on C# before, so forgive any mistakes.

▼Limitations/dependencies

The library currently has certain limitations/dependencies:

• The library uses the Everybody Edits protocol by Thanel. Whenever existing stuff here changes (eg a name changes), your bot WILL break.

• The librarycurrently doesn't really do anything with variable or lists of ids. Why? Because then my library would either require some hard-coding (which is entirely against the purpose of this) or require an AI to understand English. Example message.

• All names are lower-case. This is to allow some methods to be case-insensitive without me having to make giant work-arounds.

• The dll currently has no form of caching. Meaning it will download and parse the protocol on every run, instead of only re-parsing on a new Everybody Edits version.

If you have any suggestions, remarks or feature requests, feel free to post.

den3107

Member

From: Netherlands

Joined: 2015-04-24

Posts: 1,025

Re: [ALPHA] EEProtocol - Keep your bots from breaking due to updates.

I changed the structure a little bit, since it previously didn't support sendable messages in the same way as receivable messages.
I also doubt I'm going to actually make the sendable message part, since I don't think the protocol for a sendable message ever really did an id shift, but instead really broke the way it worked previously.

If there're any improvements you can find or just wanna drop a "thank you for making this", feel free to do so.

XxAtillaxX

Member

Joined: 2015-11-28

Posts: 4,202

Re: [ALPHA] EEProtocol - Keep your bots from breaking due to updates.

This has been created before (cit) by Ninjasupeatsninja.
It's completely and utterly useless and will not prevent any bots from breaking.

"Whenever existing stuff here changes (eg a name changes), your bot WILL break."
No duh.

---

*u stinky*

den3107

Member

From: Netherlands

Joined: 2015-04-24

Posts: 1,025

Re: [ALPHA] EEProtocol - Keep your bots from breaking due to updates.

This has been created before (cit) by Ninjasupeatsninja.

I personally felt like this would be more use-friendly than Ninja's. Though I assume that's kinda taste-based.
Plus I feel like this method will make bots a bit more readable, since you use names instead of integers, which can obviously also be fixed by using enums or stuff alike (though with enums the bot would still break upon id shifting).

It's completely and utterly useless and will not prevent any bots from breaking.

Pretty much all my current bots break solely because of the index shifting on the receiving message part (mostly init, obviously), which would be fixed fixed by using stuff like this or Ninja's.

"Whenever existing stuff here changes (eg a name changes), your bot WILL break."
No duh.

Trust me, even with this notice people are going to say "y i gets KeyNotFoundException?!".
Plus it would be possible to write some (possibly complicated) logic that tries to interpret newly found names and convert them to the old names as extra reference. For example remove all whitespace (some message names have spaces while others don't, so they might change) or look at synonyms for words on non-existent keys to find its closest relative.
In that case it's not a guarantee your bot will break when a name would change, which currently is not the case.

P.S.
If you're gonna bring the potion problem in again (not sure it was you, so excuse me if it wasn't):
That bot would be impossible to fix, unless you switch to an alternative to potions, which might not always exist. Automating a method of detecting alternatives to removed mechanics would have to be done hard-coded, which, again, is against the whole principle of this dll.
This dll is meant to keep your bot running when additions are made (as mentioned in the OP). It MIGHT still save your bot when things are removed, but obviously only if you didn't use the things removed.

XxAtillaxX

Member

Joined: 2015-11-28

Posts: 4,202

Re: [ALPHA] EEProtocol - Keep your bots from breaking due to updates.

If you were to do something like this, I'd highly suggest NOT basing it off of a markdown document and format it the same way that already existing framework does. (see: BotBits)
I'm fairly certain any mashing on the keyboard would be more user-friendly and productive than his libraries, however shifting the burden onto a higher-level abstraction of the problem is not a practical solution.

And yes, I brought up the potion dilemma, however it was a refutation against Ninjasupeatsninja's flat-out refusal to drop outdated bots.

---

*u stinky*

Tomahawk

Forum Mod

From: UK

Joined: 2015-02-18

Posts: 2,847

Re: [ALPHA] EEProtocol - Keep your bots from breaking due to updates.

You could always...y'know...skip trying to code the impossible and just embed an auto-updater as the next-best thing.

Then cuddle up to proc for insider info on protocol changes and push a pre-update release that'll handle both protocols.

---

One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.

den3107

Member

From: Netherlands

Joined: 2015-04-24

Posts: 1,025

Re: [ALPHA] EEProtocol - Keep your bots from breaking due to updates.

If you were to do something like this, I'd highly suggest NOT basing it off of a markdown document and format it the same way that already existing framework does. (see: BotBits)

At first I wanted to format in such a way, yes.
However there's a problem when you'd want to do this automatically (which is the whole point of this):
Instead of this being a DLL, it'd be an executable. Why? Because obviously you'd want intellisense (autocomplete) when looking through the message types.
In order to provide that, you'd have to first parse the protocol (through whatever means) and then compile an assembly containing enums/classes/whatever which could then be imported into your personal bot.
So I went for, what I think is, the next best thing, which would be a multi-level dictionary style, so you use a ton of hooked brackets and strings ([""]) instead of dots and names.
Sadly this method obviously still doesn't provide intellisense due to the strings.

About the part of not basing it of a markdown document:
I know it's not the best thing, but it would be either that, reading the source of another decently-updated product (like botbits) or reading out the swf itself, where the swf method would be WAY more trouble to make (trouble I don't wanna go through) and I personally also expect would be way more prone to bugs.

Though I do want to say:
If you have other alternatives, please do tell, so I can look into the possibilities to make this thing sturdier and potentially more useful.

You could always...y'know...skip trying to code the impossible and just embed an auto-updater as the next-best thing.

This wasn't meant as an "alternative" to auto-updaters, but instead as a manner so that the bot wouldn't NEED an update altogether when the id's would be shifted due to added mechanics.

Aside from that it's also meant for both public and private bots. I personally hate having to fix all id's after 3 major updates (due to not touching my bot in a while). So I made this so I don't have to fix it myself, but it's (most of the time) already fixed.
Plus, as I said in my previous post. I can now use names instead or integers, where obviously names are much more meaningful.