 |
As delivered, the camera pieces are NOT in the folders where they belong. The dds files go into dds/models/darkmod/props/textures. The mtr file goes into materials. The lwo files go into models/darkmod/mechanical. The tga file goes into textures/models/darkmod/props/textures. |
|
|
Since it's difficult to put the camera parts in the right place, 2 prefabs would be necessary, one for a wall-mounted camera, and one for a ceiling-mounted camera. |
|
|
Scripting is needed to make the gears turn in the right direction. Probably binding them to the head will take care of the fact that the gears are pitched. |
|
|
Pm'ing Obs to see if he can have a look at this as Gman is upto his eyes in getting 2.06 out the door atm. |
 |
Modified the camera visibility check with rev #7562: game/SecurityCamera.cpp - Traces for head and origin (shoulders could be added, but are probably not needed?) - Trace starts a bit in front of camera, as it seems that the model blocked the trace sometimes |
|
|
This is ready for testing? |
|
|
It is. |
 |
I see this is marked as fixed in 2.07, and http://wiki.thedarkmod.com/index.php?title=What%27s_new_in_TDM_2.07#Assets says it was added in 2.07, but the only camera models I can actually find in my 2.07 installation are the models/darkmod/mechanical/security_camera.ase family. Am I missing something? |
|
|
I have uploaded the camera stuff as per above but haven't committed them to svn as I thought they would be tested before doing so. It seems they haven't been added afterwards either. The code is there, though (see above comment), so if you download the files you should be able to use the camera. Note that the camera is an entity. Seems like there was a misunderstanding here, sorry. :( |
|
|
Added with rev. #15644 |
|
|
There are no script files in that rev. Were there code changes as well? |
|
|
I'll take a look. I somehow messed up the camera related stuff, but I will try to fix it as soon as I find the time. Sorry. :( |
|
|
Ok, thanks. No rush. |
 |
It would be great if this camera has the ability to follow the player for a short while after it detects you and before it fires the alarm. Similar to the t2 style cameras. Other wise its really easy to just side step out of its view cone when detected. Also the default alarm drops my FPS to like 15, probably because its alerting the entire map. |
|
|
If we're adding enhancement suggestions here, may I add one about letting the default skin and particle names be overridden by mappers via spawnargs? Recently someone wanted an invisible security camera for something and couldn't get the skin working; I checked the code and saw it seemed to be using hardcoded on/off skins (so I ended up suggesting overriding those built-in skins with same-named ones as a workaround). The spark particles are hardcoded too, I think, so anyone trying to create the 'gruesome sentries' from http://wiki.thedarkmod.com/index.php?title=Magic#Necromancy would get sparking animal heads. |
|
|
I found Epifire's camera models in the 2.08 beta. Is everything there to close this? Should it be left open for my and Kingsal's comments just above, or should those get their own tracker entries? |
|
|
I have a working Epi camera in one of my 2.08-dependent WIPs, so the camera works. I have not implemented any of the suggestions after the Apr 27 2019 note. I don't plan to, and Obs is no longer around, so these suggestions would need to be implemented by someone else, perhaps in 2.09. |
|
|
See attached picture. |
 |
I've got a working setup of the security camera in an FM, but the version in core TDM is in shambles and impossible to use in a mission. I've decided to look into getting it into a useable, core-grade state. Edit: this has been solved and can be disregarded. (The problem that I can't solve is that the camera uses a hardcoded spotlight with the texture lights/biground1. This texture has no falloff image, so there's a hard cutoff to black at the end of the spotlight's range. Since I don't want to modify biground1, which is heavily used in all FMs, I'd like to give the spotlight a custom texture. However, I see no way of modifying this without going into the source code. It'd be appreciated if a coder could modify Epifire's security camera's spotlight to use a light texture called "lights/spotlight_security_camera" (which I will create) instead of "lights/biground1". Better yet would be if the mapper were able to modify this texture by changing a spawnarg on the camera, i.e. "texture_spotlight".) |
|
|
I have the camera working nicely in WS6. A camera pk4 with missing bits is included. I can’t work on it, but can provide the camera pk4 to whoever has the time. |
|
|
Ah, more hardcoded stuff; cf. my comment above. I assume the cameras seen in some released missions are using the built-in spotlight, so it would certainly be best to make the light texture settable via spawnargs (if you add a substantial falloff to the default camera light you might need to check whether those missions have changed enough to need repacking with biground1 set manually). |
|
|
Thanks grayman, I already got all the necessary assets from you. For me it's a matter of polishing its implementation to follow existing conventions and be as user-friendly & versatile as possible. I've meanwhile found a suitable script event to let the scriptobject override properties of the inherent spotlight, using values from spawnargs. I've done the same for the broken skin, and made the lamp toggle upon simple trigger (rather than 3 callobjectfunction entities) and am adding status tracking so that each camera's status can easily be checked by scripts. |
|
|
@VanishedOne it's impossible to use the security camera as it exists in core TDM due to a missing script, so only FM's that have their own copy of the assets from grayman will have this security camera. The question is whether they contain a complete copy, or still partially rely on core assets. |
|
|
My pk4 layers on what’s in the core assets. I don’t recall if there are 2.09 sdk changes as well. Will look tonight |
|
|
There are FMs using func_securitycamera (with the older model I think Biker made), but I don't know whether any uses the "spotLight" spawnarg (which seems to be handled in idSecurityCamera's code) to set up its light. I just checked Hidden Hands: The Lost Citadel and it seems to use a bound light entity instead. |
|
|
Ive been using security cameras with the spotLight function. Otherwise they wont change color when they spot the player or alert nor will they turn off when the camera is broken. However, you can't use a custom light texture atm. This should be exposed in the script as a spawnarg for mappers. OR we should set the script up so it just does everything through the bound light entity set by the mappers. This might actually be better as you you can preview the light in DR and tweak it more easily. |
|
|
@VanishedOne Everything I've done with the scriptobject so far should be compatible with the older security camera in existing FMs. Anyway, I could see no evidence of the old camera spawning a visible light, even though there is a lightOffset spawnarg. The spotLight spawnarg only appears in the newer camera. @kingsal I've already made the scriptobject override the light texture if one is defined in a new spawnarg. But it seems I'm not able to do much more with scripting, since many light script events don't seem to work on projected lights. Making the light entity accessible to mappers by def_attaching it or making the camera inherit from an electric lamp would be best, but probably require quite some code adjustment. What's needed most is that the code reads new spawnargs from the camera entity. So far, this could be: - making the spotlight use "spotlight_dist" instead of "scan_dist" - making the "broken" particle use "broken_particle" instead of a fixed particle name (sparks). |
|
|
A more serious problem is that the camera can be destroyed by broadhead arrows. I believe I could stop broadheads by encasing the camera with a "clip_plusmoveables" mesh so that only splash damage from fire arrows gets through, but for a core-grade AI-like entity this is not particularly elegant. Edit: a simpler solution might be to def_attach the collisionmesh so that a direct hit of the collisionmesh doesn't count as hitting the camera. Splash damage still works. |
|
|
"spotLight" has existed since Doom 3 (maybe not exposed in the func_securitycamera entityDef): see line 139 at https://github.com/TTimo/doom3.gpl/blob/master/neo/game/SecurityCamera.cpp What doesn't seem to have existed in id's code is an explicit light shader, so I'm not sure what it would have defaulted to. Re. damage, yes, I've muttered before about how the Doom 3 approach to damage doesn't lend itself to anything like Thief's SlashStim/BashStim/PokeStim, so anything physically damageable reacts in much the same way to any weapon. |
|
|
I actually like that they can be hit by broadheads. Theres so little use for broadheads in the game already. It makes sense that a well placed shot would break the lens. @dragofer - I say leave it as is for now. I am not able to get the script to adopt my custom light for some reason. |
|
|
Due to ill health I won’t be back on the computer until tomorrow morning, at which point I will send what I found missing from the 2.08 camera support. You can compare my solution with yours and we’ll resolve the missing bits. |
|
|
Thanks grayman, it's very much appreciated. I can confirm that the custom version I was working with matches what I extracted from WS:6, so it seems likely no further action is needed from your side. I've recently realised that I've learned enough about scripting to somewhat comfortably advance to working directly in the C++ source code with this security camera entity. So I believe I can help myself for most of the things that I think still need doing to finalise this asset. The first thing I've done was to add a new script event, getSecurityCameraState(), with rev 9109. I'll start compiling all potential changes to the security camera in the description of this ticket. |
|
|
Ok, good luck. |
|
|
This ticket can be set to resolved since Epifire's camera has now been fully functional in SVN for a few days, thanks to a .pk4 from grayman and some final touches by myself, i.e. making clipmodels and reorganising how the entityDefs are setup and inherit from each other. Further changes to security cameras apply to all new cameras equally and will be tracked in 0005528. |
- Anonymous
