Newbie DarkRadiant Questions

[Obsttorte]

frob_simple means that you can frob it even if you are carrying a body. What you need (or mean) is frob_peer.

 

Btw.: If I frob something, it isn't highlighted anymore.

[Moonbo]

Whoops, you're right, I meant to say frob_peer not frob simple. When you frob and grab a ragdoll so that it's in the grabber, it most certainly continues to highlight. But it's peers (in this case the head) stop highlighting. I'm looking for a way that the frob_peer items continue to highlight when in the grabber just as the moveable being grabbed does.

[Obsttorte]

As said, on my side objects in the grabber are not highlighted, so I cannot reproduce what you are aiming for. Maybe someone else can

[Moonbo]

Hrm...so you're saying if you look at a moveable candle holder in TDM (extinguished for better visibility) it will highlight, but if you pick it up in the grabber the holder will un-highlight? Weird...for me it will still be highlighted while it's in the grabber (though the attached candle will un-highlight, which is the issues I want to avoid).

Edited September 20, 2014 by Moonbo

[grayman]

@Moonbo:

 

Starting with 2.02, if you grab a body and drag it around, the head will highlight. Is this not happening?

 

Please describe how you've set up your candlestick and its holder.

 

Obs probably has "Highlight held objects" disabled in his Settings, and you have it enabled, which would explain the different highlighting behavior.

[Moonbo]

Hey Greyman,

 

Thanks for the feedback. I was using the candle holder as an example. Here is my setup: I have a func_static made of a brush, and I have a moveable made out of a second brush. The func_static brush is a frob_peer of the moveable brush such that when I pick up the moveable brush both brushes move around. Because they're frob_peers both brushes highlight when I look at one of them. However, when I grab the moveable, the func_static brush stops highlighting. I don't have any other spawnargs besides the ones setting frobability and the frob_peer/bind relationships. What I'd like to have happen is that the func_static brush remains highlighted even while the moveable brush is in the grabber.

 

Thanks!

Edited September 20, 2014 by Moonbo

[grayman]

When you grab an object like that, apparently the master is grabbed (the object all the other objects are bound to), and only the master remains highlighted. I made a special case in 2.02 when a body is grabbed, so that the body and its bound head are highlighted, but this change doesn't apply to non-bodies.

 

I imagine the decision to grab the master was made so that you'd pick up candlesticks & their holders by the holder, which makes sense in the real world.

 

Unless someone can come up with a script workaround to give you what you want, you'd need to request a code change. Since it's not the norm, we'd prolly create a new spawnarg that says to use the new behavior (highlight everything) when that spawnarg is used.

[Obsttorte]

Whether an object shows up highlighted or not is controlled via the shaderParm11. So you could give all objects in question a scriptobject that copies the shaderParm11 value over to the bound children.

 

An easier approach may be to run an infinite loop which checks whether the player has something in his grabber every frame. If so, it traverses all the bound entities and set its shaderParm11 to 1. The script may also take sure to set said value to zero once the object is released from the grabber.

[Goldwell]

I have a vent section in my FM and I want to change the foot step noise the player makes when crawling through the vent because the default one does not sound right to me.

 

Is it possible to have a custom noise whenever the player stands on things?

[demagogue]

I think the two things you could try are either replacing the old footstep sounds in your own pk4 (remember to preserve the same folder structure as the root folder in your pk4, then any file in the pk4 takes priority), or you could make your own surface material with the new sound, either on the vent material itself (a custom vent brush) or on a nodraw surface brush (a custom nodraw brush you layer on top of the vent), I mean take one of the existing materials and modify it to use your own footsteps.

 

Edit: For that matter, the first thing you might try is the different nodraw surface brushes already there, putting them on top of the vent ground, and see if there's another sound in there that fits better.

[SteveL]

Yes have a look through the tdm_nodrawsolid_ textures in the common/ folder. There are over a dozen custom footstep sounds ready made.

[Melan]

I have a question regarding readables. Is there a straightforward way to set up a readable that does not display a GUI, just text on the screen? This was a very useful function in Thief.

[Tels]

I have a question regarding readables. Is there a straightforward way to set up a readable that does not display a GUI, just text on the screen? This was a very useful function in Thief.

 

You mean by frobbing the readable?

 

It can easily be done with a custom GUI and a bit of custom script that displays the text. I've written such a module for SM, I'm sure you could re-use it (or just parts of it, my version even deals with texts that are displayed for a certain amount of time and then shows the next and so on).

[Springheel]

Just give the readable entity a "frobable" "0" spawnarg (not sure on the spelling).

[nbohr1more]

I will go ahead and say that this request is written in slightly confusing (nebulous) terminology but that is probably a

byproduct of my own jargon vernacular too. "No GUI" can mean "no interactive note", "no GUI coding", or (what I think

you want) "no parchment, just text over the screen". The last one would be solved by Tels' method while the first would

be Springheel's method.

[Melan]

Thanks! I meant both possibilities.

 

I will try the lazy method first, then see if it is all right that way. It was very straightforward in Thief, while making a custom GUI and a custom script is significantly beyond my skills.

[buck28]

Anybody seen this before? I am using the stormy skybox, with lightning and thunder. Way on the other side of my map and deep underground, I have a patch, floating,(not touching anything) with a cobweb texture. It flashes when the skybox flashes? Or at least I think that is what is happening. It looks as if it would be in a barn, with a clear view to the lightning flash; but it is in a room, underground. Can't wrap my head around this one. The other cobwebs are fine. What would cause the skybox, to connect with one small patch in this way? I'm baffled.

 

STORMY SKYBOX + COBWEB PATCH = FLASHING COBWEB????

[Sotha]

Anybody seen this before? I am using the stormy skybox, with lightning and thunder. Way on the other side of my map and deep underground, I have a patch, floating,(not touching anything) with a cobweb texture. It flashes when the skybox flashes? Or at least I think that is what is happening. It looks as if it would be in a barn, with a clear view to the lightning flash; but it is in a room, underground. Can't wrap my head around this one. The other cobwebs are fine. What would cause the skybox, to connect with one small patch in this way? I'm baffled.

 

STORMY SKYBOX + COBWEB PATCH = FLASHING COBWEB????

 

Does the room have caulk? Light can shine through caulk.

 

If nothing else is illuminated, but only the cobweb, try to move the cobweb a bit. Sometimes the decals can be just in a problematic position and moving it helps.

[SteveL]

Have you tried noclipping and stepping into the wall of the underground room? That way you should be able to see both the cobweb and the skybox at the same time and you'll be able to tell for sure whether they're in sync.

 

Does the cobweb have any globals in its material shader? You can right-click on the texture in DR's Media tab to see the shader. That's the only way I can think of off-hand that a texture might change appearance based on what some other texture is doing.

 

Also, looks like that skybox comes with two light-flashing entities: one in skybox itself, and another some distance below for you to place in your map. It's called "fx_thunder". If you didn't position that deliberately, use 'J' to search for it in DR and see where it ended up!

[buck28]

Thanks gentleman; I will try both.

[NeonsStyle]

Does the room have caulk? Light can shine through caulk.

 

Excellent tip. Didn't know this, and it solved a problem I was having Thanks.

[buck28]

Do patches need to be converted to func static, before release, or is it ok to leave them as worldspawn? It seems I heard that it would improve performance, somewhere, but can't recall where.

Or can they be converted? I haven't even tried to see if that would work yet or not. If not, good.

[Moonbo]

Hey buck28,

 

Totally fine to leave patches as worldspawn. If you're using patches to make uneven ground, then it might be a good idea to turn them into FS and give them the noshadows spawnarg, otherwise I haven't noticed a big change in performance by leaving patches alone.

[Sotha]

Complex patches can be notoriously shadow tris hungry. For instance, if you have a big piece patch working as a uneven ground, you should ALWAYS make it into a func_static and have "noshadows 1"

My justification is this. Let's say the ground floor piece is 1000 tris. Not very complex. One light hits it. Now you have 1000 tris object and 1000 shadow tris. If two lights hit it, you will have 1000 tris object, and 2000 shadowtris. And the worst part is that these shadow tris are never visible to the player because they are cast on the geometry below the ground patch!

 

As a rule of a thumb: make all patches (or larger collection of batches and brushes) into func_static, and make them all non-shadow casting if they do not absolutely need a shadow. You will save a lot of shadowtris, your mission runs much smoother, and nobody is gonna notice the lack of shadows. Of course, leave shadows on for objects that do require shadows.

 

Another rule of a thumb: if the object is large enough that it's shadow has a gameplay purpose, let it have it's shadow. Otherwise always disable shadows. If something looks very odd without their shadow, as an exception, let it have a shadow. This little guideline takes you very far.

[buck28]

@Moonbo

@Sotha

 

Thanks to both. That helps a lot!