TDM security cameras

[kingsal 592]

Hello everyone, I've been thinking about messing around with the new security cameras and had a few questions that people might have answers too. I know these are a WIP feature.

- Currently, the camera stops in place once it locates the player. Is it possible to append the script to have it follow the player's movement (similar to the t2 cameras)? I'd want to be able to set its max "follow" speed as well.

- Is there a way to adjust its visual acuity similar to the AI?

Obviously I'd want to do this stuff without messing the the source so it would have to be appended to the object script.

It would be wonderful to hack those things in if possible.

 

Thanks!

 

[duzenko 660]

@grayman?

[grayman 2974]

Follow the player: No.

 

Acuity adjustment: No.

 

You could add these feature requests to issue #4731.

[duzenko 660]

I would prefer this implemented as spawnargs rather than scripts for performance sake.

[kingsal 592]

Cool. It would be great if they have the function to follow the player to create that tense moment of escaping its view. Otherwise it will alert and the player can just take half a step out of its view and avoid having to get away.

 

Thanks for the info. I'll add a note in the bugtracker.

Edited June 9, 2019 by kingsal

[duzenko 660]

I don't know what features we already have but I would also like to see some kind of alarm indicator (LED-like on the camera body)

• green - no detection
• yellow - camera suspicious, follows player movementt (?)
• red - triggers alarm (give player a second or two to put it out with a fire arrow?)

[kingsal 592]

That would be great!

 

If I remember correctly in T2 the spot light color changes?

 

So the camera could have something like: searching_color, detected_color, and alarm_color spawnargs available to authors. This could effect the spot light and also the light textures on the model. Bonus if it can also change color on any effects like a lens flare glow attached to it.

[Goldwell 2477]

In regards to following the player, is it not possible to make a change to this script? http://forums.thedarkmod.com/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/page-16?do=findComment&comment=396357

 

The script for that looks like this:

object statue_look
{
	void init();
	void loopLook();
	vector viewDir;
	vector direction;
	float cosine;
	float tolerance;
};
void statue_look::init()
{
	thread loopLook();
}
void statue_look::loopLook()
{
	while(1)
	{
		if (distanceTo($player1)<1024)
		{
			viewDir=sys.angToForward($player1.getViewAngles());
			direction=getOrigin()-$player1.getOrigin();
			cosine=viewDir*direction/sys.vecLength(direction);
			direction_z=0;
			if (cosine<sys.cos($player1.getFov()/2+30))
			{
				setAngles(sys.VecToAngles(-direction)+'0 90 0');
			}
		}
		sys.waitFrame();
	}
	
}

If you remove the "if (cosine<sys.cos($player1.getFov()/2+30))" bit and it's associated brackets those statues now follow the player (it does bring up some smoothing problems but that's another thing).

 

Couldn't you trigger that in the security camera script so that if it spots the player it will activate that follow the player script for a duration until the player has been out of sight for X amount of seconds?

[VanishedOne 547]

 

I don't know what features we already have but I would also like to see some kind of alarm indicator (LED-like on the camera body)

• green - no detection
• yellow - camera suspicious, follows player movementt (?)
• red - triggers alarm (give player a second or two to put it out with a fire arrow?)

 

I think this has code support already: I haven't confirmed it works but you can see a shaderparm being updated in idSecurityCamera::SetAlertMode(). It needs a material on the camera model to use that shaderparm though, and as far as I know neither the current (Biker's?) model nor Epifire's new one has that, probably because it isn't a documented feature.

[peter_spy 1603]

I've been looking into this as well, using this article: https://wiki.thedarkmod.com/index.php?title=Security_Camera

Right now I'm interested in the last (most simple) example in particular. E.g. can I control the FOV of the image that is being sent to the display? It seems pretty wide by default.

[Obsttorte 1524]

You could try reducing the scanFov spawnarg on the respective camera. If that doesn't work, you may be able to manipulate the look of the view by using only a part of the texture.

[peter_spy 1603]

It works only with the first setup, where the camera is an image source for the display. It doesn't work with target_null.

[Dragofer 1429]

I've recently started looking into the security camera after noticing that core TDM's version of Epifire's camera doesn't work, while there is a useable .pk4 in circulation.

Ticket 0004731 and this thread show that there are also some issues with the coding, such as skins and the spotlight being hardcoded and therefore not customisable by mappers. There is also room for improvement, such as making the camera follow the player once he's been sighted or detected to make escape less trivial.

Having recently looked into the source code, C++ seems familiar enough to me now that I may be able to address such points, in addition to fixing the core assets to make it possible to use in FMs without external downloads. I've compiled everything that I have on my radar currently after investigating the camera and reading the forums & bugtracker:

Early issues, fixes required for adequate function and customisability:
- restore outdated/missing defs and scriptobjects in SVN
- hardcoded: spotlight properties and texture
- hardcoded: sparks particle when the camera is destroyed
- hardcoded: names of skins
- colour switches handled inefficiently by the scriptobject
- add a script event to check the camera's state (done: getSecurityCameraState(), returns 1 to 5)
- can't be switched off properly and STATE_PAUSE is immediately dropped
- camera can be destroyed by broadhead arrows. (make immune, or see stretch goal for making lens the vulnerable spot)
- camera is destroyed too easily by far away fire arrow splash damage (increase health)

Intermediate issues:
- allow adjustment of visual acuity
- make the time taken go to full alert depend on the brightness of the lightgem
- make the camera follow the player once sighted/detected

Stretch issues:
- make the lens vulnerable to broadheads. Probably requires the camera to be an md5mesh with a bone for the lens.
- detect AIs hostile to the camera's team

Maybe someone would like to comment on or add to this list?

A complicating factor is that a camera with an older model and entityDef is already in use in FMs. Ideally all changes would be backwards compatible, but in the worst case some FMs may need to be repacked. In any case, anything done here would be for 2.10 at the earliest, though testing could be done by downloading a custom build via the tdm_installer.exe.

[Dragofer 1429]

I think we should establish a convention for how security cameras can be disabled, damaged and destroyed. My proposal for the default behaviour would be the following:

- fire arrows: 2 indirect hits would break it, 1 direct hit would obliterate (flinderize) it

- water arrows: switch the camera off for 10-15s and make it spark. Let 3 shots permanently disable it so it can't be switched back on.

- sword & broadhead arrows do no damage by default. A stretch goal would be to let a precise shot at the lens make it blind.

- blackjacks do no damage (they don't seem to damage anything anyway)

[Amadeus 360]

Three water arrows to permanently disable a camera seems a little high. Also, it might be a tough thing for the player to learn/intuit because if they shoot a second water arrow and the camera still isn't broken, they aren't going to want to waste another one (unless there is some clue hinting at the camera becoming progressively more damaged with each shot). Also, I really like the idea of using broadheads to land a precise shot at the lens, and if that does become the way to kill cameras, we probably don't need the water arrows to kill them, only temporarily disable them

Edited Thursday at 04:15 PM by Amadeus

[kingsal 592]

Also with regards to how they are damaged/ disabled:

While playing around with them in my own mission (which has a bunch of these guys). I find its more interesting to use high value arrows to destroy/ temporarily disable OR find a switch to power them down. A couple proposals:

- Water arrows to temporarily short circuit them. Maybe 10 seconds or so by default? Could be handled with a water stim
- Fire arrows to blow them up. This is a bit more tricky as fire stims wont work. Maybe a damage threshold? Or simply give them a good amount of health and make their texture immune to broadheads? Im not entirely sure how to do that. We do have a concept of "armor" on AI materials which might help.

[VanishedOne 547]

This is going to be configurable for different camera types that might exist in future, yes? Given that the Wiki mentions necromancers' guardian skulls, and eyeball plants have been mentioned on the tracker... (Edit: also, the water arrow feature especially would be a nontrivial change to existing maps that use the cylindrical camera model.)

Re. damage types: yes, we're hitting the limits of the Doom 3 way of handling damage again. You could try distinguishing projectile collisions from melee ones via clipmodel contents, perhaps.

Edited Thursday at 10:08 PM by VanishedOne

[kingsal 592]

The current set-up Dragofer has is configurable for all kinds of things. The idea is to keep it as flexible as possible, while still manageable.  I think we're talking about an entirely new camera definition, so these won't interfere with old maps. In the case that they do, I believe its only a small number of maps that use security cameras and we can reach out to those authors to let them know.

Im not sure if clipmasks have types associated with them and some things might even use the same ones, but that sounds like a potential avenue. 

EDIT: Looks like there is some idea of a melee weapon in collision information, not sure about arrows. I guess those would be in the projectile code like @VanishedOne mentioned.

MeleeWeapon.cpp:

#include "Game_local.h"
#include "Grabber.h"
#include "DarkModGlobals.h"
#include "MeleeWeapon.h"

CLASS_DECLARATION( idMoveable, CMeleeWeapon )
END_CLASS

const int CONTENTS_MELEE_WORLDCOLLIDE = MASK_SHOT_RENDERMODEL | CONTENTS_MELEEWEAP | CONTENTS_CORPSE;
const int CONTENTS_MELEE_ACTCOLLIDE = CONTENTS_MELEEWEAP | CONTENTS_BODY; // parries/held items, AI

 

[kingsal 592]

Sorry one more bit: I think some concept of damage threshold would be the way to go if we wanted them to be immune to everything but firearrows. Dragofer already has some concept of this in his code.

So any amount of damage underneath the threshold of the firearrow gets thrown out. (assuming a direct shot from a fire arrow does a good deal more damage than anything else)

[VanishedOne 547]

It might be worth starting to think about turrets as well.

I'm coming to think there just isn't a single optimum approach to camera vulnerabilities: making them vulnerable to various projectiles adds gameplay options but could mean nobody with a quiver of broadheads or water arrows will ever bother to hunt down the power switch, especially in areas where AI can't easily see a broken one. 

Fortunately, this is a problem with an established mapping solution:

Edited Friday at 02:23 AM by VanishedOne

[Dragofer 1429]

I think I'd tend towards Thief's approach of making security cameras quite sturdy so that the player either has to invest high-value arrows or find a way to switch them off. Fire arrows are underused in TDM imo. Water arrows are rather abundant in relation to security cameras, so I think they should only temporarily disable them, as a potential extra feature in TDM.

The idea with making the lens vulnerable to broadhead arrows is interesting, but broadheads come so cheap that the lens would have to be quite hard to hit, which would be frustrating in a similar way to how the blackjack is hard to use reliably for some people. Also, the old security camera has 2 huge lenses, so that would be quite trivial there.

Regarding technically modifying vulnerability to various weapons, I can give the security camera an own ::Damage method that is passed the reference to the inflicting entity (broadhead, sword etc.), so that's not a problem. The main thing is to come up with a "damage_mult" spawnarg system that lets the mapper tweak these vulnerabilities.

Also, a damage threshold isn't currently an option because fire arrow splash damage does less damage than a broadhead, but I think that was because the security camera until now used the base idEntity::Damage method, which discards some of the information from the incoming hit (i.e damageScale) and simply just reads the damageDef. I think a threshold isn't really needed anyway if you can use damage_mult spawnargs - the only thing I'm using a damage threshold for is to decide whether or not to flinderize a dead security camera.

And yeah, this is all customisable, we're talking about establishing the standard TDM behaviour here.

I'm all for making a turret, btw, especially if someone has a good model and projectiles to work with - but one thing at a time.

[VanishedOne 547]

The thing with the water arrow idea is, sitting in place watching areas is what a security camera does, so there isn't that big a difference between temporarily and permanently disabling one unless you need to traverse an area repeatedly. T2 Watchers are sometimes used like Bafford gate guards, to direct the flow of gameplay by making an ingress point impossible to stealth through. If they can be disabled with fairly common tools, that isn't really viable. Camera looking straight down a well lit corridor? Water arrow. Camera pointed directly at a valuable object? Water arrow.

I'm not against the idea as such - I think carefully timing your water arrow hit and grabbing of the loot could be fun too - but I think there are definite reasons why a mapper might want to deploy waterproof cameras.

[Obsttorte 1524]

I agree with @VanishedOnethat making cameras vulnerable to water arrows should not be the default behaviour. If a mapper really wants the player to be able to temporally "disable" the camera, he could simple place a torch where the player uses the water arrow on and that gets relit by ai or an electric light and a light switch.

Cameras are already relative limited in a sense that they can't move and are often restricted in their fov. So their should be some advantage compared to guards that outweight that. Otherwise mappers may only use those things due to aesthethics, which would be a waste of the work invested imho.

[chakkman 398]

I can't remember at all how it was in Thief... could you destroy the security camers there?

I actually liked the idea of Dragofer, to require 3 water arrows to destroy the camer, making them spark on the first hit. At least that would make sense to me. Drown such an electronic device in water, and it will stop working at some point.

Fire arrows should be sparse, like in the original Thief's, and, one shot should be enough to destroy a camera. They're loud and noticeable anyway.

BTW, mission makers should give more water arrows to the player in general. I remember in almost every mission in the original Thief's you had plenty. In TDM, even in the missions with undead and holy water, you rarely get enough to be able to kill all the undead... most missions are quite unbalanced, in terms of equipment.

Edited Friday at 06:00 PM by chakkman

[kingsal 592]

@VanishedOne Thats a good point. I think on balance the most interesting part about the cameras is avoiding them and then trying to find a switch in the level to turn them off (at least in the case of my own experiments).  Outright destroying them or even disabling them should require the use of a valuable item. Maybe water arrows are too common for that and we should just stick with firearrows as the players way of immediately dealing with them if they choose to.

We do run into this problem where different maps will use different conventions so maybe turning the water arrow disable thing off be default, but leaving it available to mappers is the way to go. 

EDIT: I also had the thought that temporarily disabling them with a flash bomb is interesting. It would be more difficult to do and usually flashbombs are more rare. Anyways- a good bit of that can be handled by the mapper and stim-responses. Maybe we just leave the code in for a "temporarily disabled" state incase a mapper finds use for it. Keep in mind the idea is to make these somewhat modular so it can turn into eyeball plants and floating skulls or whatever where a disabled state might make sense.