Raeven0 - custom FGD question

[UltraProAnti]

what happened to auto resize on move_rope and keyframe_rope?

also: what happened to render mode: color in func_brush and func_illusionary etc?

i've used that rendermode in earlier maps (which i'll need to go back to do some more work on, so it's kinda important i know what 'color' is now), and valve used it on the white light brushes they used with fluoro lights

finally: why are ropes no longer drawn in hammer?

 

[TCfromBN]

finally: why are ropes no longer drawn in hammer?

But they are!

 

[UltraProAnti]

not in mine they're not. they were last time i used them, which was prior to installing Raeven0's FGD

 

[TCfromBN]

Somehow, I managed to forget that the title had custom FGD by the time I replied. :upstare:

 

[Raeven0]

Drool. Let's see.

From hl2-rae108.fgd... I removed auto-resize with a note that it was "broken", probably because it was unused in code or because I noticed that ropes resize themselves automatically no matter what.

For the render modes, I made a test map with a few brushes and models using the various modes, so my code looks like this:

	rendermode(choices) : "Render mode override" : 0 : "Used to set a non-standard rendering mode on this entity.  All render overrides implement FX Amount and FX Color.  'World Space Glow' is the same as 'Additive,' but if the sprite's origin is obscured, the entire sprite will be invisible." =
	[
		0: "Normal - no override"
		//1: "Color"  ***same as 2, commented out***
		2: "Texture - use FX Amount and FX Color"
		3: "Glow - sprites get bigger w/distance"
		4: "Solid - brushes absorb bullets?"
		5: "Additive - erase sprite background"
		//7: "Additive Fractional Frame"  ***same as 5, commented out***
		9: "World Space Glow - see below"
		10: "Don't Render"
	]

Ropes not drawn in Hammer... You know, that's a good question. They were drawn before! I'll see if anything's changed on the SDK side.

 

[UltraProAnti]

so 'color' = 'texture'? will decompiled valve maps automatically change 'color' to 'texture' for these brushes, or just generate an error?

i'm sure i've seen ropes NOT auto-resize. you'd think if they were parented to other objects that they would, but...

yes - ropes were drawn before, but not now. grr...

 

[Raeven0]

The two rendermodes function exactly the same, to the point that you can ignore any unrecognised keyvalue warnings Hammer generates. I'm just not a fan of redundancy

Really? I don't think I've ever seen a rope not follow what it was parented to. Hmm, do you think auto-resize might only be useful for Rigid ropes, which would intuitively not try to resize?

Ropes are no longer drawn because of a change Valve made to their SDK. Ropes by Valve's FGDs have a MoveSpeed property that is totally unused in-game, so I removed it from my FGD edits with no problems; however, at some point, Hammer stopped rendering ropes without a set MoveSpeed. :flame: Now I have to put a useless thing like MoveSpeed in. At least I can disguise it under the name "Rope Hack". ...

 

[UltraProAnti]

aha the culprit is found. movespeed isn't useless though, if it lets people see what their ropes are doing before compile. i've found this invaluable on more than one occasion

when can we expect this updated FGD?

 

[Raeven0]

I will be away by a couple hundred miles for most of next week, so I've quickly hacked together a few FGDs with a MoveSpeed() property on the ropes.

One day I'll get around to producing that version 1.0.9 that I always wanted, especially since summer is come.

 

[UltraProAnti]

thanks! d/l now

edit: ok i've checked it out and there's just one thing: the ropes are now drawing, however they are all drawing taut (even though i have slack set at 100, which in-game is pretty slack), regardless of what value is put in the 'slack' field

could it be that the missing auto-resize has something to do with this?

edit #2: the answer to that last question is no. i tried adding the auto-resize from the base.fgd back into yours and nothing changed. hmmm

 

[Raeven0]

Set the Position Interpolator to 2.

 

[UltraProAnti]

ok, got it now. thanks :up:

 

[UltraProAnti]

i just noticed something else, in light_dynamic. selecting 'down' from the angle dropdown gives you 90 0 0, which is in fact up - and vice versa

FYI

 

[Raeven0]

Which is Valve's problem, not mine.

Valve lights use a screwed-up pitch system. In Hammer, the light appears to be pointing up, but RAD and Source turn lights around completely before calculating how their light casts. I have no idea why. Instead of Pitch-Yaw-Roll, you have Yaw-Roll, and then that extra Pitch property that is totally redundant but has to be used anyway.