Hey there, forgers. Do you know the situation in H2A when you made a great map, but it would always crash when being played with a larger lobby? Well, I think I have found the reason for that. No good news. You may have noticed that every map you make has got a certain byte size. Well, if that byte size is over a certain point the map won't load with a certain amount of people. Let me explain (The following part is contained of details - if you want to see the important message, skip the spoilers) : Spoiler For five days now I have been delving into the byte sizes of our forge canvases, and I found out that the minimum size for a map is 793 bytes [No objects on the map/Map name: One digit/Description: One digit]. All three canvases Nebula, Skyward and Awash have no differences in the matter of byte size. For every additional digit (spaces,too!) in the map name/description you have to add in 1-2 bytes. This is the list of the byte size of every single forge object there is (bottom-up): Spoiler Structures: 23 bytes Naturals: 23 bytes Scenery: 23 bytes Objectives: All objectives 30 bytes - except for Infection Shields (23 bytes) Spawning: Initial/Respawn Points 23 bytes, Initial Camera 30 bytes, Respawn Zones 30 bytes, Safe/Kill Zones 29 bytes Scripting: Timers/Switches 24 bytes, All triggers 30 bytes - except for Trigger On-Destroyed (26 bytes) Gadgets: Explosives 24 bytes, Man Cannons/Gravity Volumes 23 bytes, Trait Zones 32 bytes, Teleporters 33 bytes, Base Shields/Special FXs/Toys 27 bytes, Lights 28 bytes Map Gadgets: Switch/EMP Switch/ Garage Door/G D Switch 28 bytes, Glass Window/Ice Stalactite/Power Core/Barrier 27 bytes, Console Switch 24 bytes Powerups: 27 bytes Vehicles: 27 bytes Weapons: 27 bytes Test: Map [Map name: TEST , Description: TEST] with 1x Grid, 1x Teleporter, 1x Console Switch, 1x Switch Toggle, 1x Garage Door (All three connected) on it. In game: 933 bytes - - - My list: 931 bytes Keep in mind that I took 1 byte for each digit of both ESTs. You can do that with every map you made (Divergences of 5 bytes are normal, because no byte size from the list above and each digit is exact). Another thing I found out with that is that connected Scripting doesn't add anything in. Also we can conclude that byte sizes of objects have nothing to do with object size/shape/details. So now that everyone knows the basics, let's move on to the important thing I want to tell you: The next part includes examples and speculations, but important ones. So at the beginning of MCC I made a map that was full of large cliffs, but only had like 200 objects. We didn't know why, but it worked with a 14 player lobby. It was laggy, but it worked (as I said before, byte sizes have nothing to do with framerate issues, that would be another topic about rendering objects). That map has got about ~6000 bytes. Five days ago I checked out all of the maps' byte sizes and they all made sense to me in the matter of lobby experiences and overall performances. I came to the solution that a map has to be under a certain byte size in order to work with a bigger lobby. In the following I want to share my speculations to the byte sizes and how they affect a custom game. If you want to make a map that can support 14-16 players and has got multiple rounds the byte size has to be under 5000-6000. A map that supports 10-12 players and has got multiple rounds should have a byte size of under 7000-8000. One that plays with exactly 8 players should have under 8000-10000 bytes (multiple rounds) or under 9000-11000 bytes (one round). One/Two player/s can play a map with any byte size together without having any issues. With three players it already could be crucial if they play a map with over 13000 bytes. Spoiler Map with an average of 28 bytes object size and 200 objects: 5600 bytes Map with an average of 28 bytes object size and 400 objects: 11200 bytes Map with an average of 28 bytes object size and 600 objects: 16800 bytes Keep in mind that all these results are not official. You understand that it is pretty difficult to decree standards due to connection failures, no dedicated servers in custom games and other bugs in the MCC. So I'll leave you with these speculations that are vague, but may not be all that wrong; and they should be taken seriously. Thanks for reading this. Please tell your friends about this thread and fill in your own experiences. I suppose this is pretty important for every single forger since I don't think that will fix that issue in the near future. But as you will know the Halo Forge Community is indestructible. We'll just deal with it. Bud. EDIT: Some people down below have much more knowledge than I have about such things, so go ahead and read their opinions about this topic as I think that theirs are more correct than mine.
Another thing I want to add is: When you check out the byte size of an uploaded map or a map in the temporary files it will always be around 33000 bytes big. That's not the actual map size! When a map is being uploaded or is in the temporary files it gets converted into a kind of 'package', so other people can download it and save it aswell. Think of it like a ZIP folder, just that the size doesn't get compressed.
Thanks for researching this, Buddy. While its unfortunate that we have to deal with these issues, its good to know how to potentially work around this. I personally don't believe 343 will ever fix this unless they're pushed hard enough to since they're still preoccupied with fixing matchmaking.
I think you're close, but not quite there. From my own observations, I noticed that it's only Spawned-In objects that affect the ability for multiple players to load the map. I tested this by creating a map using the full object count, but then used Scripting to only spawn in those objects in increments. I noticed that the map would always initially load, but everyone would get kicked out after spawning in certain increments of those objects. Now this could be connected to your theory of byte size on objects. It could be that for every spawned object, it takes up a certain number of bytes in memory (and certain objects will use up more bytes than others), and if you have too many of these spawned objects, taking up too much memory, then it breaks the map (memory overflow most likely). Having more players would also use up more memory, so that's why some maps would work with lower player counts, but then break with more players. I also believe it's actually only visible objects that are attributing to this issue. So what I suspect is that there is a certain allocation of visual/rendering memory available, and anything that is a visual thing will add to this memory allocation. I believe it is probably this memory that is overflowing - when there are too many visual objects spawned onto the map. So, in my opinion, it's an issue of too many spawned-in visible objects taking up too much visual/rendering memory that breaks maps - made worse with more players on the map, also taking up more visual/rendering memory. But this is just an educated guess of course!
How much byte size did that map have, Buddah? I'm curious. Yup, you're most likely right! Everything sounds obvious.
Wow, how did I not see this post before. I was just going over file sizes of maps the otherday and postulating that the problems must be connected to this. Thanks man!
I think one element that can be easily overlooked when measuring byte size comes from your example of how more characters of the title add more bytes to the overall size to the saved map. When you place an object the coordinates x,y,z location in the 3d world is recorded. When you rotate an object the pitch, yaw and roll are recorded. I believe if you don't edit by coordinates and don't snap to angle it can cause the map size to be greater primarily because if you use the rotation snap or edit by coordinates the numbers are rounded to the nearest tenths place (e.g. 1.4, 1.8, 2.5 versus placing them organically and recording the values 1.438, 1.812, 2.525) With your example there would be a considerable amount more information transmitted between clients when downloading the map data including each individual object requiring slightly more loading time but also significantly increasing the chances that some of the packets are lost resulting in a desync. Which could be exactly why players drop.
Great, I haven't thought about that! For your last point, yes, it highly likely is a problem of the connection and the servers. That has never happened before in a Halo game.
Erm, did you guys forget my post? It's not to do with overall byte size of maps, it's to do with the actual number of spawned in visible objects being rendered at any given one time - it's just that the more visible rendered objects your maps have, the more likely it is that you have a map that has a larger byte size. More players means more visible objects to render (i.e. the players themselves, their weapons), plus additional network data that wouldn't apply when you're testing the map on your own. The only correlation I see between the byte sizes, is that individual objects have a certain byte size, and thus rendering that object will most likely use more Rendering Memory, and it's that Rendering Memory that's hitting its limit when your maps fail to load. I've already proven to you guys that you can completely fill up your map's object count and still get it to load, so long as you don't have every item spawned into the map at once. Now, is that particularly useful? Probably not, but it shows that the actual problem is to do with the number of concurrent spawned-in visible objects, and NOT the file size of your map. As an example of something that might actually be useful to you. You can probably have as many scripting objects, or invisible objects on your map as you like. The only thing you need to worry about, in making your map load for multiple players, is how many visible objects you add to your map - this is the limit you need to worry about. I might do run a quick test on this tonight to prove that is the case, but I'm pretty sure it is. Please don't propagate misinformation. Edit: And I've created a test map to prove it. Uses full 650 object count, file byte size is huge (18,000) and it loads fine with multiple players. Know why? Because none of the objects are visible ones, they're invisible explosive volumes, Scripting objects, Spawn points, etc - all things that you can't see in-game. That same map loaded in Forge kicks everyone out, because in Forge you can see all those objects. So yeah, to clarify, it's nothing to do with Map file sizes, and it's not even strictly to do with pure object count; it's to do with the number of concurrent visible objects on your map at any given one time. *Drops the mic*
Makes sense. Byte size is still relevant though as it can serve as an indicator of how many pieces were used on the map. Take for instance a map that's bigger than 15,000 bytes or whatever, it most likely has over 500 pieces used. Hell, it's probably over 550.
Yes, you can generally infer a rough correlation between byte sizes, pieces used, and whether your map will load. But I just want people to be aware that it's not strictly caused by total object count or byte size - but more specifically, a limit in how many concurrent spawned-in visible objects you can have. Made up example: You're map's file size is 10,000 bytes and has a 400 object count, and it isn't loading for 8 people. So you think "I know, I'll delete some spawn points, scripting logic, respawn zones, objectives, etc, to lower the file's byte size and object count". What you will then find is that you've actually done absolutely nothing to fix the issue, because although you have lowered the file's byte size and object count, you've not actually removed any visibly rendered objects from your map. Furthermore, you may have a map that initially seems fine, but then you have some dynamic element on the map, where players can hit a switch or whatever, to spawn in a bunch more objects, and then suddenly your map stops working and you're wondering why. Well, my explanation of a concurrently spawned-in visible object limit is why. Life lesson: It's important to know the exact reasons as to why something is happening, so that you can figure out the exact way to deal with that thing happening. Otherwise you'll potentially be reacting to something in the wrong way, based off of false assumptions and overgeneralisations. #TheMoreYouKnow
I fail to see how GPU rendering is the verdict of how players are going out of sync and disconnecting. Even when you split screen the framerate goes way down yet still there's no direct relation to sync problems. We're most likely missing some factor here and I truly don't believe finding this factor is going to bear any fruit primarily because there will still be nothing we can do about it. Back to the principal though we may not be able to use the amount of bytes alone that a map size is to determine the problems associated with disconnects and crashes but we may be able to use it to gain some insight into how forge saves data. It is not possible for any of us to genuinely know how the engine works because none of us have seen the game from a developers standpoint. We all base our beliefs and opinions on how we observe that they work based on observation and testing alone. That does not mean we are sharing misinformation but it means we are collaborating to best determine how we can maximize our efforts. There are principals at work here that we can use to narrow down our search but because we're not developers and we can't possibly validate our observations that is at the core of how fruitless our endeavors are. I will say that I think the logical approach to these concepts is what will shed light on the mechanics at play that cause the crashes and disconnects but I still do not believe solving them to be as beneficial to us as the time we are investing into solving them... To more effectively solve the problem we should try to analyze the individual maps that tend to cause disconnects, crashes, and desyncs.
maybe because the problem isn't people going out of sync? this is purely a connection issue nothing more. with the maps they are transmitted before the game starts and if it was just an issue of packet loss then people would probably just end up on broken versions of maps instead of being booted. the issue is running out of RAM to use. if there isn't enough RAM to safely load everything on the map and all the players then it's going to end the game. maps that also seem stable early on can crash later on from a build up of dead bodies taking up more RAM. i also firmly believe that the complexity of objects also has an impact because i've seen some maps with less objects used be consistently unstable when compared to maps with more objects with the main difference being the type of objects used. all file sizes does is tell you the amount of objects on the map. it doesn't in any way show you how stable the map is going to be as @buddhacrane has pointed out. yes we may not know exactly how the game works. but those of us with programming experience can decently hypothesise what is going on. those without are more likely to be drawing the wrong conclusions.
I used to mod halo 1 to the point that i made custom maps. I would put the custom maps on multiple modded xbox and we'd play on LAN on them although its success wasn't consistent so there was a slight chance the consoles would go out of sync and we'd disconnect. We'd try again a moment later in the exact same conditions and it would work fine. The same problem happens with these maps that's why I see it as a sync problem. A loss in packets would explain that. Even if you bring up cmd prompt and type "ping 8.8.8.8 -n 10000" you will occasionally see a dropped ping.. the same happens with every internet connection ever. Only an integrated QOS can sufficiently guarantee connection packets aren't lost.
and you know that problem you had on h1 was a d-sync and not a resource issue how exactly? at the moment this just sounds like your assumption based on a specific symptom but the cause could be something different. it being a d-sync issue doesn't really add up. the symptons we're having is map with a high visible object count not being stable. the game crashing back to menu even for the host (not lost connection game over),what appears to be random instability when more items of any kind appear and groups of people getting booted in large lobbies randomly. usually when its an of sync issue the game goes to black screen to try and re-sync everyone, those who fail get booted from the game but this isn't what happens, instead the game just throws you back to the menu with no warning which suggests something else is the cause. what i think is happening: - when the game starts a copy of the map is downloaded from the host to each client. any missed packets during the download are resent until they are received as per a typical download. after so many attempts and it still fails then the person is booted from loosing connection. - once the map has been downloaded and the game started each client loads the map from the file they downloaded, this file is also stored in your temporary history. - with each object attempted to be loaded it's creating a new copy instead of creating a new reference and applying a transform to it. - after loading the map the players are loaded, if it fails to allocate enough resources it throws an error and immediately ends the game. why it doesn't apply to connection: - because the map is transmitted before the game even begins. - the netcode is asynchronous - what is actually in the maps themselves is just references to the objects, so location, rotation, texture, physics and properties for each object. the objects geometry, collision mesh and texture is stored within the canvas. - each map is stored locally on the client and doesn't need to be constantly transmitted - the only information that is transmitted during the game is when an object moves. if it doesn't move or can't move it isn't transmitted in order to save on bandwith. if it was the bandwith requirements would be massive yet reach and h4 could get by easily and practically the worst connections possible. h2a seems to have connection spike issues but appears to be un related to forge maps since it happens on every map and even on dedis but this was fixed in a patch a while back. i do appreciate you guys trying to figure out what's going on but i honestly think you're barking up the wrong tree.