funk_breakable "pressure related&qu Created 9 years ago2015-05-29 07:53:26 UTC by 23-down

Hi this is little embarrassing but before I spend anymore time in trying to find a solution I rather ask. Perhaps one of you knows a faster method.

I'm rather tired at the moment so perhaps I simply can't find the solution that would otherwise fly straight into my head. Anyway I've got the following situation:

Hl1 - Op4 My func_tracktrain which drives just nicely is suppose to destroy few wood signs while colliding with it.

The specific signs are defined as func_breakable's however when the train passes through the objects - myself included it is as if they're func_illusionary's. I don't get it. I remember times when my trains got stuck on every little nonsense and now that I actually want something smashed nothing happens. ^^ Typical Hl always playing backwards on you. The flags for pressure are enabled. Of course they will break only when I directly jump onto them by leaving the train with noclip. ^^

Any ideas? I for once was thinking about an alternative by killing the named objects with a trigger_once however that is not really a solution as I'm in a non controllable Black Mesa train so the player may either walk in the front section of the train (which would be just fine) or stand at the rear section (which would be bad). So concluding that this is not an option.

How would you guys solve this issue?

If it's a func_tracktrain, could you use the Fire on Pass parameter of a path_track to break the signs when the train passes them? I imagine that would work much like the trigger_once option you suggest, except you can specify the break by where the train is rather than the player.

Ah fantastic idea yes I could do that Jessie thx..

Probably that's how it's done in HL, too.

Ya probably it did work so thanks again. Now I'm facing a new problem that doesn't make sense... But I'll post that in a separate topic shouldn't I be able to figure this out myself.

May as well post it here if you need to.

New Question:

Hi again since I don't wanna spam this forum with tons of questions that have probably been asked before I'll post my question in here.

This is purely hypothetical and I don't think it may even work at least I couldn't imagine how. But here we go:

Most of you surely remember the rotating lift prior to the test chamber in Hl1 right?

Now I was wondering if a similar elevator may be possible but instead of having doors opening from left to right may it be possible to have doors that act like train barriers?

So for example: They close my elevator at 90 degrees and when reaching the destination another 90 degrees further we would be at 180 degrees total.

Wont be possible will it or could you think of anything?

It could be possible, with a ridicoulusly complex setup of func_tracktrains.

I can't make sense of what you asked. Can you provide a drawing or something?

Well imagine this:

You enter an elevator facing north. Now like in half-life this elevator will rotate while driving up to the next level. So instead of facing north when you originally entered the elevator it's now facing west. 90 degrees into another direction.

The question was if it's actually possible to have closing doors that also rotate with the elevator that are attached to the elevator. But the whole question was pointless anyhow engine wise it's just not possible.
I did it in a different fashion now.

Which brings me to a new problem I've just stumbled upon.

I've got that same regular elevator (simple track train with 2 destination points)

But I don't want it accessible till the player finds a key card. I do know how the key card thing works on func_doors combined with an env_globe & multisource but does the same thing actually work on a func_train?

I'm currently experimenting how I could get it working but once I've found the keycard which actually aims at the elevator nothing happens the lift wont move.

EDIT: Weird I just redid the whole thing from scratch as I couldn't imagine why it wouldn't work and suddenly it does. Although everything is exactly the same as before no changes.. Hammer is so weird - so often.

First answer - like Dr. Orange said, it might be possible using some weird setup of func_tracktrains and overlapping path_tracks. Hard to debug without moving everything around.

Second answer - yes.

And a new question...

My map is progressing rapidly and my map pack requires only 2 more maps for implementation.

I once again am facing a problem that annoys me and I don't know what else to do. I'd imagine many of you had similar issues yourself in the past so I ask right away.

I've got a red texlight which I want to turn off by replacing it with a green light once the power has been restored. So far so good my green light appears etc..

However the red light source wont vanish. What I did: Defining my red texlight in an info_texlights with a 0 brightness output (I've got it in my lights.rad with the real output)

and then having a func_button aiming at my texture (func_wall). The red glowing texture itself vanishes which would suggest that everything is working fine. However the light that was shining in the surroundings of it remains.

So the original texture stops shining but the light still emits where it used to shine (and still does).

Any ideas why that's happening and how to fix it?

Btw in it's place will appear a 2nd brush that was formerly hidden per func_wall_toggle which has a green texture instead at least that's working so far. Of course having red and green light sources mixed looks not that great.

EDIT: Once again I was able to manage it myself.. env_render helped.. Till today I barely used these entities so it's easy to forget about them.

Before I go dig up how I was making switchable texlights in my TWHL Tower map, if your green light is working properly but not the red one, have you tried setting up the red one the same way as the green one?

Nevermind, guess I missed your edit.

I always thought texture lights were only for static lights and trying to turn them on/off wouldn't work.

The question was if it's actually possible to have closing doors that also rotate with the elevator that are attached to the elevator. But the whole question was pointless anyhow engine wise it's just not possible.

Not with the standard engine, no. This is why more people need to use spirit. That setup would be super easy.

Oh trust me Urby I would switch to it right away unfortunately without the Op4 entities my opposing Force mod is rather pointless and considering that barely anyone ever in all those years created stuff for it I'm tempted to go along with it..

How ever if you do know one or two things about coding and could help me setting it up spirit v1.8 with op4 entities I'm more than willing to swap over..