[SDK] Fluid

ugotpwned · 2015-02-21 06:21:14

Website (Coming soon!) | GitHub | NuGet
Fluid is a flexible, all-in-one SDK for Everybody Edits made with the programmer in mind.

Fluid is an Everybody Edits Software Development Kit (SDK) created by ugotpwned (me) for .NET, hosted conveniently on NuGet for easy access. The goal of Fluid is to circumvent the burdens of the PlayerIO Client Library by condensing everything into a simplified, yet heavy-duty library that facilitates the process of creating bots. Fluid contains user-friendly classes that make programming bots a cinch for beginning developers, and is advanced enough to handle the demanding tasks of high-level programmers.

Key features of Fluid include:

World and lobby connections
Advanced, real-time physics engine with potion handling
Storage provider utilizing Json.NET
Simplified, token-less Kongregate and Armor Games login
Organized message handlers

Fluid is hosted solely on NuGet. To install the package to your solution, go to the NuGet Package Manager Console and type:

PM> Install-Package Fluid

Or, use the NuGet interface and search "Fluid".

*Moved to github*

After you install the package to your solution, you'll probably want to start making a bot.

For full documentation, look at the README on the GitHub page.

If you need further assistance, please contact ugotpwned (me).

BuzzerBee

BuzzerBee · 2015-02-21 06:22:34

Very nice SDK, definitely rivals some of the more popular ones that are out there.

Can't wait to see this develop further!

By the way, really nice topic

Zumza · 2015-02-21 14:42:43

Its very nice!
I see that lot of people try reinventing the wheel.
How its this better than Skylight by example?

lrussell · 2015-02-21 16:11:26

Or Cupcake, CupCake 2, BotBits, and PacketDispatcher.

ugotpwned · 2015-02-21 19:38:03

Zumza wrote:

Its very nice!
I see that lot of people try reinventing the wheel.
How its this better than Skylight by example?

I'll take this question as how it differs from the most currently available sdks.

-Fluid has easier methods of logging in with Kongregate and Armorgames, simply with a username and password.
-Mousebreaker authentication is supported, and as I know of now, the only supporter. (Rabbit's method is broken)
-Lobby connections are available, which means the user can interact with the shop, and use energy, etc.
-And a small feature as of now, but I plan to expand later, is the ability to change the level through properties. Ex. Block.ID = BasicGray would change id without having to upload specifically
-Physics engine supports all potions. (EEPhysics does not)

This is a small list, and unfortunately I'm in a hurry so I couldn't get them all, but I hope this outlines some of the more obvious differences.

ugotpwned · 2015-02-21 23:22:22

lrussell wrote:

1. That's very simple to implement (convert username to user id, use id to detect authentication method).
2. Fair enough, but I've yet to see pretty much any Mousebreaker users.
3. Fair enough, could be handy.
4. BotBits fully implements that already.
5. Fair enough, but could be an update to EEPhysics.
Not trying to belittle the project, but I guess there's just so many now that it should be unified... q_q

Yeah of course, criticism is good.

I don't think you understand what I meant by logging in with kongregate and armorgames with a username and password. I mean that you can use your actual kongregate or armor username, and kongregate or armor password to login to everybodyedits. No token involved. And lastly, realistically there are only about a few kits that I know of, Cupcake, BotBits, and EECloud that are functional.

BuzzerBee · 2015-02-22 06:52:56

Zumza wrote:

Its very nice!
I see that lot of people try reinventing the wheel.
How its this better than Skylight by example?

lrussell wrote:

Or Cupcake, CupCake 2, BotBits, and PacketDispatcher.

ugotpwned wrote:

...realistically there are only about a few kits that I know of, Cupcake, BotBits, and EECloud that are functional.

Wot there's no such thing as CupCake 2. Also I've never heard of PacketDispatcher.

EECloud was the predecessor of CupCake and isn't functional. CupCake is also becoming more obsolete, I think, as Processor expands BotBits.

So really, there aren't that many.

So why not combine the ones that are already released?

For one, that is impractical as that would basically be like creating a new SDK.

Secondly, BotBits and Fluid are both great tools but they are very different from each other in syntax and functionality. BotBits is probably more structured and has less room for mistakes with the developers. While Fluid provides easy customization and can pretty much be adapted into projects already created.

All in all both SDKs are great and it just comes down to a matter of preference. I've had the pleasure of working with Ugotpwned and Processor and they're both great coders so you can't go wrong with either.

By the way this was typed on my phone so please forgive any errors

Zumza · 2015-02-22 17:58:42

Its feeling strange when I say " I use Fluid by ugotpwned "

Lionhart · 2015-02-23 21:20:18

Ah, that new-SDK smell. Since this appears to be becoming a market, I'll try it out and offer some feedback when I'm done. That might help you or other people who want to download it.

ugotpwned · 2015-02-24 01:56:41

Lionhart wrote:

Ah, that new-SDK smell. Since this appears to be becoming a market, I'll try it out and offer some feedback when I'm done. That might help you or other people who want to download it.

Thanks! That would be great.

Anch · 2015-02-24 03:04:00

Koya · 2015-02-24 12:33:34

ugotpwned wrote:

-Mousebreaker authentication is supported, and as I know of now, the only supporter. (Rabbit's method is broken)

The last time I checked, EE was broken on Mousebreaker..

Lionhart · 2015-02-24 23:21:45

Quick review, perhaps more to come.

I will start with some inconveniences I had:

• `if (Client.LogIn())` doesn't make much sense in terms of readability. It doesn't look like I'm logging in, only seeing if I am logged in. Were it not for this guide I would have no idea what that meant.

• BlockID.cs simply throws every ID into a huge list. A class hierarchy (Block type, package, color) is much better in my opinion. It may be a bit longer in usage but is a little easier to read and write.

• There is a warning that I have never seen before ― mismatch in processor architecture in PcapDotNet.Core. Hasn't been a tangible issue yet but I would still look into it.

• `eventMessage.ChatMessage.Message` feels redundant/repetitive. I don't see the need for the middleman there.

• Player.cs has no public constructor. I understand the reasoning for this ― who needs to create a player if it is all handled by Fluid? Well, there is one use. If one wishes to extend the Player's properties ― for example, adding a Score property ― they have to create a new Player object from scratch (which includes Name, Id, and anything else the developer needs). Then, they need to add a layer between Fluid and their own application so that they can interact (updating properties, calling methods). It's just infinitely easier to inherit the Fluid.Player object, so they can build on top of what you've built instead of starting over and connecting the two.

Good things I've experienced:
• NuGet was extremely convenient.

• Not at all hard to get started, unlike my experience with Cupcake. I love Processor but I feel like I need to read a textbook before I can start writing. That's just me though.

Overall, this isn't bad. There were no bugs to speak of, only minor inconveniences.

On the other hand, it's also not revolutionary. I would like to see some features that nobody has thought of, such as the Player inheritance that I mentioned earlier. Knowing what your users are using it for is pivotal. Some people are content with an elementary reader and writer, but I like to use absolutely everything at my disposal. If I were you I would just consider the different applications of Fluid and how they can receive support.

For example, what if I am the type to create dozens of small bots? You can reduce the amount of ritual boilerplate code by having a quick and dirty login method.

Or what if I am the type who is obsessed with analyzing data? You can never stop adding different types of information. And letting us know that they exist instead of making us read the source.

ugotpwned · 2015-02-25 00:50:04

Koya wrote:

ugotpwned wrote:
-Mousebreaker authentication is supported, and as I know of now, the only supporter. (Rabbit's method is broken)
The last time I checked, EE was broken on Mousebreaker..

Works for me
http://imgur.com/0nH7kIo

Lionhart wrote:

Quick review, perhaps more to come.

I appreciate your feedback.

• BlockID.cs simply throws every ID into a huge list. A class hierarchy (Block type, package, color) is much better in my opinion. It may be a bit longer in usage but is a little easier to read and write.
I agree, and I'm probably going to add an alternative for people that like this option instead.

• There is a warning that I have never seen before ― mismatch in processor architecture in PcapDotNet.Core. Hasn't been a tangible issue yet but I would still look into it.
I've looked into it, and its really not an issue. Shows the warning no matter what architecture specific package your using.

• `eventMessage.ChatMessage.Message` feels redundant/repetitive. I don't see the need for the middleman there.
While it may seem repetitive, it's really just bad naming convention, the ChatMessage contains the player who said the message. Will be changed in the next update though for convenience.

• Player.cs has no public constructor. I understand the reasoning for this ― who needs to create a player if it is all handled by Fluid? Well, there is one use. If one wishes to extend the Player's properties ― for example, adding a Score property ― they have to create a new Player object from scratch (which includes Name, Id, and anything else the developer needs). Then, they need to add a layer between Fluid and their own application so that they can interact (updating properties, calling methods). It's just infinitely easier to inherit the Fluid.Player object, so they can build on top of what you've built instead of starting over and connecting the two.
...
On the other hand, it's also not revolutionary. I would like to see some features that nobody has thought of, such as the Player inheritance that I mentioned earlier. Knowing what your users are using it for is pivotal. Some people are content with an elementary reader and writer, but I like to use absolutely everything at my disposal. If I were you I would just consider the different applications of Fluid and how they can receive support.
Yes, I've actually thought about this and the solution you offered isn't really an optimal one in my mind. Letting the user creating a object used of the kit isn't optimal, especially with players because you're relying on accurate information and no unique information from the user. It's already easy for the developer to create their own player class, it just can't be a WorldPlayer. To add information around an object they could easily create a class like GamePlayer which contains a WorldPlayer and additional properties they need. That would be the best way for people to do this, that's just programming. When players need to save their data that's a different matter, and that's why I have a JsonStorageProvider to save and load user made classes.

tl;dr Fluid still has a long road-map, and I'll continue to take feedback and change as necessary.

Processor · 2015-02-27 01:33:13

Lionhart wrote:

Not at all hard to get started, unlike my experience with Cupcake. I love Processor but I feel like I need to read a textbook before I can start writing. That's just me though.

Not just you Q_Q

ugotpwned wrote:

Yes, I've actually thought about this and the solution you offered isn't really an optimal one in my mind. Letting the user creating a object used of the kit isn't optimal, especially with players because you're relying on accurate information and no unique information from the user. It's already easy for the developer to create their own player class, it just can't be a WorldPlayer. To add information around an object they could easily create a class like GamePlayer which contains a WorldPlayer and additional properties they need. That would be the best way for people to do this, that's just programming. When players need to save their data that's a different matter, and that's why I have a JsonStorageProvider to save and load user made classes.

Back in the days of EECloud, we used to allow every "plugin" to have their own player class inherited from the main player class. And then you inherited Plugin<MyPlayer>.

While it was pretty convenient, it was really hard to write APIs for it, because every API class that accepted a player as a parameter had to have a internal version of itself (because multiple plugins running on the same connection had different player object types) and it used to be a real mess. Nowadays, I usually provide a "Metadata" API, which is basically two methods: Get<T>(string name); and Set<T>(string name, T object);

Having custom wrappers around the player classes is kinda hard because you need to have an internal dictionary mapping the players returned by the api to the ones you have. Oh and have fun making sure there are no memory leaks when people leave

A much better solution would be to use something like http://connectedproperties.codeplex.com/ here...

ugotpwned · 2015-02-27 04:46:31

Processor wrote:

Having custom wrappers around the player classes is kinda hard because you need to have an internal dictionary mapping the players returned by the api to the ones you have. Oh and have fun making sure there are no memory leaks when people leave

Imo, it's really not that hard, and what memory leak are you talking about? There would be no memory leaks if they wrapped around it, .

But, because it seems "hard" to many people, I added methods to attach your own data to world players.

Processor · 2015-02-27 15:12:45

ugotpwned wrote:

Imo, it's really not that hard, and what memory leak are you talking about? There would be no memory leaks if they wrapped around it, .

You would need to make sure to remove players once they leave the room or your dictionary will expand infinitely.

I'm not exactly sure if I understood what you said correctly, but having built in methods to save variables on players is a good idea for a bot framework imo. This is something you actually see often in frameworks, example: WinForms Controls have a Tag property...

ugotpwned · 2015-02-27 20:09:18

Okay, I hope you understand memory leaks because a dictionary expanding infinitely for one is impossible in this context and also makes no sense. Two if it theoretically happened wouldn't be a memory leak, dictionaries are automatically released by the garbage collector.

Processor · 2015-02-27 20:44:42

I do understand memory leaks, I think you don't understand the situation I am trying to explain. Well, nevermind, since you've added methods to attach properties, this isn't a concern anyway.

ugotpwned wrote:

if it theoretically happened wouldn't be a memory leak

Wat?
A memory leak isn't a memory leak, okay...

C# is still vulnerable to memory leaks, they just don't happen with circular dependencies like they do in unmanaged languages. A GC isn't the magical answer to every memory leak problem, lol

ugotpwned · 2015-02-27 20:49:01

Guy, I never said a memory leak isn't a memory leak or that gc is the magical answer. Ofc c# is vulnerable, usually only with unmanaged calls/resources though. *facepalm*

Processor · 2015-02-27 21:00:34

ugotpwned wrote:

Ofc c# is vulnerable, usually only with unmanaged calls/resources though. *facepalm*

In my experience, debugging and fixing managed memory leaks have been a much harder task. Usually, people understand how to deal with unmanaged resources. C# makes it really easy to dispose unmanaged resources. This convo is hopeless, can we drop it?

Anyway, I've started experimenting with your api. One issue I've been encountering is that the "playerHasBuildersClub" is not set correctly... Any idea why?

EDIT: Thx for fixing

Official Everybody Edits Forums

#1 2015-02-21 06:21:14, last edited by ugotpwned (2015-03-17 04:04:44)

[SDK] Fluid

#2 2015-02-21 06:22:34, last edited by BuzzerBee (2015-02-21 06:41:38)

Re: [SDK] Fluid

#3 2015-02-21 14:42:43

Re: [SDK] Fluid

#4 2015-02-21 16:11:26

Re: [SDK] Fluid

#5 2015-02-21 19:38:03, last edited by ugotpwned (2015-02-21 19:38:54)

Re: [SDK] Fluid

#6 2015-02-21 23:22:22

Re: [SDK] Fluid

#7 2015-02-22 06:52:56, last edited by BuzzerBee (2015-02-22 06:55:28)

Re: [SDK] Fluid

#8 2015-02-22 17:58:42

Re: [SDK] Fluid

#9 2015-02-23 21:20:18, last edited by Lionhart (2015-02-23 21:25:10)

Re: [SDK] Fluid

#10 2015-02-24 01:56:41

Re: [SDK] Fluid

#11 2015-02-24 03:04:00

Re: [SDK] Fluid

#12 2015-02-24 12:33:34

Re: [SDK] Fluid

#13 2015-02-24 23:21:45, last edited by Lionhart (2015-02-24 23:35:23)

Re: [SDK] Fluid

#14 2015-02-25 00:50:04, last edited by ugotpwned (2015-02-25 00:52:38)

Re: [SDK] Fluid

#15 2015-02-27 01:33:13

Re: [SDK] Fluid

#16 2015-02-27 04:46:31

Re: [SDK] Fluid

#17 2015-02-27 15:12:45, last edited by Processor (2015-02-27 15:17:05)

Re: [SDK] Fluid

#18 2015-02-27 20:09:18

Re: [SDK] Fluid

#19 2015-02-27 20:44:42

Re: [SDK] Fluid

#20 2015-02-27 20:49:01

Re: [SDK] Fluid

#21 2015-02-27 21:00:34, last edited by Processor (2015-02-28 13:22:15)

Re: [SDK] Fluid

Board footer