Crashing on connect to Master Server

[Echo38]

Badger, I repeat, I am unhappy with the situation, too, but Coff's workaround does enable your squad to play together.

 

Really, it should be a sticky. I didn't know about it until a few days ago; I was lucky that someone linked me to Coff's post, which is buried in this thread. Viper? Could you make the workaround a sticky thread? It'd do a lot to help people out and also diffuse a lot of the anger flying around, I think.

Edited September 28, 2012 by Echo38

[BIGNEWY]

the work around does not always work

 

also if you are say 1 hour into a mission and crash out, and then try to rejoin you can not, the server drops from the master server list and then it will not allow you to rejoin via I.P "connection interupted"

 

its killing multiplayer. but we are a resilient bunch of dedicated ED followers and we do our best to keep positive despite this long standing issue

[Nate--IRL--]

Well , not being able to connect has led to my squad basically falling apart ..... and I honestly do mean that sincerly . We havent flown together in over 2 months ..... and now the members have just gone off somewhere else .

 

And the server connection is becoming more often for me , anyway .....

 

Is it ok that a squad , with its own server falls apart , and this is a direct result of faulty goods , and false advertising .

 

I know it is less than Ideal, but why not roll back to an earlier version that works?

 

Nate

[Echo38]

the work around does not always work

 

Clarify?

 

also if you are say 1 hour into a mission and crash out, and then try to rejoin you can not, the server drops from the master server list and then it will not allow you to rejoin via I.P "connection interupted"

 

its killing multiplayer. but we are a resilient bunch of dedicated ED followers and we do our best to keep positive despite this long standing issue

 

Yes, it is indeed a problem that it makes hosting public games impossible at times and problematic at all other times, as you describe. However! If you never attempt to host a public game, but merely host a direct-connect game (mislabelled "LAN") from the beginning, then people who C.T.D. or otherwise disconnect during the mission can rejoin with no problem, regardless of whether or not the server list crash is occurring at that time.

[BIGNEWY]

Clarify?

 

I have and others tried the work around,

 

I.E not login in until you have selected LAN from the top and then login so the fetching of the list does not crash the client. but still getting a crash when you go to fetch the list.

[159th_Viper]

Viper? Could you make the workaround a sticky thread?

 

Updated current MP sticky with relevant posts:

 

http://forums.eagle.ru/showthread.php?p=1561877#post1561877

[Echo38]

I have and others tried the work around,

 

I.E not login in until you have selected LAN from the top and then login so the fetching of the list does not crash the client. but still getting a crash when you go to fetch the list.

 

That isn't the workaround I was talking about; it's only part of the workaround, followed by an action which negates the workaround, thus causing the crash.

 

Here's a step-by-step description of the full workaround, which will enable you to host a private game even during the times at which the master server list crash is occurring; do not select Internet from the Source box at any point during this process:

 

The host must do the following: open Multiplayer, cancel the login, select LAN* from the Source dropdown box, and then login. Do not select Internet from the Source box. Now that you're logged in to the master server, click on NEW SERVER, then select LAN from the Server Type dropdown box. Check the port number, then hit START.

 

All clients must then do the following: open Multiplayer, cancel the login, select LAN from the Source dropdown box, and then login. Do not select Internet from the Source box, as this will cause the crash if the bug is occurring at the time. Now that you're logged in to the master server, click on Connect by IP, then enter the host's external IP address and port in the following format, without the brackets: [address]:[port]. For example, if the host's external IP address is 38.47.127.50, and if he is using the default port of 10308, then you will enter the following: 38.47.127.50:10308

 

If the host is correctly configured for hosting in general--that is, if you're able to join him normally using the Internet source during the times when the server list is working properly--then you should be able to connect. If you can't, try restarting the program; a single restart of DCS has done the trick so far in each case, for everyone who has attempted to join my server using this workaround.

 

* This is mislabelled; it should read "direct connect" instead of "LAN." So, it works for remote connections, not just on local area network. E.g. it'll allow someone from Britain to join a host in Germany, and so on, rather than requiring the two to be in the same building.

Edited September 28, 2012 by Echo38

[BIGNEWY]

We will give it a go tonight, thanks for taking the time to type it out Echo38 :thumbup:

 

That isn't the workaround I was talking about; it's only part of the workaround, followed by an action which negates the workaround, thus causing the crash.

 

Here's a step-by-step description of the full workaround, which will enable you to host a private game even during the times at which the master server list crash is occurring; do not select Internet from the Source box at any point during this process:

 

The host must do the following: open Multiplayer, cancel the login, select LAN* from the Source dropdown box, and then login. Do not select Internet from the Source box, as this will cause the crash if the bug is occurring at the time. Now that you're logged in to the master server, click on NEW SERVER, then select LAN from the Server Type dropdown box. Check the port number, then hit START.

 

All clients must then do the following: open Multiplayer, cancel the login, select LAN from the Source dropdown box, and then login. Do not select Internet from the Source box, as this will cause the crash if the bug is occurring at the time. Now that you're logged in to the master server, click on Connect by IP, then enter the host's IP address and port in the following format, without the brackets: [address]:[port]. For example, if the host's IP address is 11.111.111, and if he is using the default port of 10308, then you will enter the following: 11.111.111:10308

 

If the host is correctly configured for hosting in general--that is, if you're able to join him normally using the Internet source during the times when the master server list is working properly--then you should be able to connect. If you can't, try restarting the program; a single restart of DCS has done the trick so far in each case, for everyone who has attempted to join my server using this workaround.

 

* This is mislabelled; it should read "direct connect" instead of "LAN." So, it works for remote joining, not just on local area network.

[badger66]

I know it is less than Ideal, but why not roll back to an earlier version that works?

 

Nate

 

I would , but the squad doesnt want to .

[badger66]

but we are a resilient bunch of dedicated ED followers and we do our best to keep positive despite this long standing issue

 

Yep , we are :) ..... Im just looking forward to the day it works as said ..... then we will be a delighted bunch of chappies .

[Speed]

Just semantics. The CTD occurs when connecting to the master server. I don't care if the moon is causing the problem, its a master server bug. And that is how everyone who has the problem will recognize it.

 

And if it is purely a client side problem, then why does it work sometimes and not others? Nothing is changing on the client side, what is changing is what is being sent from the master server.

 

So when can we expect 1.2.1?

 

It doesn't matter if its the master server or the client. Connecting to the master server is the problem and so calling it a master server bug is quite accurate.

 

Its just a petty way of trying to antagonize pissed off customers who cant use the game.[/Quote]

Again, quite wrong, connecting to master server is not the problem. It's displaying the server list that is the problem. Next time the problem is occurring, cancel the login screen, change your "Source" to LAN, then connect to the master server. You will have no problem. Now switch your "Source" to "Internet", and you will crash immediately.

 

It's a server list problem. The reason that everyone starts crashing at the same time is everyone's server list is the same.

 

The reason it's important to understand this is because it means

1) 1.1.1.1 still works while this problem is occurring. Many online squads still use 1.1.1.1, partially due to this problem.

 

2) I have seen people using this problem as evidence why the master server is a bad idea for DRM and it should be abolished. So it's important to note that this problem has nothing to do with the master server and would probably occur even if there wasn't a master server login at all.

[BIGNEWY]

well we had a go at connecting via LAN tonight and all we had was an attempt to connect to our server and then "cant connect"

 

Server has been up most nights for years hosted by Ogerman we can connect when we do it via Internet no problem but not LAN, ports are forwarded firewalls set correct but no joy.

 

Then I started to get the client / server bug crash when we reverted to the normal way to connect.

 

I have given up going to go watch tv and wait for a patch lol

[Speed]

well we had a go at connecting via LAN tonight and all we had was an attempt to connect to our server and then "cant connect"

 

Server has been up most nights for years hosted by Ogerman we can connect when we do it via Internet no problem but not LAN, ports are forwarded firewalls set correct but no joy.

 

Then I started to get the client / server bug crash when we reverted to the normal way to connect.

 

I have given up going to go watch tv and wait for a patch lol

 

Yea, I wish the LAN method worked for me too. I wanted to play some last night, but after a forty-five minutes of crashing on trying to display the server list, I had to give up.

 

Like you, all that I get when trying to bypass the display of the server list using "LAN" or "History" source, and connecting to a server with direct IP, is the "Can't Connect" message. The purported direct IP connection "work-around" is not a work-around, not for the vast majority of us.

[Azrayen]

well we had a go at connecting via LAN tonight and all we had was an attempt to connect to our server and then "cant connect"

 

Guys... the workaround has it flaws, but it will work perfectly as long as you respect the steps... you (client) and the server (host) if needed.

 

c0ff posted:

You can Connect by IP to any server a long as either

1) server is in the received master list

OR

2) server is in the LAN mode

 

Translation: If you cannot get the master server list (because it is "crash time"), then you can only join servers that were launched in source=LAN.

The workaround is perfectly doable for people who control the host/server. Any squad-organised flight is perfectly OK, at all times: just put the host and the clients in source=LAN.

The bug is blocking for:

- people who try to reach a public host (such a server will always be in source=INTERNET)

- people who try to re-join, at a bad time (crash time) a server in source=INTERNET that they were previously able to see, because the first time they connected it was not "crash time".

 

BTW, I'm not sure the INTERNET/LAN is a "wrong" label. It's labelled "source". What source is it? It means the "source from where do you want to get your servers list?"

 

Cheers,

Az'

[Echo38]

all that I get when trying to bypass the display of the server list using "LAN" or "History" source, and connecting to a server with direct IP, is the "Can't Connect" message. The purported direct IP connection "work-around" is not a work-around, not for the vast majority of us.

 

As I wrote elsewhere, I was indeed unable to use C0ff's workaround if I tried his first suggestion ("connect by IP [...] as long as server is in the received master list"); it caused the clients to get "Can't Connect." However, I was able to use his workaround if I used his second suggested method ("server is in the LAN mode"). All clients who have thus far attempted to connect to my server, using my instructions, have done so successfully. Speed, have you tried following my workaround guide exactly? I mean, with both client and host following it exactly?

 

BTW, I'm not sure the INTERNET/LAN is a "wrong" label. It's labelled "source". What source is it? It means the "source from where do you want to get your servers list?"

 

The server list Source dropdown box isn't the big problem; it's the Server Type dropdown box when hosting. That's absolutely incorrect, as one must select LAN if using C0ff's second method of remote joining. It should be called "LAN or Direct Connect," or something like that, rather than "LAN," which would mean that remote clients couldn't join (which isn't the case).

Edited September 29, 2012 by Echo38

[BIGNEWY]

Thanks AZ and Echo38 for trying, the work arounds do not work for us and we have given up.

 

We get "cant connect" no matter what method we use.

 

The patch for a fix is long overdue, 2 months now with a broken product is not good for the online community or ED's reputation.

 

I can deal with the normal crashes weapons.dll effects.dll and so on, but now in its current state having a crash now means you can not get back into a server. Multiplayer is broken and until its fixed I am going to stay grounded.

[Azrayen]

Thanks AZ and Echo38 for trying, the work arounds do not work for us and we have given up.

 

We get "cant connect" no matter what method we use.

The "cant connect" is typical for

- server in INTERNET (NB: the server setting is done on the "NEW SERVER" page, not on the first page in multiplayer)

- clients in LAN.

 

Would you mind trying again, following the screenshots below?

[Bricks]

It's a server list problem. The reason that everyone starts crashing at the same time is everyone's server list is the same.

 

Nitpicking. :yawn:

 

For the user, it doesn't make the slightes difference, if the MasterServer is causing the problem, a bug in receiving the client-list or a corroded network-plug: We can't change or fix the problem!

 

So these "YOU'RE WRONG, WE KNOW BETTER"-posts from testers or mods doesn't help anybody. It's received as lecturing, by many users, as you can easily see over the last 10 pages.

 

 

Fact is: There is a big problem. We can't fix it. So you have to fix it.

 

(Yes, I know it's already been fixed, but that honestly doesn't let us connect any better either.)

[BIGNEWY]

Once again thanks for trying AZ

 

we have tried it this way and still get the "cant connect"

 

We have tried other host's all our ports and firewalls are set correctly, -=Shrek=- squadron has been running a server for years and connecting has never been an issue until this bug came about.

 

I will wait for the patch, many of us are.

[159th_Viper]

 

So these "YOU'RE WRONG, WE KNOW BETTER"-posts from testers or mods doesn't help anybody....

 

It does and is relevant when it comes to reporting problems/issues.

 

Granted, this matter under discussion has now been fixed, but what about the next major issue (pray none will occur)? If we as testers and/or the Devs have to wade through 10 pages of user reports that all amount to a problem being reported incorrectly, then how on earth are we supposed to reliably get to the bottom of any issue reported?

 

We attempt to inform the members how to report issues in stickied threads and even that falls on deaf ears. We are accordingly necessitated to repeat ourselves over and over and over again in an attempt to secure proper, detailed, informative and factually correct bug reports in order to properly investigate issues so reported.

 

If that means that it is received by some as lecturing then so be it. At least we as testers are doing all we can to ensure than our future time is not wasted chasing vague/incorrect reports. As the Dev already also stated,

 

Clear and unambiguous identification of the problem is necessary to have any kind of useful feedback.

 

Thank you for your understanding.

[BIGNEWY]

To be fair Viper, this issue has only just been made a sticky in known problems http://forums.eagle.ru/showthread.php?t=87424 after 2 months of the problem, no wonder you guys have to repeat yourselves.

 

dont envy you guys anyway, keep smiling

[159th_Viper]

To be fair Viper, this issue has only just been made a sticky in known problems http://forums.eagle.ru/showthread.php?t=87424 after 2 months of the problem, no wonder you guys have to repeat yourselves.

 

dont envy you guys anyway, keep smiling

 

I was referring to this sticky :)

 

http://forums.eagle.ru/showthread.php?t=88164

[Bricks]

I guess we all know, that stickies are less attractive than a 24 pages discussion. And I guess we all are guilty to not read every post in such a thread. I surely don't envy you for the job, Viper.

 

Still, and that was my point: It's the tone that makes the music.

 

And maybe some of the posters I was referring to, had better posted just a copy of that sticky instead of disassemble and contradicting every sentence in a hasty "bugreport". At least IMHO this doesn't really add to deescallation. And IMHO the issue is volatile enough.

 

Remember, most of the posters here seem to just come from a crashed session or disconnect.

[159th_Viper]

Remember, most of the posters here seem to just come from a crashed session or disconnect.

 

Quite so, which in all probability explains the existence of forum rule 1.10 very well :)

 

In any event, this discussion relating to the crash is mostly superfluous as the client-side bug has been rectified. It is now the wait for 1.2.1. that is relevant.

[Echo38]

If we as testers and/or the Devs have to wade through 10 pages of user reports that all amount to a problem being reported incorrectly, then how on earth are we supposed to reliably get to the bottom of any issue reported?

 

We attempt to inform the members how to report issues in stickied threads and even that falls on deaf ears.

 

I agree that most people (even most beta testers) don't do a good job of bug reporting. There's another side to the coin, though. Bug reports are quite a bit of trouble to post according to the instructions; I did so anyway, and went out of my way to make it as informative as possible and contain multiple crash logs. However, my report never was acknowledged, not even by a word, so I have no idea whether all the effort I went to was wasted or will be used. This is very discouraging for someone who is attempting to cooperate fully in testing & reporting bugs.

 

I was a beta tester for another flight sim-game; I submitted approximately ninety unique reports (including, whenever possible, screenshot, track, video, and/or WTR), about twenty-five of which bugs were subsequently fixed by the developer (and many more were confirmed). Some of the minor bugs and more subjective problems were overlooked, which is understandable (given the busy schedule of the developers), but the project manager took great care to respond with at least a word to the majority of the bug reports (especially the more serious ones), even if just to inform us that they were unable to fix it at that time or could not reproduce the bug. This feedback encouraged us to be more active in our participation in the beta testing, because it showed that our efforts (which sometimes took up hours of our volunteer time) were not being ignored.

 

In short, beta testing is just as thankless of a job as forum moderation, and perhaps even more so than sim development. (At least the devs get paid!) And that is why the vast majority of people C.B.A. to make an organized, helpful bug report. It's regrettable, but I can't altogether blame them.

Edited September 29, 2012 by Echo38