quake-c-users — Email support

Re: [Quake-C] sv_maxspeed

[Cobalt <co...@te...>]

Ok, I got it to compile, however I dont see a speed increase , at least not 
significant.

The sideways "pulling" effect I had with the old code is gone though which 
is good.

                    // Try new calculation sugguested by Number 6
                    local float f, ms, v;

                    ms = cvar("sv_maxspeed");
                    f =  ms * 1.6; // at 320 max, this is 576

                    v = vlen(self.velocity);
                    if ((!self.cl[CL_CMD_FORWARD] || !self.cl[CL_CMD_SIDE]))
                    {
                    if (v > ms)
                    self.velocity = self.velocity * 0.95;// (ms / v); // cap 
it
                    }
                    else
                    if (v < f)
                    {
                    if (self.cl[CL_CMD_FORWARD] > 20)
                    self.velocity = self.velocity * (f / v);
                    else
                    {
                    f = ms * 1.25;
                    if ( (fabs(self.cl[CL_CMD_SIDE]) > 20) || 
(self.cl[CL_CMD_FORWARD] < 20) )
                    self.velocity = self.velocity * (f / v);
                    }
                    }

       I am guessing the CL_CMD  side and fwd are sending the values ok, 
though not sure if  20 is the velocity or something else?
       This is assumming we have the rune, and we have maxspeed set to 350 
last time I looked.

        I forgot, there is a [ showspeed ] cvar you can activate which will 
show your moving speed nead the hud. So will do some more tests.




 

Re: [Quake-C] sv_maxspeed

[<qu...@ca...>]

On 2016-04-03 14:58, Cobalt wrote:
> Will try putting this fix in later.
> 
> Runequake seems to have the players rune thinking every frame, then it
> Compares what Rune you got and calls other stuff, so for example the 
> Athlete
> Rune calls:
> 
> 
> void ()
> Athlete_Run =
> {
>  if ((self.cl[CL_CMD_FORWARD] || self.cl[CL_CMD_SIDE]) && self.flags &
> FL_ONGROUND)
>   if (vlen(self.velocity) < 440) // Cobalt fix attempt for bug
>   self.velocity = self.velocity + self.velocity * 0.10;
> };
> 
> 
> Is there an advantage putting the code in player run? I guess I will 
> try
> your code there first, but as for the rune_flag stuff you wrote,
> basicly my side looks like this:
> 
> if (self.runetype == RN_ATHLETE)  Athlete_Run ();
> 
> So would it now look like:
> 
> if (self.runetype & RN_ATHLETE) k = k + 1;
>  else k =  1;
> 
> ??


k is a counter for the haste runes.

This is the standard haste rune:
if (self.rune_flag & RUNE_FLG_HS) k = 1;

This is for the haste TECH from lithium:
if (self.rune_flag & TECH_TEIM) k = k + 1;

What this code does is set k = 1 for the haste rune, or the tech.
If you have both, k gets set to 2, then tweaked for the math.

If you only have one rune in use, that math can be a lot simpler.

You could just use k = 1 if RN_ATHLETE is true;
The else logic you have with the math from my code would always cause 
the haste effect.

I like the techs because they have slightly different effects.
And that you can combine runes and techs for even more possibilities.

Of course once you have runes, you always want to have one - or you
end up at a disadvantage.

With runes in DM it is often about getting the combo of rune and tech
that give the advantage you want.

Re: [Quake-C] sv_maxspeed

[Cobalt <co...@te...>]

Will try putting this fix in later.

Runequake seems to have the players rune thinking every frame, then it 
Compares what Rune you got and calls other stuff, so for example the Athlete 
Rune calls:


void ()
Athlete_Run =
{
 if ((self.cl[CL_CMD_FORWARD] || self.cl[CL_CMD_SIDE]) && self.flags & 
FL_ONGROUND)
  if (vlen(self.velocity) < 440) // Cobalt fix attempt for bug
  self.velocity = self.velocity + self.velocity * 0.10;
};


Is there an advantage putting the code in player run? I guess I will try 
your code there first, but as for the rune_flag stuff you wrote,
basicly my side looks like this:

if (self.runetype == RN_ATHLETE)  Athlete_Run ();

So would it now look like:

if (self.runetype & RN_ATHLETE) k = k + 1;
 else k =  1;

??

Then of course the rest of the math.

===
Cobalt


----- Original Message ----- 
From: <qu...@ca...>
To: "Cobalt" <co...@te...>; "QC" 
<qua...@li...>
Sent: Saturday, April 02, 2016 12:59 AM
Subject: Re: [Quake-C] sv_maxspeed


>I remember making the haste rune due a player speed increase being a 
>headache.
> The old rune code only sped up weapon fire and speed.
>
> I have this in player_run
>
> // haste run faster - moved up here for morphs
> local float f, ms, v, k;
> k = 0;
>
> if (self.rune_flag & RUNE_FLG_HS) k = 1;
> if (self.rune_flag & TECH_TEIM) k = k + 1;
>
> if (k)
> {
> if (k > 1) k = 1.2;
> ms = cvar("sv_maxspeed");
> f =  ms * 1.6 * k; // at 320 max, this is 576, for both runes 691
> if (self.movetype == MOVETYPE_FLY) f = ms * 1.4;
> v = vlen(self.velocity);
> if (!self.movement_x && !self.movement_y)
> {
> if (v > ms)
> self.velocity = self.velocity * 0.95;// (ms / v); // cap it
> }
> else
> if (v < f)
> {
> if (self.movement_x > 20)
> self.velocity = self.velocity * (f / v);
> else
> {
> f = ms * 1.25 * k;
> if (self.movetype == MOVETYPE_FLY) f = ms * 0.9; // flight speed side & 
> back normally .8 * ms
> if ( (fabs(self.movement_y) > 20) ||  (self.movement_x < 20) )
> self.velocity = self.velocity * (f / v);
> }
> }
> }
>
> This code uses sv_maxspeed as a base.  I'm pretty sure it ignores 
> cl_forwardspeed.
> It creates the cap and then makes some tweaks.
> Similar to yours, but with more math.
>
> I dont remember all the details, but the tweaks are important.
> This runs every 1/10 a sec in player frames.
>
> It seems really cool.  But controling movement is hard.  Especially with 
> both haste runes!
> If there is any challenge in nav, with haste it sucks.
>
> In singleplayer you could use slowmo and velocity mod to do Flash (dc 
> comics char.) type stuff.
> Or a matrix type bullet time.  That would be wicked.
> Wont work in DM or coop though.
>
>
> On 2016-04-01 13:44, Cobalt wrote:
>> Trying to fix a bug in the old Runequake QC involving an athletic rune 
>> which
>> makes the player have a slightly faster velocity.
>>
>> Apparently if you set your clients cl_forwardspeed way high you get crazy
>> speed with it. It uses this code:
>
>
> It shouldnt.  At least it wont go past sv_maxspeed.
> And if you bump that up, then any player could exceed the usual limit.
> I'm not sure if dp fixes it or how, but in the old engines diagonal moves, 
> wall hugging and bunny hopping
> all violated sv_maxspeed by some amount.
>
>
>>
>> if ((self.cl[CL_CMD_FORWARD] || self.cl[CL_CMD_SIDE]) && self.flags &
>> FL_ONGROUND)
>>   self.velocity = self.velocity + self.velocity * 0.10;
>>
>>       As an fix, we took the code and  changed it to:
>>
>>        if ((self.cl[CL_CMD_FORWARD] || self.cl[CL_CMD_SIDE]) && 
>> self.flags &
>> FL_ONGROUND)
>>        if (vlen(self.velocity) < 440) // Cobalt fix attempt for bug
>>       self.velocity = self.velocity + self.velocity * 0.10;
>>
>>
>> Apparently its an improvement as your speed does not perpetually 
>> accelerate,
>> however theres a side effect where you can have some
>> increased movement sideways and not always recover quickly when moving in 
>> a
>> straight line.
>>
>> This case the engine is a port of the old Proquake engine, and its able 
>> to
>> hack into the client with thos cl_ commands I guess.
>
>
> That does sound pretty hacky.  I had no idea proquake did such things.
> Ideally, the server should always maintain ents, with client side stuff 
> for HUD, fancy gfx, etc.
>
>
>> sv_maxspeed is usually 320 by default, however Runequake has it set to 
>> 350.
>> We originally thought it was 400, so thats why we set the fix to be
>> < 440, so I guess we can try < 385 to see if that helps, but was more
>> curious if there was a better option than the velocity, other than 
>> porting
>> to Darkplaces and using
>> sv_playerphysics...which is what we may wind up doing anyhow one day.
>>
>
> Yep, these days using an old engine is tricky.
> 

Re: [Quake-C] sv_maxspeed

[<qu...@ca...>]

I remember making the haste rune due a player speed increase being a 
headache.
The old rune code only sped up weapon fire and speed.

I have this in player_run

// haste run faster - moved up here for morphs
	local float f, ms, v, k;
	k = 0;

	if (self.rune_flag & RUNE_FLG_HS) k = 1;
	if (self.rune_flag & TECH_TEIM) k = k + 1;

	if (k)
	{
		if (k > 1) k = 1.2;
		ms = cvar("sv_maxspeed");
		f =  ms * 1.6 * k; // at 320 max, this is 576, for both runes 691
		if (self.movetype == MOVETYPE_FLY) f = ms * 1.4;
		v = vlen(self.velocity);
		if (!self.movement_x && !self.movement_y)
		{
			if (v > ms)
				self.velocity = self.velocity * 0.95;// (ms / v); // cap it
		}
		else
		if (v < f)
		{
			if (self.movement_x > 20)
				self.velocity = self.velocity * (f / v);
			else
			{
				f = ms * 1.25 * k;
				if (self.movetype == MOVETYPE_FLY) f = ms * 0.9; // flight speed 
side & back normally .8 * ms
				if ( (fabs(self.movement_y) > 20) ||  (self.movement_x < 20) )
					self.velocity = self.velocity * (f / v);
			}
		}
	}

This code uses sv_maxspeed as a base.  I'm pretty sure it ignores 
cl_forwardspeed.
It creates the cap and then makes some tweaks.
Similar to yours, but with more math.

I dont remember all the details, but the tweaks are important.
This runs every 1/10 a sec in player frames.

It seems really cool.  But controling movement is hard.  Especially with 
both haste runes!
If there is any challenge in nav, with haste it sucks.

In singleplayer you could use slowmo and velocity mod to do Flash (dc 
comics char.) type stuff.
Or a matrix type bullet time.  That would be wicked.
Wont work in DM or coop though.


On 2016-04-01 13:44, Cobalt wrote:
> Trying to fix a bug in the old Runequake QC involving an athletic rune 
> which
> makes the player have a slightly faster velocity.
> 
> Apparently if you set your clients cl_forwardspeed way high you get 
> crazy
> speed with it. It uses this code:


It shouldnt.  At least it wont go past sv_maxspeed.
And if you bump that up, then any player could exceed the usual limit.
I'm not sure if dp fixes it or how, but in the old engines diagonal 
moves, wall hugging and bunny hopping
all violated sv_maxspeed by some amount.


> 
> if ((self.cl[CL_CMD_FORWARD] || self.cl[CL_CMD_SIDE]) && self.flags &
> FL_ONGROUND)
>   self.velocity = self.velocity + self.velocity * 0.10;
> 
>       As an fix, we took the code and  changed it to:
> 
>        if ((self.cl[CL_CMD_FORWARD] || self.cl[CL_CMD_SIDE]) && 
> self.flags &
> FL_ONGROUND)
>        if (vlen(self.velocity) < 440) // Cobalt fix attempt for bug
>       self.velocity = self.velocity + self.velocity * 0.10;
> 
> 
> Apparently its an improvement as your speed does not perpetually 
> accelerate,
> however theres a side effect where you can have some
> increased movement sideways and not always recover quickly when moving 
> in a
> straight line.
> 
> This case the engine is a port of the old Proquake engine, and its able 
> to
> hack into the client with thos cl_ commands I guess.


That does sound pretty hacky.  I had no idea proquake did such things.
Ideally, the server should always maintain ents, with client side stuff 
for HUD, fancy gfx, etc.


> sv_maxspeed is usually 320 by default, however Runequake has it set to 
> 350.
> We originally thought it was 400, so thats why we set the fix to be
> < 440, so I guess we can try < 385 to see if that helps, but was more
> curious if there was a better option than the velocity, other than 
> porting
> to Darkplaces and using
> sv_playerphysics...which is what we may wind up doing anyhow one day.
> 

Yep, these days using an old engine is tricky.

[Quake-C] sv_maxspeed

[Cobalt <co...@te...>]

Trying to fix a bug in the old Runequake QC involving an athletic rune which 
makes the player have a slightly faster velocity.

Apparently if you set your clients cl_forwardspeed way high you get crazy 
speed with it. It uses this code:


if ((self.cl[CL_CMD_FORWARD] || self.cl[CL_CMD_SIDE]) && self.flags & 
FL_ONGROUND)
  self.velocity = self.velocity + self.velocity * 0.10;

      As an fix, we took the code and  changed it to:

       if ((self.cl[CL_CMD_FORWARD] || self.cl[CL_CMD_SIDE]) && self.flags & 
FL_ONGROUND)
       if (vlen(self.velocity) < 440) // Cobalt fix attempt for bug
      self.velocity = self.velocity + self.velocity * 0.10;


Apparently its an improvement as your speed does not perpetually accelerate, 
however theres a side effect where you can have some
increased movement sideways and not always recover quickly when moving in a 
straight line.

This case the engine is a port of the old Proquake engine, and its able to 
hack into the client with thos cl_ commands I guess.

sv_maxspeed is usually 320 by default, however Runequake has it set to 350. 
We originally thought it was 400, so thats why we set the fix to be
< 440, so I guess we can try < 385 to see if that helps, but was more 
curious if there was a better option than the velocity, other than porting 
to Darkplaces and using
sv_playerphysics...which is what we may wind up doing anyhow one day.

Re: [Quake-C] Frikbot, dynamic waypoints

[Cobalt <co...@te...>]

Made some progress with the Frikbot ways, seems you can use Frikfile to save 
them, though the older version Frikbot Im using had the code commented out , 
I just uncommented it and seems to save them.

I loaded up this converted Doom map (babel) and ran around doing things - 
tried to cover all the items , then saved them apparently seemed to go ok, 
however the stuff in the middle of the map didnt get any ways made? 
Strange....and the bots seem to pick up routes and drop them.

Was curious if Number 6 or anyone here wants to try loading the map and the 
ways in a local session of Frikbot and let me know what they see?

The map and the ways are in zip format here [ 
http://tempsend.com/89B603A4AC ]

===
Cobalt


----- Original Message ----- 
From: "Cobalt" <co...@te...>
To: "QC" <qua...@li...>
Sent: Saturday, January 16, 2016 3:33 AM
Subject: Re: [Quake-C] Frikbot, dynamic waypoints


> Hi 6
>
>> So, I ported frikbot into the code recently.
>> (Which I have decided to re-mark v2.0 and dispense with 1.07, this will
>> be nothing like 1.06)
>> You can see the trail of waypoints, one every 128 units or so.
>> I might loosen that up a bit, a ton get made on large levels.
>
> Which version of Frikbot is it?
>
> A guy in Inside 3d called Dr Shadowborg made a newer unoficial release 
> that
> he linked me to. There
> is a new routing for selecting the bots spawn that brings telefragging to
> nearly 0, and works well.
>
> Also it looks like the bot fires while roaming the waypoint path , and I
> dont remember the FRikbot that
> came with Q1 Arena doing that, so I am guessing its his changes taking
> effect.
>
> Hes also modified bot_angle_set () a great deal. Mostly randomizing the 
> aim
> x and y a bit based on skill.
> I believe hes right, that the code as is aims too perfectly. The reason I
> posted about dmg_take earlier is that
> Frikbot drives that flash and tilt effect bonkers with the old angle set
> code...and a skill > 0 bot. The aim is too perfect and your screen is red
> constantly, making it impossible to play with alot of bots. Hes put in 
> other
> changes like aiming at the feet with the RL, which is a good idea, however
> its only good if enemy.absmin_z = bot.absmin_z ...otherwise another calc 
> is
> needed...which I am working on.
>
>
>> Cool.  All I need to do is change that number, code is already done.
>> It is also possible the bots will play a level better with more
>> waypoints.
>
> Not sure if Im understanding what this mod does. Is it making more
> waypoints, or as you say
> the player / real client is making them as he moves? I dont think the
> original Frikbot has the player laying waypoints,
> at least not in my code travels through there.
>
>> And I'm pretty sure the bots themselves make waypoints as well.
>
> The version I have, I know they dont. Its an older version I think called
> FBX_b, but I am gradually modding it , and
> keping the b_ version in tact because in some ways its got its own
> characteristics worth keeping over the newer version.
>
>> So, load a level, visit everywhere - or at least the interesting places.
>> And then frikbot should know the level.
>> I can not say how those compare to human coded ones.
>
> Ok then I guess Ill have to peek at your code, I guess you are now laying
> waypoints with the client.
> If so, are you creating way files specific to maps?
>
> Also not sure , but if the waypoints have an EF_NODRAW flag, on them, they
> wont be part of the network traffic packets, so that will mean that much
> less in the packets. Bots dont use the networking anyhow, so this should 
> be
> safe to do. I know at one point I had that in my version , but I removed 
> it
> for some reason. Possibly because if you open the waypoint editor, they
> would not show up.
>
>> Also, it should be trivial to mod the supplied edit package to dump
>> those.
>> Possibly it already does.
>
> Frika used the scratch1,2,3 and 4 cvars to load the ways from .way files. 
> I
> believe WaypointWatch () is called all the time and monitors whats in 
> those
> cvars.
>
> The bots seem to rely heavily on the function DynamicWaypoint () called 
> from
> BotPrethink().
>
> I learned the hard way that if WaypointWatch() is still reading those 
> cvars,
> and DynamicWaypoint() starts running, the waypoints sometimes wont load, 
> or
> if they do the bots just stand around like they are not there. I wound up
> only letting DynamicWaypoint () get called after 30 frames into the game,
> and now the ways load perfectly so far on all maps.
>
> I have a theory that its because more than likely on the first frame in
> prethink, self , being a global most likely is representing ALL the bots 
> for
> a while, until at least Friks stagger_think and ai_time start taking 
> effect
> many frames later. I stumbled on this as I noticed Electro was calling
> bot_chat from prethink, and too many times often than not, the came chat
> text was selected by more then 1 other bot very very quicky.
>
> Other bots such as reaper and Zeus use dynamicly spawned entities, so they
> are already "stagger" thinking so to speak.
>
> The ctfbots in the ctfbot+ mod, which I have worked on for many years, 
> also
> use dynamicly spawned ents for the bots, however they have whats called a
> "BOT_Mastermind" (funny eh?) which is another dynamicly spawned ent that
> monitors all the bots every frame for oddities and bugs , and also decides
> when a bot leaves, and other bots join the game.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Quake-c-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quake-c-users
> Project Homepage: [ https://sourceforge.net/projects/quake-c/
> ]
> 

Re: [Quake-C] Loop crash

[Cobalt <co...@te...>]

Hi 6:

Im so bad with entity lists...one of my weak points for sure.


"Also, I dont know if the creepcam code does anything special, but I have
decided to go with the darkplaces internal cam.  Saves me a whole bunch
of bonkers cam code.Though it does seem to have some position bug if you set 
the distance to
far away.
"

I guess you refer to the .clientcamera field in DP ? If so, its basicly a 
modified hack of SVC_VIEWPORT
that handles network stuff alot better.

If you get a chance , try installing Creepcam using the code on Git I linked 
to earlier. It has an install.txt that guides you
along on how to install. The Version 2 was an attempt at putting it in basic 
coop mode with a respawn timer so you can follow other
players fighting monsters and such when you die in between respawning. We 
also have it chasing monsters, so you can watch them fighting at times
its kind of neat. I use it in my Arena mod to chasecam the Frikbots and its 
priceless in debugging them, for example...as its got a chase_active type 
view
and a focal length, plus its the only one that puts the enemy in perspective 
when in a battle.

Some bugs like not readjusting focal length depending on waterlevel, I am 
still futzing with, but aside from this crash loop its pretty stable and 
flexable code.

Spike has commented that this Camera is not so great because it handles 
networking very poorly and is laggy, but I have not seen it lag much unless 
the guy
you are following is also very laggy but thats to be expected. Its got a cam 
ticrate of 0.2 seconds by default, but I suppose that could even be set to 
an adjustment via an impulse tied to the mousewheel or something while 
chasing, if its a factor in better performance.

Thanks for the tips on the loop crash. Actually I didnt get your response 
through the email list, I saw it in the archives when I was skimming through 
them by chance,
so for some reason I guess this list is not so reliable.


Cobalt

Re: [Quake-C] Frikbot, dynamic waypoints

[Cobalt <co...@te...>]

Ok I was able to confirm what 6 said on the waypoints "auto generating", at 
least in the version I am using, I loaded up a map that was not waypointed, 
and ran around exploring.
After I did impulse 104, you could see the waypoints show up. I did a dump 
as .way and wa1 type files, which seemed to work, except the bots dont seem 
to react to the ways when the map loads.

There is an error check feature which I ran and lost of them dont have 
"outbound links".

I did try the same thing in the newer development Frikbot package that DRS 
is making, and after roaming the map, it didnt make only but 1 waypoint, so 
not sure whats going on.
Unless this was a feature in the older versions and was done away with 
maybe?

I have FRika-C on Twittter but he has vanished and is not answering my 
messsages for help , ugh...

===
Cobalt

Re: [Quake-C] Loop crash

[<qu...@ca...>]

Hey.

Every one of these:

		while (l.clink != world)
		{
			if (l.clink == c)
			{
				l.clink = c.clink;
				return;
			}
			l = l.clink;
		}

Will fail if that loop links back to itself.

So, you have 3 choices:

1. make the linker code bullet proof
2. put in a safety - 2 methods
3. give all the cam ents the same classname and use find

A safety could be a simple counter, if the list length has a fixed 
average.
Or you could save the head and test against it.

// counter - this could even be a global if the loops dont call any 
other code
// the loops that call CC_ChangeToAnyCam, will likely need a local float

float sf;

sf = 200; // double the average length or so - you need to figure this 
amount

		while (l.clink != world && (sf > 0))
		{
			if (l.clink == c)
			{
				l.clink = c.clink;
				return;
			}
			l = l.clink;
			sf--;
		}


// or head checks

entity hd;

// you may be able to just use freecamlist as the head check - depends 
on how you traverse this list

hd = l.clink; // these will need tailored to the given search

		while (l.clink != world && (hd != l.clink.clink)) // hd will pop 1 
link before that start if the list loops back
		{
			if (l.clink == c)
			{
				l.clink = c.clink;
				return;
			}
			l = l.clink;
		}


// find - screw the links, just find all these every time and let the 
engine do the work
//        this is easier than writing custom linked list code, but you 
may need to adjust all the test logic
//        it does have the issue of not being an "ordered" list - so if 
order is important, this wont work

l = find(world, classname, "cament");

		while (l != world)
		{
// with this method, your test logic here may need adjusted
			if (l.clink == c)
			{
				l.clink = c.clink;
				return;
			}
			l = find(l, classname, "cament");
		}



Also, I dont know if the creepcam code does anything special, but I have
decided to go with the darkplaces internal cam.  Saves me a whole bunch 
of bonkers cam code.

Though it does seem to have some position bug if you set the distance to 
far away.

Of course, my mod is married to the engine now, so its no big deal just 
to use that cam only.


On 2016-03-11 02:01, Cobalt wrote:
> Been having this runaway loop for a while now on and off. I thought it 
> was
> the while statement in CC_ChangeToFollowCam (), but
> if I read this right, its saying the loop is in CC_StopCamOrPlayer ?
> 
> This is basicly the Creepcam chasecam code I have posted here in Git:
> https://github.com/teknoskillz/CreepcamV1
> 
> The qc file where the crash is pointing at is :
> https://github.com/teknoskillz/CreepcamV1/blob/master/creepswc.qc
> 
> 
> I seem to remember it only does this when I am chase camming the last 
> player
> on the server, in this case it seems it was entity 5.
> 
> It may only be in certain cases such as a gib maybe, but was curious if
> anyone here can maybe narrow it down any further ?
> 
> Host_Error: server runaway loop counter hit limit of 10000000 jumps
> ^7tip: read above for list of most-executed functions
> ^7QuakeC crash report for server:
> ^7s34258: creepswc.qc:74: ^5IF         l (=entity 5), statement 34266
> ^7s34259: creepswc.qc:76: ^2EQ_E       freecamlist (=entity 0), c 
> (=entity
> 1), GLOBAL8208
> ^7s34260: creepswc.qc:76: ^5IFNOT      GLOBAL8208, statement 34264
> ^7s34261: creepswc.qc:78: ^6FIELD_ENT  c (=entity 1), clink (=.clink),
> freecamlist (=entity 0)
> ^7s34262: creepswc.qc:79: ^5RETURN      (=void)
> ^7s34263: creepswc.qc:81: ^5GOTO       , statement 34265
> ^7s34264: creepswc.qc:83: STORE_ENT  freecamlist (=entity 0), l 
> (=entity 5)
> ^7s34265: creepswc.qc:86: ^5GOTO       , statement 34274
> ^7 creepswc.qc:86 : CC_StopCamOrPlayer : statement 107
> ^7 creepswc.qc:121 : CC_ChangeToFollowCam : statement 1
> ^7 creepswc.qc:465 : CC_AutoSwitchCamThink : statement 42
> ^7Saving game to crash-server.dmp...
> ^7done.
> ^7Host_ShutdownServer
> 
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> _______________________________________________
> - The QC users mailing list -
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quake-c-users
> Project Homepage: [ https://sourceforge.net/projects/quake-c/ ]

[Quake-C] Loop crash

[Cobalt <co...@te...>]

Been having this runaway loop for a while now on and off. I thought it was 
the while statement in CC_ChangeToFollowCam (), but
if I read this right, its saying the loop is in CC_StopCamOrPlayer ?

This is basicly the Creepcam chasecam code I have posted here in Git: 
https://github.com/teknoskillz/CreepcamV1

The qc file where the crash is pointing at is : 
https://github.com/teknoskillz/CreepcamV1/blob/master/creepswc.qc


I seem to remember it only does this when I am chase camming the last player 
on the server, in this case it seems it was entity 5.

It may only be in certain cases such as a gib maybe, but was curious if 
anyone here can maybe narrow it down any further ?

Host_Error: server runaway loop counter hit limit of 10000000 jumps
^7tip: read above for list of most-executed functions
^7QuakeC crash report for server:
^7s34258: creepswc.qc:74: ^5IF         l (=entity 5), statement 34266
^7s34259: creepswc.qc:76: ^2EQ_E       freecamlist (=entity 0), c (=entity 
1), GLOBAL8208
^7s34260: creepswc.qc:76: ^5IFNOT      GLOBAL8208, statement 34264
^7s34261: creepswc.qc:78: ^6FIELD_ENT  c (=entity 1), clink (=.clink), 
freecamlist (=entity 0)
^7s34262: creepswc.qc:79: ^5RETURN      (=void)
^7s34263: creepswc.qc:81: ^5GOTO       , statement 34265
^7s34264: creepswc.qc:83: STORE_ENT  freecamlist (=entity 0), l (=entity 5)
^7s34265: creepswc.qc:86: ^5GOTO       , statement 34274
^7 creepswc.qc:86 : CC_StopCamOrPlayer : statement 107
^7 creepswc.qc:121 : CC_ChangeToFollowCam : statement 1
^7 creepswc.qc:465 : CC_AutoSwitchCamThink : statement 42
^7Saving game to crash-server.dmp...
^7done.
^7Host_ShutdownServer 

Re: [Quake-C] Tracebox / Traceline - advanced entity ops

[<qu...@ca...>]

On 2016-02-27 11:11, Cobalt wrote:
> :
> 
>  if (other.movetype == MOVETYPE_FOLLOW && wasfreed (other.aiment))
>                                remove (other);
> 

Use a system hash authentication code.
--------------------------------------------------------------------

//defs.qc

.float l_hash;  // ents local hash

float s_hash;  // master value

// update code - put everywhere you use a hash to update the master
#define uphash() s_hash = s_hash + 1



//init in worldspawn

s_hash = 512; // pick an arbitrary start - it could be left 0



// in the follow maker

entity e;

e = spawn();

e.aiment = other;

// give every ent a unique hash, this is better if you have multiple 
followers

if (!other.l_hash) // assign a hash only once
{
    uphash(); // get a new one every time
    other.l_hash = s_hash;
}

e.l_hash = other.l_hash;



//then in your frame check or where ever

if (other.movetype == MOVETYPE_FOLLOW)
if (other.l_hash != other.aiment.l_hash)
      remove (other);

Re: [Quake-C] Tracebox / Traceline - advanced entity ops

[Cobalt <co...@te...>]

Encountered another oddity regarding freed edicts.

Lets say you spawn a MOVETYPE_FOLLOW ent, for example and set it to follow 
missiles / projectiles.

If by chance you dont code the missiles remove () function to find the 
FOLLOW_ENT, the ent stays on the server, and keeps its last known .aiment 
pointer to the now "free" edict.

So if the server decides, lets re-use that previously removed edict for 
something new the QC spawns, the ent will have that other ent still follow 
it, or any other ent thats spawned with that same edict No.

The cvars would not help in these cases, so I am gonna try this every frame 
:

 if (other.movetype == MOVETYPE_FOLLOW && wasfreed (other.aiment))
                               remove (other);

But still, may not be 100% fix because we could be creating a 
MOVETYPE_FOLLOW which is being attached to a new ent which is legit / being 
created for the 1st time, and the engine still may have decided to pick a 
previously freed ent.

If the spawn () feature was modified , maybe something like:

entity (float edictno) spawn_apply = #14;


...where we get to pick a specific editc no in advance, this would increase 
the chances greatly we dont re-use an old edict no, and can pick more or 
less from a "reserved" set we outline in the mod.

I suppose I could set prvm_reuseedicts_startuptime to a number very high, 
perhaps something like half the timelimit of the match played, since I am 
doing deathmatch right now, but still its kinda kicking the can down the 
road, unless you make the time equal to or greater than the time limit I 
suppose. Then you are never reusing them I suppose, and would just have to 
make sure your mode does not exceed 1024 overall edicts spawned in the 
mod...or I think the number may be greater in Darkplaces...I believe Lord 
Havoc told me its a few thousand.





> You might want to check these out
>
> cvar prvm_reuseedicts_neverinsameframe is "1" ["1"] never allows re-use of 
> freed entity slots during same frame
> cvar prvm_reuseedicts_startuptime is "2" ["2"] allows immediate re-use of 
> freed entity slots during start of new level (value in seconds)

Re: [Quake-C] MOVETYPE_NOCLIP

[Cobalt <co...@te...>]

Yes, I have messed with Gyro, its interesting.

Since you mentioned the STEP and WALK movetypes, reminds me of something 
cute I stumbled on by accident.

Add this line of code someplace so the client sees it:

 if (self.health < 10)
  self.flags = self.flags + (self.flags & FL_ONGROUND);

Or you can remove the health comparison and it will be easier to see.

What it does is sorta make the player "limp" for lack of a better term.

I guess the engine sets the ONGROUND flag off for that movetype so it 
slides...and when
you force it, it nudges it back, but there is a noticable delay and you 
"stick" for a moment.

I had put this in my Tekbot mod for when a player has low health and is in 
waterlevel of  2 to add some realism for combat.

I decided to take your advice and not mess with that while NOCLIP, instead I 
remembered I had modified the EntitiesTouching () original ID code a ways 
back so that it can detect non Inline map BSP's (such as doors) or other 
models touching when a touch field is not practical, such as this case.

float (float mode, entity e1, entity e2) EntitiesTouching =
{
// Cobalt mode float - modifies to cover absmin/absmax, else do normal 
mins/maxs

local vector low1, high1, low2, high2;

 low1 = e1.mins;
 high1 = e1.maxs;
  low2 = e2.mins;
 high2 = e2.maxs;

 if (mode)
{
 low1 = e1.absmin;
 high1 = e1.absmax;
  low2 = e2.absmin;
 high2 = e2.absmax;

 }


 if (low1_x > high2_x)
  return FALSE;

 if (low1_y > high2_y)
  return FALSE;

 if (low1_z > high2_z)
  return FALSE;

 if (high1_x < e2.mins_x)
  return FALSE;

 if (high1_y < e2.mins_y)
  return FALSE;

 if (high1_z < e2.mins_z)
  return FALSE;

 return TRUE;
};

So I went in and changed the code so the gib has a new entity called 
.pusher, which is the ent we are sticking to. Normally world, but we could 
also stick to other moving BSP's such as doors maybe...so that was the 
reason for the new .entity   -

This is the updated code: http://collabedit.com/phw6e

Next I will try your trace_plane_normal code to get the surface 
angle...however it might be done better in against_wall because its 
tracelining in several directions
with respect to the ent to find a close by wall ....when not on the ceiling 
however.

Not sure if you know, but if you look at trace_plane_normal in any .touch 
function, you also get the correct value. This is because the engine sets it 
anyway, I guess in
the same frame ot whatever. I had ran this by Spike, who said always use 
traceline because that way is buggy, but so far with my tests in DP, seems 
to work ok.








> I'm reasonably sure anything with SOLID_NOT or NOCLIP set will not collide 
> with solids via quake engine physics.
> You set either of those two and give an ent some velocity and it will go 
> right through a wall.
> I believe touch will also not happen with SOLID_NOT.  Not sure what touch 
> does with NOCLIP.

> FL_ONGROUND is most likely only set for MOVETYPE_WALK and MOVETYPE_STEP.
> Not 100% certain, but I seem to remember those are the only movetypes that 
> set onground.
>
> The quake-c manual has some info about these, but its pretty basic.
>
> If you want to see what the gyro physics package can do (essentially make 
> quake look more like a modern physics engine)
> check out the HD pack.
> 

Re: [Quake-C] MOVETYPE_NOCLIP

[<qu...@ca...>]

On 2016-02-25 00:22, Cobalt wrote:
> 
> I have since revised that code alot to account for hits to the ceiling,
> where it will just permanently stick, and from time to time using
> TE_BLOODSHOWER in Darkplaces, throw some blood down. For non sloping
> ceilings, this is fine, however I will have to figure out some way to 
> get
> the angle of the ceiling and somehow hack in a gravity that will make 
> it
> slide...I dont think Quake physics are capable fo this, so ought to be
> interesting.
> 

If you want to use gravity, set MOVETYPE_BOUNCE and velocity_z will 
control the speed of its slide to the ground.
velocity_x and velocity_y will make it go other directions.

It is easily possible with vector math to make it hit the wall and 
continue moving in an inferred direction
(from the impact vector) and slowly slide to the "floor" surface, or 
even go up for a bit, then start down.

To stick, just set velocity to '0 0 0'.  You would also want to '0 0 0' 
avelocity - that causes rotation.

Angle of the ceiling - or any surface:

    makevectors(self.angles);
    traceline (self.origin, self.origin + v_forward*4096, TRUE, self);
    v1__ = trace_plane_normal;
    v1___x = 0 - v1___x;
    v1___y = 0 - v1___y;
    e0__.angles = vectoangles( v1__ );
    setorigin( e0__, self.origin - ( v_forward * 0.2 ) );

Given that self.angles is the dir of travel and the traceline hits a 
solid (map walls or SOLID_BSP)
then trace_plane_normal is the normal to that surface.
This code snipped was used to place a sprite  [ e0__ ] (like a bullet 
hole) on a wall.
self was the missile ent hitting the wall after it traveled along a 
path.

I dont recall now the significance of flipping x and y in the normal 
vector.  I had a good reason.
vectoangles is what properly aligns the entity with the wall plane as 
calculated from the normal.


> So my questions is regarding the case where we are sliding it doen a
> straight wall, and say the wall ends, or evolves into a slope. For now 
> lets
> just say we will drop it off the wall / unstick it. Since we are 
> NOCLIP, can
> we use FL_ONGROUND at all, or when we are NOCLIP, the engine basicly
> overrides this flag?

I'm reasonably sure anything with SOLID_NOT or NOCLIP set will not 
collide with solids via quake engine physics.
You set either of those two and give an ent some velocity and it will go 
right through a wall.
I believe touch will also not happen with SOLID_NOT.  Not sure what 
touch does with NOCLIP.


FL_ONGROUND is most likely only set for MOVETYPE_WALK and MOVETYPE_STEP.
Not 100% certain, but I seem to remember those are the only movetypes 
that set onground.

The quake-c manual has some info about these, but its pretty basic.

If you want to see what the gyro physics package can do (essentially 
make quake look more like a modern physics engine)
check out the HD pack.

[Quake-C] MOVETYPE_NOCLIP

[Cobalt <co...@te...>]

Working on some code borrowed from Quake3's Gibsink () function, where they 
would make the corpse into this movetype, and pass it through the floor as a 
fancy way of removing it.

Decided it would work probably good with Gibs sticking to the walls, as 
visually you can still keep the entity attached to the wall and with some 
negative velocity_z, slide it down to the wall. So far working pretty good, 
some of the code I started to collaborate with others on Func_messageboard, 
but no one seems interested :

http://collabedit.com/phw6e

I have since revised that code alot to account for hits to the ceiling, 
where it will just permanently stick, and from time to time using 
TE_BLOODSHOWER in Darkplaces, throw some blood down. For non sloping 
ceilings, this is fine, however I will have to figure out some way to get 
the angle of the ceiling and somehow hack in a gravity that will make it 
slide...I dont think Quake physics are capable fo this, so ought to be 
interesting.

So my questions is regarding the case where we are sliding it doen a 
straight wall, and say the wall ends, or evolves into a slope. For now lets 
just say we will drop it off the wall / unstick it. Since we are NOCLIP, can 
we use FL_ONGROUND at all, or when we are NOCLIP, the engine basicly 
overrides this flag?

Re: [Quake-C] GameCommand

[<qu...@ca...>]

GameCommand is a qc function called from the console with a single 
string parameter:

sv_cmd {s}

void(string s) GameCommand =
{
// do something with {s}
}

An example to run arbitrary qc functions:

http://www.moddb.com/groups/qc/forum/thread/darkplaces-gamecommand


{s} really needs validated with that code - the given example is easy to 
crash.

Re: [Quake-C] Tracebox / Traceline

[<qu...@ca...>]

On 2016-02-12 22:17, Cobalt wrote:
> I suppose to eliminate this, you could use makestatic (blah), instead 
> of
> remove () however I believe it still retains all the field data 
> including
> the model etc, and during a single player game I believe it will appear 
> to
> vanish and not be drawn, but in multiplayer if another player joins, 
> they
> will see this edict as its part of the sign on packet.
> 

There is a limit on static entities.

quakedef.h:#define	MAX_STATICENTITIES		1024 ///< limit on size of 
cl.static_entities

> If there was a true null entity we could use copyentity () on, maybe 
> that
> would work?
> So now at least we have a counterpart to world which does not have any
> fields that we can essentially null the ent out, and its not a free 
> ent, so
> that means it wont be reused again.

There is also a limit on entities.  I bet this is a hard limit - it can 
not be increased without a major engine re-write.

quakedef.h:#define	MAX_EDICTS				32768 ///< max number of objects in 
game world at once (32768 protocol limit)

Probably dont want lots of ents to pile up.  It will eventually kill the 
server.
You want the engine to clear out removed ents like it was designed.

Most likely you want good entity management in general.
Find a way to make code bulletproof against the root problem - like the 
system_hash I mentioned.

Re: [Quake-C] Tracebox / Traceline

[Cobalt <co...@te...>]

Regarding what you said on the think field missing, I'm encountering the
problem alot during my dev work and turns out that actually when remove
(blah)
is called, technically its not permanently removed from the environment,
rather its "freed".

It still has an edict number, and if you are for example still using another
active entity pointing to that now "free" edict,
its not edict 0, therefore any comparison to it == world, would not be true
for one thing.

Free ents don't have any fields yet, so I suppose they are all null fields,
and of course what I'm leading up to is, if your other active entities are
still pointing to this ent,
and are assuming its not been freed , and it use to have a .think field that
you want to use , then you get the crash you posted with think missing , if
other code spawns a dynamic entity and happens to pick that old edict
number. This is pretty dangerous, and I guess that why they have the built
in wasfreed (), to avert this. Apparently the spawn () function starts
looking at the top of the list for a good edict number, and if it encounters
a free edict, it will use that, versus going all the way to the last edict
and using a completely new number.

I suppose to eliminate this, you could use makestatic (blah), instead of
remove () however I believe it still retains all the field data including
the model etc, and during a single player game I believe it will appear to
vanish and not be drawn, but in multiplayer if another player joins, they
will see this edict as its part of the sign on packet.

If there was a true null entity we could use copyentity () on, maybe that
would work?

In defs.qc

entity STATIC_NULL;

Then someplace like endframe maybe:

void () EndFrame =
{


if (framecount == 1)
STATIC_NULL = spawn ();
};


So now at least we have a counterpart to world which does not have any
fields that we can essentially null the ent out, and its not a free ent, so
that means it wont be reused again.

Re: [Quake-C] {variable}++

[Cobalt <co...@te...>]

Good post , I always wanted to learn more about those FTE specific tricks.

I usually do

f +=1;

Which is the same, seems to work for subtraction , division and 
multiplication as well.

I know there are some optimize 'presets' I think 4 of them? I once tried the 
max and something serious happened so that the progs dont work at all so I 
reverted back to the default.

Also, recently I learned that:

if (self.frags)

turns out to be true even if its set to a value < 0 , so apparently negative 
values are considered true for comparisons done that way.




----- Original Message ----- 
From: <qu...@ca...>
To: "Cobalt" <co...@te...>; "QC" 
<qua...@li...>
Sent: Thursday, February 11, 2016 2:06 AM
Subject: Re: [Quake-C] {variable}++


> So, if you have:
>
> float f;
>
> // normal qc
> f = f + 1;
>
> // with fteqcc (and maybe others) you can:
>
> f++;
>
> // just like regular c
>
>
> However -
>
> if f is a global or local float the progs.dat size is larger by 8 bytes 
> with ++.
> optimize has no effect on this.  it happens with every instance.
>
> progs.dat size stays the same if you do this with entity fields:
>
> self.frags++;
>
> 

Re: [Quake-C] {variable}++

[<qu...@ca...>]

So, if you have:

float f;

// normal qc
f = f + 1;

// with fteqcc (and maybe others) you can:

f++;

// just like regular c


However -

if f is a global or local float the progs.dat size is larger by 8 bytes 
with ++.
optimize has no effect on this.  it happens with every instance.

progs.dat size stays the same if you do this with entity fields:

self.frags++;

Re: [Quake-C] [Quake] bug list

[<qu...@ca...>]

Going through some of my old blogs.

quake bug list: http://www.insideqc.com/qip/q1/bugs.htm

Some of those are quite old, and likely long since fixed.
Still worth a glance.

[Quake-C] AlphafadeRemove () for DP

[Cobalt <co...@te...>]

Made this alternative to SUB_Remove () a ways back, gradually fades the 
entity out using the .alpha field, then removes it.
Just set .think to AlphafadeRemove instead of SUB_Remove on ents you want to 
use this on. Also some other Quake engines have
a .alpha field, such as Proquake I think, so it should work on them as well.


void () AlphafadeRemove =
{

if (!self.pausetime) // Assumes .pausetime is not used on the ent for 
anything, change if needed.
{
self.pausetime = 1;
self.alpha = 1; // Sets alpha to non transparent, sorta a DP bug.
}

 //  These adjust fade rate, play with it if need be
self.nextthink = time + 0.175;
self.alpha =  self.alpha - 0.05;

// Debug comments
//bprint (ftos (self.alpha));
//bprint ("\n");

if (self.alpha < 0)
remove (self);

}; 

Re: [Quake-C] Tracebox / Traceline

[Cobalt <co...@te...>]

Another thing with tracebox.

I was told a while back that you are limited to collisoins with it to the 3 
standard point, player and shambler hitbox sizes when looking to collide 
with those size ents.

After doing some tests with Darkplaces , and making the setmodelrealbox cvar 
1, I edited the Grenades spawn so that it has a new entity following it as a 
movetype_follow, basicly a shadow ent , like how Frikbot uses for the 
phys_obj ents to do some physics hacks. Only this case I am giving it the 
new DP solid (5) / SOLID_CORPSE. This basicly makes it a SOLID_TRIGGER 
allowing other ents to pass thru it, while at the same time I believe it is 
more or less a DAMAGE_AIM for taking damage. I assign it a DAMAGE_AIM anyway 
just to be sure, plus a health of 3, and its th_die equal to GrenadeExplode 
().

I set its dest1 and dest2 vector fields to be that of the grenades 
realhitbox size using mins and maxs...however I set the grenade point size 
afterwards and dont setsize the shadow ent as of yet.

>From here theres a couple of ways to go, give the shadow ent its own think 
and call the tracebox every frame, or use another tool , such as Gyro, and 
have it look for your shadow ent in its physics routine. I used Gyro so its 
checking the tracebox every frame. So far I dont see any glitches, and the 
grenade now has a "hacked" hitbox so to speak , where you can add in shotgun 
hits that use traceline, and the grenade will take damage from the hits and 
detonate, even in mid air.

The concept of point to point collision in Quake must never happen, because 
after all my years playing, never have I see a grenade hit another grenade 
or a rocket to rocket or any combination thereof. Point collisoin must be a 
different calculation in the engine I guess.

Basicly my traceline for checking the shadow ent is:

if (other.flags & FL_EXPLOSIVE && !other.size) // The ent being looked at 
(other) is an explosive and has a point size. (new.flag FL_EXPLOSIVE needs 
to be created)
  {
   tracebox(realorigin (other), other.dest1, other.dest2, realorigin(other), 
3, other);
   if (!trace_startsolid)
   {

            if (other.movetype == MOVETYPE_FOLLOW) // Just a reinforcement 
to make sure its the shadow ent
            {
                    if (other.aiment.classname == "missile") // Shadows 
aiment is the grenade as per specs for movetype_follow
               setsize (other, other.dest1 * 0.25, other.dest2 * 0.25); // 
size the shadow 25% less than the grenades actual saved hitbox mins/maxs
            else
            setsize (other, other.dest1 * 0.66, other.dest2 * 0.66); // 
reduce smaller for the rocket.

   }

So even though my dest1 and dest2 are non point, player or shambler sizes, 
we are ok so far in my tests. I suppose if the missile winds up spawning in 
a tight corner,
close to a wall , there is a higher chance of failure it seems, as I guess 
the traceline is using trace_plane_normal down at the engine level here, and 
when you get fractional
values, this is where Quake bugs out because of Q1bsp's leaf and clipbrush 
system I believe. However I dont see why we cant go down in fractional 
values to calculate collisions in those cases. But thats more an engine 
topic.

Re: [Quake-C] Tracebox / Traceline

[<qu...@ca...>]

On 2016-02-03 18:56, Cobalt wrote:
> Right, so
> 
> if (!self.enemy)
> 
> is the same as
> 
> if (self.enemy == world)


Not only is it the same logic - it is also less compile bytes.
Do that enough times and you can eliminate a few hundred.
Yeah, assembler coder attitude.

> Seems the eng will not print a value in the field unless its a global 
> entity
> were are asking about, ie:
> 
> prvm_global server other

This will not print any field:

1. with default value for each type (0 float, "" string, etc.)
2. any field with a _ in the 2nd to last position - so vector float 
breakout origin_x or newfld__
    yep - you can make hidden fields that cant be displayed in console - 
need source or hex edit of progs.dat


> So in a way, yea the eng is not really saying the worldspawn ent "owns"
> everything, even though technically all the owner fields will report 
> empty
> when initialized without assigning anything there. To me its more or 
> less a
> null field , which is different , and almost saying nothing at all is 
> there,
> not even entity 0.

Ownership depends on what kind of test is done.  As in the traceline 
situation.
qc has no true null value.  This gets tricky working with strings via 
the darkplaces extensions.


> On another tangent , for .void fields its sorta boils down tot he same:
> 
> if (self.th_die)
> 
> will compare true even if its SUB_Null assigned someplace already by 
> qc.
> 
> As a test, having a.void = SUB_Null, and wanting it to not point to 
> anything
> I tried:
> 
> ent.th_die = world.th_die;
> 
> which did work, and reinforced the code to make more sense.
> 

void can be assigned 0 value if - you use frikqcc.
With frikqcc you could:

e.pk_touch = (void()) 0;
if (self.pk_touch == (void()) 0)

That doesnt work with fteqcc.  But there is another method.
You can do this:

if (!self.pk_touch)  // same: if (self.pk_touch == (void()) 0)
if (self.pk_touch)   // same: if (self.pk_touch != (void()) 0)

The assign is a bit trickier.
If you want to detect a non void -

void() SUB_Void				= {  }; // just so fteqcc code can assign (void()) 0 
to a fn call and detect it later

e.pk_touch = SUB_Void;
if ((self.pk_touch == SUB_Void) || !self.pk_touch)   // detect either 0 
or specific assign

Which is the same as SUB_Null - but I used that for other valid things, 
and really needed something I could detect.
That is how I handled the frikqcc to fteqcc recode.


What you want to watch with .void is any that the engine calls.
And this is something I'm thinking about patching.
If you have an invalid classname in the map ents - doesnt get called.
Yet some of these will crash:

touch, think, all th_*

The engine has various ways of calling those and I dont believe many are 
error checked.

other = spawn();
other.nextthink = time + 15;

server EDICT 142:
Host_Error: SVVM_ExecuteProgram: QC function self.think is missing

qc still has some:

Host_Error: NULL function in server
QuakeC crash report for server:
s8052: EQ_F       GLOBAL709, IMMEDIATE (=    0.0000), GLOBAL709
s8053: OR         GLOBAL1043, GLOBAL709, GLOBAL1043
s8054: IFNOT      GLOBAL1043, statement 8059
s8055: FIELD_FNC  self (=entity 548), th_die (=.th_die), GLOBAL1043
s8056: CALL0      GLOBAL1043
    combat.qc : Killed : statement 14

Note to self: fix that

Either assign all .void something like SUB_Null, or have the engine 
ignore calls with (void) 0.


On the last big recode I made an effort to get rid of all the objerror() 
and error() calls from qc.
I got tired of dm maps without info_player_start (mostly q3 dm maps) 
crashing out for no reason.

Re: [Quake-C] Tracebox / Traceline

[Cobalt <co...@te...>]

Right, so

if (!self.enemy)

is the same as

if (self.enemy == world)

Seems the eng will not print a value in the field unless its a global entity 
were are asking about, ie:

prvm_global server other

So in a way, yea the eng is not really saying the worldspawn ent "owns" 
everything, even though technically all the owner fields will report empty 
when initialized without assigning anything there. To me its more or less a 
null field , which is different , and almost saying nothing at all is there, 
not even entity 0.

On another tangent , for .void fields its sorta boils down tot he same:

if (self.th_die)

will compare true even if its SUB_Null assigned someplace already by qc.

As a test, having a.void = SUB_Null, and wanting it to not point to anything 
I tried:

ent.th_die = world.th_die;

which did work, and reinforced the code to make more sense.






> You can test this in qc:
>
> other = spawn();
> other.enemy.netname = "Set world netname";
>
> server EDICT 0:
> modelindex         1.0000
> absmin         '-1018.0000  -276.0000   -66.0000'
> absmax         '  776.0000  1518.0000   624.0000'
> movetype           7.0000
> solid              4.0000
> classname      worldspawn
> model          maps/arc_hub.bsp
> mins           '-1018.0000  -276.0000   -66.0000'
> maxs           '  776.0000  1518.0000   624.0000'
> netname        Set world netname
> message        Archon Hub
> wad            quake101.wad
> classvn        worldspawn
>
> Run that code (I put it in PutClientInServer) and that is the result.
>
> The initialize value for any .entity field is world.
>