Bug fix - noclip touching triggers

Post tutorials on how to do certain tasks within game or engine code here.
Post Reply
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Bug fix - noclip touching triggers

Post by mh »

This one's shockingly simple. At the end of SV_Physics_Client, change this:

Code: Select all

SV_LinkEdict (ent, true);
To this:

Code: Select all

if (ent->v.movetype == MOVETYPE_NOCLIP)
	SV_LinkEdict (ent, false);
else SV_LinkEdict (ent, true);
Now when noclipping around a map for testing purposes you're no longer going to have to be careful to avoid teleports, changelevels, trigger_monsterjump shooting you into the air unexpectedly, etc.

Bonus Discussion

It's possible that noclip-but-do-touch-triggers may be intended/desired behaviour for a player edict in a mod, and this fix will break that. I personally can't think of any situation that would warrant it, but (1) I'm not a modder so I'm not qualified to do this thinking, and (2) stock ID Quake does nothing to prevent it.

Should we set another flag to detect if the noclip behaviour came from a console command and only run this behaviour if so?

Should noclip also force notarget behaviour?

Should this behaviour be developer 1 only?
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
taniwha
Posts: 401
Joined: Thu Jan 14, 2010 7:11 am
Contact:

Re: Bug fix - noclip touching triggers

Post by taniwha »

Nice, that one has been bugging me for a long time (but never enough to do anything about it). However, why not SV_LinkEdict (ent, ent->v.movetype != MOVETYPE_NOCLIP)? A good compiler will do the same thing (I've seen gcc do it), but I feel the one call is clearer than two separate calls. Can even do SV_LinkEdict (ent, !developer.value || ent->v.movetype != MOVETYPE_NOCLIP).

I think this is one of those things that id never fixed due to lack of time and pressing need, rather than intended design.

ps, I prefer to use "if" to select different code paths rather than simple parameter values (unless things start getting too messy, then I'll use an "if"). Also, if you prefer to keep the ==, use !(ent->v.movetype == MOVETYPE_NOCLIP).
Leave others their otherness.
http://quakeforge.net/
r00k
Posts: 1111
Joined: Sat Nov 13, 2004 10:39 pm

Re: Bug fix - noclip touching triggers

Post by r00k »

Nice this makes sense for noclip!
One thing i noticed, i ran over a trigger changelevel and it bounced me off the map. :O


something i added to noclip, (especially for viewing demos)

Code: Select all

	if (r_viewleaf && r_viewleaf->contents == CONTENTS_SOLID)// if spectating from off the map then make the walls transparent
	{
		glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
		glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA);
		if (r_novis.value)
			glDepthMask (GL_FALSE);
		glEnable (GL_BLEND);
		glColor4f (1, 1, 1, 0.5);
	}
	else
	{
		glColor4f (1, 1, 1, 1);
		glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
	}
...draw texture chains

Code: Select all

	if (r_viewleaf && r_viewleaf->contents == CONTENTS_SOLID)//R00k: Spectator 0/20 walls
	{
		glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
		glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
		glDisable (GL_BLEND);
		glDepthMask (GL_TRUE);
	}
reset...

This will draw all texture chains 50% transparent so u can noclip above the map or where ever and see all the players running around like ants ;)
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Bug fix - noclip touching triggers

Post by mh »

taniwha wrote:Nice, that one has been bugging me for a long time (but never enough to do anything about it). However, why not SV_LinkEdict (ent, ent->v.movetype != MOVETYPE_NOCLIP)? A good compiler will do the same thing (I've seen gcc do it), but I feel the one call is clearer than two separate calls. Can even do SV_LinkEdict (ent, !developer.value || ent->v.movetype != MOVETYPE_NOCLIP).

I think this is one of those things that id never fixed due to lack of time and pressing need, rather than intended design.

ps, I prefer to use "if" to select different code paths rather than simple parameter values (unless things start getting too messy, then I'll use an "if"). Also, if you prefer to keep the ==, use !(ent->v.movetype == MOVETYPE_NOCLIP).
Making code easier to read for people who have less experience with the language and may be confused if they see a condition as a function param I guess, but overall it's not a big deal and about as useful a point of discussion as an argument over brace styles. On the other hand, if you ever want to add another condition in which something different is done, if ... else makes it easier to do so and without having to disrupt pre-existing code too much, so it has it's benefits. I've been burned by that one before when trying to be too cutesy and reduce lines of code in this manner - future maintainability can be a very large motivator.

Specific example from my own code:

Code: Select all

if (RealFogDensity > 0)
	Shader = &d3d_AliasPixelShaders[SS_MESHFOG];
else Shader = &d3d_AliasPixelShaders[SS_MESH];
Why not use a ternary operator here? Because if I ever wanted to add a third condition in which a different pixel shader was selected I end up with a mess of nested ternary operators. And a fourth condition? Hello potential bugs, goodbye easy maintainability.

Ultimately the purpose of tutorials is to show info, not to be one person's ideal of syntactically perfect.

Another useful addition for noclipping, by the way:

Code: Select all

if (r_viewleaf->contents == CONTENTS_SOLID)
{
    glClearColor (0.2, 0.2, 0.2, 1.0); // or whatever...
    glClear (GL_COLOR_BUFFER_BIT);
}{
That can be optimized out into a single glClear call in R_Clear if people prefer, but noclip isn't exactly a high-performance mode anyway.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
taniwha
Posts: 401
Joined: Thu Jan 14, 2010 7:11 am
Contact:

Re: Bug fix - noclip touching triggers

Post by taniwha »

Indeed, it is more just style, and if/else does have its advantages, too. I was just curious.

Ah, yeah. grey does look a bit better than black.

What about fog? The noclip world looks a little odd when fog is enabled.
Leave others their otherness.
http://quakeforge.net/
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Bug fix - noclip touching triggers

Post by Baker »

Does this make it so you don't grab weapons and health boxes?

[Is the noclip movetype ever actually used in a mod? ]
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
taniwha
Posts: 401
Joined: Thu Jan 14, 2010 7:11 am
Contact:

Re: Bug fix - noclip touching triggers

Post by taniwha »

Baker: indeed it does.
Leave others their otherness.
http://quakeforge.net/
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Bug fix - noclip touching triggers

Post by mh »

Grey is better I think cos it's easier to see things when noclipping - with black a lot of detail gets lost (especially if lighting is dark).

Not too concerned about fog to be honest; I don't see this as a mode where correctness is important. All the same - turn off fog when viewleaf is CONTENTS_SOLID maybe? Given that the main purpose of noclipping out of a map is to see things, that seems to make sense.

And yeah, you won't pick up stuff either.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Post Reply