nomdeplume

I think some of the animations aren't interruptible by the game generally, but just in case: are you using disableAI "ANIM" before playing your anims? If so, disabling that might allow the unit to die right away, but might also cause other problems. Assuming that's not a solution, all I can think of is watching the state of the unit and doing switchMove "" to cancel the animation when the unit is killed. Either polling with something like _sleepto = time + 10; waitUntil { time >= _sleepto or damage myCharacter >= 1 }; if (damage myCharacter >= 1) then { myCharacter switchMove ""; }; Or you could perhaps add a "Killed" event handler to the unit and re-enable its normal animation processing there. Of course... I'm guessing that switchMove "" will actually make it behave normally again, so you might want to assign that to a radio trigger or something easy just to test, i.e. shoot the unit 'til you're sure it's dead, then activate the trigger to see what effect switchMove "" has.

I wish I could test this before posting, but ... Normally when playing I only have the option to move to an already-occupied position if that position is held by an AI in my command. So, is it possible for the (AI) driver of the vehicle to be not under the command of the players? I could be completely off track here, so apologies if I'm making things up.

I'm at work at the moment so I can't upload an actual demo. If nobody else does beforehand I will do when I get home tonight. SQF script should look something like: _camera = "CAMERA" camCreate [3586.29,3521.55,21.17]; _camera cameraEffect ["INTERNAL", "BACK"]; _camera camPrepareTarget [-53999.71,-54233.82,57903.27]; _camera camPreparePos [3586.29,3521.55,21.17]; _camera camPrepareFOV 0.034; _camera camCommitPrepared 0; waitUntil { camCommitted _camera }; _camera camPrepareTarget [-64971.27,66001.25,-37325.42]; _camera camPreparePos [3586.29,3521.55,21.17]; _camera camPrepareFOV 0.677; _camera camCommitPrepared 10; waitUntil { camCommitted _camera }; _camera camPrepareTarget [-64567.47,46601.25,-37325.52]; _camera camPreparePos [3582.59,3521.55,21.17]; _camera camPrepareFOV 0.670; _camera camCommitPrepared 10; waitUntil { camCommitted _camera };

titleCut doesn't need anything in front of it, but the wiki page also says that it's obsolete and to use cutText instead. So perhaps try with that. Re: attachTo, I just meant you should check to make sure having the camera previously attached is actually the reason it's bobbing up and down afterwards when you've moved it (detached it). I get that bobbing effect even if I've never attached a camera to anything, if its target is a walking person.

If it's changed, then why are all the camera commands still the same since Operation Flashpoint, i.e. the game before Arma 1? :) For example, here's a thread on the forums from 2002 which you'll see is remarkably similar to what's been discussed here. Are you running your own script with "exec" or "execVM"? If you're using exec, then your script needs to be written using the SQS syntax. It's what camera.sqs will generate to the clipboard, so it's common to use that for cutscenes even if you normally use SQF for everything else. However, the camera.sqs also adds the @camCommitted line, so since you've been missing that all along SQS has a few differences to SQF, most notably with how it does branching and looping. But for a simple linear script like most cutscenes use, the only interesting differences are: SQS is line delimited, that is, each command has to be on its own line. SQF is semi-colon delimited, i.e. each command has to end with a semi-colon, and newlines are just aesthetic. SQS uses "~seconds" for a sleep, while SQF has a function called sleep. SQS uses "@condition" to pause the script until "condition" evaluates as true. SQF has the waitUntil command to achieve the same effect.

Try getting rid of your attachTo temporarily - I'm pretty sure you'll see the exact same result. The character animation itself bobs up and down, and if you're having a camera target a person, then its target point will bob up and down as well. Probably better to target it at a static position instead.

The camera stuff is the same in both games. Why would you think your script would have the camera pause between positions? What's there to tell the script not to immediately move to the next lines of code, thus repositioning the camera? Normally one puts either a fixed delay using "sleep 5;" (for SQF) or "~5" (for SQS) after each camCommit 0 or camCommitPrepared 0. One also normally puts either "waitUntil { camCommitted _camera };" (for SQF) or "@camCommitted _camera" (for SQS) so the script will halt processing until the camera has finished moving to the new position - that's for the lines you're using a delay in the committal time. Pretty sure that'd be explained in that video Gladius linked to... again, nothing's changed in Arma 2 here, it's all the same stuff, there's no reason to do Arma2-specific camera tutorials.

Yep you don't need to destroy or specifically detach the camera, just moving its position somewhere else with camSetPos or camSetRelPos is sufficient. If you do for some reason create a new camera, you need to use cameraEffect for it to become "active".

Have you added -showScriptErrors yet??? From that snippet, you're mixing a global variable (Bman) with a local variable (_Bman) - unless you're defining _Bman somewhere that's not going to work, and even if you are it's a bit confusing using two different names for (presumably) the same object. And if they're different objects, then that's even more confusing. :) Also, your attachTo is missing a ]. Finally, you need to commit the camera for some of the things to take effect. _cam camCommit 0; to commit immediately. I think the setRelPos is redundant (either use attachTo or setRelPos, not both - depending on the effect you're after). I think this one does what you want: _cam = "camera" CamCreate (getPos Bman) _cam cameraeffect ["internal", "front"]; _cam attachTo [bman, [-0.25, 0.5, 0]]; _cam camsettarget Bman; _cam camCommit 0; though you probably want to move it a bit further away.

For HALO (start free-falling, option to open parachute when you want, steerable): [this, 3000] exec "ca\air2\halo\data\scripts\HALO_init.sqs" in the unit's init field. Change 3000 to the altitude you want it to start at. For a regular parachute that's steerable, you need to create a vehicle of the type "BIS_Steerable_Parachute", which I don't think is present in the editor anywhere. Then you need to move the player/character into the gunner position (charname moveInGunner paraname). Below is the HALO_Parachute.sqs script which is run by the HALO script above when the player selects the "open parachute" option. Some of it deals with the blur effects and so on, but you can see the code you'd need after the "give steerable parachute" comment.

Can you post the script (or a representative portion of it) that you're using for the camera? "the normal ArmA I script" doesn't mean much to me... Re the modules, are you running the current patch (1.05)? My memory could well be faulty, but I think maybe one of the first released versions of ArmA 2 didn't include the modules thingy in the editor.

It'll depend on the commands used of course, but for the most part they should work. Arma 2 has some new scripting commands, but pretty much all the old ones should work as they did in previous versions of the game. There's also changes related to content, so if you're using a script that adds Arma1 weapons to a unit, then it probably won't work since some of the weapons may not exist in Arma 2.

Scripts run with exec or execVM are run in parallel with other scripts, i.e. the calling script doesn't wait for the script that was run to finish. So you're running both scripts simultaneously, which may result in strange things happening depending on what they do. For a GET IN, you'll probably need to use "assignAsCargo" before you order them to get in, otherwise they won't get in anything. Alternatively, you might be able to use one of the functions to attach the waypoint to the vehicle so they know which vehicle to board... but I think assignAsCargo is just as easy, anyway. i.e. at a "GET IN" waypoint, the group will mount whatever vehicle they have been assigned to get in using one of the assignAs... functions. You can place waypoints on top of objects within the editor, but I've never really trusted that myself.

A group is a type of object in the game which represents a group of units who share a common leader. i.e. if you put units on the map and use the group mode to link them, they're all one group. You use the group unit command to find which group a particular unit belongs to. You can either assign a global variable to the group and reference that in scripts - useful for player squads and other "special" groups that you frequently manipulate in your scripts. Alternatively, you can find the group of a particular unit whenever you happen to need it. Some commands will require a group object to work, otherwise require a unit object, and others will work with either. In your example, if you change the first line to _wp = (group jimmy) addWaypoint [position player, 0]; he should then come to you. If you're frequently manipulating or interacting with a particular group, it's good to assign it to a global variable at the start of the game. You can do that by putting mygroupname = group this; in the init field of one of the group members. Just remember that if you set a unit's probability of presence (or condition of presence) such that it's not always present, its init code won't be run if it doesn't exist. So you should put this in the code for a group member which will always be present in the mission. By convention, one usually uses the group leader, but it'll do the same thing if it's run by any unit which is a member of the same group. After you've done that, you can just use "mygroupname" to refer to that group anytime.

Well, you need to use a script whenever you can't do something with the editor, or it'd be too cumbersome/inflexible/annoying to do it in the editor. Where that line lies depends on your own personal preferences; I'm comfortable with programming in general so I generally go to scripts pretty early, and only use the editor for basic things. Scripts suit my way of thinking about things better than the editor UI usually does; but for other people it's the opposite, and they'll try to find solutions using the editor's tools. As to where: probably in your jump.sqs (you'll need to change it to SQS syntax though - in this case, simply removing the semi-colons from the ends of the lines should be all you need to do), but the more general answer is "you run the script when you want the commands the script executes to take effect". Most often you'll invoke scripts from triggers, as in-game triggers can provide a very nice starting point; or from init.sqf. Yes, the _wp variable name is arbitrary and could be _pizza or whatever. Obviously _wp in my head is short for "waypoint" - it's best to use meaningful names, or it can be very difficult to work out what your script is doing even if you were the one who wrote it. The _ means it's local and only exists within that script, and since we don't need/want to reference it anywhere else that's a good thing. But other than that the name is up to you. Also in the first one, "position _veh" gets the position of a vehicle which has been assigned to a local variable called _veh; and _group is a local variable referencing whatever group it is that you want to move. So you'll have to assign them somehow. If you want to try with "GETIN NEAREST", then I'd change the first line to _wp = _group addWayPoint [position leader _group, 0]; so they try to get in a vehicle at their present location.

You'd have to check the ACE2 docs I suppose. They do have this list on the Biki: http://community.bistudio.com/wiki/Class_Lists_for_ACE2 but it doesn't seem to contain information about vehicles. Within the game, you can use (in the init field) diag_log weapons this ; diag_log magazines this to get a list of the weapons and magazines on the unit written to the ArmA2.RPT file, and you should be able to work out from that which ones you want to re-add. So that's a more general solution.

I would use a script to add the new waypoint. The code generally looks something like this: _wp = _group addWayPoint [position _veh, 0]; _wp setWaypointType "GETIN"; _wp setWaypointSpeed "FULL"; _wp setWaypointCombatMode "GREEN"; _wp setWaypointBehaviour "CARELESS"; _wp setWaypointCompletionRadius 5; _wp = _group addWayPoint [position player, 0]; _wp setWaypointType "MOVE"; _wp setWaypointSpeed "FULL"; _wp setWaypointCombatMode "GREEN"; _wp setWaypointBehaviour "CARELESS"; _wp setWaypointCompletionRadius 5; Have a look at the biki entries for each, but presumably you've used waypoints in the editor so it should be pretty straightforward. The trickier part will be getting units to get in the nearest vehicle. There is a waypoint type "GETIN NEAREST" which might do what you want in certain situations. Otherwise if there's particular vehicles you want them to use, you might need to assignAsCargo and then order them to get in it, possibly after checking first how far they are from it and whether it's still usable (canMove).

In the unit initfield, removeAllWeapons this; will remove all of the weapons from the unit. Then you can add back the weapons you want, e.g. for a AH-1Z: removeAllWeapons this; this addMagazine "750Rnd_M197_AH1"; this addWeapon "M197"; Within the editor it'll all need to go on one line, since you can't insert linebreaks into the editor dialog. But it'll still work (the semi-colon marks the end of statement, new lines are just for readability). You can find a list of weapons here.

What is _cam? Don't you need to create cameras first using camCreate? Telling a non-existent variable to "camSetTarget" some guy doesn't sound like it would achieve very much.

unit setUnitPos "DOWN"; There's also "MIDDLE" (for crouched) and "UP" (for standing).

Strange, I didn't forget to injure my character but didn't get the healing option from the warfare hospital. Though maybe they're faction-specific? I was a civilian and I think I put a Russian one down. Never mind then, glad it's working.

"Any" is pretty much a synonym for "undefined" - after the loop is finished, _guncount is no longer in scope and won't have any value. I'd move that hint up to within the if (_guncount > 0) statement block. I think binoculars and some of those other items are considered "weapons" (i.e. you use addWeapon to add them), so it's very likely weapons will always be returning something. You can find a list of equipment types at http://community.bistudio.com/wiki/ArmA_2:_Weapons#Equipment Maybe change the _guncount line to _guncount = {not (_x in ["Binocular", "ItemCompass", "ItemGPS"])} count _guns; and add any other items the player is likely to get to that list. while {(!hwep)} do is correct syntax. The ()'s aren't strictly necessary but don't hurt.

It's probably quite rare that that happens. You could prevent it from breaking the mission by making sure you check whether you actually got an object back from "nearestObject", i.e. bldg = (position this nearestObject nnnn); if (not isNull bldg) then { bldg setHit [...] }; That way if the building magically disappears in a later release, your script will just disregard it. Or alternatively damage one in some other location on the island. Of course, even if it isn't found, the only script that might fail to run will be that particular one which probably doesn't do anything else.

Probably the best place is to report it via CIS at dev-heaven - it's a community-run issue tracker that BIS' developers do actually use. You could also try posting a concise and clear description of the problem in the troubleshooting forum here.

How strange... it does indeed work fine. It doesn't work if you try to play it in the unit's init field, but that doesn't explain why it didn't work in my previous attempt where it was cycling through animations using a radio trigger and switchMove. You do need to disableAI "ANIM" first, which I had done... so I don't know. Maybe previous animations that were played had confused its state? This one works fine with both playMove and switchMove.