Official Everybody Edits Forums

Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?

You are not logged in.

#1 Re: Bug Reports » Cannot join Campaign-World 'Frostbitten' » 2016-02-12 01:00:28

Seemingly yes. As it appears I am not even able to join any other level anymore including self-created ones.

#2 Bug Reports » Cannot join Campaign-World 'Frostbitten' » 2016-02-08 01:14:01

EuadeLuxe
Replies: 2

Hello there,

simply put: whenever I try to join the first world of the Wintery Wonders Campaign 'Frostbitten' I get disconnected with the following error message: http://prntscr.com/a0dcez
I have had this issues for several days now, tried logging in and out on both beta.everybodyedits.com as well as everybodyedits.com but nothing helped. I am wondering if only I am experiencing
this bug or whether this might bee a frequent issue. In any case I would be delighted if it could be helped.

Best regards,
EuadeLuxe

#3 Re: Bug Reports » [UI] Profile display offset » 2015-09-28 21:54:55

If it's been causing problems for some time now, it might be an idea to fix the size of the UI container displaying all worlds. You could then pre-render the mipmap of any ultrawide worlds onto an extra image if that's feasible and scale that image down for display afterwards. That would at least not cause the world container to overflow anymore.

Best regards,
EuadeLuxe.

#4 Bug Reports » [UI] Profile display offset » 2015-09-28 21:14:56

EuadeLuxe
Replies: 2

Hi there,

Some profiles don't seem to be aligned properly when viewing them on the homepage:
QFV31i7.png

As this only happens shortly after worlds are being loaded I suspect it's got to do with the arrangement and sizes of the world minimaps shown on the right.

Meta-Information:
Browser: Google Chrome
Browser Version: 45.0.2454.101 m
Flash version: Shockwave Flash 19.0.0.185 (PPAPI, PepperFlash)

Hope that information is detailed enough.

Best regards,
EuadeLuxe.

#5 Re: Game Business » [Update] 27th of September - Half blocks, low gravity effect, more! » 2015-09-28 14:54:39

I do have to say that I really enjoy the domestic pack. Seemingly TOOP's hard work paid off after all //forums.everybodyedits.com/img/smilies/wink

Great work, keep updating!

#6 Re: Bots and Programming » [Statistics] Best Delay For Sending Blocks » 2015-03-14 20:22:18

Btw, you should also take into account for Network Latency. So if you really want to be as accurate as possible you might even need to calculate the player's current ping.

#7 Re: Bots and Programming » EE Troll Catcher [Help w. Accuracy] » 2015-02-21 14:39:00

Well, I don't know whether you actually got my point. In one sentence: "Work by connecting several small evidences in a user-defined manner into a cohesive detection network." I personally can't image what chrome's flag page has to do with that.

#8 Re: Bots and Programming » EE Troll Catcher [Help w. Accuracy] » 2015-02-20 23:38:53

Well, I don't actually suppose that one may simply write "that one bot that will prevent trolling". I assume so, as you will have for any of your detections either some heuristics or at least some thresholds. In fact though, you could easily leverage them to at least create a utility which might come in handy at some point of development. You see: You could define several "rules" whose thresholds may be changed in a configuration file. By doing so you would enable the users of your bot to try out and experiment what effects different violation levels of the rules you implemented in your bot would have which effects on the gameplay in general. Thus your users could determine on their own how far they'd like to take it with troll prevention. Just for clarification, here's one stupid example for demonstration:

Let's assume you had a rule which always checks on how many blocks a player places in a specific time span. If the value surpasses a configurable threshold it would throw a violation which your bot could then handle accordingly.

The configuration might look like this:

# The number of blocks a player may set in x seconds:
rule.brick.place.threshold=50

By combining multiple rules now (e.g. how distant those blocks are placed from each other - useful for making a distinct detection of whether a player is building those "troll lines" we all know) you could effectively narrow down the set of possible trolling interactions. Only if defined (maybe event configurable) criterias would be fulfilled you would then assume a player to be a troll. In case you know the Minecraft Plugin "NoCheatPlus" - this is effectively what it does in order to prevent hacking: giving its users the ability to sort out whatever they don't like on their servers.

Hopefully you got a rough understanding of what I'd suppose.

Best regards,
EuadeLuxe.

#9 Re: Bots and Programming » [Question] Access level » 2015-02-20 11:08:42

Well, um, what about restructuring your code a little bit here? I assume you've got that class called user in some kind of namespace. So you've got exactly two options to overcome your problem:

  1. You make all fields inside your user class private and have the message handler be a function inside your class so that it will have access to the classes private fields directly. For users of your class you may then simply provide read-only properties. You might even want to consider a manager class for your user's which maps each user object on its unique id.

  2. Or you might want to have that manager class to have access to the user object's fields by making all the fields package-intern (I don't remember how it is called in C#) and putting the manager class inside the very same namespace. You then need only one message handler inside the manager class which will look for the appropriate user object whenever a message is received and then updates its fields properly.

In fact, I suppose this is what @tikenalpha proposed as well.

#10 Re: Bots and Programming » [BotSDK] PacketDispatcher for easier Bot-Development » 2015-02-20 01:04:32

@Processor: Yeah, but how should something be different if it's explicitely defined by EE //forums.everybodyedits.com/img/smilies/tongue ?  And yes, I totally agree with you, that performance shouldn't be the greatest of all concerns when it comes to writing bots for EE. Currently for getting into it I'm developing the "Game of Life" for EE just to get used to it again and in fact performance of deserialization is not really the big problem there.

#11 Re: Bots and Programming » [BotSDK] PacketDispatcher for easier Bot-Development » 2015-02-19 22:18:13

It's quite hard to get any reasonable benchmarks for it as there are several points one should consider about any kind of information posted here:

  1. The number of handlers which will be invoked once a packet is received will change dynamically. Therefore invocation times will ultimately sum up.

  2. The more payload a packet contains the longer it will need in order to be deserialized. As the length of packets varies greatly (from the init packet to the god packet for example) there's no really "consistent" time a deserialization of the raw message data will take

But still I've benchmarked the time it takes to deserialize different messages into their respective packet wrapper classes and summed them up here:

  • 205 x PacketPlayerCollectCoin: 00:00:00.0041107 => 0.02005ms per Packet

  • 200 x PacketPlayerBrickPlace: 00:00:00.0056117 => 0.02848ms per Packet

  • 36 x PacketPlayerChat (each one contained exactly four characters): 00:00:00.0009833 => 0.02731ms per Packet

Still, these numbers will barely be of any use to you as you should do not have to worry about them in any existing system.

I do not now how the dispatcher compares against CupCake or similiar as I did not try them out yet (as I mentioned in the introduction, I just recently began to develop bots again). In fact a comparison against PlayerIO would be useless as the packet dispatcher still uses the PlayerIO.Message object internally. The only place where the packet dispatcher might be faster then using PlayerIO message handlers directly is, when it comes to the point that multiple handlers deserialize the very same message multiple times. Still, these are very vague predictions.

#12 Bots and Programming » [BotSDK] PacketDispatcher for easier Bot-Development » 2015-02-19 16:41:42

EuadeLuxe
Replies: 9
Introduction

Hello to all of you out here,

after quite some time I went back to creating bots for EE and soon got into it again. Actually though, I have been disgusted of writing the "message" handlers (as PlayerIO calls them) all by branching for different types of messages and always having to know the order of the messages internally in order to get at the information I want. Therefore I sat down and wrote a small system which might be useful to some of you. Please excuse me, if something similiar already exists, but as I said I just returned to creating bots so i'm not up-to-date when it comes to that.

Below you will find a quick overview of the system and a link to the GitHub-Repository.

----------------------------------------------------------------------------------------------------------------

The Basic Concepts

The basic concept of "MessageLib" (that's what it's called like) is that all messages sent to EE or received from EE are wrapped into classes. Each class may then either be an inbound packet (i.e. a packet which you receive) or an outbound packet (which you may send). Using the Connection object which probably all of you know you are given an extension method called Send(...) which will effectively do all the serialization into the actual Message object for you, i.e. there's no difference in whether or decide to use messages directly or use MessageLib. For inbound packets things even get a bit nicer as MessageLib provides you with something I call a "Dispatcher". Whenever you acquire a new connection object you may hand it over to the dispatcher which will from now on respond to all received messages and dispatch them around all your listeners. I hear you saying: "But what da heck are listeners?" Well, arguably it'd be best, if I'd just show you a little example:

using MessageLib;

namespace MyHyperCoolBot
{
    public class MainClass
    {
        public static void Main()
        {
            // We assume that these instances we're already initialized:
            PlayerIOClient.Connection connection;

            // Here we may now create our dispatcher:
            PacketDispatcher dispatcher = new PacketDispatcher();
            dispatcher.AddConnection( connection );
            dispatcher.RegisterListener( new MyPacketListener() );
        }
    }


    public class MyPacketListener : IPacketListener
    {
        [PacketHandler]
        public void onInit ( Packets.In.PacketInit init )
        {
            // Do something awesome with our packet:
            string worldKey = init.Derot;
        }
    }
}

In this example the onInit(...) method of our listener will be invoked whenever an "init" message is received. Why is that? Because the packet dispatcher does all the work of deserializing the messages appropriately for you and then invokes any methods of listeners registered to it which fulfill the following conditions:

  1. The method possesses an PacketHandler attribute

  2. The method takes exactly one parameter which is an instantiatable type implementing the IInboundPacket interface

This effectively means that you may treat whatever EE sends to you as some kind of event which may be handled by any object you like. Another example for getting notified whenever a user takes the crown:

[PacketHandler]
public void onPlayerCrown( Packets.In.PacketPlayerCrown crown )
{
    // We might do all kinds of things here. crown.UserID is the ID of the user who has taken the crown.
}

For sending a packet back to EE we would do something like this:

connection.Send( new Packets.Out.PacketPlayerTrophy() );

which would give our bot the silver crown. The library comes with a whole bunch of predefined packet classes. If you find them to be wrong or not working please let me now, or even fix them yourself. If you are missing In- / Outbound packets you may tell me as well or you may even write them yourself. Just have a look at how it's done in the library itself, it's really not that hard. Just don't forget to make your packet known to the PacketDispatcher by doing:

dispatcher.RegisterPacket( typeof( MyVeryAwesomePacket() ) );

----------------------------------------------------------------------------------------------------------------

Conclusion

To me this system has proven its value as it allowed me to decentralize my work a lot more than registering message handlers all the time. Also it allows for much cleaner code in my opinion - that must not be true in yours as well (!).

Finally, here's the link to the project's GitHub-Repository, enjoy: https://github.com/EuadeLuxe/MessageLib

Best regards,
EuadeLuxe.

Board footer

Powered by FluxBB

[ Started around 1715785016.1393 - Generated in 0.112 seconds, 10 queries executed - Memory usage: 1.38 MiB (Peak: 1.53 MiB) ]