I waited four years to not have my suggestion picked. Thus, I'm going to nitpick. There should be grammatical marks at the ends of the all of the quoted sections. That said...
huge, perfectly spherical steel balls [and then some joke about balls of steel]
Methinks "snap to grid" refers to snapping to the grid at it's current grid size, i.e. every 4 units with a grid size of 4, to every 1 unit when un-snapped. Try holding Alt and moving, I think that goes off the grid. That said, there's few practical uses for moving things completely off the grid. May I inquire as to what you are doing?
Make the switch/button trigger a multi_manager. Add parameters to the multi_manager where the keys are the names of the light entities, and the values are how long you want before they get triggered. Sorry if that's not in depth enough, typing this on my phone at work.
Assuming that you've set the multisource up appropriately and that's just some glitch, try having the monsters trigger trigger_relays instead, which in turn trigger the multisource.
It might solve the problem, but that method is typically frowned upon for causing other issues, as well as just being a bit sloppy.
You probably could get away with doing that if the map isn't too complex, but the ideal way to do the sort of thing you have in that picture is using vertex manipulation to make brushes that mimic those shapes without cutting into each other.
Button targets the door. Set the door's angle to the direction you want it to move. Give it a negative lip value to how far you need it to move. Set the Toggle flag.
Well, a simple set up of a func_button and a func_door with a heavy negative "lip" value should do it. Is there something specific about it that you're trying to do?
Even if he hadn't already addressed this very issue stating that he won't do anything about it, the very last post also says that he won't be working on it for an indefinite amount of time.
[Obligatory "if-it-works" clause] Do trigger_changetargets change the end/start of an env_beam? If so, some clever use of those could decouple the beam.
I have conducted tests under the observatory eye of DiscoStu, and have discovered two things: 1) trigger_changetargets cannot alter the target of an env_beam. Disabling Smart Edit shows that neither the end nor start targets use the parameter "target"; this is likely why. 2) An env_beam set to target "player" neither follows the player nor targets him/her in any way. The beam defaults to targeting the map's origin.
Both these issues may have solutions in Spirit (indeed, the first can be worked around in vanilla), and while I could guess at how to solve the first, the second, far more significant issue I am less sure of.
Posted 8 years ago2016-05-21 10:33:48 UTC
in HL3Post #330174
Let's face it. If it ever exists, the only real way it can possibly happen by this point is it just showing up on Steam one day. They can't announce that shit anymore.
Testing it out on a different editor isn't that much of a hassle. You would just have to set up the game and compile configs again, which is easier given that A) You would already have everything you need, just have to point to it, and B) Sledge organizes those configs more neatly than Hammer.
P.S. Sledge is nigh-identical to Hammer in function, you don't have to learn anything. It'd take maybe ten minutes to test this stuff out, tops. (As for Jackhammer, I wouldn't know.)
I'd say first step is look for any malformed brushes. If you've been doing any vertex manipulating or clipping, check those brushes for invalidity to make sure they aren't causing the trouble. I'm pretty sure invalid brushes have caused strange clipping errors for me in the past.
There's a trigger_inout that can do that very thing in Spirit, but I don't believe there's any one entity to achieve the same effect in vanilla Half-Life.
I haven't really been listening to much music lately. I usually listen to music when it's all I can really do (while walking, driving, etc.), and I haven't had a whole lot of that. Nevertheless, take this.
I mean, a disco, with as many lights as one would expect... would probably be pretty hard to pull off under the above limits. Maybe not impossible... but tricky.
EDIT: Just realized this is in the Source forums. I don't know if the below still applies in Source.
Make sure to check your compile logs. If you have an area with many different styles of lights / lights that turn on/off independently, it may not compile correctly due to the exponential amount of light data required. Adding a targetname would factor into this because it means the light can then be triggered on/off.
1) Can you close the lid when you are outside of it? 2) When you say you "can't close the lid", do you mean that it starts to close but then stops and goes back, or that it doesn't move at all?
I don't know what the hell this conversation is even about anymore. Anywho...
Pengy, have you considered implementing skewing textures? I'm vaguely aware that you can do it with something like "align to view" and certain camera angles — I'll have to find the tutorial or whatever it was that detailed that — but a more standardized method could be helpful to some.
Could someone please confirm that you can only nudge vertices with the arrow keys if you drag-select them (and cannot if you click-select them)? It's kinda annoying.