Official Everybody Edits Forums

SirJosh3917

Formerly ninjasupeatsninja

From: USA

Joined: 2015-04-05

Posts: 2,095

Can we please have some consistency?

UPDATE: created a class to help propel this agenda forwaard

BlockPacket

I hate the fact that EE is so inconsistent everywhere. Ranging from the GUI to the backside development. It's sickening. It's not fun to develop for. It's tiring. It's angering. Why should I be dealing with the fact that you have a separate message for every single block type? I expect "b" to contain every single block that I need to place. It should have a basic amount of information, and every block that gets placed should send that. But no - there's 'bc', 'bs', 'lb', 'pt', 'ts', 'wp', 'br', and 'b'. Why? This is outrageous. There are these minor discrepancies everywhere.

Here's my solution to 'b' :

EXAMPLE PACKET
    "block":
        [0]: playerid as uint ( the id of the player responsible for placing the block )
        [1]: layer as uint ( could be a bool for extra packet saving, if bool: true for foreground, false for background. If the need arises for multiple layers, use bytes: 0x00 for foreground, 0x01 for background or continue using uint )
        [2]: x-coordinate as uint
        [3]: y-coordinate as uint
        [4]: blockid as uint ( there are alot of blocks, and while I believe that blocks should have more "morphs" to lighten up on the massive amount of id overuse, I won't get into that here )
        [5]: blocktype as uint ( please see below for block types )  |Could save packet space and use a byte
        { As 'Regular Block ( 0, 0x00 )' }
        
        { As 'Number Value ( 1, 0x01 )' 
            OR
          As 'Morph ( 2, 0x02 )' }
            [6]: [Number Value OR Morph] as uint ( [the number value OR the morph] )
        { As 'Sound Block ( 3, 0x03 )' }
            [6]: Sound Id as uint ( the sound id )
        { As 'Label Block ( 4, 0x04 )' }
            [6]: Text as string ( the text on the sign )
            [7]: Color as string ( the color of the sign )
        { As 'Portal ( 5, 0x05 )' }
            [6]: Portal Rotation as uint ( for additional compatibility with the Number Value and Morph packet. )
            [7]: Portal Id as uint ( the id of the portal )
            [8]: Target Id as uint ( the target that the portal is going to )
        { As 'Sign Block ( 6, 0x06 )' }
            [6]: Sign Text as string ( the text on the sign )
            [7]: Sign Type as uint ( the type of sign as a uint ) |Could save packet space and use a byte
        { As 'World Portal ( 7, 0x07 )' }
            [6]: Target World as string ( the world id that is the target )
FOR ADDITIONAL CONSISTENCY: I changed all instances of 'int' to 'uint' for additional consistency, and I have slight faith in the packet serializer that it'll minimize the size of the uints.

I also suggest continuing broadcasting the good ol' 'b' and the like until V 230 so that the bot world has time to adjust to this sudden change in protocol.
I also suggest attempting to have some consistency between every packet , e.g. in my new 'block' packet, since playerid is at the 0th position, you *should* expect the 'c' message to also have the PlayerId at [0], and to use the same uint ( not Integer ) datatype.

Honestly this is the most frustrating thing, and it'd be very nice if someone on the small development team that EE has to make some progress towards consistency.

Just remember that the "If it ain't broke, don't fix it" motto was also applied to hospitals who still used Windows XP and got the WannaCry malware on their systems causing lots of damage.

Also, for additional packet storage saving space, consider switching some uints to ints and uints to bytes for additional packet saving space, since I used all uints for consistency.
__________________________

I'd like your opinion on my new packet-suggestion-idea-change, and what parts of it you agree with and what parts you don't.
If you also see multiple packets that have discrepancies, do note them.

__
UPDATE:
For the sign packet, made sign text first and then sign type because it makes more logical sense in the brain.

---

Scarlet - EE & EEU Minimaps for the forums

Smiley Face Game | Join Discord

Finance me. I want your money.

LukeM

Member

From: England

Joined: 2016-06-03

Posts: 3,009

Website

Re: Can we please have some consistency?

IMO it would be more consistent to have every message type always be the same than have conditional arguments that you need to check previous values to see if they should be there or not...

Tomahawk

Forum Mod

From: UK

Joined: 2015-02-18

Posts: 2,847

Re: Can we please have some consistency?

It’s worth finding out why multiple block messages were created in the first place.

There may be a good reason.

---

One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.

LukeM

Member

From: England

Joined: 2016-06-03

Posts: 3,009

Website

Re: Can we please have some consistency?

^ probably just because they require different information (that's why there are different message types in the first place, otherwise why don't we merge all messages into a single doStuff message, with every parameter being optional)

SirJosh3917

Formerly ninjasupeatsninja

From: USA

Joined: 2015-04-05

Posts: 2,095

Re: Can we please have some consistency?

UPDATE: created a class to help propel this agenda forward

BlockPacket

---

Scarlet - EE & EEU Minimaps for the forums

Smiley Face Game | Join Discord

Finance me. I want your money.

Gosha

Member

From: Russia

Joined: 2015-03-15

Posts: 6,211

Re: Can we please have some consistency?

This was made for easier bot making and clientside coding.

It's easier to send just 1 type of message to send the block. So you won't need to make a class to switch block id for block types.
It's easier to receive multiple types of blocks so you won't need to switch between block ids from 1 type of message.

den3107

Member

From: Netherlands

Joined: 2015-04-24

Posts: 1,025

Re: Can we please have some consistency?

for additional packet storage saving space, consider switching some uints to ints

Correct me if I'm misunderstanding:
Are you saying here that some uints should be switched to int to save packet size?
The reason I'm asking this is because both ints and uints use 32 bits of space (the uints just have an extra bit for bigger number signs because it's unsigned (non-negative)).

Something I would like to add is to improve the message names...
Two examples:
tele vs teleport (sounds more like respawn vs teleport).
god vs togglegod (sounds more like togglegod and togglegodright/privilege).

Haven't really looked into inconsistencies in message structure, and been a while since I wrote a bot.

Slabdrill

Formerly 12345678908642

From: canada

Joined: 2015-08-15

Posts: 3,402

Website

Re: Can we please have some consistency?

I don't know how the current storage system works, but assuming placing a block only sends one packet and not two, I approve of this.

There are times where I don't care what block is placed, so it would be useful to only need to listen to one packet type in those cases instead of 10.

---

suddenly random sig change

Tomahawk

Forum Mod

From: UK

Joined: 2015-02-18

Posts: 2,847

Re: Can we please have some consistency?

I don't think this suggestion is an improvement.

1. The current block messages have a fixed number of params each. This makes them simple for newbie bot coders to use, as compared to the inherent variability of your hypothetical message type.

2. I like the idea of being able to track only portal placements (for instance). It allows for a bunch of optimisation as compared to a single block message - where every message would need to be scanned to find the portals. Your suggestion would be introducing lag to message-type-specific BALs.

This is outrageous.

I'm assuming it annoys you because of all the human-friendly variables you build into your bot, such as portalRotation and signType in your GitHub example. This is good if you're coding BotBits, otherwise it's a waste of time imo.

If I were you, I'd get rid of those vars and handle block messages the same way InitParse handles "init" - i.e. vacuum up the data with as few assumptions as possible.

Here's my code on a plate because at least someone still makes bots;

▼Code

Idk what nub put Layer into "br", but even with that annoyance the mapdata is still super easy to maintain with this method.

//=========================================

string[] blockTypes = { "b", "bc", "br", "bs", "lb", "pt", "ts", "wp" };

struct Block
{
    public int ID;
    public object[] args;
}

Block[,,] bl;  //[layer, x, y]

List<object> args = new List<object>();

//========================================

void OnMessage(bla bla)
{
    if (blockTypes.Contains(m.Type))
    {
        switch (m.Type)
        {
            case "b":
                bl[m.GetInt(0), m.GetInt(1), m.GetInt(2)].ID = m.GetInt(3);
                break;
            case "br":
                bl[m.GetInt(4), m.GetInt(0), m.GetInt(1)].ID = m.GetInt(2);
                bl[m.GetInt(4), m.GetInt(0), m.GetInt(1)].args = new object[] { m[3] };
                break;
            default:
                bl[0, m.GetInt(0), m.GetInt(1)].ID = m.GetInt(2);
                for (uint i = 3; i < m.Count - 1; i++) args.Add(m[i]);
                bl[0, m.GetInt(0), m.GetInt(1)].args = args.ToArray();
                args.Clear();
                break;
        }
    }


   ...the rest of OnMessage
}

On a side note, portal ID and target ID are Int32's.

---

One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.

SirJosh3917

Formerly ninjasupeatsninja

From: USA

Joined: 2015-04-05

Posts: 2,095

Re: Can we please have some consistency?

for additional packet storage saving space, consider switching some uints to ints

Correct me if I'm misunderstanding:
Are you saying here that some uints should be switched to int to save packet size?
The reason I'm asking this is because both ints and uints use 32 bits of space (the uints just have an extra bit for bigger number signs because it's unsigned (non-negative))..

My bad, will edit OP.

I don't think this suggestion is an improvement.

1. The current block messages have a fixed number of params each. This makes them simple for newbie bot coders to use, as compared to the inherent variability of your hypothetical message type.

2. I like the idea of being able to track only portal placements (for instance). It allows for a bunch of optimisation as compared to a single block message - where every message would need to be scanned to find the portals. Your suggestion would be introducing lag to message-type-specific BALs.

I understand that each block message is unique and allows you to pick up different block types. That's fine. What I'm aggravated by, is the fact that ( in your own code ) you had to make two seperate and special cases for "b" and "br". Why? Why wouldn't EE just keep the layers, x, y, and id the same. While I didn't mention this in OP, it still strikes me as inconsistent and messy. Every block message, from "b", "br", and the likes of all of them, should have set positions on X and Y, and set block id locations, and such. "b" and "br" are exempt from this, as you show. You yourself are even angered at this in your post. EE's 'b' messages and their children should go something like:

[0] -> X
[1] -> Y
[2] -> playerid
[3] -> layer ( or custom param arguments start )

feel free to edit that.

I'm assuming it annoys you because of all the human-friendly variables you build into your bot, such as portalRotation and signType in your GitHub example. This is good if you're coding BotBits, otherwise it's a waste of time imo.

People yell at me if I don't code that c# nicely.

If I were you, I'd get rid of those vars and handle block messages the same way InitParse handles "init" - i.e. vacuum up the data with as few assumptions as possible.

Because it's a class, I did this so users could edit specific functions of a case if they wanted to. Also, it helps make checking the message a lot easier to ensure no "fraudulent" packets ( exceptions raised when trying to get a uint when it's really an int? )
But you still have a valid point.

On a side note, portal ID and target ID are Int32's.

Counterargument: check again

On a side note,

(mind the "A INT" grammatical error, should be "AN INT" )

Also, I like your light-weight addition of handling map data. The only downside that I see is that you don't handle the arguments uniquely or anything, but to do that you'd have to create a class and then you'd end up getting my class that I made, and you also loose the whole point of compatability across versions... ( e.g.

▼this

---

Scarlet - EE & EEU Minimaps for the forums

Smiley Face Game | Join Discord

Finance me. I want your money.

den3107

Member

From: Netherlands

Joined: 2015-04-24

Posts: 1,025

Re: Can we please have some consistency?

I like the idea of being able to track only portal placements (for instance). It allows for a bunch of optimisation as compared to a single block message - where every message would need to be scanned to find the portals. Your suggestion would be introducing lag to message-type-specific BALs.

I'm not sure I agree to this.
You always receive all messages (you can't tell the server "only send me 'pt' messages, k thx").
A check against ninja's hypothetical "type" parameter takes nanoseconds. Considering that lag is like trying to breath with specific intervals to be the most efficient with the oxygen in the air.
Now if we would actually receive (at least) millions of messages per seconds (so basically big data analysis) then this kind of micro optimization could be of use, but only then.

Now about your guys' block class...
Looking at Ninja's example, first thing I think of is "Why not use inheritance?".
Base would be block, containing position, layer and id and the inherited classes would add things like origin and destination (for portal).
Gets rid of all the redundant variables and you can make specifications easier (for example only allow a PortalBlock as parameter, instead of check later inside the method if it's actually a portal block).

Looking at Tomahawk's example I'm happy I won't be looking at it next month.
Not because it's necessarily ugly code, but because I won't know what is in each position. And what about an update where an item is added at index 0 and everything has to move up? Nothing works anymore. Great! massive refactoring...
Having said this, I would like to adres the following:

i.e. vacuum up the data with as few assumptions as possible.

This is the exact opposite of what your code does.
While you indeed make no assumptions in the single place where you handle the block message...
You have to assume everything that's inside the block everywhere else in your code!
Again, if the staff would change the order you would have to refactor, but at least it would be in a single position, instead of all over your code.

LukeM

Member

From: England

Joined: 2016-06-03

Posts: 3,009

Website

Re: Can we please have some consistency?

^ I mostly agree with the first half of your post, but

Looking at Tomahawk's example I'm happy I won't be looking at it next month.
Not because it's necessarily ugly code, but because I won't know what is in each position. And what about an update where an item is added at index 0 and everything has to move up? Nothing works anymore. Great! massive refactoring...
Having said this, I would like to adres the following:

i.e. vacuum up the data with as few assumptions as possible.

This is the exact opposite of what your code does.
While you indeed make no assumptions in the single place where you handle the block message...
You have to assume everything that's inside the block everywhere else in your code!
Again, if the staff would change the order you would have to refactor, but at least it would be in a single position, instead of all over your code.

While this would be true if you needed to actually use the blocks data (e.g. for physics simulation), the majority of bots don't do this, they usually only need to store the data to be sent back to EE later (or compared with other stored data), so they dont actually need to know what it means, just that its there.

SirJosh3917

Formerly ninjasupeatsninja

From: USA

Joined: 2015-04-05

Posts: 2,095

Re: Can we please have some consistency?

Looking at Ninja's example, first thing I think of is "Why not use inheritance?".
Base would be block, containing position, layer and id and the inherited classes would add things like origin and destination (for portal).
Gets rid of all the redundant variables and you can make specifications easier (for example only allow a PortalBlock as parameter, instead of check later inside the method if it's actually a portal block).

That's quite the idea. I'll consider implementing a version of my class that's up to your specifications.

Looking at Tomahawk's example I'm happy I won't be looking at it next month.
Not because it's necessarily ugly code, but because I won't know what is in each position. And what about an update where an item is added at index 0 and everything has to move up? Nothing works anymore. Great! massive refactoring...

I believe my code may have the same issues as you stated here. Massive amounts of hard coding of what position is where, I'll have to consider making some kind of method where you can easily update the class to the latest standards and specifications, that make it significantly easier to change things.

---

Scarlet - EE & EEU Minimaps for the forums

Smiley Face Game | Join Discord

Finance me. I want your money.

benedani

Member

Joined: 2015-02-19

Posts: 98

Re: Can we please have some consistency?

Sorry for gravedigging, but seriously, EE's implementation of different block types is the worst way they could have possibly done it. (Well, apart from using a different message for every single block that exists lol) "m.Count" exists. object array exists. Where's the problem with having a single Block class with x,y,layer,block id and an object array for the arguments which are then simply put into a simple "b" message? Just like sending "b" just puts the arguments after the block ID. Well, even if they won't put everything into "b", at least fix that issue where different special block messages literally have the player ID at different indexes. A switch case: case: could be done, but... seriously? Example: pt (portal) has all the data THEN the player ID, at index 6. Regular "b" has it at index 4, once again the final index. Not only that, most (if not all) other messages have the player ID at index 0. I'll take a nice m.GetInt(0) over some m.GetInt(m.Count - 1) any day.
Anyways, about ints and uints, I think either one works. I have an overall better model, though, which would add those 4 integers to a byte array with 6 bytes:

xxxxxxxx
xxxxxxxx
yyyyyyyy
yyyyyyyy
liiiiiii
iiiiiiii

x = block x pos
y = block y pos
l = layer, duh
i = block id

tl;dr new block messages
send: "b", {0, 42, 0, 69, 0, 9}, <insert args here>
receive: "b", 3, {0, 42, 0, 69, 0, 9}, <no args here cuz gray basic>

Perhaps bgs could be moved to the 32768-65535 range? I'm not exactly sure how it would exactly be ported over, but if it's magically done with every level and bot updated, it's WAY simpler to just check a single bit than have a lookup table. And no, this won't allow fake foreground blocks or solid backgrounds (could be server checked), although I don't exactly see the issue with doing that; IMO it would make for some fun concepts. (And if the bgs DO end up being moved to 32768+, packs should also be moved to a consistent range; kinda annoyed by some basic blocks being single/double digits while others are 1k+. Perhaps lower 5 bits in block IDs could be ID of the block in the pack (e.g. different colors), bits 6-13 (starting from 1, right to left) are for the block packs (e.g. basic or brick), 14-15 for function, and 16th is that BG thing I talked about earlier. Would prevent stuff like that happening again. Maybe different colors of blocks should be morphs, though; also morphs would be able to be selected before you place them, but I guess I'm going a little far, so I'll stop now.)