Official Everybody Edits Forums

Could also be the frogs !

FISHBOT SOON. ᴵ'ᶫᶫ ᵗʳʸ ᵗᵒ ʰᵃᵛᵉ ᶦᵗ ᵘᵖ ᵃᶰᵈ ʳᵘᶰᶰᶦᶰᵍ ᵇʸ ᵗʰᵉ ²ᶰᵈ

spartan is betterrr

You can't just replace your reference with a newer version. Obviously if you replace the library the code will be different. One of the most obvious being that Logging in now requires playerIoSegments.

Touche.

No more illuminati pls. thx. k bye.

Sigh.

Here's some handling code for you. Feel free to explore the rest of the handlers for the other lobby messages.
https://github.com/ThyChief/Fluid/blob/ … Handler.cs

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*

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.

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

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.

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.