Bug fix - noclip touching triggers

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

  Code:

SV_LinkEdict (ent, true);

To this:

  Code:

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?

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).

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:

   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:

   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

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:

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:

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.

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.

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

[Is the noclip movetype ever actually used in a mod? ]

Baker: indeed it does.

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.