ARMA 2: OA beta build 95248 (1.62 MP build)

[Tonci87 163]

An elitist community full of butthurt people. After reading the last pages I understand why some people describe this forum with those words.

Seriously guys if you know BIS then you know that the Devs always (well almost) listen to the community and they are generally very helpfull.

I'm 100% sure that BIS is working on the problem. I'm also sure that there must have been a quite serious and unpredictable problem with the Linux server exe. Shit happens and the Devs apologized for it. Leave them alone so that they can spend their time working instead of reading your rather useless rage posts.

[MavericK96 0]

An elitist community full of butthurt people. After reading the last pages I understand why some people describe this forum with those words.

Seriously guys if you know BIS then you know that the Devs always (well almost) listen to the community and they are generally very helpfull.

I'm 100% sure that BIS is working on the problem. I'm also sure that there must have been a quite serious and unpredictable problem with the Linux server exe. Shit happens and the Devs apologized for it. Leave them alone so that they can spend their time working instead of reading your rather useless rage posts.

No kidding. Maruk, Dwarden and Suma have all commented on this topic and yet people still are complaining. It'll be released when it's done. How hard is that to comprehend?

Not to mention this discussion doesn't belong in this thread, anyway.

[Famewolf 1]

Yes. It it my own fault, my responsibility. And this is what I do:

- I apologize

- I do my best to fix the situation

- I try to find a temporary workaround (which currently seems to be using the Wine - not perfect, but it seems workable)

I understand you are perhaps not interested in any of those three lines, and you want the situation fixed now and immediately. Unfortunately I am unable to provide that.

Let me repeat we are aware of the problem and we try to fix it as soon as possible, and we apologize for the inconvenience made.

Accepted.

[Banshee 9]

Yes. It it my own fault, my responsibility. And this is what I do:

- I apologize

- I do my best to fix the situation

- I try to find a temporary workaround (which currently seems to be using the Wine - not perfect, but it seems workable)

I understand you are perhaps not interested in any of those three lines, and you want the situation fixed now and immediately. Unfortunately I am unable to provide that.

Let me repeat we are aware of the problem and we try to fix it as soon as possible, and we apologize for the inconvenience made.

We totally understand that and just ask that it'll be handled better in the future. That's all what our bitching and moaning is about. At least from my side. :)

[pchaxor 0]

First off thanks Maruk, Dwarden, Suma and the rest of BIS for all your hard work on making Arma2 so great. So many years invested with you guys and I LOVE YOU with all my heart. Great people doing great things. HELLS YEAH!

Now for my rant ...

I think some of these people need to take a week off and go for a walk or maybe do some geocaching, hiking, camping maybe some metal detecting, go spend time with family or just take a freakin break from it. I think it would be good for us instead of the complaining and ranting. You know, the devs have to take time away to go deal with this crap in the forums instead of fixing the problem or spending time with their family... So big fuckin whoopie ... your server is empty, well you know what so is ours. Yes, we run Linux and we preach to all the players to not upgrade until the servers are updated, they know this and you should do the same. Its a few days; maybe a week, let them do their jobs and get it done and get it done right. I would rather shut my servers down for as long as it takes and go play some DayZ until it is ready for production than listen to another mother fucker cry and bitch about no linux server blah blah blah. If you don't like it and how shit works 'round here then get the fuck on. The community don't need cry baby ass bitches. :)

Sorry ... just irritates the shit out of me ... SHUT THE HELL UP ALREADY and let them get it done.

[JayC 0]

The clue is in the name: Wine Is Not An Emulator.

WINE simply translates Windows functions and calls to their Linux equivalents. It's like an API more than anything else.

Look, you obviously don't know how WINE works, so please stop misinforming people. You can learn how it truly works at WINEHQ.org.

Simply put, any speculation can be made as to the reason for this, but the important thing is that currently there is no native Linux server yet for this version (libraries are being updated), and currently WINE is a possible workaround. The Linux server will be released when it's ready. This has been stated by multiple devs, community representatives and the CEO :)

They can call it something else, but it's an emulator... as you said it translates windows api calls to linux api calls, which is a form of emulation...

WINE isn't a possible work around for the vast majority of these high end linux servers sitting in a datacenter with no ability to install WINE safely.

Most importantly, WINE is ALWAYS going to be slower than a native application.

[Kindling 1]

They can call it something else, but it's an emulator... as you said it translates windows api calls to linux api calls, which is a form of emulation...

I refer you to 'Wine is not that kind of emulator'. WINE is a library, just like any other - eg. DirectX or libc. Would you call them emulators? I don't think so.

WINE isn't a possible work around for the vast majority of these high end linux servers sitting in a datacenter with no ability to install WINE safely.

The phrase 'high end' doesn't have anything to do with anything. How can you prove a 'majority' of anything? And what does a datacenter have to do with anything? I run WINE on many servers that I colo in a datacenter. Furthermore, installing WINE 'safely' is easy - you download it and compile it, preferably verifying the code first yourself. Just as you would do for any other application. WINE is a professionally used, secure and stable library - just like many others.

The only case where installing WINE would be difficult is in a managed server scenario, where you don't actually have root access to the server (in which case you may still be able to install WINE if you can convince your admin to install the dependencies) or in a rented game server scenario, where you don't get any access to the internal system at all (in the case of many rented game server companies that provide services for BF3 and Activision's Call of Duty series). Neither of these categories would cover 'high end' or 'vast majority' as it's pretty clear that most admins are capable of renting or colocating their own servers in datacenters.

Most importantly, WINE is ALWAYS going to be slower than a native application.

Again, I refer you to 'Wine is not that kind of emulator', it states here that 'WINE can even be faster [than Windows]. This is because WINE provides alternative, open source functions that replace the Microsoft ones. With this kind of process, WINE's code is open to the public - many others can and have found ways to drastically improve performance in many areas, in some cases letting WINE's functions outperform Windows native functions.

And before you throw VMWare's name about, check 'Virtual Machines' - VMWare and it's equivalents emulate a full system, including hardware (they actually provide an extra layer of code or more between hardware and software) - they will always be inherently slower than WINE or Windows native because of this. VMWare in particular is also closed source - it does not open it's code to the public, so there is no way for developers to suggest fixes and optimizations that would increase the throughput of their emulator. I'd suggest, if you are looking down the emulation route, to use an enterprise-level hypervisor such as Xen (which, again, is slower than native but offers several advantages over VMWare by being open source and having the ability to use IOMMU to pass through physical hardware such as NICs to the VM).

I'm done with this 'argument'. Stop spouting inaccuracies and let's return to this topic at hand - complaining about the server or lack thereof doesn't help anybody, nor does attempting to deligitimize the only reasonable workaround with faulty logic and ignorance.

Edited July 27, 2012 by Kindling

[imago 1]

- I try to find a temporary workaround (which currently seems to be using the Wine - not perfect, but it seems workable)

It's working as well as can be expected. Here is what I did (abridged)

sudo add-apt-repository ppa:ubuntu-wine/ppa

sudo apt-get install wine1.5 xvfb x11vnc

winetricks xact

winecfg

copy my linux 1.60 arma2oa into the ~/.wine/drive_c/arma2oa folder

patch a windows box to 1.62

upload 7zs of the changed Expansion addons, dta and common addons and deflate them on the server, it was ~350MB upload IIRC

upload the exe and dlls in place from the windows box as well

sudo -u imago xvfb-run wine arma2oaserver.exe -world=Zargabad -cpuCount=4 -exThreads=0 -maxMem=2047 -port=2302 -ip=72.20.13.73 -config=zl.cfg -cfg=basic.cfg -name=server -BEPath=C:\\arma2oa\\zl -pid=C:\\arma2oa\\zl\\zl.pid -profiles=.

x11vnc -rfbport 6001 -display :99

at this point i was able to vnc to the box on port 6001 and interact with the the arma2oaserver.exe main window and console output

Thanks again BIS! I look forward to switching back to native binary whenever you get it squared away!

[Kindling 1]

It's working as well as can be expected. Here is what I did (abridged)

sudo add-apt-repository ppa:ubuntu-wine/ppa

sudo apt-get install wine1.5 xvfb x11vnc

winetricks xact

winecfg

copy my linux 1.60 arma2oa into the ~/.wine/drive_c/arma2oa folder

patch a windows box to 1.62

upload 7zs of the changed Expansion addons, dta and common addons and deflate them on the server, it was ~350MB upload IIRC

upload the exe and dlls in place from the windows box as well

sudo -u imago xvfb-run wine arma2oaserver.exe -world=Zargabad -cpuCount=4 -exThreads=0 -maxMem=2047 -port=2302 -ip=72.20.13.73 -config=zl.cfg -cfg=basic.cfg -name=server -BEPath=C:\\arma2oa\\zl -pid=C:\\arma2oa\\zl\\zl.pid -profiles=.

x11vnc -rfbport 6001 -display :99

at this point i was able to vnc to the box on port 6001 and interact with the the arma2oaserver.exe main window and console output

Thanks again BIS! I look forward to switching back to native binary whenever you get it squared away!

If you want a bit more of a minimal config, you can use the script here to compile a stripped-down version of wine suitable for running the server and use Xvfb to run it in the background (you won't have any access to the application, though - just stopping and starting).

[ast65 10]

huh, why was 95389- thread locked?

[gossamersolid 155]

huh, why was 95389- thread locked?

Maybe they found a big issue with that beta and they will be releasing a new one soon?

The thread being locked stopped me from downloading that beta because I felt like something was up.

[suma 8]

The beta is OK, seems like the thread was probably locked by mistake.

[pchaxor 0]

I think most of us Linux server admins are just going to wait to do it right.

WINE to me (opinion) seems like a coble job to get inferior code to run on a superior box at the cost of resources and possibly causing more issues that may result in a trip to the colo.

We are just going to have to stop WINE'n and wait for the real deal to be ready.(I am a funny guy heh?)

If BIS Devs need a few Linux admins to test an Alpha ... I have a box ready for testing. (I would rather be part of the solution than the problem.)

Edited July 27, 2012 by pchaxor

[imago 1]

If you want a bit more of a minimal config, you can use the script here to compile a stripped-down version of wine suitable for running the server and use Xvfb to run it in the background (you won't have any access to the application, though - just stopping and starting).

as far as i can tell, everything i just did as posted previously has a smaller footprint than what that script tries to do (and it works) I did however download that script before even attempting running arma2oaserver.exe on WINE as a reference, so all glory and honor go to the author of said script.

[Kindling 1]

as far as i can tell, everything i just did as posted previously has a smaller footprint than what that script tries to do (and it works) I did however download that script before even attempting running arma2oaserver.exe on WINE as a reference, so all glory and honor go to the author of said script.

It all depends on the dependencies of the WINE package in that PPA - if it depends on more data, it has a higher footprint. If not, it has a lower footprint. :)

[Lokyi 10]

Well, we don't have the ability nor inclination to install WINE on our server, so that rules that out. Having the latest ACE stuff now depend on 1.62 as well...

So now we just can't plain do anything. Dead in the water.

[Rubber Grunt.dk 10]

on the WASP-server I observe massive server lags/desyncs/player drops/yellow chain with windows 1.62-server, in fact it is unplayable. Does any1 else experience poor 1.62-server performance?

[imago 1]

after a couple days of this i've had to shutdown -r now the box once already - not looking good

is there a memalloc dll i am supposed to use when running 1.62 over wine?

[ringoray 1]

Yes. It it my own fault, my responsibility. And this is what I do:

- I apologize

- I do my best to fix the situation

- I try to find a temporary workaround (which currently seems to be using the Wine - not perfect, but it seems workable)

I understand you are perhaps not interested in any of those three lines, and you want the situation fixed now and immediately. Unfortunately I am unable to provide that.

Let me repeat we are aware of the problem and we try to fix it as soon as possible, and we apologize for the inconvenience made.

good enough for me, hope it gets fixed soon as I love ArmA and I have some degree of patience.

[IsamuMiyoji 1]

are you still working on the server? or did you shutdown the developing for it again?

[Dwarden 1124]

answer is here, this thread is now closed

http://forums.bistudio.com/showthread.php?138230-Linux-1-62-95577-alpha

[peppe 10]

Hello,

I have installed wine on a centos 6.3 64 bit ... but ... running with a wine arma2oaserver I obtain:

fixme:winsock:WSAIoctl WS_SIO_UDP_CONNRESET stub

Using wine from EPEL.

Any idea?

[Kindling 1]

Hello,

I have installed wine on a centos 6.3 64 bit ... but ... running with a wine arma2oaserver I obtain:

fixme:winsock:WSAIoctl WS_SIO_UDP_CONNRESET stub

Using wine from EPEL.

Any idea?

This doesn't matter, it's simply a message for debugging. The server will still run fine :)

[peppe 10]

This doesn't matter, it's simply a message for debugging. The server will still run fine :)

Hello.

Confirmed .. It works!

Edited August 6, 2012 by peppe

[peppe 10]

Hi,

is it possible to run wine without X? I try to use the command:

wineconsole --backend=user arma2oaserver.exe -config=server.cfg -cfg=arma2oa.cfg -name=playermod -port=2302

but I obtain this message:

Application tried to create a window, but no driver could be loaded.

Make sure that your X server is running and that $DISPLAY is set correctly.

Tnx

Edited August 7, 2012 by peppe