facoptere

The following link helped me to compile Wine 1.5.27 on Debian "testing" (sid) : http://verahill.blogspot.fr/2013/04/376-wine-1527-on-debian-i386-chroot.html I had several problem before I found this tutorial (freetype font problem, several mission dev packages...)... A real PITA indeed. Then: 0/ create basic X11 env with Xvfb and x11vnc: export DISPLAY=:68 export XAUTHORITY=$PWD/Xvfb_xauth xauth -f $XAUTHORITY add $DISPLAY MIT-MAGIC-COOKIE-1 $(cat /dev/urandom | tr -c -d 0-9a-f | dd bs=1 count=16 2>/dev/null) Xvfb :68 -auth $XAUTHORITY -fbdir var -s 1 -noreset -nolisten tcp -screen 0 800x600x16 & blackbox -display $DISPLAY >/dev/null 2>&1 & x11vnc -listen (myip) -display :68 -auth $XAUTHORITY -noxfixes -q -passwd changethis & 1/ remove previous .wine folder used for dayz/arma2/wine1.4 rm $HOME/.wine 2/ create a pseudo windows shell. winecfg 3/ same winetricks as for DayZ (maybe optional...): winetricks --no-isolate corefonts sound=disabled tahoma gecko vcrun2010 (hint: If you got "unable to find a volume for file extraction", then you really need to remove .wine folder and redo winecfg) 4/ install steam & arma3: winetricks --no-isolate steam (note: MPMissions is empty. This is not an issue if you want to run default Stratis missions) 5/ create a directory structure for your server config files: C:\cfg (aka $HOME/.wine/drive_c) ├── ArmA3AlphaOA.cfg (contain netcode/timezone parameters, similar as Arma2) ├── arma3_2013-04-10_17-34-37.rpt (autocreated by the server) ├── server.cfg (contains server name, motd, mission name... similar as Arma2) ├── server.log (will contain connection logs) └── Users ****** └── server ****** ├── server.ArmA3AlphaProfile (contains difficulty profiles) ****** └── server.vars.Arma3AlphaProfile 6/ go to "$HOME/.wine/drive_c/Program Files/Steam/SteamApps/common/Arma 3" folder, then enter: wine arma3.exe -server -ip (my IP) -port=(my port) '-profiles=C:\cfg' -name=server '-cfg=C:\cfg\ArmA3Alpha.cfg' '-config=C:\cfg\server.cfg' -world=Stratis ArmA3Alpha server seems to work with this setup. I died in few minutes :)

sorry, it's a typo. I tried __EVAL and not __EVAL__

I try to use __EVAL and __EXEC in sqf files. when I write: w = __EVAL__(1+1); Preprocessing does not work for __EVAL and the following is displayed: 2013/04/03, 18:11:08 Error in expression < w = __EVAL(1+1); 2013/04/03, 18:11:08 Error position: <(1+1); Are __EVAL and __EXEC limited to some file types?

Version 1.62.101144 According to h t t p : / / community.bistudio.com/wiki/ArmA:_Event_Handlers#GetIn, "GetIn" EH should have the vehicle object as first element of _this, but in fact the player object is present. There is no such bug in "GetOut" EH. PoC: if _x is a vehicle, if you add these 2 EH: _x addEventHandler ["GetIn", { diag_log(format["GetIn debug: %1",_this]); }]; _x addEventHandler ["GetIn", compile ("diag_log(format[""GetIn workaround: real veh is "+str(_x)+" but GetIn gives %1"",_this]);" )]; In RPT you will see: 2013/01/24, 17:05:18 "GetIn debug: [b 1-1-C:1 (Vador76) REMOTE,"driver",B 1-1-C:1 (Vador76) REMOTE]" 2013/01/24, 17:05:18 "GetIn workaround: real veh is 17f390c0# 1055355: hilux1_civil_3_open.p3d but GetIn gives [b 1-1-C:1 (Vador76) REMOTE,"driver",B 1-1-C:1 (Vador76) REMOTE]" As you can see, the player is twice in _this, and there is no reference of the vehicle. On the second addEventHandler, the handler is compiled at runtime and so vehicle can be hardcoded. It's ok for logging, but you can't code anything smarter since you don't have vehicle object handle.