[request] Reverse-Compatibility Program

hummerz5 · 2016-07-27 02:47:41

Hey. I had this thought. It'd be a load of work, probably not rewarding for a lot of you, but worth some thought:

1. WPE Pro can hook into files to modify incoming packets.
2. We have many bots (right?) that don't work because of the lack of reverse compatibility, people changing protocols up and the like.

Given these, can we create a WPE-like program to interpret incoming packets and modify them to match what the bot expects?

Negative aspects:
- I imagine interpreting the data would be basically having one of the fancy remade PlayerIOClient getups, checking the message type, swapping it based on EE version (perhaps the .exe's file modified meta?)
- If the protocol changes weren't well documented (I doubt if they were), getting this system working would involve looking through defunct bots, determining why they fail, and matching the time span. This is just as useful as simply rewriting the bot.

I feel this is rather "out there" but I'm curious to know thoughts on it, besides "too much work." I mean, we could essentially make the lack of reverse-compatibility a nonissue.

SirJosh3917 · 2016-07-27 06:09:12

I'd have a bot that reads from the github protocol itself, and check if the message meets certain standards.

Koya · 2016-07-27 15:35:18

You could have a master to read the github page then create a file in which bots can read and calibrate the protocol.

Like

{
    "EEProtocol": {
        "gameinformation": {
            "gameID": "everybody-edits-su9rn58o40itdbnw69plyw",
            "version": "213",
            "roomTypes": {
                "normal": "Everybodyedits",
                "beta": "Beta",
                "lobby": "Lobby",
                "crewLobby": "CrewLobby",
                "guestLobby": "GuestLobby"
            }
        },
        "receive": {
            "access": {
                "id": 0,
                "_decription": "Occurs when you are given edit rights in the world."
            },
            "add": {
                "id": 0,
                "_decription": "Occurs when you are given edit rights in the world.",
                "messages": [
                    {
                        "mid": 0,
                        "id": 0,
                        "type": "Integer",
                        "name": "Id",
                        "Description": "The player's id."
                    },
                    {
                        "mid": 1,
                        "id": 1,
                        "type": "String",
                        "name": "Username",
                        "Description": "The player's username."
                    },
                    {
                        "mid": 2,
                        "id": 2,
                        "type": "String",
                        "name": "ConnectUserId",
                        "Description": "The player's unique user id."
                    },
                    ...etc
                ]
            },
            "addedToCrew": {
                ...etc
            },
            ...etc
        },
        "send": {
            ...etc
        },
        "models": {
            ...etc
        }
    }
}

So for the messages the `mid` would always stay constant - it would be in order of age.

So when getting width, rather than using
`m.GetInt(18)`
You load the protocol schema and reader and use
`m.mGetInt(18)` where 18 is the mid (obviously the mid would not be accurate to if it was started in 2010 but it'd be a pain to sort that out now so the mid would be selected on start)

hummerz5 · 2016-07-27 15:54:54

Very good ideas. I've considered those a time, and wondered about similar solutions myself.

I guess the point I wasn't clear about is making existing defunct programs work again (without source code) by doing some intense magic in the networking side of things.

Your methods are great, and I'd love to see /that/ kind of system made, too, but not quiet what I'm getting at.

Koya · 2016-07-27 16:01:41

hummerz5 wrote:

Very good ideas. I've considered those a time, and wondered about similar solutions myself.
I guess the point I wasn't clear about is making existing defunct programs work again (without source code) by doing some intense magic in the networking side of things.
Your methods are great, and I'd love to see /that/ kind of system made, too, but not quiet what I'm getting at.

Ouh I see what you mean now.
It's probably not worth doing it, but might be worth sorting it out for the future.

hummerz5 · 2016-07-27 18:05:34

But on that note, I'm sure bot-programming me would've loved to have a system that ensures the reverse-compatibility.

ninjasupeatsninja wrote:

I'd have a bot that reads from the github protocol itself, and check if the message meets certain standards.

I've thought about that. I wonder if the system would need a caretaker outside of that plan to ensure that if/when the "protocol" changes formats, or someone chooses to rename/redescribe a field, the system doesn't break all around.

@Koya
I'd love for a system that is as innocuous as possible. Could we make a class that inherits the Connection, but does fancy work in the GetInt on the side? Or would it be better to go full-on and make it more obvious like the current SDKs that give names to everything? (they do that, right?).

Your schema looks in-depth. Someone mentioned a while back the method that github uses to track changes in source code without the entire file. Perhaps we could save file size by using some change-tracking method like that, and the code checks back whenever the version # changes.

Would inheriting the connection (if that's possible) still allow other SDKs to run with it?

Also, the golden question: does this system even need creation? That is, what "updates" actually break bots these days? IF it's just the "init" then I guess it makes sense to head over to the fancy non-breaking init code.

Official Everybody Edits Forums

#1 2016-07-27 02:47:41

[request] Reverse-Compatibility Program

#2 2016-07-27 06:09:12

Re: [request] Reverse-Compatibility Program

#3 2016-07-27 15:35:18, last edited by Koya (2016-07-27 15:46:18)

Re: [request] Reverse-Compatibility Program

#4 2016-07-27 15:54:54

Re: [request] Reverse-Compatibility Program

#5 2016-07-27 16:01:41

Re: [request] Reverse-Compatibility Program

#6 2016-07-27 18:05:34

Re: [request] Reverse-Compatibility Program

Board footer