Forum

Bug fix - noclip touching triggers

Post tutorials on how to do certain tasks within game or engine code here.

Moderator: InsideQC Admins

Bug fix - noclip touching triggers

Postby mh » Tue Jul 17, 2012 10:05 pm

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
User avatar
mh
 
Posts: 2287
Joined: Sat Jan 12, 2008 1:38 am

Re: Bug fix - noclip touching triggers

Postby taniwha » Tue Jul 17, 2012 11:18 pm

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/
taniwha
 
Posts: 399
Joined: Thu Jan 14, 2010 7:11 am

Re: Bug fix - noclip touching triggers

Postby r00k » Tue Jul 17, 2012 11:30 pm

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 ;)
r00k
 
Posts: 1108
Joined: Sat Nov 13, 2004 10:39 pm

Re: Bug fix - noclip touching triggers

Postby mh » Wed Jul 18, 2012 12:11 am

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
User avatar
mh
 
Posts: 2287
Joined: Sat Jan 12, 2008 1:38 am

Re: Bug fix - noclip touching triggers

Postby taniwha » Wed Jul 18, 2012 1:38 am

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/
taniwha
 
Posts: 399
Joined: Thu Jan 14, 2010 7:11 am

Re: Bug fix - noclip touching triggers

Postby Baker » Wed Jul 18, 2012 1:49 am

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 ..
User avatar
Baker
 
Posts: 3661
Joined: Tue Mar 14, 2006 5:15 am

Re: Bug fix - noclip touching triggers

Postby taniwha » Wed Jul 18, 2012 2:06 am

Baker: indeed it does.
Leave others their otherness.
http://quakeforge.net/
taniwha
 
Posts: 399
Joined: Thu Jan 14, 2010 7:11 am

Re: Bug fix - noclip touching triggers

Postby mh » Wed Jul 18, 2012 2:08 am

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
User avatar
mh
 
Posts: 2287
Joined: Sat Jan 12, 2008 1:38 am


Return to Programming Tutorials

Who is online

Users browsing this forum: No registered users and 1 guest