24/7 Falcon Online CO-OP server
-
Another Battle for Balkans 1.3.0 RC 6 Live stream coming here in 5 mins:
-
Turn on Ships/Unknown on your RWR, Archer :rolleyes:
-
On popular demand we are bringing back the COOP server read the last post here: http://falcon-online.org/forum/index.php?topic=1407.msg26435;topicseen#new
-
On popular demand we are bringing back the COOP server read the last post here: http://falcon-online.org/forum/index.php?topic=1407.msg26435;topicseen#new
64 bit…? 32 I know but one can hope.
Thanks Archer, will be around later today.
-
-
-
witch version? BMS 4.32 OR BMS 4.33
-
4.33
-
CO-OP server live stream starting in 5 mins here:
-
Falcon Online COOP server is Running 4.33 U1 64 bit with Korea Strong DPRK.
-
There will be more specifics to say about this but please keep in mind that we made a trade-off decision in releasing 4.33.1 that specifically concerns MP games with scale of 10’s of players. The BMS team is aware of some specific scaling issues that can result in uneven gameplay and game code crash (CTD) events. Obviously this is less than ideal. However, we chose to release anyway knowing that a very significant portion of the community would get enjoyment and stable results out of 4.33.1 as it stands now, even if some of the larger-server-ops folks might experience frustration.
We’ve actually learned quite a bit and found some new avenues for exploration quite recently. Those investigations will continue and with luck will bear fruit in due course. We did not feel close enough to meaningful changes to address stability and scaling issues, as yet, so as to warrant holding up 4.33.1 from release. The things I’m referring too are inherent in 4.33 as well, btw, it’s not newly introduced issues per se.
We did make a couple of point fixes for issues (for example the g_bSkipAggregationBWCheck fix which we believe will help with ghost flights and the like) but more significant changes to address what we have learned will need to wait a while yet.
Now, please understand that I’m not going to try and get into more details or respond to questions here. Others more familiar with the issues will start separate thread(s) to share what we know and what we think we know and what we think are best-known-methods for improving your chances of stable MP experiences with larger population MP games.
For now, I just wanted to let you know that this is a concern for the team and to temper any frustration you might have coming if you are at some point bitten by these kinds of issues: in that regard, please know that we are aware and working on solutions.
-
There will be more specifics to say about this but please keep in mind that we made a trade-off decision in releasing 4.33.1 that specifically concerns MP games with scale of 10’s of players. The BMS team is aware of some specific scaling issues that can result in uneven gameplay and game code crash (CTD) events. Obviously this is less than ideal. However, we chose to release anyway knowing that a very significant portion of the community would get enjoyment and stable results out of 4.33.1 as it stands now, even if some of the larger-server-ops folks might experience frustration.
We’ve actually learned quite a bit and found some new avenues for exploration quite recently. Those investigations will continue and with luck will bear fruit in due course. We did not feel close enough to meaningful changes to address stability and scaling issues, as yet, so as to warrant holding up 4.33.1 from release. The things I’m referring too are inherent in 4.33 as well, btw, it’s not newly introduced issues per se.
We did make a couple of point fixes for issues (for example the g_bSkipAggregationBWCheck fix which we believe will help with ghost flights and the like) but more significant changes to address what we have learned will need to wait a while yet.
Now, please understand that I’m not going to try and get into more details or respond to questions here. Others more familiar with the issues will start separate thread(s) to share what we know and what we think we know and what we think are best-known-methods for improving your chances of stable MP experiences with larger population MP games.
For now, I just wanted to let you know that this is a concern for the team and to temper any frustration you might have coming if you are at some point bitten by these kinds of issues: in that regard, please know that we are aware and working on solutions.
Are you stating BMS 4.33 U1 is not suitable (ie. unstable) for Multi-Player sessions exceeding 10 players?
-
Note
The things I’m referring too are inherent in 4.33 as well, btw, it’s not newly introduced issues per se.
-
I’m a bit dissapointed to hear this because that very F-O campaigns with large number of players still keep me close to BMS and I believe I’m not the only one. There are lots of guys like me loving proper Force vs Force events.
But I hope You guys (BMS Devs & F-O devs) will tighten cooperation even closer than ever before to solve all the MP problem. F-O has also very talented folks and it’s a Great platform to hunt those bugs. Fingers crossed.
-
Are you stating BMS 4.33 U1 is not suitable (ie. unstable) for Multi-Player sessions exceeding 10 players?
Let me put it this way: we know of specific behaviors that players can engage in that, in scenarios with geographically spread out sessions that number in the 10-20 range, will likely result in at least blue-pause events and potentially CTD events. I’m not making any value statement about suitability. For smaller numbers of players at a time these behaviors are rock solid stable all day and twice on Sunday. Since, as has already been pointed out twice now, this isn’t new with 4.33.1 I can say this: 4.33.1 is no less suitable than 4.33 and probably more suitable owing to the tweaks around the edges of the larger issues such as the g_bSkipAggregationBWCheck. Does that help clarify??
-
For further clarification and empirical results of testing please see the very latest (updated post Update 1) BMS Manual p96 and the supporting annex with the actual results on p280.
-
Since, as has already been pointed out twice now, this isn’t new with 4.33.1 I can say this: 4.33.1 is no less suitable than 4.33 and probably more suitable owing to the tweaks around the edges of the larger issues such as the g_bSkipAggregationBWCheck. Does that help clarify??
Yes, it does. Thank you Boxer.
-
Let me put it this way: we know of specific behaviors that players can engage in that, in scenarios with geographically spread out sessions that number in the 10-20 range, will likely result in at least blue-pause events and potentially CTD events. I’m not making any value statement about suitability. For smaller numbers of players at a time these behaviors are rock solid stable all day and twice on Sunday. Since, as has already been pointed out twice now, this isn’t new with 4.33.1 I can say this: 4.33.1 is no less suitable than 4.33 and probably more suitable owing to the tweaks around the edges of the larger issues such as the g_bSkipAggregationBWCheck. Does that help clarify??
For further clarification and empirical results of testing please see the very latest (updated post Update 1) BMS Manual p96 and the supporting annex with the actual results on p280.
From what I can gather from your post (and after reading p.96 + annex) the issue is not specifically code related but a symptom of limited upload bandwidth available on the client and server’s end. A limit which in practice may cause the entire session to become unstable due to bandwidth saturation of either client or server (or both).
So if I understand correctly…
If we assume all clients have sufficient bandwidth ie 2048 or higher, and have this set as their connection speed while at the same time connected to a server which has enough bandwidth to adequately cope with the client load, then the caution you are stating is not relevant?
I say this because at FO we have an active solution (not publicly released) which measures each client’s available bandwidth and latency before providing access to the server.
As we can filter clients which do not meet the minimum requirements, this would shield the server from conditions where the code is vulnerable to timing issues and be “rock solid” as you stated.
Not sure what type of connection BMS are testing on but at FO we have a 1GBs pipe available so server bandwidth is not an issue. All that is required would be to filter clients.
-
Not sure what type of connection BMS are testing on but at FO we have a 1GBs pipe available so server bandwidth is not an issue. All that is required would be to filter clients.
Actually the server is running on a 2 gigabit pipe not 1, both of them. And they are hosted in a Data center on a gaming PC which is using a server grade LAN PCIe Card.
-
Actually the server is at 2 gigabit pipe not 1, both of them. And they are hosted in a Data center on a gaming PC which is using a server grade LAN PCIe Card.