Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Community Reputation

1 Neutral

1 Follower

About Kindling

  • Rank
  1. It does, Roger, but the problem is that the function we require - D3D11CreateDeviceAndSwapChain - is within the base d3d11.dll which isn't provided by winetricks and doesn't work under WINE when copied from a Windows system (like many core Windows OS libraries). D3DX11 isn't provided in any redistributable, either, it's a core part of the Windows operating system from Windows Vista onward. I have tried to implement the function similarly to the currently provided workaround for EVE Online's DirectX 11 requirement, but this doesn't allow the game to launch and probably wouldn't have the game running if it did (many more DirectX 11 functions are likely required). The next potential issue after DirectX 11 is BattlEye - the BattlEye application requires a few functions that aren't currently provided by WINE and will need to be re-implemented from a 'black-box' or clean-room perspective to avoid infringing Microsoft's EULA. That's as far as I've been in considering ARMA3 support under WINE. To go forward, we need somebody to implement more of DirectX11 - Austin English's work seems promising in that direction. Alternatively, a native port of ARMA3 to Linux is required. I think we need to be wary about jumping to any conclusions from Gustavsson's interview, there - he's certainly interested in Linux as a platform, but I think that EA is more likely to sit in the background and watch for a while, yet. As they're directly competing with Valve in distribution, I'm betting that they'll be waiting to see if Linux becomes a more popular system or not before they jump to port anything, though perhaps they'll look at publishing some of their more obscure content under Linux to 'test the waters' (as BiS seem to be doing, themselves, with ARMA Tactics!). I could be wrong, of course, I've just become a little salty concerning promises of Linux support by now. That said, I hope that if they do port any games they do it natively. WINE is great as a way to run Windows binaries but it's been created only to translate Windows API calls to Linux ones - it's another layer between the hardware and software, another level of potential problems and performance issues. It still encourages the Windows 'way of thinking' and programming styles which are totally suboptimal under Linux. To get the most out of Linux, you have to port natively.
  2. @rogerx, D3D11CreateDeviceAndSwapChain: This is a known bug and it's due to a lack of DirectX 11 support in WINE. Currently, only the dedicated server application and (possibly) headless client application will run at all. @gagagu, missing dll: winetricks xact will work just fine, as will copying over a DLL from a Windows PC or (perhaps) going into winecfg -> libraries tab and adding 'xapofx1_5' as 'disabled'.
  3. Try: sudo apt-get install linux-image-extra-3.2.0-23-virtual sudo modprobe snd_dummy If you don't get an error, great - it worked! Hopefully that solves the dsound errors - the only crashes I've seen have been from BattlEye. If you do find yourself with occasional crashes (not so bad that it's unusable but bad enough that you find yourself having to check the server every few hours or so), you can try creating a wrapper script and cronjob. Something like: #!/bin/bash if ! ps aux | grep arma3; then cd /home/arma/.wine/drive_c/ARMA3 && wine arma3.exe -server -port=2302 fi After changing the switches and paths to your own configuration, add it to a cronjob with: crontab -e and add: * * * * * /home/arma/arma3.sh To have the ARMA3 server checked every minute and restarted if necessary. NOTE: If you want to do this, you'll need to use: winetricks nocrashdialog To disable the GUI popup on a crash, so the script knows to restart the server.
  4. @NoPlanB: I've added a link to your post on the OP, so you are free to update the script in the future! @Radioman: I know that you're saying that you disabled the firewall, but what does 'iptables -L -v' give you? The client will favour servers that are geographically close, with low latency. Can you connect directly using the IP? Also, have you checked your server configuration to ensure that you are connecting to the correct master server? Can you ping that master server from your own server? In the case of the snd_dummy not found error, are you actually receiving any ALSA errors? Are you using a custom-configured kernel? If not, what version kernel are you using ('uname -a')? What are the contents of '/lib/modules/`uname -r`/kernel/sound'? Can you run 'find /lib/modules/`uname -r`/kernel/sound -type f -name snd-dummy\*' and provide the output, if any? Also, the output of 'zcat /proc/config.gz | grep SND_DUMMY'? If your kernel is customized, then you'll have to build with CONFIG_SND_DUMMY=y or CONFIG_SND_DUMMY=m (preferably the latter, if you don't want a permanent fake sound card).
  5. What filesystem are you using? Are you sure that all the files are correct and that integrity is preserved? I'd attempt to create a prefix under an NTFS or FAT32 partition and see if you still get the error, after 'verifying files', of course. Otherwise, it might be worth looking into: File/directory permissions Directory names - check that you don't have a mix of lower/upper-case directories or files mixing up WINE. It doesn't really care about case, but you never do know. Possibly use the small C program included with the ARMA 2 Linux dedicated server or your own script to rename every file and folder to lower-case only. WINE drive mapping - C: should be the prefix root, Z: should be your BSD root. Make sure that they exist in the WINE registry or through winecfg and point to the correct directories, make sure that the path to ARMA isn't ambiguous in Windows directory syntax (eg. no 'strange' symbols, nothing that could cause crazy escape string problems).
  6. @barry100: I've tested the steps on a 'clean' Ubuntu install, and it works just fine for me. You shouldn't need any other packages - xvfb provides a minimal X11 configuration. @Comp_uter15776: BE has a few issues under WINE, though I've not seen that particular issue but this bug report contains patches for both Ubuntu Precise and Quantal for a similar issue. It seems to be fixed in Raring, so you may wish to look into upgrading if the server is only used for A3. @Otoris: This could be anything, really - it's a very low-level issue. Do large Linux applications work fine? If you're getting crashes with other applications, use memtest86 to check your RAM and a stress-test tool to ensure that your processor isn't failing. Otherwise, it's probably something wrong with WINE - remove it and re-install it, preferably from a different source. @NoPlanB: Thanks, I'm sure that this will be very useful for others. Do you mind if I add it to the original post? @gagagu: Debatable. Certainly, Linux tends towards minimalism and light-ness in comparison to Windows and the modularity of Linux means that applications are each optimized for their specific purpose (Linux application philosophy is 'do one thing, do it well') - on the other hand, the code was written for Windows, not WINE. The WINE group are doing as much as they can to enable Windows applications to be run under Linux and there have been many cases of applications running especially quickly, and also occasions of applications running especially slowly - or not running at all. Mileage will vary as almost every application under a Linux system is highly customizable and configurable, so I'd suggests looking into Linux optimization if you'd like to get the most out of Linux and WINE applications alike. @icedragon64: Make sure that you're specifying all the paths correctly when you launch ARMA 3 (Windows-style switches as seen in other threads and relative to the directories as WINE sees them). You also might look to verifying files under Steam for ARMA 3 and adding missions, as you mentioned. @warezit: You'll need to 'killall Xvfb' to stop any running xvfb processes - you'll want to 'killall x11vnc', too. Restarting will also terminate those processes. It sounds like Steam may be waiting for your input - try logging in through VNC once you've got it running and have killed the previous processes - I believe you'll find a dialog box or further information on-screen. Thanks for the corrections, I've modified the OP as appropriate.
  7. Hi there Sacha, you're saying that the statistics returned by the application are incorrect when the ARMA server is run through WINE and this client application from Windows? Can you run the ARMA server under WINE with logging enabled and use this application to attempt to retrieve statistics again? To enable logging on Linux, append '2>&1 > logfile.txt' to the 'wine ...' command you use to run the server - you can message me a link to the log file saved on Pastebin or similar and I'll see what I can deduce. Unfortunately, I can't really do any testing of my own at the moment.
  8. It should be possible to run multiple servers under different WINE prefixes using Linux - I've added a short note about this to my topic. I hope others find this useful.
  9. Running multiple concurrent ARMA 3 installations under different WINE prefixes using WINE should also be possible. Each WINE prefix is a new Windows installation as far as any programs resident in the prefix are concerned and WINE has much, much less overhead than any L1 or L2 VM software (such as KVM, VMWare or Xen that emulate a whole physical system or OpenVZ that runs multiple Linux instances under a single kernel).
  10. It's difficult to troubleshoot this kind of issue - have you noticed anything odd in your WINE or server log? Have you checked iostat, vmstat, ntop and such output during the desync to ensure that you're not facing a performance bottleneck with CPU, HDD or RAM/swapping? If not, it's probably not a WINE/Linux issue (in which case you should search the forums or create a new topic). Also, be sure you don't have anything you don't need listening for connections (netstat will show you listening ports), have a look at the firewall (note 'dropped packets' in iptables -Lv and ip6tables -Lv) and generally make sure the problem is not due to your server connection or latency.
  11. winetricks nocrashdialog as noted in the WineHQ FAQ. If that doesn't work, make sure that you have the correct prefix activated (export WINEPREFIX=/home/arma/.wine for example) and try it again.
  12. It's happy with a fairly minimal set of dependencies - check my ARMA2 WINE server install script, I'm pretty sure that build will work happily with the ARMA3 server app (though I've not tested that yet). You do need some sort of X server to render the application window but I'm sure you'll find that xvfb is very light.
  13. You'll have to use Windows paths for the profile directory - all the options, configs etc should be in a Windows format. Instead of -profiles="/home/username/Documents/Arma 3 Alpha/username.Arma3AlphaProfile", use -profiles="C:\Documents and Settings\Username\My Documents\Arma 3 Alpha\username.Arma3AlphaProfile" for example. C: refers to the folder /home/username/.wine/drive_c and you can use 'winecfg' to add new drive maps, effectively allowing you to alias any folder as any Windows drive letter if you'd like WINE to have more access over different locations. And yes, saro is absolutely right - you need to be using at least WINE 1.5.x (I've only tested with 1.5.24 and up). You might have trouble with stable LTS-class distros like CentOS, Debian Stable and RHEL as they may not include support for the latest library versions that WINE 1.5 requires - in this case, it's possible to either separately install the up-to-date libraries to /usr/local or bootstrapping another distro into a chroot, perhaps Debian Testing/Unstable with debootstrap or a chroot install of Funtoo but I don't suggest this unless you're an experienced Linux administrator. It's much easier to simply try a different distro or update to a 'testing' release if outdated libraries are an issue, though of course this can cause other issues.
  14. Kindling

    ARMA2/OA/CO/Demo/Free/TOH on WINE/Linux!

    Yes, that'd work - I don't see why it doesn't recognize your mouse though - that advice no longer applies since rawinput is included with the latest versions of WINE. In PlayOnLinux, try going to Configure button > (select your virtual drive) > General tab > Wine version and choosing wine-1.5.27-linux-amd64 instead of System or whatever version you have selected.