[Release] ProtocolLookup

SirJosh3917 · 2016-07-27 19:56:56

Read from the protocol directly, and add reverse compatibility to your bot.

I decided to make this, but basically, it reads from the protocol and allows you to read messages from the protocol into an easy format.

Everything you need to know can be found on github in the readme

Nuget:

PM> Install-Package ProtocolLookup

https://www.nuget.org/packages/ProtocolLookup/1.0.0

Mediafire:

https://www.mediafire.com/?z18sbdes5rn8gbq

Funny enough, it was actually pretty easy to create...

** Note **
As of right now, it can only grab the "recieve" and "send" messages of the protocol. I will be working on some of the stuff mentioned here.

hummerz5 · 2016-07-27 21:31:24

Can you throw out an example of this usage?
Also, for future reference, WebClient can download strings, saving you the bother of deleting the file.

Looks pretty cool. If I understand it, this could use some expanding to make streamlined (right?). But it certainly makes a pointed effort

SirJosh3917 · 2016-07-28 02:32:32

hummerz5 wrote:

Can you throw out an example of this usage?
Also, for future reference, WebClient can download strings, saving you the bother of deleting the file.
Looks pretty cool. If I understand it, this could use some expanding to make streamlined (right?). But it certainly makes a pointed effort

Did two examples, https://github.com/SirJosh3917/Protocol … r/Examples

Both tested.

One example is for the (un)famous bot breaking fix - the init world width and height message.
The other is to send an "m" message, to move the bot around without breaking it during any update, passing "null so to speak" (not null, but for example, an int set to 0, a boolean set to false, a double set to 0) to any parameter required

Calyfornia · 2016-07-28 03:53:33

So instead of using the protocol in your code, you've written a library that downloads it, searches for text to

add reverse compatibility

- But the text could change in the protocol.

I really don't see the hassle with just reading it, instead of adding a bunch of arguably redundant code...

I'd use it, just I don't _really_ see a point. At all. In the slightest...

den3107 · 2016-07-28 13:07:04

Calyfornia wrote:

But the text could change in the protocol.

Thanel said in this post that the names can be considered official and probably won't change anytime soon.
Being honest I am going to make my own implementation of this, though the usage of it will be some different.
(don't worry ninja, I won't copy code if that's a concern to you)

Anyways. The point of such a lib is to, not necessarily make it reverse compatible, but most importantly make it robust. Keep it alive in the next update and the ones coming. Keep your public or private bot working after a couple months without having touched it (this might not actually work though).
Using things like this saves you the annoyance of fixing your message id's with every update.

SirJosh3917 · 2016-07-28 14:20:26

den3107 wrote:

(don't worry ninja, I won't copy code if that's a concern to you)

I don't mind

den3107 wrote:

Anyways. The point of such a lib is to, not necessarily make it reverse compatible, but most importantly make it robust. Keep it alive in the next update and the ones coming. Keep your public or private bot working after a couple months without having touched it (this might not actually work though).
Using things like this saves you the annoyance of fixing your message id's with every update.

That's exactly the function and even if the protocol happens the change, I want the dll to be "backwards compatible", so to speak, so if there was a bot made with the really early version of this DLL (the current version at the time of posting) and stuff really changed in the EE Protocol, you could download the latest DLL and replace the older one the bot had, so it keeps functioning just like it did before.

hummerz5 · 2016-07-28 16:25:02

ninjasupeatsninja wrote:

you could download the latest DLL and replace the older one the bot had, so it keeps functioning just like it did before.

edit: realized my entire post was "here's how I'd do things bro"

I'll still say this: I'd do some research into what changes you can make to a DLL and still have it work.

Koya · 2016-07-28 16:44:57

hummerz5 wrote:

Koya recently mentioned in the other topic setting up a master (repository?) with the schema, which would fit your "download the latest DLL" idea, except the user doesn't actually have to do that.

Master bot which outputs a JSON file to the web for bots to read - the master bot would keep track of message IDs and changes.
It would be faster and easier to use with this method as the syntax is unchanged.

den3107 · 2016-07-28 22:23:31

Koya wrote:

hummerz5 wrote:
Koya recently mentioned in the other topic setting up a master (repository?) with the schema, which would fit your "download the latest DLL" idea, except the user doesn't actually have to do that.
Master bot which outputs a JSON file to the web for bots to read - the master bot would keep track of message IDs and changes.
It would be faster and easier to use with this method as the syntax is unchanged.

Why JSON?
If you'd upload it to the web generally XML is most logical, some ways of getting "web pages" actually give you an XML object so you don't have to generate an object yourself.

Tomahawk · 2016-07-28 23:36:48

Something like this would only be useful if the protocol is always updated as soon as an update is pushed. Is it?

hummerz5 · 2016-07-29 00:21:18

Each time at runtime.
Ironically, the webclient downloads and analyzes the github stuff. A cache wouldn't be far fetched off that, but the file is deleted IIRC

Calyfornia · 2016-07-29 13:02:27

Or, idea, you just keep your bot up to date

It's far easier than writing a whole library to analyse the protocol, then if wording or sections change, try to guess what they were meaning. This would become more difficult with each change.

hummerz5 · 2016-07-29 13:50:06

Calyfornia, that's a valid point. However, some of us tire easily from doing those tasks repeatedly. If yo have more than one, the time grows linearly. Plus, what are bots for, but to do what humans can do with ease and speed?

If the name changes, that's on the EE admin for swapping that information out; even then, having an intermediate source would allow a caretaker to fix all easily.

Calyfornia · 2016-07-29 14:53:51

hummerz5 wrote:

Calyfornia, that's a valid point. However, some of us tire easily from doing those tasks repeatedly. If yo have more than one, the time grows linearly. Plus, what are bots for, but to do what humans can do with ease and speed?
If the name changes, that's on the EE admin for swapping that information out; even then, having an intermediate source would allow a caretaker to fix all easily.

http://www.wikihow.com/Overcome-Laziness

den3107 · 2016-07-29 18:47:22

Calyfornia wrote:

hummerz5 wrote:
Calyfornia, that's a valid point. However, some of us tire easily from doing those tasks repeatedly. If yo have more than one, the time grows linearly. Plus, what are bots for, but to do what humans can do with ease and speed?
If the name changes, that's on the EE admin for swapping that information out; even then, having an intermediate source would allow a caretaker to fix all easily.
http://www.wikihow.com/Overcome-Laziness

In this "line of work" Laziness generally means productivity which would mean less work for you and less money spent for the company. Obviously occasionally you think you make a tool which would satisfy your laziness but end up taking way too long to make it. But I think a tool like this could easily grow into something very robust. Only little machine learning is required to make it even more robust (and there are plenty of libraries out there that do almost everything for you).

hummerz5

SirJosh3917 · 2016-07-29 19:43:53

With this whole name changing thing and different stuff changing in the protocol, the user could just replace the dll, as my goal is to try have the dll be backwards compatible.

hummerz5 wrote:

I'd do some research into what changes you can make to a DLL and still have it work.

I'd follow c++, they keep all of their old usages, so you can make c++ program for 1990 while programming in c++13.

Official Everybody Edits Forums

#1 2016-07-27 19:56:56, last edited by SirJosh3917 (2016-07-27 20:00:10)

[Release] ProtocolLookup

#2 2016-07-27 21:31:24

Re: [Release] ProtocolLookup

#3 2016-07-28 02:32:32, last edited by SirJosh3917 (2016-07-28 02:38:54)

Re: [Release] ProtocolLookup

#4 2016-07-28 03:53:33

Re: [Release] ProtocolLookup

#5 2016-07-28 13:07:04

Re: [Release] ProtocolLookup

#6 2016-07-28 14:20:26, last edited by SirJosh3917 (2016-07-28 14:21:59)

Re: [Release] ProtocolLookup

#7 2016-07-28 16:25:02, last edited by hummerz5 (2016-07-28 16:35:33)

Re: [Release] ProtocolLookup

#8 2016-07-28 16:44:57

Re: [Release] ProtocolLookup

#9 2016-07-28 22:23:31

Re: [Release] ProtocolLookup

#10 2016-07-28 23:36:48

Re: [Release] ProtocolLookup

#11 2016-07-29 00:21:18

Re: [Release] ProtocolLookup

#12 2016-07-29 13:02:27, last edited by Calyfornia (2016-07-29 13:12:41)

Re: [Release] ProtocolLookup

#13 2016-07-29 13:50:06

Re: [Release] ProtocolLookup

#14 2016-07-29 14:53:51

Re: [Release] ProtocolLookup

#15 2016-07-29 18:47:22

Re: [Release] ProtocolLookup

#16 2016-07-29 19:43:53

Re: [Release] ProtocolLookup

Board footer