This is getting ridiculous. Many maps have this problem. Are there some maps that don't?
There are some rumors as to the cause:
In SC2 beta, the release of a specific patch caused a widespread drop bug. The concluded solution was to add a loading screen press any key. It supposedly only affected maps started prior to this patch. My map, Vexal Tower Defense, experiences this bug, and was started prior to this patch. However, adding the press any key did not change anything. So perhaps these issues are unrelated.
If this problem affects your map, post in this thread information you feel important and specific to your map. When was the map started? Do you use banks? (maybe bank loading causes problems?) What runs at initialization?
Likewise, if you see a post with information pertaining to a map that drops players, and your own map uses similar functions or properties, but does NOT drop players, post here as well in order to cross out possible causes.
I think it is banks, I drop every time I try to play something like zerg hunter rpg or eternal shadows rpg, which I know both maps use banks much more extensively than other maps (since they are rpgs).
No idea why it would be causing it, but thats just what I'm thinking.
It'd likely be better if this thread was reserved for posts by authors of maps. It won't help much to make blind assumptions about other peoples' work.
EDIT: What would be really nice is a post from an author using banks and not experiencing disconnects.
Please post information such as: Whether you do anything at map initialization
Whether you use banks
And, most importantly, when your map was started. It could have to do with something the editor does and not the map creator.
Yes it does all of those things. It has map initialization actions, it was started as soon as the map editor was released in beta (in April, I think), and it uses banks.
However, all that's needed is to find a single person whose map uses any of these things with no disconnects to rule them out.
When the map was originally created (the actual file) is probably very important.
When the map was originally created (the actual file) is probably very important.
What do you base that assumption on? I can't imagine how it would make a difference.
All my maps are from April last year and I've never experienced these problems. I'm not using banks though. A ton of things happen on initialization.
I've only played one map where I recognize this phenomenon. That'd be Nexus Wars. :P Happened all the time back when I was playing it. As far a I know, that map didn't use banks.
I already said why I said it could be important. It could be the case that the editor generates something behind the scenes when the file is originally created. It could be broken in older versions of sc2.
There were reports at a certain patch in the sc2 beta that redoing everything in a map from scratch in a new file fixed the problem.
Banks can only work if they are opened during the loading screen.
I think it's banks because they were the cause of loading screen freezing (an old bug that Blizzard fixed). Now, when the bank isn't load, the loading screen doesn't freeze anymore, but sometimes it drops the players. Also, I've received reports of people saying that all the players were dropped, and the few that weren't dropped did not have their scores (banks didn't load).
Banks can only work if they are opened during the loading screen.
I think it's banks because they were the cause of loading screen freezing (an old bug that Blizzard fixed). Now, when the bank isn't load, the loading screen doesn't freeze anymore, but sometimes it drops the players. Also, I've received reports of people saying that all the players were dropped, and the few that weren't dropped did not have their scores (banks didn't load).
This is false. i have my banks set up to preload, and syncronize, then open. after 3 game seconds have elapsed. and it works perfectly
Banks can only work if they are opened during the loading screen.
I think it's banks because they were the cause of loading screen
freezing (an old bug that Blizzard fixed). Now, when the bank isn't
load, the loading screen doesn't freeze anymore, but sometimes it drops
the players. Also, I've received reports of people saying that all the
players were dropped, and the few that weren't dropped did not have
their scores (banks didn't load).
Rodrigo ... your very wrong here.
My point is .... Remove all chances of your code dissconnecting players prior to the game starting.... that is during the initialization process.
I have a fully working Top100 ranking system in place which requires 700ms (which really is a lot of CPU time) to decode and process completely on my PC, in case you are worried about the impact on the server, and I've been pushing bank limitations since May. As you can see from this (just a bank with dummy records I use for local tests, actual online banks hold additional informations) I preload pretty big savefiles for up to 9 players in the lobby.
My findings:
- Loading big compressed strings is MUCH faster than preloading a lot of integers one by one. Also, when the map takes too much to load someone WILL crash... so don't preload every single sound you use in game, just the ones that will be used in the first minutes to avoid that awful starting client lag.
- My encryption algorhytm (md5sum-like parity check, actually) was too complex before I optimized it, and occasionally made everyone crash after 1 second for the very same reason.
- I can safely load the first bank in the Map Initialization thread, as long as it doesn't load immediately. If I don't set a delay, someone occasionally gets the "Desynced!" server message along with a corrupted bank.
- Same happens if I try to load and process all 9 banks at once, that's a guaranteed desync, I need something like a 1 second delay inbetween banks.
- Only the first 7xx characters of each string are loaded, that's why I needed to split Rankings data in 11 different chunks. Loading partial strings doesn't cause crashes though afaik.
- Patch 1.2 removed size limitations, I could barely have a Top40 before that.
- I tried Blizzard signatures when they were implemented and scrapped them quickly. When a genuine check fails, chances are the player itself will get dropped for some reason.
However, all that's needed is to find a single person whose map uses any
of these things with no disconnects to rule them out.
This isn't very scientific, and doesn't actually prove anything. "Absence of evidence does not imply evidence of absense." This type of analysis lacks a control group, i.e. something to compare results against. You're basically saying "this apple is broken, but this orange is fine, therefore..." Therefore nothing.
What's a great deal more scientific is to do what Soul is saying. Make changes to what you have now and compare the results. You map as is becomes the control group, and it's easy to compare the results of an experiment against it. If you try something, and it doesn't fix the problem, then you know without a doubt that it was not the cause of the problem and you can rule it out. If it you try something and the problem actually goes away, it doesn't actually prove that the problem is gone. It's easy however to determine that the problem is less dramatic at the very least. It's important to have something to compare it to, make small changes, and compare again. This is how debugging works.
You should listen to Soul. I'm fairly certain he knows what he's talking about.
When the map was originally created (the actual file) is probably very
important.
This is an assumption. When you are debugging, it is important to question all assumptions. Is this true? Can you actually evaluate it? I'm not saying it is or isn't true, but you can't just state that it's important without actually determining that it is first. Otherwise it becomes a red herring. You'll send yourself down the wrong road looking for answers, and you won't find them until you step back and question the assumptions that you've made.
Remember, debugging is not about finding the answers, it is about searching for the answers. You can't find the answers if you don't search for them. There is a science to searching.
This is false. i have my banks set up to preload, and syncronize, then open. after 3 game seconds have elapsed. and it works perfectly
My banks also are syncronized after 3 game seconds, and I am 100% sure they are opened during the loading screen (since the loading screen was freezing based on the amount of information I had in the bank).
My banks also are syncronized after 3 game seconds, and I am 100% sure they are opened during the loading screen (since the loading screen was freezing based on the amount of information I had in the bank).
So do you know any way to prevent that? all i was saying in my last post was that banks will still load properly even if not used at map initialization.
My banks dont hold that complex of variables, and there's only 4-5 bank entries per player and my games been dropping random people with as small of a group as 4. i know runling run uses banks, and i never see this problem there
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
This is getting ridiculous. Many maps have this problem. Are there some maps that don't?
There are some rumors as to the cause:
In SC2 beta, the release of a specific patch caused a widespread drop bug. The concluded solution was to add a loading screen press any key. It supposedly only affected maps started prior to this patch. My map, Vexal Tower Defense, experiences this bug, and was started prior to this patch. However, adding the press any key did not change anything. So perhaps these issues are unrelated.
If this problem affects your map, post in this thread information you feel important and specific to your map. When was the map started? Do you use banks? (maybe bank loading causes problems?) What runs at initialization?
Likewise, if you see a post with information pertaining to a map that drops players, and your own map uses similar functions or properties, but does NOT drop players, post here as well in order to cross out possible causes.
Maybe we can fix this.
I think it is banks, I drop every time I try to play something like zerg hunter rpg or eternal shadows rpg, which I know both maps use banks much more extensively than other maps (since they are rpgs).
No idea why it would be causing it, but thats just what I'm thinking.
I also think it is banks. It happens in my maps too.
Okay. This isn't exactly good evidence.
It'd likely be better if this thread was reserved for posts by authors of maps. It won't help much to make blind assumptions about other peoples' work.
EDIT: What would be really nice is a post from an author using banks and not experiencing disconnects.
How about this guys....
Stop doing shit at map initialization.....
Do shit like handle banks after all the players have been in game for a couple seconds at least
@SouLCarveRR: Go
Again, not a very useful post.
Please post information such as: Whether you do anything at map initialization Whether you use banks And, most importantly, when your map was started. It could have to do with something the editor does and not the map creator.
EDIT: Rodrigo, when were your maps first created?
Well...
Vexal ... does your map do anything at map initialization?
Such as interact with the banks....
people saying "oh its the banks" that tells me even less.
@SouLCarveRR: Go
Yes it does all of those things. It has map initialization actions, it was started as soon as the map editor was released in beta (in April, I think), and it uses banks.
However, all that's needed is to find a single person whose map uses any of these things with no disconnects to rule them out.
When the map was originally created (the actual file) is probably very important.
What do you base that assumption on? I can't imagine how it would make a difference.
All my maps are from April last year and I've never experienced these problems. I'm not using banks though. A ton of things happen on initialization.
I've only played one map where I recognize this phenomenon. That'd be Nexus Wars. :P Happened all the time back when I was playing it. As far a I know, that map didn't use banks.
@Qancakes: Go
I already said why I said it could be important. It could be the case that the editor generates something behind the scenes when the file is originally created. It could be broken in older versions of sc2.
There were reports at a certain patch in the sc2 beta that redoing everything in a map from scratch in a new file fixed the problem.
My only crashing map is killed by preloading.
Yay for 9 megs of sound!
Banks can only work if they are opened during the loading screen.
I think it's banks because they were the cause of loading screen freezing (an old bug that Blizzard fixed). Now, when the bank isn't load, the loading screen doesn't freeze anymore, but sometimes it drops the players. Also, I've received reports of people saying that all the players were dropped, and the few that weren't dropped did not have their scores (banks didn't load).
This is false. i have my banks set up to preload, and syncronize, then open. after 3 game seconds have elapsed. and it works perfectly
@MangledMind: Go
Have you tested this on Bnet?
Rodrigo ... your very wrong here.
My point is .... Remove all chances of your code dissconnecting players prior to the game starting.... that is during the initialization process.
Eh its what Id do first if I had such a problem.
I have a fully working Top100 ranking system in place which requires 700ms (which really is a lot of CPU time) to decode and process completely on my PC, in case you are worried about the impact on the server, and I've been pushing bank limitations since May. As you can see from this (just a bank with dummy records I use for local tests, actual online banks hold additional informations) I preload pretty big savefiles for up to 9 players in the lobby.
http://paste.sc2mapster.com/3421/
(file size usually around 9-10k)
Haven't crashed once since patch 1.3
My findings:
- Loading big compressed strings is MUCH faster than preloading a lot of integers one by one. Also, when the map takes too much to load someone WILL crash... so don't preload every single sound you use in game, just the ones that will be used in the first minutes to avoid that awful starting client lag.
- My encryption algorhytm (md5sum-like parity check, actually) was too complex before I optimized it, and occasionally made everyone crash after 1 second for the very same reason.
- I can safely load the first bank in the Map Initialization thread, as long as it doesn't load immediately. If I don't set a delay, someone occasionally gets the "Desynced!" server message along with a corrupted bank.
- Same happens if I try to load and process all 9 banks at once, that's a guaranteed desync, I need something like a 1 second delay inbetween banks.
- Only the first 7xx characters of each string are loaded, that's why I needed to split Rankings data in 11 different chunks. Loading partial strings doesn't cause crashes though afaik.
- Patch 1.2 removed size limitations, I could barely have a Top40 before that.
- I tried Blizzard signatures when they were implemented and scrapped them quickly. When a genuine check fails, chances are the player itself will get dropped for some reason.
This isn't very scientific, and doesn't actually prove anything. "Absence of evidence does not imply evidence of absense." This type of analysis lacks a control group, i.e. something to compare results against. You're basically saying "this apple is broken, but this orange is fine, therefore..." Therefore nothing.
What's a great deal more scientific is to do what Soul is saying. Make changes to what you have now and compare the results. You map as is becomes the control group, and it's easy to compare the results of an experiment against it. If you try something, and it doesn't fix the problem, then you know without a doubt that it was not the cause of the problem and you can rule it out. If it you try something and the problem actually goes away, it doesn't actually prove that the problem is gone. It's easy however to determine that the problem is less dramatic at the very least. It's important to have something to compare it to, make small changes, and compare again. This is how debugging works.
You should listen to Soul. I'm fairly certain he knows what he's talking about.
This is an assumption. When you are debugging, it is important to question all assumptions. Is this true? Can you actually evaluate it? I'm not saying it is or isn't true, but you can't just state that it's important without actually determining that it is first. Otherwise it becomes a red herring. You'll send yourself down the wrong road looking for answers, and you won't find them until you step back and question the assumptions that you've made.
Remember, debugging is not about finding the answers, it is about searching for the answers. You can't find the answers if you don't search for them. There is a science to searching.
Yes, i have tested this on B.net. my banks are loaded perfectly fight. what i dont know yet, is if it fixed the drop problem
My banks also are syncronized after 3 game seconds, and I am 100% sure they are opened during the loading screen (since the loading screen was freezing based on the amount of information I had in the bank).
So do you know any way to prevent that? all i was saying in my last post was that banks will still load properly even if not used at map initialization. My banks dont hold that complex of variables, and there's only 4-5 bank entries per player and my games been dropping random people with as small of a group as 4. i know runling run uses banks, and i never see this problem there