That would be pretty sweet, yes. I’ll run it by the team.
Sorry to bump an already bumped old thread, but I had an idea and wanted to run a question by the developers. I may just be called lazy for this, but I was curious if it would be possible and simple enough to add an entity that fired the same outputs as a trigger_once or a trigger_multiple, but operated as a point entity with a radial trigger like env_soundscape? It would be beneficial for setting up scripts quickly without having to create a brush volume every time you wish to add a new trigger and then recompile VBSP. Plus, a spherical trigger volume can be very useful in areas that don’t require the boxy precision of brushes. I know that you could create a spherical trigger_multiple, but hammer is notorious for messing up the vertices on spherical brushes and it still requires recompiling more than -onlyents.
It’s not a big request and is really more about convenience admittedly, rather than necessity. But it was an idea that I just wanted to throw out there, see what anyone else thought. Assuming an entity with this functionality doesn’t already exist in the editor and has somehow alluded me all this time.
There is the point_proximity_sensor , that allows you to output the distance between two entities.
So set 1 entity to !player and the other to either itself or an info_target.
I guess in the outputs you could do something like “Distance 200” target “bla bla bla”
That’s true, but that would require a logic_compare to determine if the activator is within the appropriate distance and a logic_timer to keep testing the Distance from point_proximity_sensor. I figured something like an env_trigger would help avoid having to set something like that up, but I could be oversimplifying the requirements to add such an entity. 
It wouldn’t be hard to program, but on the other hand it’s also not too difficult to just do it with standard entities. Plus, the benefit of using standard entities is that it’s more portable between other Source games. If you have a need to make a lot of these kinds of setups, that’s what prefabs are for.
Basically, prefer the standard entities whenever possible.
EDIT: To be clear, you don’t need a logic_timer. All you need to do is hook up the point_proximity_sensor’s “Distance” output to a logic_compare’s “SetValueCompare” input, and set the logic_compare’s “OnLessThan” output to whatever you want to trigger. This setup requires a grand total of two logic entities. That’s nothing.
oh wait so point_proximity_sensor will send it’s distance value to logic_compare without the need to actually call it? That is easier than I initially thought. I still think some sort of env_trigger or something would be beneficial, but I’ll stick w/ regular triggers and your suggested setup for now. Thanks for the tip!
One small thing that would be very useful would be a way to define what name a custom map gets in the saved game list- at the moment the canonical maps have their chapter titles displayed, but custom ones are stuck with their alphanumeric filenames.
There might be something that controls this already in the scripts directory, but since those files are themselves aggressively resistant to modding I have not looked at them in any detail.
So last night I just remembered that BSPZIP is a thing. I tried it out with Black Mesa, and it mostly works (other than the usual manifest/resource files). So, I think it would be pretty feasible to implement your idea if the BM programmers were to change the code to allow those files to be sourced from a BSPZIPped map.
Vscripting would be neat, or releasing some source files for us to modify would also be good.
It would be nice if we could import custom NPCs, kind of like we can with HL2/HL2 Ep2, as well as easily modify the current ones.
Custom weaponry, custom hands, etc. should all be a thing.
The NPC bit will probably never happen. Our process so far involves lots of hacks to get things working with the old animation sets from HL2. It isn’t just plug in and works.
You could allow us to use custom models for the npcs in Hammer, selecting them like you do for prop_statics and such.
You can actually do that through the character manifest, although sometimes the results can be a bit strange.
Three things I would like to see that are lighting-related, based on my recent… errrm… experiences with Office Complex.
-
A way to make lights direct-only (i.e. not bouncing) without naming them. Non-bouncing lights are useful for accent lighting and making the lighting in an area look ‘harsher’, and currently the only way to get lights not to bounce is to name them (the canon BM maps use this technique themselves for the shadow-generating lights in the stairwells in Office Complex, and possibly in other places as well). However, if you have a lot of named accent lights they can take out a sizeable chunk of the map’s entdata budget for something that could just be baked into the lightmap as usual and would have no reason to have IO properties, and they can interfere with the proper functioning of more conventional named lights that are actually turned on and off by taking up Source’s scarce lightmap “pages” unnecessarily.
-
A functional “maximum distance” parameter: In the FGD there is an option to cause lights to only cast a certain distance and then abruptly drop off to zero brightness, but it currently does not seem to have any effect at all. Having such a parameter would be very useful in preventing the “lighting pileup” problems that cause some surfaces to show up much brighter than others when multiple constant or nearly constant lights are placed in a room that is significantly longer or shorter in one dimension than in either or both of the the other two.
-
Support for negative RGB or brightness values in lights: I am imagining this behavior as being about what you would expect. A negative value would make the relvant R, G, or B channel of the lightmap darker, and as the light bounced around and attenuated that value would get closer and closer to 0. This would cap at 0 so that no actual negative values could exist in the finished lightmap- a 0, 0, -255 light (or, depending on how the property was expressed, a 0, 0, 255 light with negative brightness) shining on a white lightmap could make it completely not-blue (i.e. yellow), but that’s it. My primary interest in this sort of light is to add colored accents to very bright areas without making them even brighter, but I imagine this would also be very useful for making certain specific areas look darker or more shadowy when they are in the immediate presence of brighter lights- like in an office area where the lighting is very even (constant attenuation), making a pool of darkness under one burnt-out bulb.
I of course wouldn’t presume to command that these features be added, but I would very much appreciate at least some feedback on how feasible they would be.
After a few experiments with various sound and dialog systems, I have a couple more requests for whenever your programmers are finished with Xen and general engine updates (and have had some time to rest, of course)
- Implement this code so that the Stop input works on sounds without loop points.
- In addition to Sage J Fox’s suggestions on the previous page for custom per-map script files, per-map variants of sentences.txt, response_rules.txt, and, if at all possible, scenes.image (though as a binary file and something generated by an engine tool I realize that one’s a tall order!) would be greatly appreciated so we can get some more in-depth dialog going beyond just giving ambient_generics files with phoneme data and making an NPC the audio source entity.
I wonder how far ahead of the actual Xen update the engine update will be released?