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.
Does it matter if it is an action tool, an empty space, a block, a decorative or a background?
Can someone explain a little how the type of object affect the data weight please?
Do items with rotations or additional options such as the double jump amount of jumps or portal ID or the number of texts added to an NPC or a sign affects the weight of that object?
Does it matter if it is a normal block or an empty space?
Byte amount depending of object type: (?)
- Block impact: ?
- Action tool impact: ?
- Decorative impact: ?
- Background impact: ?
- Empty space impact: ?
- Signs placed impact: ?
- NPC placed impact: ?
- (Blue/Gray) Portal placed impact: ?
- Switches/Gates placed impact: ?
Etc
UPDATE:
I made a similar question previously, here is more information if someone need it: https://forums.everybodyedits.com/viewt … p?id=44523
4 bytes each for X and Y pos, 2 bytes for block ID. Additional parameters for special blocks require more bytes.
Signs with a lot of text take up the most I think.
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
Additional parameters for special blocks require more bytes.
1.1. Does the complexity of portal connections inside the map also has an impact on the data size (For example 100 portals that bring to the same 1 portal -VS- 50 portals that bring respectively individaully to other 50 portals all with different IDs destinations)
1.2. Also I wonder if the amount of different IDs for switches has an impact too (For example: 100 switches and 1 gates with the same number -VS- 50 switches and 50 gates all with different numbers respectively)
3. Also does it matter if it is ID 1 or ID 9999? does it has a bigger data size impact for the alrger ID number used?
How much additional data space is needed exactly for that special blocks?
I am still kinda confused
So far this is what I understand:
4 bytes each for X and Y pos, 2 bytes for block ID
So block ID (gray basic block for example): +2 bytes ID & +4 bytes location
And every additional of the same block ID in different location gives +4 bytes
Uh, I realised we're talking about DB storage size, rather than the size of the mapdata sent to a bot when it joins a room.
In which case, no idea but there should be posts about it. The way PlayerIO's DB stores info is supposedly pretty inefficient. Atilla/Capasha/Luke might know more.
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
I'm fairly certain they're comparable formats.
A simple way to figure out how efficient the algorithm is would be to work backwards. The "byte arrays" work only to efficiently list the different positions occupied. So, that made pretty good sense back when you just had gray block ID 9. Then your object just has to hold on to info like 'id? 9. And now here are the arrays of x/y coords. of every block matching that description."
But with portals, we generalized that. Now we have "id? 242. Rotation? Target? Portal ID? And now here are the arrays of x/y coords."
So, that's issue number one. Each categorization of special block that has anything different will take up more space. That is, if you have one coin gate that requires 10 coins, it takes up space. But if you add one more, you're just adding the four(?) bytes to specify where it is. But if you actually wanted to add an 11 coin gate, you'd need to create an entire new object under this system.
I'm fairly certain that your IDs and such will still just be integers anyway. It seems absurd to try and micro-manage the smaller IDs to, say, a 0-256 range when there's such essential inefficiency here.
tl;dr: if your block is unlike any other block in the world, you're making the biggest increase to world data size. If its identical copy already exists, then you're adding just a few bytes.
disclaimer: I haven't looked at this closely for arguably 3-6 years. Weird to think about that. But it might have changed since my days.
Offline
Do a sign affects the weight of that object?
Of course , it does that .The sign is sitting on block , the weight is being affected by gravity(without) or even behind or under ... The weight of the block is nearly unknown by the majority users from EE . I will take a hypothesis .
Example : If you think as physics in the real life , the thing itself , it will become more heavier than without wooden sign ... The easiest object from EE might be one-way blocks or candy pack . Meanwhile the heaviest must be the building packs or industrial packs. That's my opinion , you can think further .
Offline
The bigger the entropy of your data the more it will weight.
Also, EE Maps are sparse matrixes, empty spaces are implied and therefore you don't get any mentions of block-id 0 over the wire.
Everybody edits, but some edit more than others
Offline
basically it is stored like this:
- Block impact: ?
[0]: {
type: 9
layer: 0
x: 1 23 235 2 254 21 2,
y: 5 21 21 34 212 32 33
},
[1]: {
type: 10
layer: 0
x: 5 4 3 2 1,
y: 6 7 8 9 0
}
which means there are 7 blocks with id 9 and they are at 1x5, 23x21, 235x21 etc
same with id 10: 5x6, 4x7 etc
that means if you already have a block in the world, adding new one with the same id just adds 2 values. (it's a bit more complicated because there are chunks involved, but you get the idea)
- Action tool impact: ?
if you are talking about blocks like arrows - they don't need any special data, they are just blocks, if not, i'll tell about other blocks later
- Decorative impact: ?
similar to blocks but there is also one attribute
[0]: {
//other stuff,
rotation: 0
}
basically applies to all blocks that have a way to rotate or change
- Background impact: ?
backgrounds don't hold any data, they are regular blocks just with layer: 1
- Empty space impact: ?
empty space isn't stored.
- Signs placed impact: ?
signs:
[0]: {
type: 385,
layer: 0,
x: same as blocks,
y: same,
text: "hello",
signtype: 0
}
labels:
[0]: {
type: 1000,
layer: 0,
x: same as blocks,
y: same,
text: "hello",
text_color: "#000000",
wrapLength: 123 // after how many characters text should warp on a new line
}
- NPC placed impact: ?
[0]: {
//other stuff,
Name: "goshanoob",
Message1: "hello",
Message2: "this is ",
Message3: "my world"
}
- (Blue/Gray) Portal placed impact: ?
similar to blocks but with more attributes
[0]: {
//other stuff,
rotation: 0,
id: 123,
target: 321
}
- Switches/Gates placed impact: ?
death gates, coin doors, purple doors, team doors and other stuff that requires 1 "thing" just has
[0]: {
goal: 123
}
for example you need 123 coins.
- World portal placed impact: ?
[0]: {
TargetWorld: "PW01"
}
- Music blocks placed impact: ?
[0]: {
Id: 123
}
_____
as you can see, it is pretty intuitive. When you add data to the UI of the block, it needs more space
from this you can see npcs take more data than signs because there are 4 strings involved.
Offline
Thanks for the answers guys, Gosha answer seems to contain a lot of details about what I needed
_
What I understand is that strings are those:
signs:
[0]: { (String?)
type: 385, (String?)
layer: 0, (String?)
x: same as blocks, (String?)
y: same, (String?)
text: "hello", (String?)
signtype: 0 (String?)
}
Total strings: 7?
_
But I don´t know how to traduce it to bytes, and I can´t give an educated guess of it (I don´t know anything about programming)
How much weight in bytes is a "string"?
Do all strings weight the same?
//other stuff has the same weight than a string? (Or it means that it can have one or more strings depending on the item?)
The amount of numbers and letters seems to affect the size of the string itself as far as I can understand.
_
P.S: There should be a topic specificly to clarify how do objects affect the data size, it would be much easier to understand this if there is all information in a single place, agreed
Just to clarify, there are massive differences between the different data formats:
When in the database what Gosha said is basically correct, it's just worth adding that it's stored in a way that is almost as bad as just storing the whole things as an uncompressed string (including the keys and values and everything), so often the key "rotation" will take up more space than the data itself, so even for small values like integers a lot of space is taken up.
In memory when playing the game (either server or client side), each physical block in the world stores its own data, and duplicates are stored multiple times, so you can mostly just add up the binary data taken by each of the fields.
When transferred between the server and the client, it is serialised to an "init message" format, which is a fairly efficient (though still not great). It's effectively a combination of the best parts of the previous two formats, it only stores duplicates once, along with a list of their positions, and everything is serialised as binary, so it's relatively compact. The only significant differences are that a small amount of data is taken as overhead for storing the types of the data, and there is some special compression for the top left 256x256 blocks in the world where each position is stored in a single byte rather than two.
.eelvl files go slightly beyond this by taking the init message and stripping out some unnecessary details like the types of the data and obsolete/multiplayer only data, then compressing it (using deflate). Because of how deflate works this does end up giving you a load of weird properties like less complex portal layouts taking up less data, and english text in signs taking up less space than the same number of completely random characters.
Edit in reply to Mini's last post:
It gets a bit complicated, but for a very rough estimate you can just write it out as Gosha did removing any whitespace then count the number of characters to find a rough number of bytes. In reality I believe it's slightly more complicated, I think a couple things like integers are actually stored as binary, but those differences end up making a pretty small impact compared to the string keys and everything.
Offline
I am concluding from this that EE storage of data is just too messed up to even give a simple estimate lol
I guess the best is to just wait to see if EEO will allow me to present The Grand Grimoire as it seems that EE won´t handle all the data (in a 600x300 world), the size is what I need and I am happy with it, it is simply that EE won´t handle my envisioning for the level
Thanks everyone for your answers
I am concluding from this that EE storage of data is just too messed up to even give a simple estimate lol
I gave a simplified, with it you can roughly compare relative size difference of various block types
But the actual data is stored on PlayerIO servers. If we can't get access to raw bytes stored on the server then we can't really guess how playerio stores objects (does it compress them or not, etc)
_
What I understand is that strings are those:
signs:
[0]: { (String?)
type: 385, (String?)
layer: 0, (String?)
x: same as blocks, (String?)
y: same, (String?)
text: "hello", (String?)
signtype: 0 (String?)
}Total strings: 7?
_
no. strings are sequences of characters. In my example "string" is marked by quotations.
type: is integer
layer: is integer
x: is bytearray (like i said, the actual data is a bit more complicated)
y: is bytearray
text: is a string
signtype: is int
i didn't look into it too much so i can't tell you for sure, but basically the more characters there are in a string, the bigger you need storage for that. It all depends on how playerio stores strings and in what format, and like i said, we don't really know unless we have a way to look at raw bytes on the server
but if you want at least some info i can give you this
https://stackoverflow.com/a/3967458/7421475
edit:
I guess the best is to just wait to see if EEO will allow me to present The Grand Grimoire as it seems that EE won´t handle all the data (in a 600x300 world)
oh yeah, eeo doesn't have size limit, all those limitations are playerio's limitations on how big a database object should be
Offline
yes an empty space sucks up no data i believe (i belive bought worlds wihtout chnaging anythign in it (so not saving it not chnagign name of it ect eatts aalmost not data except its existance) ) obviously action blocks require more data espescialy switches signs an dportals (and npcs mainly bc why else are they limited) you reach teh data limit quickly in huge/great worlds wiht many signs/portals/switches also i thjhink morphable items have a bit more dat aaswell as it need to sotre morph id
thanks hg for making this much better and ty for my avatar aswell
Offline
[ Started around 1732191634.3634 - Generated in 0.197 seconds, 12 queries executed - Memory usage: 1.59 MiB (Peak: 1.79 MiB) ]