Big Dawg KS

This one has me confused. Double-click doesn't work ingame, at least for most of the time (I've gotten it to work like twice so far, but no idea how). My click speed is fine (pretty fast if I do say so myself), so I dunno what's going on. As most of you know, double-click is needed to place units in the editor... so I wouldn't call it just an annoyance. Anybody have any thoughts?

Aside from the thermal and maybe the IR lasers, the technology behind all of these features in ArmA are not based on VBS. In fact, gestures came from ArmA first.

Here is an update to this script due to a few requests. Changes from previous version (1.0): -Added following global variables (uses can be found in comments): BDKS_BulletCamNoBlur, BDKS_BulletCamFOV, BDKS_BulletCamAccTime, BDKS_BulletCamNoParticleFX -Added BDKS_ShowBulletCamToPlayer unit variable (see comments for use) -Added particle effect (nothing too fancy, I like it but I'm open to suggestions) -Added ability to terminate bullet cam in flight with key for ironsights/optics -Added blackin/blackout effects for smoother transitions -By default, player only sees bullet cam when he fires (see BDKS_ShowBulletCamToPlayer) -Added check to abort cam script if projectile not found Untested in Multiplayer. MP behaviour unknown. See comments for more info. Show spoiler for code Download cam.sqf v1.1 @ dump.no (thanks kju, can't even access rapidshare here at work anyway)

It's about time I release this. PMJqKLLwPG8 (thanks to AnimalMother92 for vid) Update: v1.1 Changes: BD Tracer Lights This fairly simple addon adds appropriately colored light sources to tracers to enhance night combat. The color and intensity of the light is determined by the config properties of the ammunition. This addon also works with the NVG only tracers on the light machineguns; these tracers emit a very dim light that is barely visible, but can be clearly seen through night vision. Note: please see the Requirements section of the readme before attempting to use this addon. Readme Download: Version 1.1 (key included) (4.38 KB) Armaholic (Thanks to Foxhound) ArmedAssault.info (Thanks to Old Bear) Mediafire Version 1.0 (3.97 KB) Armaholic (Thanks to Nightrain) Mediafire BD Server Key (forgot to pack in the zip) BD Key (key included with v1.1) Additional mirrors would be appreciated.

I've never done this before but I'm sure someone has. Is there an easy/proper way to initialize the BIS functions from within an addon initialization script?

Maybe some of you who are better algorithmists than I can lend me some help. I am looking to create a function that finds the turret path of any particular gunner in a vehicle. My method was to recurse through the turret classes in the vehicle's turret. I'm fairly confident that I can produce the algorithm to find the config path (CfgVehicles\vehclass\Turrets\etc....), but converting that into an array (or producing an array from the start) is proving too much for my experience.

So I was going through BIS's scripts and stuff and came across something very interesting, and so I thought I'd see if it interests you guys. Operation Arrowhead includes a new set of of functions called UnitCapture & UnitPlay. From what I've gathered, they basically allow you to capture the movement data (and there's one for weapon firing data) of a unit, and then play it back exactly the same way every time. It's how BIS pulled off those seemingly impossible (for AI at least) littlebird insertions in the campaign. In short, all you have to do is call CaptureUnit on a vehicle (it appears to work on people to), drive/fly it around as you see fit, and it will copy the movement data to the clipboard. Then, simply paste the data in a script, call the PlayUnit function with this data and it will play back the same movement you just recorded. I imagine this can be used to some pretty substantial potential. Ex: getting AI to land aircraft on buildings/carriers, flying/driving through objects no AI could possibly pull off, and creating some very complex cinematic scenes. Now I haven't got a chance to actually try it yet, but judging from it's use in the campaign it seems to work very nicely (at least on aircraft). You can find some documentation in the scripts themselves. They're in the OA modules pbo, under 'scenes'. Hope this interests some of you mission (and movie) makers.

So you can already find a lot of information about event handlers on the Wiki, so I'm not going to repeat all of that information. But let's start with a quick overview of what they are. Event Handlers allow you to execute code every time a specific event occurs. There are a number of different event handler types, all of which you can find on the Wiki. Every object can have any number of event handlers of any type assigned to them. Adding Event Handlers It couldn't be simpler. player addEventHandler ["killed",{hint "You are dead!"}]; Here we added a killed event handler to the player. The type, "killed" here, can be any of the ones listed on the Wiki. The code we executed was 'hint "You are dead!"'. You can call any code you want inside of an event handler. Indices When you add an event handler to an object via addEventHandler, it returns an index. You can use the index to reference the event handler (usually for removal). These indices are different for each object and each type of event handler. The indices start at 0. killedEH = player addEventHandler ["killed",{hint "You are dead!"}]; // returns 0 firedEH = player addEventHandler ["fired",{_this execVM "myScript.sqf"}]; // returns 0 killed2EH = player addEventHandler ["killed",{_this execVM "playerKilled.sqf"}]; // returns 1 fired2EH = tank1 addEventHandler ["fired",{_this execVM "tankFired.sqf"}]; // returns 0 Removing Event Handlers Simply refer to the type and index: player removeEventHandler ["killed",0]; Removing an event handler will decrease the indices of the other event handlers of that type. So 0 will always refer to the next event handler, until the object has no more event handlers of that type. You can also remove all event handlers of a given type. player removeAllEventHandlers "killed" Arguments Like most things in SQF, event handlers reserve a special variable called _this. _this contains a set of arguments (in an array) that differs for each event handler type. Usually (and I'm pretty sure for all of the current existing event types), the first argument is the object that the event handler is attached to. The arguments are very useful, and allow you to get information specific to the cirumstances of the event that you otherwise could not. You can pass these arguments on to a script as seen in the above indices examples. "Fired" Event Handler One of the most (perhaps the most) commonly used event handlers is the "fired" event handler. It can be attached on vehicles or infantry units, and fires (no pun intended) every time the unit or vehicle fires any weapon. This includes hand grenades, mines, and satchel charges. It does not include car horns, and will only execute when a weapon is actually fired (so it excludes empty weapon "clicks"). There fired event handler produces 5 arguments: 1. Object that the event handler is attached to (ie the firing object) 2. The classname of the weapon that was fired 3. The classname of the muzzle that was fired 4. The classname of the mode that was fired 5. The classname of the ammo that was fired In many cases, when we use a fired event handler, we want to get the actual projectile object that is created. You can easily do this by using the first and fifth arguments and the nearestObject command. _projectile = nearestObject[_this select 0,_this select 4]; Now, depending on the speed of the projectile, sometimes you can "miss" it with nearestObject (which only searches in a 50m radius around the object it is called on) by the time the script reaches the command. You can avoid this by either calling your script as a function (I won't go into detail about this here) or by grabbing the projectile right inside the event handler's initial scope, and then passing it to your script as an additional argument: player addEventHandler ["fired",{_this+[nearestObject[_this select 0,_this select 1]] execVM "myScript.sqf"}]; This appends the projectile object to the end of the _this array, so you can access it in your script like so: _projectile = _this select 5; Of course, if you the code you call is a function (which does not run in parallel with the engine), you don't have to worry about this. This is it for now, will post more information about event handlers in general or specific event handler types at a later time, or if someone else wishes to add anything feel free to do so.

I don't think I released version 1.0 for ArmA, but I recently revised this script for use in ArmA2 and figured some of you might appreciate it. The purpose of this script is to allow AI units to patrol inside of a building. Contrary to popular belief, the ArmA2 AI works very well indoors. This script allows you to set up a path for them to patrol using buildingPos's. When the unit reaches a waypoint, he will wait there for a short period of time before moving on. In addition, (optionally) he will watch a specified direction at that waypoint. The unit will move to the waypoints in order, and will loop when the last waypoint is reached. When the unit becomes alerted they will move more cautiously, and (optionally) will move to a specified position until they resume SAFE mode, at which point they resume the patrol. You can also cease the patrol by passing the script a condition. By ceasing the patrol you can allow the unit to move freely, leaving the building, whatever you want. Once the patrol is ceased the script terminates, so you have to execute it again to resume the patrol afterward. Here's the script: You can download it now at Armaholic (includes demo mission): BD Building Patrol Script Enjoy.

Yea, and training new devs is still far less costly/risky than retraining everyone and redocumenting everything. As far as programmers go, I suppose as long as there are some senior devs who are familiar with the intricacies of the engine and there is sufficient documentation, getting new guys up to speed (provided they have sufficient general programming knowledge) and onto a task would be pretty streamlined.

Correct, BISim is a seperate entity with different priorities. There is certainly much cooperation, but this generally limited to things that can easily/readily be shared between the products (ex: sharing models or specific engine changes). BISim devs do not (for the most part), unfortunately, work on BIS projects (not that I'm complaining :p).

DM's attitude/tone aside, everything he said was a valid excuse. You really shouldn't argue with him; he knows what he's talking about. Just about all of his information was inaccurate, which is all Deadfast was trying to point out, and you can't form a credible argument on incorrect facts. The only thing I would like to correct from Deadfast's post is that SQF did in fact exist in a primitive form in OFP, but it doesn't really matter, everything else was pretty much accurate. As for the actual topic, I think that most of the arguments for a new engine are based on a misunderstanding or lack of knowledge on the subject. Working on VBS, I've seen the RV engine capable of doing things I would not have ever expected it to do. So I know the engine has great potential, but as DM already pointed out the team working on the engine has limited manpower and resources. There are a lot of things that need fixing or improving, and all of these issues have been considered and prioritized. It's not like anyone is ignoring them. They absolutely can be addressed given enough time. Now, switching to a new engine would at this point be foolish. The entire team would need to learn a new environment, become familiar with new technology, tools, etc. before they can even stary working on the game, and would then need to reimplement every single feature from the existing engine. They would run out of money just trying to reach the level of capability they already have, before they even got to adding anything new. ---------- Post added at 01:49 ---------- Previous post was at 01:42 ---------- You may be right, but you have to understand that it would be a tremendous risk for the devs. Engine optimizations/improvements alone won't pay the bills, and with the current size of the development team they can't afford to take devs off of the revenue generating projects to do this. As BIS grows and becomes larger, as I hope/expect it will, then at some point in the future they may have enough resources to do just what you suggested and have a dedicated team working on engine optimizations & support of liscensed 3rd party projects. It's just not feasible with their current size.

I'm going to release this as beta because I want some overall feedback on it. BD 40MM (Beta) Makes some changes to the 40mm grenade launchers in OA, and adds two new 40x46mm launcher rounds: -M576 Buckshot -Fictional chemical round (very lethal) Doesn't add any new units, so check the readme for the ammo classnames; you'll need to add them in the editor. Also see the readme for more info (just read it). Readme Download Mediafire [135KB] And remember to post some comments, I'm looking for feedback. :cool:

As you may all be aware, with the recent beta patches, light sources now play a very functional role in nighttime engagements. Due to the Takistani's lack of night vision technology, I started deploying them with "light trucks", which is essentially a V3S with a searchlight mounted on it. It looked so cool that I decided to go from a one line "attachTo" command to a more complex set of scripts that lock/unlock the cargo positions that the light gunner takes up when operating the light, and that add actions to allow units to switch between a cargo position in the back of the truck and the light. With these scripts, there are two possible ways to deploy the use of the lights on these trucks: 1. As a moble light source. While the searchlight is being operated, there is only room in the back for 6 troops (8 total including driver & passenger positions in the cab). Good for nighttime patrols. 2. To support dismounted infantry. When the light is not being operated, you can seat all 12 (14 including the cab positions) troops. Upon dismounting, you can have one man operate the searchlight to help the dismounted troops identify & engage the enemy. And so I will share it with you. So if you want to make more interesting nighttime missions, give this a try. The download includes a demo mission containing all the scripts (which have info in the headers) as well as a few examples of how to deploy them. Right now I designed it only for the V3S, but perhaps you could modify it to work with other trucks (Urals/MTVRs). Download: From MediaFire (No readme sorry, but if you really need one I'll consider adding one)

It's not VBS.

From what I've seen there's ragdoll on units when they get struck by vehicles but don't die. Seeing as how you can use script to have units enter death states without dying in ArmA 2, I'd imagine you'd be able to switch units into ragdoll at any time in ArmA 3 (or maybe I'm just hoping) as well. What it would look like when they get back up though is more concerning to me. It might just be an instant transition to prone or something, though it would be cool if there were some kind of interpolation.

NP, I'm glad you got it to work, and that you were able to find a solution to the problems I was having with it (what did you end up doing btw?). I've spent lots of hours messing (and mess is the appropriate way to describe it) with animation configs trying to improve movement and add new functionality using only what RTMs are already present, and I'm glad something usable finally came of it. If you are interested in any other projects, I also had semi working lowered animations for pistols (the way AI holds them when not in combat) and launchers, though I was running into obstacles with certain hardcoded action maps. They could be transitioned to via script, but not bound to the existing raise & lower key actions. AI was also another issue. It would be cool to have these states (as well as holstering pistols and slinging rifles like in OFP) but it's just so much work. Perhaps someone who is more motivated could make an attempt.

I had the same issue. First try restarting Steam as an administrator (Right click on shortcut > properties > Combatability; Steam might give you a warning but start it anyway). Then launch the game again and it should start the installer for the Hinds DLC. If not try manually running the DataCachePreprocessor.exe in your take on helicopters\DLCsetup\Hinds directory; this will launch the game with the installer. Once you've run the Hinds installer you should be good to go (you may need to enable the DLC in the Expansions menu though).

Ok, this sort of stemmed out of an experiment I started after reading this thread. And since the concept was so cool, I decided to put it into addon form. Since I already wrote it so nicely in the readme, here's the description from it: Description: BD Hellfire is an enhancement that provides an alternative (hopefully more realistic) system for engaging targets with the AGM-114 Hellfire Air to Ground Missile system. The system forces players to use laser designation to guide Hellfires, without interfering with AI controlled aircraft's ability to engage targets with Hellfires. Currently, the system will be utilized on the AH-64, AH-1, and MQ-9 aircraft in game. The system allows you to use your own laser or lock on to other lasers to guide your missiles. In addition, it allows you to toggle between direct and top attack modes. In top attack, the missile will climb before decending on the target from above. See the readme for more info. Update: v1.1 I've improved the top attack simulation quite a bit. It is now more viable at closer ranges (it can scale depending on target distance), and it just looks cooler too. I also added some improved support for using other addons with the system. See readme for change details. This addon requires Operation Arrowhead. Readme: Download: Version 1.1 Armaholic Arned Assault.info MediaFire Version 1.0 Armaholic Armed Assault.info Strategy Informer MediaFire MegaUpload Additional mirrors would be greatly appreciated.

Awesome, but no way to get ammo count (like magazinesEx)? I'm hoping.

You may be able to accomplish this without a gesture, though it would require some tedious config work. What you can do (and I've tried this before) is allow the raised movement anim states to interpolate to the lowered states (and vice versa). The result actually looks very smooth, and there's no interruption of movement. There is one issue I had with it, which is that if you try to stop moving during the transition you end up taking a couple extra steps, though maybe you can find a way to fix/improve that. Here's an example of the config (for walking right): class AmovPercMwlkSlowWrflDr: AmovPercMwlkSlowWrflDf { InterpolateFrom[] = {"AmovPercMwlkSrasWrflDr",0.01}; }; class AmovPercMwlkSrasWrflDr: AmovPercMwlkSrasWrflDf { InterpolateFrom[] = {"AmovPercMwlkSlowWrflDr",0.01}; };

It will be the same as in ArmA 2 (and the same as it as been since OFP). Gun shoots where muzzle is pointed. Don't worry about crosshairs.

I know right? Right Click > Install Game... is just too much work. :rolleyes:

Actually I do know, but that's as much as I'm going to say about it. Other than the fact that it is pretty nice of course. ;)

I assume he is talking about how much more fluid they are, but I still wouldn't call them "arcady". Just more fluid.