[Release] FutureProof your bots today!

Processor · 2016-12-28 17:14:42

Do you know what's shameful? That almost every bot older than a few months no longer works today.

FutureProof puts an end to that.

It's not a magic fix to all compatibility problems, but if the average person cannot understand why your bot broke after an update, FutureProof probably could have prevented it. Small protocol changes (usually to "init" and "add") still cause almost every bot to crash.

I know that den3107 and ninjasupeatsninja have already tried to make the same thing before, but they're using the wrong tools for the problem. They try to parse the Protocol markdown by Thanel. This is a terrible idea, because Thanel might edit this document at any time and he never agreed to be responsible for the functionality of bots.

My solution is much easier and it doesn't require you to learn a new syntax to access messages. If you have an existing project, you can add FutureProof by only editing ~2 lines of code!

Here's how you can use it:
1. Open Nuget Package Manager Console
2. Enter "Install-Package EE.FutureProof"
3. Change your connection line to look like this:

FutureProofConnection c = cl.Multiplayer.CreateJoinRoom(...).FutureProof(218);

(In this example 218 is the game version you are writing your bot for)

The new FutureProofConnection will work just like a Connection, there is no need to change anything else.

Technical explanation

In the background, FutureProof downloads a dll file containing code that will translate messages between old and new versions. You can never predict how the game will change in the future and this approach gives me maximum flexibility to deal with compatibility issues. Effects of features getting removed or renamed can be minimized this way (e.g. rot13 and woots getting removed).

When EE updates, FutureProof will detect it (by checking the database) and convert incoming messages into their old version. Outgoing messages will be converted to their newer version and sent to the server.

Security
Source code is available on my GitHub, so you can verify these claims.

Downloading a file from the internet can be risky, so I have taken multiple steps to protect your security. The dll file is only downloaded over a secure connection from GitHub. In addition to that, its assembly is signed using a private key that only I have access to. This means that FutureProof will refuse to run the code file if it wasn't compiled on my computer, so even if GitHub was hacked, an attacker wouldn't be able to inject any code into your programs. However, you will have to trust me not to do anything malicious in that dll. I promise I won't!

If this still sounds too scary, your users are free to regularly download the dll file from GitHub, check it for viruses and place it in the same folder as your bots (or in GAC). FutureProof always prefers local resources over online ones.

FutureProof has a weak dependency on this dll, so in case the dll cannot be found or verified, your bot won't crash, but FutureProof won't be able to do its work either and will disable itself.

Use Responsibly
With FutureProof, it can be tempting to stop caring about updates. So I have to beg you: PLEASE don't write bots in version 220 when the game is in version 300! There is a small overhead every time FutureProof needs to upgrade a message and that can add up.
Every now and then, you should take the time to learn the new changes and update your code. If you are too lazy for that, please use a library which does the work for you, like BotBits. (BotBits now natively supports FutureProof too!)

Jesse, Zumza, xJeex, Swarth100, Kaleb, SirJosh3917

drunkbnu · 2016-12-28 17:25:52

Why can't I build the source myself?

Era

mrjawapa · 2016-12-28 17:47:46

Awesome! Can I play UnitEE today?

Zumza, Vinyl Melody, Slabdrill, SirJosh3917

den3107 · 2016-12-28 23:57:48

I assume though that this library will still require you to manually update the external dll/database whenever an update rolls out?

XxAtillaxX · 2016-12-29 00:17:17

The responsibility of updating a utility should be on the maintainers and an agnostic approach like this leads to unintended results and further obfuscating the issues that cause them.
If any developer is worth their salt, they will actively maintain their libraries and most likely do so in a higher-level pragmatic way, as one would with BotBits.

There's a reasonable solution to this: allow for newer utilities to replace the old unmaintained dying ones, like it always has (and always will) be.

Jesse

Processor · 2016-12-29 02:12:44

den3107 wrote:

I assume though that this library will still require you to manually update the external dll/database whenever an update rolls out?

Correct. Depending on EEProtocol would also require you to wait on Thanel. I wish I could recreate InitParse's magic here, but there is no reliable way to do so. Since FutureProof is so easy to implement, you have nothing to lose if you use it. In case I am too slow for you, you will end up updating your bot the traditional way before I'm done.

XxAtillaxX wrote:

The responsibility of updating a utility should be on the maintainers and an agnostic approach like this leads to unintended results and further obfuscating the issues that cause them.
If any developer is worth their salt, they will actively maintain their libraries and most likely do so in a higher-level pragmatic way, as one would with BotBits.
There's a reasonable solution to this: allow for newer utilities to replace the old unmaintained dying ones, like it always has (and always will) be.

FutureProof is something bot users should profit from, not bot makers. The responsibility to keep one's code updated is still on the bot's makers. I expect them to regularly update their bots but during the time they take to do so, FutureProof will serve their users.
Which is why FutureProof mixes so well with BotBits: BotBits makes sure every bot release uses the latest protocol version available and FutureProof makes sure that bot releases from today keep working tomorrow. A new release of the same bot will use the newer BotBits which will no longer require FutureProof's assitance.

I expect that bot makers will continue to do their jobs and not utilize FutureProof during development because they are too lazy to update their code. This will always be the case with BotBits and I will do my best to educate other developers on the consequences of not doing so. After all, lazy bot developer neglecting this advice isn't likely to create a good bot.

Which brings me to my last point. I don't believe it is our job (as staff) to wipe the slate clean every now and then to improve the quality of bots. If an old bot still does its job well, it should still be used until another person makes a better alternative. (This has gotten a lot easier since we've encouraged publishing bots on github) So you won't have to worry, atilla, because the players are still always going to use the best tool for their job. This has always been the case and FutureProof never aimed to change that.

AlphaJon · 2016-12-29 02:36:59

I really appreciate the effort you put into the different projects, making bot creating/using easier for everyone. <3
Maybe one day, we'll see an in-game feature for bot creation, who knows. This would be my single EE fantasy. But I also know this isn't going to happen anytime soon, unless you've gone full crazy with the Unity client's new features.

Tomahawk · 2016-12-29 15:05:07

Processor wrote:

den3107 wrote:
I assume though that this library will still require you to manually update the external dll/database whenever an update rolls out?
Correct.

So you've made yourself responsible for maintaining any bots that use this in the future? - i.e. they'll all break if you get bored?

=3 How noble. How liable. ^^

den3107 · 2016-12-29 15:35:32

Processor wrote:

den3107 wrote:
I assume though that this library will still require you to manually update the external dll/database whenever an update rolls out?
Correct. Depending on EEProtocol would also require you to wait on Thanel. I wish I could recreate InitParse's magic here, but there is no reliable way to do so. Since FutureProof is so easy to implement, you have nothing to lose if you use it. In case I am too slow for you, you will end up updating your bot the traditional way before I'm done.

I know, I know. I wasn't really looking for ways to flame your creation or anything. I just wanted to make sure I was aware of all dependencies at hand (since if this thing'd work autonomously it'd obviously be a no-brainer to go for your tool anytime).

I do hope though, that protocol generation would be more easy for you guys with UnityEE.
As Thanel already said this is fairly easy to do for the blocks, smileys and all that stuff.
In case it would be easy enough, you (or other developers) might actually be able to update this thing semi-automatically (obviously the backwards-compatibility stuff would still have to be done by hand).

P.S. Main reason I made mine as I did, was because I am one of those lazy bot developers that you mentioned in your seconds post (probably the reason why none of my BAL's really bloomed).

Processor · 2016-12-29 17:27:41

@Tomahawk: I'm not selling you bot insurance and you aren't paying anything for this. So no, if a bot breaks, the developers are responsible. By using FutureProof, you're increasing the chances your bot will survive an update, but not handing over the maintenance to me. You are still responsible for keeping your code up to date. (Read my reply to Atilla for more on this)

den3107 wrote:

I know, I know. I wasn't really looking for ways to flame your creation or anything. I just wanted to make sure I was aware of all dependencies at hand (since if this thing'd work autonomously it'd obviously be a no-brainer to go for your tool anytime).

I didn't feel flamed, sorry if it came over that way. The point I was trying to make was that this is already a no-brainer, because FutureProof is so easy to implement it that even if it stopped updating one day, you will have nothing to lose. You are right, it does depend on someone keeping the GitHub repository up to date (and then having me approve their changes, because for security purposes, only I hold the keys for an update) but that person doesn't have to be me (although it will be me, until I get bored of doing it). It is a community maintained project since it is released under MIT on GitHub.

FutureProof only comes into play whenever something unexpected happens, not after every update. New blocks, smileys, etc. are never unexpected and thus never trigger FutureProof. Last time an unexpected change happened was 12 updates ago between version 206 and 207, when the world token (used for placing blocks) was removed. Are you asking me to automate the unexpected?
Unexpected changes will happen in Unity, there won't be an end to that.

den3107 · 2016-12-29 21:44:08

Processor wrote:

den3107 wrote:
I know, I know. I wasn't really looking for ways to flame your creation or anything. I just wanted to make sure I was aware of all dependencies at hand (since if this thing'd work autonomously it'd obviously be a no-brainer to go for your tool anytime).
I didn't feel flamed, sorry if it came over that way.

I guess it was more an... Expectation than an assumption, sorry for misjudging you in that manner, I just see a lot of flaming on the bot section (or I'm just misinterpreting everything here...).

Processor wrote:

Are you asking me to automate the unexpected?

I meant that maybe id shifting could be automated (like how I'm "automating" it by reading the protocol (which still has to be updated manually hence the quotes)) with UnityEE.
Obviously I don't know how much you're changing the internal structure in the Unity version and I expect you guys to still use PlayerIO. So I personally doubt you will be able to automatically generate the parameter id's of the messages out of Unity, which Thanel showed IS possible for smileys and stuff.
I also mentioned that indeed, the backwards compatibility ("fixing" the unexpected) would still have to be done manually:

den3107 wrote:

obviously the backwards-compatibility stuff would still have to be done by hand

I guess I didn't really explain that part enough, but I felt like the post was getting big enough.

Anyways, yeah, do make sure you mention once you're bored of updating it, since otherwise people will probably be like: "Nah, Processor probably just got a vacation and can't update it right now!" Until we're a year further.

XxAtillaxX · 2016-12-29 22:59:38

Processor wrote:

FutureProof is something bot users should profit from, not bot makers. The responsibility to keep one's code updated is still on the bot's makers. I expect them to regularly update their bots but during the time they take to do so, FutureProof will serve their users.

It's of no mystery why you've attempted this. Unfortunately, it remains as useless and insipid as the projects you're attempting to outperform, as any implementation of a stupid idea is nonetheless, by virtue, a stupid implementation.
You seem so very adamant about 'future-proofing' when you are the one causing bugs that undermine actual future-proof measures. You reject consistency as staff, and expect people to use your utilities to solve the issues you create.

There's a few cases in point from my experience.
The first being, you retain non-existent properties on older worlds, so instead of subjecting every world to the changes you create, you allow outdated properties.
The second being, you changed the casing on BigDB object properties. It used to be all lower-case, everywhere, and now it's idiioticCamelCasing.
Gee, I wonder which are yours? width, height, owner, worlddata, name, plays, type, allowpotions, woots, totalwoots, Likes, Favorites.

It used to be the case that you could read a world from the database, and send each block with the properties in order.
Now, you have to deal with blocks with rotations potentially not sending because you expect default values server-sidedly and older worlds do not contain the properties required.

You're clearly unable to maintain future-proofing of any kind, and nobody should put their users' security at risk with downloading binaries they do not control.

Additionally, they shouldn't need to turn to daddy to fix their one-off problems for them in the first place.
Why don't you just have them hand over their source, if you're so adamant about future-proofing?
You've often taken it upon yourself to do their bidding, and openly suck up to the community, such as pandering to your user-base for staff to hire. Who knew graphic suggestions would turn into an employment applicant forum? Why not do the same in this case?

Processor wrote:

Which is why FutureProof mixes so well with BotBits: BotBits makes sure every bot release uses the latest protocol version available and FutureProof makes sure that bot releases from today keep working tomorrow. A new release of the same bot will use the newer BotBits which will no longer require FutureProof's assitance.

You know what would further ensure bots continue working? If you were to make a notice about the pending changes to developers. Instead, you'd rather have them use your tools.

Processor wrote:

I expect that bot makers will continue to do their jobs and not utilize FutureProof during development because they are too lazy to update their code. This will always be the case with BotBits and I will do my best to educate other developers on the consequences of not doing so. After all, lazy bot developer neglecting this advice isn't likely to create a good bot.

Anyone who uses this (which happens to only be the two people you're copying from, if you're lucky) will expect it to live up to it's misleading 'future-proofing' title.
A skilled developer will update their bot accordingly, instead of getting on their knees and opening their mouth for staff members to provide them with 'future-proofing' in such a profoundly stupid way.

Processor wrote:

Which brings me to my last point. I don't believe it is our job (as staff) to wipe the slate clean every now and then to improve the quality of bots. If an old bot still does its job well, it should still be used until another person makes a better alternative. (This has gotten a lot easier since we've encouraged publishing bots on github) So you won't have to worry, atilla, because the players are still always going to use the best tool for their job. This has always been the case and FutureProof never aimed to change that.

It's not your job as staff to support bot developers, however you've decidedly taken it upon yourself every so often to do their bidding, like now, whilst neglecting actual advice that is tangential to success of the game itself, amusingly.
I'm not worried in the slightest. I'm very well aware people will use the best tool for the job, and they'll discard this one in the process.

Processor · 2016-12-29 23:21:52

Dear atilla,

I did this as a member of the EE community and the protocol changes made to EE are done on behalf of the everybodyedits programming team. Please acknowledge this fact.
The EE programming team consists of more voices than only mine and even then I am not going to put my own interests as a bot programmer before the overall administration's goals (which I admit, have been lacking bot friendliness, but that is outside this topic's scope, feel free to create a topic about it elsewhere).
BotBits was created before I became staff and it still remains a project I maintain independent of my administrator role in the game. It is pretty obvious that FutureProof was created for BotBits, so the same applies to FutureProof.

I have dedicated a big section of my post to security and I think it does clarify important aspects of every risk involved. I also offer alternatives for those who are having trouble trusting my method. Ultimately, it will be the developers' and users' decision to accept or deny the risk and I believe I have done enough on my side to educate the users.

Also you seem to have ignored all I've said so far, so I am not going to respond to the rest of your comments. The answers are already in the thread.
Since you clearly aren't going to use this tool, why don't you go waste your time elsewhere?

Best wishes,
Processor

XxAtillaxX · 2016-12-29 23:39:45

The primary voice is yours, and that's clearly evident within the sources.
You say you aren't putting your own interests before the administration's goals, however you're knowingly pending changes that will break bots and instead of giving notices, you're updating this utility.

I have created topics in relation to the issues I've reiterated, and yet instead of resolving them as a staff member, you've decidedly created utilities that would cut around the edges, at best.
I don't believe in anything independent when you're updating your utilities in advance of breaking updates you're fully aware of.

I'm not dismissing your assurances and acknowledgements to users about the inherent insecurity that using this would provide.
It would make a lot more sense to have an open-source pragmatic approach of reviewing the sources before rolling them out to your users, and since such a thing is impractical there remains an essence of insecurity with auto-updating binaries.

I'm not going to waste my time using this tool, like most people, however I'm fully capable of criticising regardless - just because I'm not going to use something, doesn't mean I shouldn't criticise it.

Zumza, Jesse

Processor · 2016-12-30 09:01:46

It's unlikely I will work on updates to FutureProof before an EE update is released to the public, because working on the EE update itself will be more important. The same has applied to BotBits in the past.

If you are looking to critize the staff decisions, this is not the the right place to do so.

Vinyl Melody

Tomahawk · 2016-12-30 18:02:01

▼Me reading this thread:

Proc, I suppose you could post about protocol updates in advance without revealing the update content - i.e. "string will be inserted at init[5]". That way those interested in keeping their public bots working can do so.

Processor · 2016-12-30 18:59:10

@Tomahawk Keep in mind that with your suggestion users will need to download new bots and that won't work if the developer is too busy to update their bot. Therefore it is not a solution to what FutureProof is trying to fix. There will be some downtime after an update even if you use FutureProof. The benefit you get from FutureProof is that it is not dependent on the developers.

Since this is entirely offtopic, I suggest you PM me or create a new topic. I'll gladly talk about the challenges we'd face if we were to release such information ahead of our schedule and why we aren't already doing this.

From now on, I will be issuing off-topic warnings whenever someone addresses me about anything regarding the game administration itself.

Zumza · 2016-12-30 23:08:23

Processor wrote:

From now on, I will be issuing off-topic warnings whenever someone addresses me about anything regarding the game administration itself.

You should be issuing off-topic warnings whenever somebody is off-topic.

Btw. I like this project and I'm looking forward for its BotBits implementation.

Processor · 2017-05-20 21:18:29

An update has been released allowing backwards compatibility for bots made in version 220 or lower. The breaking change in the latest update was a change in "add" that added two new fields at 22 and 23, effectively pushing field 24 (CanEdit) two ids up. The fix removes these new fields, pushing CanEdit back to its old location.

If you have any issues, feel free to message me.

Processor · 2017-05-22 15:17:00

Futureproof v2 was released today.

The new update gives more flexibility to the bridge module, allowing FutureProof patches to fix more complex changes.
The bridge module is now only downloaded if the bot is outdated!

You can update to v2 from NuGet.

If an old bot using FutureProof/BotBits broke after the last update, you can try fixing it by updating their FutureProof library. Simply paste this dll in the same folder as the bot's executable.

Official Everybody Edits Forums

#1 2016-12-28 17:14:42, last edited by Processor (2016-12-28 20:47:11)

[Release] FutureProof your bots today!

#2 2016-12-28 17:25:52

Re: [Release] FutureProof your bots today!

#3 2016-12-28 17:47:46, last edited by mrjawapa (2016-12-28 17:47:53)

Re: [Release] FutureProof your bots today!

#4 2016-12-28 23:57:48

Re: [Release] FutureProof your bots today!

#5 2016-12-29 00:17:17

Re: [Release] FutureProof your bots today!

#6 2016-12-29 02:12:44

Re: [Release] FutureProof your bots today!

#7 2016-12-29 02:36:59

Re: [Release] FutureProof your bots today!

#8 2016-12-29 15:05:07

Re: [Release] FutureProof your bots today!

#9 2016-12-29 15:35:32

Re: [Release] FutureProof your bots today!

#10 2016-12-29 17:27:41

Re: [Release] FutureProof your bots today!

#11 2016-12-29 21:44:08

Re: [Release] FutureProof your bots today!

#12 2016-12-29 22:59:38

Re: [Release] FutureProof your bots today!

#13 2016-12-29 23:21:52

Re: [Release] FutureProof your bots today!

#14 2016-12-29 23:39:45

Re: [Release] FutureProof your bots today!

#15 2016-12-30 09:01:46

Re: [Release] FutureProof your bots today!

#16 2016-12-30 18:02:01, last edited by Tomahawk (2016-12-30 18:02:39)

Re: [Release] FutureProof your bots today!

#17 2016-12-30 18:59:10

Re: [Release] FutureProof your bots today!

#18 2016-12-30 23:08:23

Re: [Release] FutureProof your bots today!

#19 2017-05-20 21:18:29, last edited by Processor (2017-05-20 21:19:14)

Re: [Release] FutureProof your bots today!

#20 2017-05-22 15:17:00, last edited by Processor (2017-05-22 15:36:46)

Re: [Release] FutureProof your bots today!

Board footer