it has quite unfortunately, become the expected.
Oh look server down. meh, whatever, happens every day anyway.

@Jayjay how do you know?

Guys its about time this shit show of a game is dropped. like i said before, it once had potential.  But if it can not be mannaged propperly why even play it? its just crashing over and over, and having multiple devs on it isn't doing much to help the problem.

seems so.

tunmi did say that he was shutting rotu down, i am not sure if it is perminent or not but i would have thought he would have said on here

Well the shutdown of rodu and bs came not to long after my final bs post on the bs thread .  If they are somehow tied then so be it, but I highly doubt it. It just seems a coincidence.  It is his choice weather he chooses to inform his players of his choice of shutting a game down, especially those that pass through these forum pages.  After all he doesn't want to be associated with this forum.  Personally, I do hope he figures himself as a developer out and if he does indeed bring one of his projects back, I do hope it is the one that he is really passionate about, and that it is one he really wants to succeed.  Like i said before he has potential as a dev, but he needs to find his way.  Take a few years and learn a language of programming really well, or pick up a project, really hammer out the bugs, and problems, and then release it.  Also another task that takes time.

That is for sure

as tunmi said, ratu and bs was just discontinued

You know, It's not that bad to have a public list of BGT games that failed and got taken down. And even some explanation about each game to prevent the newer devs pick BGT as their dev tool of choice. If it wasn't for BGT and its networking system and its weird debugging code, this game wouldn't be taken down.
A hint. Do not yell at me "Shut up we're bored of this topic coming up everywhere". There are still people, even talented people, that use bgt as the tool of their choice. And It's for the best if they read through all this negativity towards BGT and eventually stop using it.
Thank you!

Ah. Then I failed to express my purpose well enough.
I'm not at all trying to put all of this on BGT, even though I admit that my post looked like that. The developer himself plays the main role, as you have also suggested. To put it simply, it's just a matter of management. Management of the code, the gameplay, ETC ETC.
also, What I meant by that post was that BGT is not suitable for multiplayer games. It is not, as many others have also confirmed. It is using a very old version of ENet library, and definitely the networking system is not complete. One simple example for that would be lack of support for TCP. Not that it is essential for multiplayer games, as I know that FPS-type games use UDP as you can transport packets at a rediculously fast speed. But having support for both types is something that any Network library has. Let alone BGT which is an engine.
Again, the inefficiency of BGT's network support is proven before many times and is not something that can be avoided. Even the best developer out there cannot make a multiplayer FPS-style game that uses BGT, with a small lag time. I mean if it was only me thinking like that, I wouldn't post this about BGT. But since I have read here and there about all this, and that I Have had experiences with the engine, I'm also promoting it. The instances you brought up are not really fast-paced online games. I mean the multiplayer part of them isn't. Even crazy party, which really, cannot be compared to an FPS game, used to get extremely laggy. And yet it's not just comparable to an FPS game.
And manamon's networking is really not that heavy. It's all some packets sent at a slow rate. Not at all comparable to an FPS game again.
I have had online projects both in BGT and Python. And I have seen the performance of both, hence my reason to post all this.
Oh. One last thing about what I meant by BGT's improper way of presenting debugging features.
Simply, an efficient game engine would present some ways for handling errors and runtime errors in linux.
Last but not least, lack of Exception handling matters a lot, and it is not there in BGT. One thing that if were there, the use of "Runtime monitors" would drastically decrease and even there wouldn't be a use for them if the dev would use the exception handling code properly.
Sorry, this got too long. My intent for posting this was just to prevent the one person whose going through all of our posts from picking up BGT as their language of choice

Uh, @370 what are you talking about? Of course BGT has support for TCP. Ever heard of send_unreliable?
The hole reliable / unreliable thing is just a by product of ENet. Literally all of the lag people experience with BGT games comes down to bad coding, and your own game, firefight was no exception to that, either.

@kianoosh, I'm interested as to your response to post 371 which brings up an excellent point as to the lack of lag.
Re, exception handling, that's not entirely BGT's fault, nore is it unheard of the languages doing the same logic, I.e, this is C:

int do_something(int *x)
{
    if (*x == 0)
    {
        return 1; // We failed
    }
    return 0; // We succeeded
}

C lacks try and accept, which we can still get around by doing if (do_something()). If C gets away with it, I don't see try and except as being essential. Are they nice? Sure. Are they a good characteristic of a language, I don't think so.