bravo1romeo

No Crash dumps. Yes, had a dsound.dll, removed it. Launches and runs OK now, can't believe I didn't think of that.

Installed 1.60 RC2 from 1.59 manually updated ArmA to 1.11 as per instructions. 1.60 87147 Crashes on launch with the message: ArmA 2 REINFORCEMENTS has stopped working. 1.11 86734 Crashes on launch with the message: ArmA 2 has stopped working. Both crash after about the 3rd tick on the loading bar. Installed the Beta 1.60 87136 Beta launches and runs fine. Running on a laptop P170MHx i7-2720QM 8GB RAM GeForce 460M (drivers 8.17.12.8562 15/OCT/2011)

Since 1.59 BI seem to have removed the 'serverCommand' command in order to stop misuse of it by those who do not have admin rights. The problem now being I have several custom programmed mods on my server which do things automatically such as kicking players who run ace on a vanilla server, kick players who do excessive friendly fire, kicking players running banned mods, etc. These mods run server side only, I have tried serverCommand "#login *password*" before issuing the serverCommand "#kick *playername*" have even tried serverCommand "#exec kick *playername*" but it seems as though it has been disabled completely. Are there new restrictions on the command or does it no longer work at all? I really don't want to have to enable verifysignatures to kick people using banned mods, because there are a lot of 3rd party mods which the general (behaving) public like to use on the servers and finding out every one of those mods and getting the server key for them is going to be a very long and pain in the ass task.

Yes they are included and all BI pbos use the bi.bikey so client side files auth regardless of what the server side ones are.

The issue is the Update Patchs are for windows, and they patch the .pbo files with updates, but there is no equivalent patch for linux! So to update linux I have to first update on windows, which is quick and only requires downloads the size of the patch ~300MB But then I have to upload to my server, every file which has changed in it's entirety, which last time equated to over 4000MB of uploading and since my upload rate is much lower than my download rate it took me almost 20 hours to get my server updated! Can't a similar .pbo updater be released for linux so I can just execute it from ssh?

set the logFile="server.log"; command in your config and go through the logs, it should show errors for mods being loaded.

put the obj's in an array objarray = [obj1,obj2,obj3]; then pass the obj number (0, 1 or 2) to the script, then use: waituntil {(objarray select _objective) >= 2};

If you want to set the 'billboard' texture on a sign. Simply place the kind of sign you want to use in the editor from: Empty -> Objects (signs) and then in the init place: this SetObjectTexture [0,"pathtotexture.paa"]; place your texture in the mission folder, jpg can also be used. They work in multiplayer and the is no need to go pulling apart pbos etc.

Waiting on the linux 1.55 for our dedicated servers I'm starting to have withdrawal

It has changed the filetype to open with arma2. Depending on your operating system, You can remove it using some of these steps: http://www.annoyances.org/exec/show/article02-500 and then run cpbo again. Or what I do is open regedit, search for and delete all folders named exactly ".pbo" and then run cpbo again.

All characters within the arma2 directory in linux must be lowercase. This is because in linux upper and lowercase are treated as completely different characters, 'A' is not the same as 'a'. Where as in windows 'A' is the same as 'a' when it comes to filepaths. If you have any uppercase characters the game will not load the files and probably crash. Also the mod loading string needs escape characters between semicolons: -mod=@mod1\;@mod2\;@mod3

Issue is resolved, It wasn't to do with BAF. The host was wrong.

Released on armaholic, should work with all artillery; M119, D30, mortars etc, Would probably even work on a tank but I haven't tried. http://www.armaholic.com/forums.php?m=posts&q=10819&n=last#bottom

I have been searching everywhere as to what defines the owner of ammunition class objects. I think it's some kind of ownership variable set to the ammo object when it is created by whichever weapon/muzzle from whichever player. For example, if I place a satchel, and when the satchel is detonated, it kills an enemy, the game knows that satchel belonged to me and my kill score increases respectively. However if I just spawn a satchel and detonate it, the killer will be <null-object> Same applies with bullets / rockets / shells etc. Is there any way of setting the ownership of an ammo class object which is spawned manually?

In that case, I've come up with a workaround. By creating a special weapon class in which you can load any magazine. firing the weapon with the 'useweapon' action teleporting the ammo to desired location, and then removing the weapon from the player. Anything destroyed / killed by the ammo counts as kills towards the player

I have found some strings within the game exe: objectCreator, Creator, magazineCreator I think they may be related however I have no idea what commands to use or how to access them.

Was referring to the BIS artillery module. Load the module in and an artillery piece and attach a camera, you will see.

I have an artillery system where the kills count as the operator of the cannon. The BIS system seems to delete the shell after firing and create a new one over the target. It would be great if the ammo objects actually contain a variable which is the 'owner' which can be retrieved and set using the getVariable and setVariable commands. Only have to find out what the variable name is. Maybe a BIS programmer can shed some light on it if they ever find this thread. Interesting theory on the 'wtf' moments. I ran a test to see by detonating one of my satchels near an enemy, whilst in plane sight of them, at a range just under 300 meters. The enemy hit the deck but then soon declared 'clear'. And continued to scan the area. I then fired a few shots into the air and that got his attention and he alternated between looking at me, and scanning. But I still appeared as unknown to him. It wasn't until I actually shot at him and the bullets landed near him that he identified me as enemy. Closer range may be a different story though.

If your trying to track where the shell came from I't would be easier to just note which vehicle fired the shell, then mark it's position if the shell lands near the unit which you want to track it. PM me if you wan't me to work on some code. On a side note I have tested my map aiming script. It provides several advantages over the ingame module: Kills actually count as yours when they impact. (the module seems to delete the projectile and respawn it resulting in kills not counting.) Calculates both high and low trajectories Takes into account, air resistance, ground topography, height of your howitzer ASL. (unlike the module where you have to reference your height vs target height) Can be used on any projectile weapon, such as Tanks and Grenade launchers.

I have been messing about with vectorUp and vectorDir. Here's a way to try get your head around it. There is a cube around the vehicle, the center of the cube and the center of the vehicle are [0,0,0]. The cube is a World Cube.. It does not rotate in repect to the world, the vehicle rotates within it. The red line is vectorUp, the point at the end of the red line is the coordinates within the cube that the top of the vehicle points to. The Blue line is vectorDir, the point at the end of the blue line is the coordinates within the cube that the front of the vehicle points to. The game will return the coordinates of the point which is a distance of 1 from the center. However you can set coordinates which are any point along the vector and it will result in the same angle.. Eg: [0.2,0.4,0.4] is the same as [0.4,0.8,0.8] you can set vectors outside the box with numbers greater than 1 but when you work with sine and cosine you will end up with the same results the game calculates anyway. The vector coordinates should be 90 degrees from each other always, you can set them so that they are not and the game will calculate based on where the vector would be if it were to swing to 90 degrees, but you may get results you do not want so it's easier to calculate them to be 90 from each other anyway. One way to do this is to calculate vectorUp first, then calculate vectorDir so that the point lies on the circle which is shown in the image. For example, to set your plane flying 90 degrees up in the air with the belly facing North East (the direction it would be flying before pulling up) vectorUp = [-1,-1,0], vectorDir = [0,0,1]. Flying sideways towards North West vectorUp = [-1,-1,0], vectorDir = [-1,1,0]. Note that in each example vectorUp is the same, because the top of the plane is facing the same point, but vectorDir is different because the nose is pointing elsewhere.

You can make a bulletcam using switchcamera and a very simple code. In the vehicle / unit init: this addEventHandler ["fired",{nearestObject [_this select 0,_this select 4] switchCamera "EXTERNAL"}] To get camera back to player create a trigger, replace 'this' in activation with: ! alive cameraOn and then in On Act.: vehicle player switchCamera "INTERNAL"; Make sure you set the trigger to repeatable. Does not require calling an external script, can be done completly in the editor. See my video:

Neglecting air resistance will result in incredibly inaccurate results. the velocities of objects can be obtained with the velocity command. I'm working on a artillery - map aiming script, the maths is very complex. I pulled apart some binaries and found the value used for Air resistance on the M119 shells is 0.00045 and they are fired at 850 meters per second. Using projectile camera chase scripts I have found that Tank shells actually travel much further than the Howitzer shells in the game (talking KM here), and in the binaries I found tank shells to have air resistance set to 0.00004. The force slowing the projectiles is F = V² x R Where V = velocity, R = air resistance. Still working on the maths. NouberNou what exactly are you trying to track shells for, I don't quite get what your trying to achieve, there may be an easier way.

autohover action is: unitName action ["autoHover", vehicleName] vehicleName can be set as: vehicle unitName eg: unitName action ["autoHover", vehicle unitName] ofcourse replace unitName with the name of the pilot HOWEVER: autoHover will only work with human controlled players, not the AI. IF an AI is in control of a plane, and it is not flying, the AI will try to taxi to the airport and take off from the runway, they seem to want to do this even if you use the disableAI command. This is why if you put a plane on the carrier with an AI it will happily turn and taxi off the starboard side. You can get the effect of an AI controlled plane launching off the carrier with a script which gradually changes the velocity of the plane until it is off the end of the carrier and then you leave it for the AI pilot to take over, you can do this with the A10 even though if you try to take off from the carrier manually yourself in an A10 you wont get the speed in time and you will crash, think of it as a 'catapult' script. The same script method can be used to launch a plane like the F35 or AV8 vertically, however without the nossels pointing downward it just doesn't feel right. I've tried to script the thrusters downward using the animation command, I pulled apart the config.bin for the F35 and found an animation reference to "vtol" but using the command: f35 animate["vtol",1]; (or 0) doesnt seem to do anything to the f35. (yes I have named it f35 I've checked the basics). unlike the MV22 where the pack script calles on a similar reference: _mv22 animate["pack_engine_1",_phase]; using the command: mv22 animate["pack_engine_1",1]; (with an Osprey named mv22), will turn the left engine forward, and mv22 animate["pack_engine_1",0]; will turn it upwards. using "pack_engine_2" will do the right side engine. and calling the script with: _handler = [mv22,1] execvm "\ca\air2\mv22\scripts\pack.sqf"; fully packs the Osprey, _handler = [mv22,0] execvm "\ca\air2\mv22\scripts\pack.sqf"; fully unpacks. But no luck for animation for the nossels on the F35. Maybe somone from BIS can hint us as to what animations to call or even how to force an AI into VTOL mode.