Beta patches policy

[maruk 80]

We definitelly should try to avoid such a long gap between beta patch and final release as was the case of the version 1.15 (1.16).

It was purely caused by heavy work load on Arma 2. From reading this discussion, I believe that is the only real problem here.

It was never our intention to keep 1.15 for such a long time but time really passed by way too fast over there in Chernarus ;)

And believe, if there were not some really serious problems we felt may make Arma 1 unplayable in long term (Vista bug anyone with a lot of RAM?) we probably wouldn't commit to this 1.15 develpment at all.

[bravo 6 0]

i believe the problem was not the time between patches, but as Q mentioned, the name BIS used to release them. IE, BIs released "beta" patches, and this word is terrible to understand for most of human community. There are several servers that don't even try it because it has the name "Beta" in the patch.

What i understand here and what i believe Q is trying to say to BIS is that in future "beta" please remove the "beta" name in the patch.

Just release future patches using a normal patch name without the "beta" word! Do not use the "beta" name in the file. It will "stupidly" change peoples idea about it.

edit: Typo: Its all a matter of names!

I know names doesn't matter but as you know, it does for alot of ignorant people. (no Offense meant)

Edited April 27, 2009 by bravo 6

[Deadfast 43]

Removing the "beta" part from a beta patch would only result in people complaining why there is so many bugs in it and whether BIS even tested it prior to the release.

[bravo 6 0]

People need to have sense about this working developement.

Things have been improved in huge scale, those improvements took time.. there for more patches appeared. Since ARMA2 is very similar to ARMA1, makes sense things continue to improve.. there for there possibly will exist more patches.

Jesus, i really don't know whats the big deal with this patches thing.

Its very awesome that BIS makes patches and improvementes, meaning they found better ways to run the game. Its stupid to denie these patches.

Again: If all these negative feelings exist is due to the name "beta".

[.kju 3240]

Removing the "beta" part from a beta patch would only result in people complaining why there is so many bugs in it and whether BIS even tested it prior to the release.

This is not what BI patching history tells us.

Every beta patch significantly improved the game in many ways

AND

introduced hardly any new crucial bugs

AND

must full patches were merely a rename of a beta patch.

You guys seem to neglect the actual reality here.

PS: The community test patches. This is the idea of beta patches by the way..

[Yoma 0]

I just think the decision on patch policy is entirely in the developers hands.

Surely they have their reasons to follow the path they are following and without deep understanding of their developement process we are in no position to tell them what to do/what not to do.

Maybe they don't want to release a beta version as non-beta untill they have working linux server. And surely the process of making/testing a working linux server is too costly to do it on every beta release.

Anyway, long beta's are becoming a fashion nowadays (just take a look at Google...) so i personally don't give a damn if a patch is beta or non-beta.

Again, there is no such thing as a perfect world and anything BIS can do will have it's pro's and con's.

Also maybe we overestimate the time BIS can financially afford to put in patching Arma given the developement of Arma2.

[sickboy 13]

Agreed on too much time has past between the patches.

I'm kinda unsure myself how far BI has responsibility in the other matters...

• Fact: ArmA: Linux Support: Not too great
  
• Fact: ArmA: Beta Patches come out now and then: Not too great for servers hosted at companies that don't allow beta patches
  

-------------

• Solution: Don't order a Linux server for ArmA, or do not complain that you are behind with Patches. Or run under Wine?
  
• Solution: Don't order a server at a company who doesn't allow Beta patches, or do not complain that you cannot run Beta patches.
  

I guess this is a bit 'harsh', and probably because i've always ran Windows Servers for Games, I see it this way.

Anyone else? :)

Edited April 28, 2009 by Sickboy

[landdon 0]

I do not see a problem with a patch called beta and I think BIS should continue with it's present method. I think there was only one mistake BIS made during this last release and that was no support for the Linux. That is only because 1.15 seemed to me to be a substantial release and therefore it would only seem prudent that this release would have included a Linux Version. Now as serveral people have noted, we as the public do not know the financial strenght/budget nor feedback given regarding 1.15. Only BIS can really make that determination, one can only hope that every so often and on the day that BIS will no longer support Armed Assault and moves to Armed Assault II that those in the Linux community along with us using a Window Server will both recieve the same server version. In my opinion there are more pressing issues with Armed Assault then if a patch is called Beta or not.

[HitmanFF 6]

Solution: Don't order a Linux server for ArmA, or do not complain that you are behind with Patches. Or run under Wine?

I've been running a linux (root) server for OFP and ArmA since 2002, and most all of the server/map management scripting that's running on the server, is partly web based, partly scripted and quite dependent on the underlying OS. A lot of time and effort has gone into developing and fine tuning them, and it would be a significant effort to get everything running under Windows. I have a lot more in-depth knowledge on linux than I would ever hope to gain on windows. So that alone would stop me from switching over to windows, and then I won't even touch on pulling back the server from the colocation, installing windows and everything else needed and bringing it back to the colocation. So it's not simply ordering a windows server and that's that ;). Wine doesn't run the ArmA server unfortunately; it would be the ideal solution for me if it did.

I guess this is a bit 'harsh', and probably because i've always ran Windows Servers for Games, I see it this way.

It's a matter of taste really. I've always run linux servers for games, it's what I'm used to. The major issue for me is the fact that we have been waiting for the linux server since last December, when v1.15b was released, with no clue when the linux server will be released. We've installed vmware + windows on our linux server to run the windows ArmA server, which is doable, but it does mean a major performance hit. And all of the aforementioned scripting doesn't work anyway, so we have to manually transfer map updates, stop/start the server etc.

[sickboy 13]

I've been running a linux (root) server for OFP and ArmA since 2002, and most all of the server/map management scripting that's running on the server, is partly web based, partly scripted and quite dependent on the underlying OS. A lot of time and effort has gone into developing and fine tuning them, and it would be a significant effort to get everything running under Windows. I have a lot more in-depth knowledge on linux than I would ever hope to gain on windows. So that alone would stop me from switching over to windows, and then I won't even touch on pulling back the server from the colocation, installing windows and everything else needed and bringing it back to the colocation. So it's not simply ordering a windows server and that's that ;). Wine doesn't run the ArmA server unfortunately; it would be the ideal solution for me if it did. It's a matter of taste really. I've always run linux servers for games, it's what I'm used to. The major issue for me is the fact that we have been waiting for the linux server since last December, when v1.15b was released, with no clue when the linux server will be released. We've installed vmware + windows on our linux server to run the windows ArmA server, which is doable, but it does mean a major performance hit. And all of the aforementioned scripting doesn't work anyway, so we have to manually transfer map updates, stop/start the server etc.

Hehe, those are good reasons I suppose :P

I guess my statement was a bit shortsighted :) BI's 'half' linux support doesn't make it easier either :)

PS; maybe useful for you: for Windows you can use ServerDOC for free: http://www.serverdoc.com ; restart / start / stop over HTTP. The paid version has some scripting support, though if I was considering writing anything for it, I would probably rather write something platform independent in Ruby :)

[max power 21]

I think you can safely say that BIS is running at its maximum possible output for supporting this game while it has other projects to finish. The patches are beta because they are not fit for RC and so that we can test them and find problems. They seem to develop the linux server after the windows server, and so developing potentially unstable linux servers off of beta software seems like a waste of time. There is no reason for any different patching policy, since if we wanted only full patches, they would have to do all of their testing internally, and we would see nothing from them for much greater spans of time.

[Yoma 0]

I've been running a linux (root) server for OFP and ArmA since 2002, and most all of the server/map management scripting that's running on the server, is partly web based, partly scripted and quite dependent on the underlying OS. A lot of time and effort has gone into developing and fine tuning them, and it would be a significant effort to get everything running under Windows. I have a lot more in-depth knowledge on linux than I would ever hope to gain on windows. So that alone would stop me from switching over to windows, and then I won't even touch on pulling back the server from the colocation, installing windows and everything else needed and bringing it back to the colocation. So it's not simply ordering a windows server and that's that ;). Wine doesn't run the ArmA server unfortunately; it would be the ideal solution for me if it did. It's a matter of taste really. I've always run linux servers for games, it's what I'm used to. The major issue for me is the fact that we have been waiting for the linux server since last December, when v1.15b was released, with no clue when the linux server will be released. We've installed vmware + windows on our linux server to run the windows ArmA server, which is doable, but it does mean a major performance hit. And all of the aforementioned scripting doesn't work anyway, so we have to manually transfer map updates, stop/start the server etc.

I know it's not the best solution, but couldn't you try something with VMWare or some other virtualisation software? Sure you'd get a performance hit, but it's better then nothing i guess...

I know for sure that if i'd put a server in colocation i'd be running virtualised environments... Simply for flexability...

On a decent machine performance shouldn't be too bad either...

Anyway of course a decent linux server would be great but not if it would hamper for example Arma2 developement.

[maruk 80]

As I am reading the discussion, I can understand the problems for Linux server users. Unfortunately, considering install base and our resources -two closely related variables - generally speaking, it's either late Linux servers or no Linux servers at all. I would be very happy to be able to say something different but unless something changes significantly this is the way it is going to be in foreseeable future. It took very long time after the release of OFP to get Linux server done and released, it also took long time after the release of Arma and that's the way it is.

[d3nn16 3]

After reading a number of posts I came up with some """""great""""" ideas:

- call beta patches FPUB patches, that is Final Patch Unless Bugs :-) (maybe do this once just to see the players' "face")

(- make a Linux version for Arma (maybe less time for linux server update ?) :-D)

- BI should run an Arma server and ask players complete an ingame feedback form at the end of special made missions (will give bored players loafing around servers some motivation)

[sickboy 13]

Thanks Maruk for reply.

I know it's not the best solution, but couldn't you try something with VMWare or some other virtualisation software? Sure you'd get a performance hit, but it's better then nothing i guess...

I know for sure that if i'd put a server in colocation i'd be running virtualised environments... Simply for flexability...

On a decent machine performance shouldn't be too bad either...

Anyway of course a decent linux server would be great but not if it would hamper for example Arma2 developement.

He already mentioned it in the quoted text.

I just realized; I'm hearing a lot of great things about VirtualBox's performance compared to VMWare, esp harddrive performance if im not mistaken; you might want to give that one a go during the absence of Linux variant of your wanted version.

[maruk 80]

For those interested in more general perspective, I found these two industry examples worth more than any post that I could write:

http://www.stormrisers.com/news/35_stormrise_patch_2_cancelled.html

http://community.enemyterritory.com/index.php?q=node/248

[.kju 3240]

Patching requires significant effort, no doubt about that.

At the same time at least part of your patching progress benefits your engine

development, as well as future products in general.

In addition the community does take part in the patching progress to a very degree as well.

On the one hand by testing your product and reporting problems. On the other hand

by developing fixing themselves and trying to distribute them.

So it is to be considered what processes and tools are needed and useful to benefit of

the free tremendous effort the community contributes to the development of your products.

In the end most important is how can the company benefit of maintaining and improving a product

in the long run. Expansion packs or monthly/regular payment for continuous support and development

or other sources of revenue come to mind.

Edited May 1, 2009 by kju

[Mojo 0]

In the end most important is how can the company benefit of maintaining and improving a in the long run.

I thought that was why the public beta version of the patches are released, to offset the costs and to allow the developing aspect of the community to test the beta code with their own beta code to find and repair problems, thus keeping compatibility to a maximum and being able to find out if the bug is with the community developed code, or the company's code.

Expansion packs or monthly/regular payment for continuous support and development or other sources of revenue come to mind.

This first, wouldn't that be Queen's Gambit? It seem to me that they are already working on methods to offset a growing cost center. As to the later, a monthly fee for a setup like this would flop. Pure and simple. Unless they maintained official servers, where community developed code is prohibited. Consider also, this company isn't configured to be a EQ or WoW or LoTR. If they were to consider the change, they'd soon have to outlaw most community deveopment, because of the compatibility issues. You can't charge a monthly fee and then accept all the blame for poor coding.

In short, they already do everything they can and they do it well enough. There still hasn't been any compelling argument that leads to a change in how they do business. The only shortcoming they have is the linux builds, but they've explained that (repeatedly).

[.kju 3240]

Well of course you can always ignore what people write (refer first two posts), and

cherry-pick whatever you want and tell us your little nice little story no one is interested in hearing. ;)

Re: Public beta

Again read post 1 and 2. Read again my post before yours.

Re: Expansion packs

BI decided that A1 had no potential for an addon and concentrate on A2 instead.

The addon was made by their partner firm to a large degree. If Resistance of QG, payed

off financial wise, we will see with possible A2 expansion packs (based on the degree of

success of A2 itself of course).

Re: regular payment.

There are many smaller and bigger companies making smaller games with different

business models making very good money with it. Time to look over the edge of a plate. ;)

Re: In short, they already do everything they can and they do it well enough.

Compelling argument is that you always do better and reconsider your priorities.

The world around you is changing, so is your product and situation of it.

This post is about A2. Just to let you know.

[xxbbcc 6]

I haven't read through the entire discussion, just skimmed through a few entries, but in general, I think the BIS patch policy is all right. Patches are coming out, when other game developers drop the keyboard when 1.0 ships out. This is great. What's even better is that BIS actually expands the game with some of the patches - for free! This is not something that would be expected of them.

I wouldn't mind buying expansion packs and campaigns for a reasonable price, if that helps BIS. However, paying for patches (monthly fee, etc.) is entirely out of question. Patches are for fixing problems in the game and we all know how buggy ArmA was when it came out (and for a long time after.)

Here are a few things that I wouldn't mind buying (if they're high quality/high performance):

- animal packs with animals that roam the land automatically, in any mission, once added (no scripting/mission editing needed)

- female models packs

- kids

- etc.

- new complex campaigns (like Cold War in OFP)

Some of these are available as community addons, but I wouldn't mind getting officially supported versions, as long as quality- and performance-wise they're fine.

[Placebo 28]

Well of course you can always ignore what people write (refer first two posts), and

cherry-pick whatever you want and tell us your little nice little story no one is interested in hearing. ;)

I see nothing wrong with his reply, it's on topic to the discussion in hand, last I checked you're not the forum voice who decides how people are allowed to reply to threads, so please don't act that way. Just because you have a firm stance on the issue doesn't mean you can then make arrogant, condescending comments to other members of the forum simply because they don't acquiesce and bow down to your wisdom and opinion.