NPC firing of target_counter / target_activate on func_plat

OK dudes. A couple of simple one's for ya.

Have a target_counter in my map that I want to fire it's Target when a number of NPC's die.
Have read the tutorials and set up as instructed.
target_counter works when I point a trigger_multiple at it. Count's 3 hits then executes scriptrunner. Using target2 with a small print script to ensure that it's counting correctly.
Does not fire when I target NPC's at it though. How to I trigger something with an NPC death. Doesn't seem to be target or target2 so am a bit stuck.

Also!

Have a platform that I have set to Inactive. Pointing a target_activate at it and for love or money it will not activate. Have tried triggering with triggers and scripts. For the love of god someone help me get this damn platform start working. Works fine when I uncheck Inactive.

Thanks as always for your excellent help!

You could try a deathscript, if all else fails.

As for the platform, try a target_activate followed by a trigger.

NPC_target is the key you are looking for. An NPC will trigger the entity named in NPC_target when the grim reaper comes to pay a visit.

Target_activate has always worked for me with all the entities I've used it with. But then again, I have no use for func_plats so maybe it's a broken entity. But before believing that, you should double check all your connections.

Hmm yes perhaps a scripted func_static rather than a func plat would be better. Guess I'm being a little lazy.

Is there any reason why you can't just use a func_door instead of a func_plat? I would think a door more suitable for the scenario you described, and you won't require extra scripting.

Solved this problem by replacing all func_plat with func_static.

Sorted although the combination of target_counters, func_statics, triggers and target_scriptrunners is quite mindboggling!

I'm with Seto on this one, why not just use a func_door?

Because I have pretty thin floors and they're made of glass so they player can see what's happening underneath. Unless I'm supposed to use the lip function in some crazy way...

What? Now I'm confused. How exactly would using a func_door differ from a func_plat or func_static then?

Well a func_door only moves it's own width as far as I know. It slides in one direction the width of the block itself.
You can offset this movement by using the Lip attribute (so you're door still sticks out a little). If you make that lip attribute huge it could act in a similar way to a func_plat but thats a pretty messy way of doing things in my opinion.

In order for a func_door to work as a platform for me it would need to be the height of the entire floor that it descends the player down to (because it will only move the it's own height). This is fine if your platform is one long solid block that raises and lowers into a solid floor that you can't see through but for me I need a free floating platform that is only a few units tall to move between one floor and another.

I basically I have 3 floors to this section of the map. Each floor has a glass floor so you can see through to the floors below. If the floors were solid and not directly above one another it wouldn't be a problem but because of the way the area is stacked and because you can see directly through to the floor below the player would see this huge block raising and decending in the area below. Not very pretty (but has an interesting level design element to the idea, huge block act's as platform on one level and as a door on lower level.. hmmmm)...

Perhaps I'm missing a very simple way to use a Func_door in place of a func_plat. If you could explain your method for how to do this perhaps I can understand the method you're suggesting.

What exactly prevents you from using the lip key if it works? Don't be too stuck on the entity names thinking a func_door can only be used for doors. In theory the game could have only one super brush entity that would work for everything with various flags and keys but for practical uses it's easier to have "short-cuts" like these, where the different functions were groupped into separate entities under some sensible names.

Ok. Thanks... still liking the func_statics just because I don't have to re-compile if I want to change the speed of the platform or the wait times. Gives me just a little more flexibility if I can run most of the workings through scripts.

I can't really blame you since I always use func_statics myself. I never liked figuring out those numbers in Radiant; it's much easier to just place a couple of ref_tags in the map and set a time instead of a speed. Plus if you don't like the lighting the elevator gets in the actual place in the map, you can move it somewhere else in Radiant and then just move it to the correct place in your initial level formatting script, simply using the ref_tag that's already there.

Personally, I never bothered with lip key/values unless I wanted a lip on a door. Rather than bother with it, what I'd do is set up my platform that I wanted to be the platform, then I'd make a nodraw brush which would reach to the place I wanted the lift to stop, and then I'd make both brushes a func_door. No need to worry about lips or the like, no extra entities, no scripting. However, I agree that being able to change the properties of the lift without recompiling would be nice indeed, as well as using time instead of speed.

Hey that's a pretty clever way of using func_door! Hadn't even considered using no-draw or caulk. Will stick to my method but you've expanded my mind as to what is possible.