Photographic camera

[chupchup]

Hi
I am working up some ideas for a coop surveilance mission requiring the players to take photos of a number of targets. I don't have OPF installed at the moment (friend is sending disks from Adelaide - Melbourne [Australia]). I have done a search of the site but I couldn't find any example of someone else doing this.

So I need a camera.

The idea is for a camera classed as a weapon that fires "film" bullets with very high velocity (so they fly flat), zero deviation and do 0 (zero) damage. Perhaps 2 different kinds of mags: 200 shots for digital camera and 12 shots for converntional film. (or even 2 kinds of cameras- a conventional film and a digital camera). It needs to have zero recoil and no smoke FX. Preferrably it will use the binocular animations and use up a binocular slot in the inventory. The model shouldn't be a problem because I believe that OFP already has a camera model. Of course, an updated modern camera would be even better. A camera range finder optic would be the icing on the cake and a 0-4x zoom function allows for longer range shots. If you like this idea and decide to make a model, perhaps a few versions with different sized zoom attachments would be nice. Oh, and a "click" sound for when it is fired (photo taken).

I can then make a script using the "hit" EH and link it to the targets. It will check if the target was hit by the camera and can then give the camera operator a message that they have photographed the target. Alternatively, a digital camera "hit" EH script can make an array of the targets photographed and when it is linked to a radio backpack the shots can be "uploaded" and the array checked against an array of all the targets requiring photographing in the mission. A message can then come thru the radio informing the player of which targets remain to be photographed. A conventional film camera can be used to take shots and the film (ammo) can be left at a hidden drop point for collection by someone else (for those espionage themed missions). There are lots of other options for an addon like this but I can't do it unless one of you elite addon makers helps me out .

So, if you think this is worth doing (and it hasn't been done already), please get involved. I have no modelling skillz and my 'puter isn't set up for making PBO,s etc at the moment. I can however work up any scripting required (that being my OFP speciality;) and I fully intend on making missions that utilise it. Hopefully I will have OFP installed on my box within a week. Until then, I can script without OFP, I just won't be able to test them.

***Edit***
Just a note: this addon is not for taking screenshots. I have read the screenshot thread. The purpose of this addon is to have a camera "weapon" that can use Event Handler scripts to log target names within an array following the target being hit by a "film" bullet.
***/Edit***
Thanx in advance  .

[LoTekK]

I had actually started working on something like this a couple weeks ago, but it got waylaid due to real life commitments. Been planning to get back into it, but haven't gotten a chance yet. I had been toying in my head with some of the ideas you had about the scripting side (in particular the zero-damage projectile), though I was actually wondering if it was possible to create a "larger" fake projectile, so that the camera could be used properly, rather than like a sniper rifle (ie, there would be some room for error).

There were a couple of limitations that I had thought of, though, with anything of this sort. For one, there's no way to determine current FOV. So if the camera was of a variable zoom, you wouldn't be able to determine if the shot was a "good" one, so to speak (framed properly, subject isn't too small in the frame or extends out of the frame). Though I guess for game purposes that shouldn't be too bad.

The other thing I was wondering about was if enemies would react to the projectile even if it was set to do zero damage.

One other possibility I had considered was to use a "fired" eventhandler to check for the desired targets in a predetermined arc in front of the player. Of course, again, this wouldn't be able to take into account FOV. Additionally, it wouldn't be able to tell if the target is actually visible to the player. However, it would get around the fact that the "hit" eventhandler only triggers past a certain damage threshold (which is why it doesn't fire if you hit a tank with a 5.56 round).

Anyways, the model was being worked on, but the way I constructed it I'm having some issues with texturing the bugger. I may end up deciding to rework it from scratch, but for the time being:



:p

For the moment it's using a primary weapon slot (since the pose mostly works), but there are issues with the hand sticking through the lens assembly. For the time being I just rotated the camera model to fit, so it looks somewhat goofy if you look closely.

I'd be interested in working with you to realize this, though. While part of my initial goal was to create an actual combat cameraman for the combat photography thread, the other part of it was to create a useable camera for recon-type missions.

edit:
Wait. There's a camera model in OFP? Where?

edit2:
Having it in the binocular slot could be nice. A smaller camera, though, since the default anim is one-handed. Having it in the rifle slot, though, allows the player to move around with it, and being that my original idea was to have some sort of combat photographer, it made sense.

[chupchup]

Thanx for responding LoTekk, like the model!

I might be wrong but I thought there was an Empty/Objects/camera available in the editor (might need the Kegs [or other] Editor Upgrade). Could be wrong about that.

I agree that FOV will be an issue but I think that there are creative ways of getting around this. EHs with the scalar:howMuch return such as "Hit" and "Dammaged" allow for a script to tell where the target was hit. Similarly, by getting a return on the target and the photographer it is possible to determine the distance between them, and the facing (getdir) of the target.
So if I have a mission where the player has to take a photo of the turret of an experimental Chinese tank: Following the triggering of the EH, a script can check where the shot hit, the facing of the tank and the distance between the two. If these returns meet the criteria required for a successful photograph in the mission, the script can give suitable feedback to the player. Or they can sneak away to their hidden Sat uplink and send it to SOCOM only to be informed that the shot is not suitable and they will have to try again. Etc.

About enemies reacting to the damage, even if it is 0 (zero): another option to test is if it is possible to set the damage to a minor negative number such as -0.1? This might get around the "hit" EH threshold issue and the AI reaction issue all in one. I have no idea but testing will prove/disprove it.

I think that the best approach with an addon like this is to aim for versatility and user simplicity. Having a couple of different cameras with adjustable zooms eg x2 (FOV 0.5), x4 (FOV 0.25) and x6 (FOV 0.1667) and a max distance that it will take the shot 100/200/300m (or whatever). The Optic can have a little box or circle in one corner that can turn red (using the Cutrsc command) if the range is too far, indicating that the shot is unfocused. A longer range camera might even have a minimum range and a minimum FOV eg 0.75. So shots cannot be made at close range (within 50m). The optic would be something like the Shilka (I think?) optic where there is no central dot. Most cameras have a circular range finder and dont obscure the centre of the view. So a player would have to be sure of their photo because there is no exact `dot' on the optic like there is on an aimpoint scope. Lots of options here.

For night photography regular cameras can use a flash for shots out to 25m. Will need to creat a flash FX with glow and suitable white light splash. Some creative thinking and scripting might be able to determine if the target is lit. Ie within 25m of a working lamp post or a vehicle that is facing it and is not in Stealth behaviour or too damaged to have working lights. A night camera with a passive IR lense can use the NVG night vision resource (if possible).

Other ideas include:
Having batteries for the camera so that whenever it is held it is assumed to be switched on (or it has a "switch on camera" addaction) and the batteries gradually run down. One of the players carry slots (probably a pistol one to be nice must have a "camera batteries" if they want to be able to replace them. One slot = infinite batteries. A script checks if they are carrying the "camera batteries" magazine and gives them the action option to replace them if they run down. Otherwise, the camera won't work. Using the flash will drain them even faster.

Like I have mentioned, being able to interface a digital camera with a Satellite Radio or computer object. Send the shots to someone and that results in new mission directives, etc.

If the camera is digital it might be able to be used to save other files from a computer object during a mission. Eg: sneak into the terrorist safehouse, take some photoz and download their manifesto from the laptop they have on the top floor.

A digicam can also be used to view other in-mission photoz. You find a USB mem-stick on a dead guy, load it into your camera and get to see the photos and data he had stored there. (using TitleRsc).

^Most of these options are more mission side than addon side but I guess that I am illustrating some of the things that could be done with a camera in-game.

The goal is to make something that allows mission makers the broadest possible utility while providing whatever generic functions we can think of cramming into it.

What do you think?

[LoTekK]

Okay, just did a quick test by altering the damage values of class bulletsingle to 0 and a couple of negative values, and there was zero AI reaction to getting hit. Unfortunately, however, there was a physical (visual) reaction to the hit, in that the unit "flinched" (for lack of a better word) when hit. But at least it was otherwise completely unaware of being hit. Which brings me to the eventhandler. It doesn't fire at those damage levels, even the negative ones. Heck, on a whim, I even tried -100, but no dice. It won't be tricked.

edit: Just noticed something else. At damage 0 or negative, a nice side effect is that the projectiles don't kick up dirt or dust when they hit the ground. Unfortunately they still produce a cloud of blood. Don't think it's an ECP thing, either, since there's no blood spray/blood droplets. Haven't tested on objects or vehicles.

As for determining zoom, your comment about using various types of cameras led me to a similar idea. Muzzles! Since a single weapon can have various muzzles, each with their own optic and zoom limits (min and max), and yet can share the same magazine, this should be absolutely doable, and doesn't require the user to haul around three separate cameras (not that that would be possible if they were all classed as a primary or binoc). For the purposes of the game, each muzzle can simply be described as a preset or something similarly inane.

Magazine cap, battery life, etc, can probably be figured out later, though I'd personally suggest against a battery life sort of thing. Most modern cameras have batteries that can last an inordinate amount of time. I'd consider the battery thing to be more of an annoyance than a feature. I'd much rather it be abstracted.

edit:
Just thought of an alternative method of handling the actual picture taking. I'll take a look at the bulletcam script to figure out how the author tracks each bullet, but basically I was thinking that using a "fired" eventhandler, you could run a fast loop that constantly checks the distance of the projectile against an array of targets. This array could be defined by a mission maker as a global var. This would allow a bit of leeway as far as not needing to be spot on with targeting (addressing my point about not needing to use the camera like a sniper rifle).

The script could be setup to exit if the initial distance to any one of the targets is greater than the threshold determined by the muzzle (ie, zoom lens). This would prevent it from needlessly eating CPU cycles. It could also exit if the subsequent loops find that the distance to the closest target is increasing, again saving needless processing.

Further cutting down on cycles. When the script starts, make a local copy of the target array. If the projectile distance to any of the targets is increasing (supposing that the mission involves multiple targets in different areas), delete those from the local array.

Sorry if this is rambling. Just putting my thoughts down on possible ways to script this bugger.

[chupchup]

No probs with the battery thing, I see that as a potential scripting / editing thing rather than being `hardwired' into the addon.

Muzzles are a good idea. muzzles can represent zoom pre-sets, filters or all kinds of things and it is easy to get a scripting return on them for additional results.

So far as the blood spray goes, it is an object. I can't remember the name but in some prior scripting I have done it came up. It can therefore be deleted on creation. This will not be 100% foolproof but will work most of the time.

Is the blood splash normal sized (such as from a rifle) or is it really small? I seem to remember that they are scaled according to the damage scalar (up to a limit) but I could be wrong on this one.

So far as the "hit" event handler, this is not such an issue. I have a couple of scripts that work off "Fired" EH that can get a return on the round in the air and it's position. There are a few other potential work arounds for this but I will need OFP installed to test. (next week).

I will be running OFP on minimal addons and no mods so my PC should be a good basic test-bed.

Let me know as soon as you have a basic version. I have done a deal of cpp editing in the past so I can check that over too. I think that by using CutRsc overlays to the Optic, the player can be given feedback about whether they just took an effective photo or not; ie: range errors, flash errors, etc.

[LoTekK]

Ah, you posted as I was editing. Looks like you've already got the projectile tracking sussed then.

As for the blood cloud, it was a regular-sized one. At least from what I remember. I haven't played OFP without ECP for a while now.

The CutRsc thing would be a good idea. Nice way to let the player know. Would probably have to do some checks so that it doesn't tell the player that target A, which is 4km away and directly behind, is out of focus, for example.

[chupchup]

As far as I remember all bloodsplats and dirt puffs from firing rounds are the result of a proxy that is created at the point of impact. It is possible to search for the proxy and delete it if so.

An alternative is to make the `film' as ammo class `grenade' and give it zero damage and a clear texture (so it is see thru). I don't think that grenades cause the puff proxy. In the same way as there is no puff when two objects collide in the game (like a car into a building [assuming neither is destroyed]). Try it out and see what happens.

[LoTekK]

So far classing the ammo as "granate" still produces the blood puff. I'm going to set that one aside for the time being.

Currently I'm working on alternate static anims for the camera, so I don't have to get all hacky and rotate the camera model in O2 (since that ends up looking rather goofy). I've got a static pose currently for large cameras like the one in the earlier screenshot (haven't gotten as far as getting the anim classed up yet, though, so no tests as of yet). I'll see about creating an anim for a smaller camera without the stupidly large telephoto lens, and maybe one that would suit a compact one-hander camera that could maybe go in the binoc slot.

I'll update when I get a little more done.

[Planck]

Does the LaserDesignator use an ammo type?

If so, maybe you can use a similar set-up.


Planck

[LoTekK]

I had considered looking into the LD at some point, but I recalled reading a bit about its code being, well, inaccessible. The major problem? No entry in the config.cpp. None whatsoever. It's referenced in the saboteur class as an inventory item, but that's it. Another issue is that it doesn't set off the "fired" eventhandler.

As for the animations, it appears this won't be possible without creating a whole new unit class. I had incorrectly assumed that Cheetah's FN P90 pack was adding the custom anims to the weapon class somehow. Instead, the units that he's classed in cfgVehicles who start out with the P90 are the only ones that use the custom anims. Giving a P90 to a regular unit will result in said unit using the stock anims from anim.pbo. :-\

So, I guess that's out, since I don't particularly see the benefit of that route. *sigh* Back to the drawing board.

[Planck]

If you depbo the LaserGuided.pbo in your addons folder you will fing the config for the laserguided stuff.

Might be worth a look anyway.


Planck

[LoTekK]

If you depbo the LaserGuided.pbo in your addons folder you will fing the config for the laserguided stuff.

Doh! :-X I'll have a gander at it, see if anything useful turns up. Thanks for the heads up!

Any ideas on the anims? Or is the method Cheetah used the only feasible way?

[Planck]

Probably Cheetahs way is the only way or maybe the easiest way, but then, anims I know very little about.


Planck

[LoTekK]

I'll try and dig around about the anims. Hopefully some way turns up.

Umm, anybody have a successfully .cpp'd config for the LD? I tried the Amalfi's cpp->bin, but it won't take. No error messages, nothing. I just end up with the same files I started with.

edit:
Dug around on the BIS forums with nothing conclusive. Doesn't look like it's going to be possible to have custom anims attached to a weapon in the config.cpp. I did, however, have a hairbrained idea pop into my head. I'm going to hit the sack and see what I can come up with tomorrow if I have some spare time.

Oh, does anyone know if it's possible to poll the current animation being played on a unit? Kind of like how with some custom units like BAS or LSR Delta/Rangers you can check if the goggles are up, down, or currently animating. Is it possible in some similar manner to find out if the unit is currently playing the running animation, for example?

[Planck]

Try this tool


Planck