quake-c-users — Email support

Re: [Quake-C] Tracebox / Traceline

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

On 2016-02-03 14:07, Cobalt wrote:
> Ok, some more tough lessons on Traceline.
> 
> Could not figure out why tracelines were failing, and turns out the 
> ignore
> entity not only ignores the entity you specify, but anything that 
> entity
> "owns" using the .owner entity field.
> 
> So I suppose if you set the ignore ent as "world" , any entity that you 
> set
> its .owner field to as "world" would also get ignored as well. By 
> default
> the .owner field is null / not populated on ents, and I am not sure but 
> I am
> pretty certain  this is not the same as entity 0 (world)
> 

Without digging into to much engine code:

int entnum;
prvm_edict_t *ptent;

// get a pointer to ent 1
entnum = 1;
ptent = PRVM_EDICT_NUM(entnum);

Ents are a variable struct (prvm_edict_t *) of all the field data.
This is done with a complex set of pointers.

The entity field itself is just a number - entnum.  That number is a 
reference to the entity struct.
The engine hides this from quake c and they work like pointers.

So, any entity pointer with 0 in it points to the world entity.

In qc you can set that with:

self.enemy = world;

Note that all entity pointers are initialized with the 0 default, which 
is world.

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.

Re: [Quake-C] Tracebox / Traceline

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

Ok, some more tough lessons on Traceline.

Could not figure out why tracelines were failing, and turns out the ignore 
entity not only ignores the entity you specify, but anything that entity 
"owns" using the .owner entity field.

So I suppose if you set the ignore ent as "world" , any entity that you set 
its .owner field to as "world" would also get ignored as well. By default 
the .owner field is null / not populated on ents, and I am not sure but I am 
pretty certain  this is not the same as entity 0 (world)



----- Original Message ----- 
From: "Cobalt" <co...@te...>
To: "QC" <qua...@li...>
Sent: Sunday, January 24, 2016 2:59 PM
Subject: [Quake-C] Tracebox / Traceline


>
> A while back I was told that if you do a tracebox on an ent using its mins
> and maxs, and the mins and maxs are not a point, player or shambler size
> hitbox, tracebox wont work?
>
> I seem to recall this being true back then, but I was puzzled because isnt
> tracebox using tracelines same functions at the engine level? Is traceline
> only going to collide with the 3 standard hull sizes when its checking
> against an ent? So far tracebox seems to work when checking an ent thats a
> custom size against the world bsp - IE
>
> tracebox(realorigin(self), self.mins, self.maxs, realorigin(self), 3, 
> self);
>
> Im using the "nomonsters" float as 3 which is a new one for DP only.
>
> //definitions that id Software left out:
> //these are passed as the 'nomonsters' parameter to traceline/tracebox 
> (yes
> really this was supported in all quake engines, nomonsters is misnamed)
> float MOVE_NORMAL = 0; // same as FALSE
> float MOVE_NOMONSTERS = 1; // same as TRUE
> float MOVE_MISSILE = 2; // save as movement with .movetype ==
> MOVETYPE_FLYMISSILE
> float MOVE_WORLDONLY = 3;
> //description:
> //allows traces to hit only world (ignoring all entities, unlike
> MOVE_NOMONSTERS which hits all bmodels), use as the nomonsters parameter 
> to
> trace functions
>
> So far it does seem to work reliably like that from my tests....but there
> may be a problem when the ent is in a tight corner or a scrunched /
> irregular formation of the map?
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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/
> ]
> 

[Quake-C] Tracebox / Traceline

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

A while back I was told that if you do a tracebox on an ent using its mins 
and maxs, and the mins and maxs are not a point, player or shambler size 
hitbox, tracebox wont work?

I seem to recall this being true back then, but I was puzzled because isnt 
tracebox using tracelines same functions at the engine level? Is traceline 
only going to collide with the 3 standard hull sizes when its checking 
against an ent? So far tracebox seems to work when checking an ent thats a 
custom size against the world bsp - IE

tracebox(realorigin(self), self.mins, self.maxs, realorigin(self), 3, self);

Im using the "nomonsters" float as 3 which is a new one for DP only.

//definitions that id Software left out:
//these are passed as the 'nomonsters' parameter to traceline/tracebox (yes 
really this was supported in all quake engines, nomonsters is misnamed)
float MOVE_NORMAL = 0; // same as FALSE
float MOVE_NOMONSTERS = 1; // same as TRUE
float MOVE_MISSILE = 2; // save as movement with .movetype == 
MOVETYPE_FLYMISSILE
float MOVE_WORLDONLY = 3;
//description:
//allows traces to hit only world (ignoring all entities, unlike 
MOVE_NOMONSTERS which hits all bmodels), use as the nomonsters parameter to 
trace functions

So far it does seem to work reliably like that from my tests....but there 
may be a problem when the ent is in a tight corner or a scrunched / 
irregular formation of the map?

Re: [Quake-C] droptofloor ()

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

Came across another oddity on this function...if the ent is on a staircase 
and you call droptofloor (), it will place the ent's min_z on the surface of 
the step that I guess the tracelines in the engine pick as being the ground 
plane. So you can wind up with entities partially embedded into higher parts 
of the stairs.

One of my little projects is coming up with some qc that can detect stairs 
kind of reliably. I have done it using the players / clients physics, which 
was easier since its a MOVETYPE_WALK, but for other ents such as gibs and 
corpses, seems to pose a new challenge.




----- Original Message ----- 
From: "Cobalt" <co...@te...>
To: "QC" <qua...@li...>
Cc: "Forest Hale" <lor...@gh...>
Sent: Sunday, January 03, 2016 1:30 PM
Subject: [Quake-C] droptofloor ()


> Interesting function.
>
> I call it a "destructive" function because it actually will drop the ent
> calling it to the floor no matter what when you call it. I have tested it
> using an dummy ent as "self" to avoid that problem, but I also learned 
> that
> if the floor has openings or gratings / gaps that pass through to a lower
> level, droptofloor will drop the ent through the grating / openings. Not
> sure if this is 100% of the time, or if the tracelines or whatever the
> engine is doing happens to contact
> openings in the floor all the time to fool it. Seems to me for this to 
> work
> right, the function would need some redesign to either let you do a non
> destructive test on the ent , or actually move the ent to the floor.
>
> Also the function checkbottom () seems to work well on ents that have all 
> 4
> lower corners of their bounding box resting on a solid floor, with no
> openings or gratings. So if this was somehow worked into droptofloor (), I
> think it would be a much better built in than it is now.
>
>
> ==
> Cobalt
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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] Frikbot, dynamic waypoints

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

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.

Re: [Quake-C] announcing qc v2.0

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

What will it do?

http://www.moddb.com/groups/qc/forum/thread/quake-c-v20

How about no more spawn functions in qc?

Spawn any item you want with a script in cfg files.

Re: [Quake-C] Frikbot, dynamic waypoints

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

On 2015-12-22 14:44, Cobalt wrote:
>> I'm going to say this: as you and the bots roam a level dynamic 
>> waypoints are created.
>> That is how I remember it at least.
> 
> Could be in another newer version that what I have, or I have a bug in
> the code somewhere.
> 

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)

I had a look around and checked entites and bounding boxes.

http://www.moddb.com/groups/qc/images/frikbot-x-dynamic-waypoints

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.

Hrm.  Might even be 108 units...

#define noway_radius 108 // no new waypoint in this radius

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.

And I'm pretty sure the bots themselves make waypoints as well.


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.

Also, it should be trivial to mod the supplied edit package to dump 
those.
Possibly it already does.


If you want to check out this exact code:

https://github.com/six-of-one/qc_v1.07/tree/efd1ae3989bddd10dc47543a85a7f3ccf6cd0178/frikbot

[Quake-C] (no subject)

[<je...@qb...>]

    Cobalt,Thanks for the comments.
simultaneous shots:  no recollection... tried to look it up on qip but page wouldn't load.
frikbot:  Lightninghunter released a slightly improved bot with the Ultimate waypoint pack (amazing btw, rocket jumps,etc).  I recall a newer version discussed on i3d.  Also recall fall avoidance discussion but no clear solution.
rotate doors:  smoother rotation on engines with the fix.



I downloaded it and took a peek. Nice, it has the old QIP fixes by Maddes in there, which was something I was looking for ...all nicely commented too.I find the armor fix/no damage  while drowning is always the one I make sure I put in. Im not sure what the "No silmultaneous shots" thing is about in combat.qc in T_damage. unless its the fix for the multidamage / multient thing for the shotgun?I think Orion posted a fix for that on Inside3d years ago, and they went on and added capability for watersplashes with reverse tracelines for the sg and ssg if I remember right.Options for Gyro, and Frikbot are sensible. Not sure what the Doors thing is, I assume by Goldenboy, perhaps rotating bmodels ?Oh as far as Frikbot goes, not sure if thats fbx you included or not, but I saw you have the 6 basic waypoint files in there, and there are some more waypoint files for some of the other ID maps that are fairly decent. Frikbots page has old ones and lots of em dont work too well, but the file I got from Moddb for Frikbot seems to have some good / better ID map waypoints in them so far:[ http://www.moddb.com/mods/frikbot-x/downloads/frikbot-x-with-waypoints ]Figuring what version of Frikbot is in what, is a tough job, there were alot of versions. Im messing around with that today, trying to get the waypoints for e1m2 going...and they are almost always failing. They must not be coded right as far as I can tell....and with so many versions maybe its possible for them to glitch if the ways were written with an older bot I guess.==Cobalt----- Original Message ----- From: To: Sent: Monday, December 28, 2015 10:56 PMSubject: [Quake-C] Yet another generic abandoned qc code project...
    JEFF

Re: [Quake-C] dmg_take,dmg_save

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

On 2016-01-12 01:39, Cobalt wrote:
> Hrm, so it is commented in the original progs release or no?
> 
> targ.dmg_take = targ.dmg_save = 0;
> 

Look at the engine code:

                  PRVM_serveredictfloat(ent, dmg_take) = 0;
                  PRVM_serveredictfloat(ent, dmg_save) = 0;

That does the same thing.

> The Botcam in Frikbot (not sure what version ) has this in the camera 
> think:
> 
> (where I suppose enemy is the targ)
> self.dmg_take = self.enemy.dmg_take;
>  self.dmg_save = self.enemy.dmg_save;
> 
> So I guess that will transfer the screen flashes to the cam follower of 
> the
> player.
> 

Perhaps.  The engine code still must get called.  Which happens when 
writing to the client.

That is a whole other trace.

Re: [Quake-C] echo

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

Sure , sounds good.

Some forums have m2f and f2m (forum to mail) features where lists can 
crosspost from each other.

I dont think I can expect mush sipport or new features here using SF...but 
the support over on Moddb seems maybe a little better.

I recall Fidonet back in the BBS days had crossposting options.



> I'm going to echo the better stuff from the mail list on the forum under
> discuss or vault for the moddb qc people that are not on the mail list.

Re: [Quake-C] dmg_take,dmg_save

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

Hrm, so it is commented in the original progs release or no?

targ.dmg_take = targ.dmg_save = 0;

Adding the above to the very top of t_damage () should reset them so they 
dont accumulate upon taking damage.

Or can modify this piece as follows:

if (targ.flags & FL_CLIENT)
{
targ.dmg_take = take;
targ.dmg_save = save;
targ.dmg_inflictor = inflictor;
}

The Botcam in Frikbot (not sure what version ) has this in the camera think:

(where I suppose enemy is the targ)
self.dmg_take = self.enemy.dmg_take;
 self.dmg_save = self.enemy.dmg_save;

So I guess that will transfer the screen flashes to the cam follower of the 
player.



As for multi_damage with the multi_ent thing, I think this would take care 
of it but not usre.

There is a fix on a forum for multidamage that I put into one of my mods. 
Not sure what the problem with it is in the original Id src.  I believe its 
worth fixing tho.


> // add to the damage total for clients, which will be sent as a single
> // message at the end of the frame
> // FIXME: remove after combining shotgun blasts?

Re: [Quake-C] echo

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

I'm going to echo the better stuff from the mail list on the forum under 
discuss or vault for the moddb qc people that are not on the mail list.

When I have time anyway.

Re: [Quake-C] dmg_take,dmg_save

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

This is it:

combat.qc:

void(entity targ, entity inflictor, entity attacker, float damage) 
T_Damage

// add to the damage total for clients, which will be sent as a single
// message at the end of the frame
// FIXME: remove after combining shotgun blasts?
	if (targ.flags & FL_CLIENT)
	{
		targ.dmg_take = targ.dmg_take + take;
		targ.dmg_save = targ.dmg_save + save;
		targ.dmg_inflictor = inflictor;
	}

There is no other qc reference in any other function.


Darkplaces has this:
(I'd gather that glquake, and others are similar.)

void SV_WriteClientdataToMessage (client_t *client, prvm_edict_t *ent, 
sizebuf_t *msg, int *stats)

//
// send a damage message
//
         if (PRVM_serveredictfloat(ent, dmg_take) || 
PRVM_serveredictfloat(ent, dmg_save))
         {
                 other = PRVM_PROG_TO_EDICT(PRVM_serveredictedict(ent, 
dmg_inflictor));
                 MSG_WriteByte (msg, svc_damage);
                 MSG_WriteByte (msg, (int)PRVM_serveredictfloat(ent, 
dmg_save));
                 MSG_WriteByte (msg, (int)PRVM_serveredictfloat(ent, 
dmg_take));
                 for (i=0 ; i<3 ; i++)
                         MSG_WriteCoord (msg, 
PRVM_serveredictvector(other, origin)[i] + 
0.5*(PRVM_serveredictvector(other, mins)[i] + 
PRVM_serveredictvector(other, maxs)[i]), sv.protocol);

                 PRVM_serveredictfloat(ent, dmg_take) = 0;
                 PRVM_serveredictfloat(ent, dmg_save) = 0;
         }

Perhaps whatever msg content is causes a flash on the screen.


The only qc controlled screen flash that I know of is:

stuffcmd (self, "bf\n");

That happens when you pick up weapons / items, etc.


On 2016-01-11 12:13, Cobalt wrote:
> Just got a response on the func_messageboard forum, apparently these 
> control
> the tint and color of the red screen flash that happens to a real 
> client
> when taking damage?
> 
> I will test this later to confirm.
> 
> If so, this is one example of something that ought to be commented in 
> to new
> clean QC sources...I dont think I have ever ran accross this while 
> browsing
> other Quake C before.

[Quake-C] dmg_take,dmg_save

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

Just got a response on the func_messageboard forum, apparently these control 
the tint and color of the red screen flash that happens to a real client 
when taking damage?

I will test this later to confirm.

If so, this is one example of something that ought to be commented in to new 
clean QC sources...I dont think I have ever ran accross this while browsing 
other Quake C before.

===
Cobalt

Re: [Quake-C] dev tools

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

Sounds neat, though only for Linux...have not tried compiling Quake in Linux 
yet.

They call functions such as ClientConnect () , WorldSpawn () and 
ClientDisconnect () "Entry points"
as I have heard them described by other coders over the years. I suppose 
these are directly tied to in as engine as control points or whatnot.

I know as I have modded QC, I noticed it would be nice to have an editor 
that can "bookmark" entry points like these so its simpler to navigate to 
them, as they tend to have to be visited more often than other functions.

==
Cobalt

Re: [Quake-C] dev tools

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

Finally released my modest collection of dev. tools.

http://www.moddb.com/mods/quake-hack/downloads/linux-quake-command-line-tools

The comment on page describes basic uses.

They perform searches mostly.


Examples:

If you wanted to find out for instance where PutClientInServer is 
referenced:

lsf  PutClientInServer


What functions contain dest2 and list function contents:

deb qc dest2


How many QUAKED specify "big" ammo box
(if put or leave QUAKED in your source)

deqed big


List global / local variables (best it can, some of these are a shot in 
the dark)

gvar
lvar


List every entity field variable

allevar


You can also count code, search source without comments, and
some other fancy stuff.

I tried to make it as bullet proof as possible, but some features depend 
heavily on the
environment.  qctac relies on fteqcc warnings.

$HOME/quake is created, but relies on you to populate it or tweak 
/usr/local/bin/.bash_quake
to your setup.  You can use the search functions on code anywhere.
(I just noticed qrc will complain if not in q1lab/source, and has no 
override.
This is because it copies dir contents to /tmp.)

Many aliases exist to shorten typing - .f = .float, .e = .entity, etc.

And please be aware of the 'rm -f' temp file removal!
grep "'rm'" /usr/local/bin/*

I would see what every one of those remove.  And dont run these as root, 
EVER!
You dont want to ever know that something that works fine for normal 
users like "'rm' -rf /tmp/.qc/*"
does something very bad when run as root.

(Plus backup your files - I recommend a local git store for version 
tracking at the least.)

-6

[Quake-C] droptofloor ()

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

Interesting function.

I call it a "destructive" function because it actually will drop the ent 
calling it to the floor no matter what when you call it. I have tested it 
using an dummy ent as "self" to avoid that problem, but I also learned that 
if the floor has openings or gratings / gaps that pass through to a lower 
level, droptofloor will drop the ent through the grating / openings. Not 
sure if this is 100% of the time, or if the tracelines or whatever the 
engine is doing happens to contact
openings in the floor all the time to fool it. Seems to me for this to work 
right, the function would need some redesign to either let you do a non 
destructive test on the ent , or actually move the ent to the floor.

Also the function checkbottom () seems to work well on ents that have all 4 
lower corners of their bounding box resting on a solid floor, with no 
openings or gratings. So if this was somehow worked into droptofloor (), I 
think it would be a much better built in than it is now.


==
Cobalt

Re: [Quake-C] Yet another generic abandoned qc code project

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

Heya Jeff


I downloaded it and took a peek. Nice, it has the old QIP fixes by Maddes in 
there, which was something I was looking for ...all nicely commented too.

I find the armor fix/no damage  while drowning is always the one I make sure 
I put in. Im not sure what the "No silmultaneous shots" thing is about in 
combat.qc in T_damage. unless its the fix for the multidamage / multient 
thing for the shotgun?

I think Orion posted a fix for that on Inside3d years ago, and they went on 
and added capability for watersplashes with reverse tracelines for the sg 
and ssg if I remember right.

Options for Gyro, and Frikbot are sensible. Not sure what the Doors thing 
is, I assume by Goldenboy, perhaps rotating bmodels ?

Oh as far as Frikbot goes, not sure if thats fbx you included or not, but I 
saw you have the 6 basic waypoint files in there, and there are some more 
waypoint files for some of the other ID maps that are fairly decent. 
Frikbots page has old ones and lots of em dont work too well, but the file I 
got from Moddb for Frikbot seems to have some good / better ID map waypoints 
in them so far:

[ http://www.moddb.com/mods/frikbot-x/downloads/frikbot-x-with-waypoints ]

Figuring what version of Frikbot is in what, is a tough job, there were alot 
of versions. Im messing around with that today, trying to get the waypoints 
for e1m2 going...and they are almost always failing. They must not be coded 
right as far as I can tell....and with so many versions maybe its possible 
for them to glitch if the ways were written with an older bot I guess.


==
Cobalt





----- Original Message ----- 
From: <je...@qb...>
To: <qua...@li...>
Sent: Monday, December 28, 2015 10:56 PM
Subject: [Quake-C] Yet another generic abandoned qc code project


> Howdy! Great to see the activity on this list. I haven't been actively
> coding qc lately, but I enjoy lurking around.
>
> A year ago I got pretty far with a 'Combo' QC source project.  It turned
> out other folks were doing something similar at the same time-
> attempting a durable code base with lots of features and as cleanly open
> source as possible.  Maybe someone will find it useful - download and
> more info: https://qbism.com/viewtopic.php?f=8&t=22

[Quake-C] Yet another generic abandoned qc code project

[<je...@qb...>]

Howdy! Great to see the activity on this list. I haven't been actively
coding qc lately, but I enjoy lurking around.

A year ago I got pretty far with a 'Combo' QC source project.  It turned
out other folks were doing something similar at the same time-
attempting a durable code base with lots of features and as cleanly open
source as possible.  Maybe someone will find it useful - download and
more info: https://qbism.com/viewtopic.php?f=8&t=22

qbism

Re: [Quake-C] Counting hits in FireBullets ()

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

On 2015-12-26 22:05, Cobalt wrote:
> I try to avoid .chain because I read someplace a find radius command 
> can
> change that field inadvertently.
> Not sure if this is fixed with Darkplaces or other engines, but it 
> seems it
> was maybe a Winquake bug.
> 

findradius links the ents it finds with .chain - on purpose, that is how 
it functions.
No bug here.  So if it gets called, it will be changing some .chain for 
some ents.

The trick to using .chain is make sure findradius doesnt get called 
while you use it.
Additionally you could use any .entity {named} field if it is unused.

Re: [Quake-C] manual and spec - html linked version 3.4

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

Looks neat.  Some of those links in there to stomped and ftpcdrom probably 
wont load up anymore...so yea needs editing.

this place tried to get copies of all those places and lots of other good 
resources before they disappeared off the web,  and it looks like they are 
overhauling the site : http://quakewiki.org/

As it is Wiki and lets you interact and modify as new engines come up with 
new things etc, its neat but apparently the domain has transfered and they 
want you to go to #qc on IRC. I have been on the IRC channel lots of times, 
and theres not a hella lot of talk on QC, but lots of other games and other 
non QC happens to post. When smeone does post a QC problem, takes a long 
long time before you see a response, and really not all the time the 
response is helpful.

Id post for help here, or on your mod db forum, or on the func_messageboard 
forum for coding: 
http://www.celephais.net/board/view_thread.php?id=60097&start=1875

Before I really head to #qc, but thats just my preference.


----- Original Message ----- 
From: <qu...@ca...>
To: <qua...@li...>
Sent: Saturday, December 26, 2015 10:06 PM
Subject: Re: [Quake-C] manual and spec - html linked version 3.4


> Took me awhile to plow through all the docs and figure out where to put
> this stuff...
>
> https://six-of-one.github.io/quake-specifications/index.htm
>
> Needs some editing, but that is the last major revision.
> This is where I go for most of my reference.
>
> Mostly for answering questions, I code qc by instinct now.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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] Counting hits in FireBullets ()

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

> Multifrag is an interesting idea for a statistic.

Quake 3 apparently has it. I use to play Enemy Territory alot and its 
basicly a shell of Return to Castle Wolfenstien, also based on the Q3 
engine, and some servers had put in the miltikill sounds from Q3 and
got them working.

> Part of my painkeep 3.0 release / code update calls for some advanced DM
> stats:
> first kill
> last kill
> most kills on one spawn
> most kills in first 6 secs of DM
> highest kill rate (frags /sec)
> accuracy (hits vs. misses)
> highest railgun instant hit count
> A shotgun multi hit would be a good add.

First kill and last kill, I first saw in Call of Duty when I tried playing 
that. They also have something called a "deathstreak", where after you do 
many times in a row,
you come back for a while with higher health por something...

Quake 3 seems to have an award that plays a voice sound of "Perfect" if you 
win the match without dying once. The rest you mention seems Q3 has some
a medal that you see on the screen when you get that kind of stat.

In plain Quake, hard to get more then 1 kill with just the plain 
"boomstick"...the spread is only like 6-8 units or something like that, 
while the ssg is alot wider in spread.

> Code wise it is logically the same, so its a matter of aesthetics.

Yes, true...simplifying is always alot better. I wonder if FTE compiler 
would see that and optimize it?


> As far as counting hit ents, I'd likely dispense with the locals and use
> .chain

I try to avoid .chain because I read someplace a find radius command can 
change that field inadvertently.
Not sure if this is fixed with Darkplaces or other engines, but it seems it 
was maybe a Winquake bug.

I will experiment with that code you posted , maybe I will understand entity 
chains a little better...it was always something
I never understood, and because of the findradius thing, I wound up avoiding 
studying that pretty much completely in my Quake C degree ... :o)

> Also note - that loop could have a logic bug.  It looks solid, but I
> find entity chains of any kind to
> have the potential to get messed up.

Yea, could be the bug I just mentioned.

I know for a fact during my modding, I will eprint (ent) for some reason 
just to see what entities are touching a certain field or hitting a 
traceline etc,
and it could be a brand new entity, just spawned a short time ago, and while 
Im not assigning any .chain field to it in the spawn or elsewhere, its got 
an entity number
in that field.

DP has some new entity chain management extensions that maybe are better to 
use , have not tried them. Its also got a hitmask extension you can set so 
tracelines can
collide with things normally they would not, and pick up tags on surfaces 
and such, ala Quake 3 style with Quake 3 compiled maps.

Anyhow, I wound up finding what seems to be a short term solution to my goal 
with the hitcount firing bullets. I am settling for a multikill, so the 
count wont really matter
unless the entities hit are killed, which makes sense. This will pick up 
multikills with almost all weapons. The trick is the self.attack_finished 
timer. It works great with slower reloading weapons,
but with the faster like the LG, wont ever see a multikil unless both guys 
have maybe 2 health between them and you aim exactly the center of where 
they are touching.

====================================================================
.float kills_thisframe; // declare new field in safe place in defs.qc

In the function :  W_WeaponFrame () in Weapons.qc , right above the 
ImpulseCommands ();  call, put:

self.kills_thisframe = 0; // reset number of kills this frame on a new 
attack


In Combat.qc in the Killed () function, the line above : 
ClientObituary(self, attacker);
paste this:


if (targ.flags & FL_CLIENT && attacker != world && targ != attacker)  // 
reinforcement player kills player
 attacker.kills_thisframe = attacker.kills_thisframe + 1;

 if (attacker.kills_thisframe >= 2)
 {
bprint ("Multikill ! ! ! !\n");
}

====================================================================

Also since Im modding in a Q3-ish environment, there are pretty much no 
spikes or nailguns. A thought crossed my mind, that
the sng in quake , ought to have maybe an allowance of bullets passing 
through a target at close ranges. Namly the ssg and the sng.

So if you are up close with a sng you can calculate the distance from the 
attacker and the targ and basicly set a "lethal" range, and modify the 
damage
and or, make some code that appears to show the spike or bullet passing 
through the player. Now you can have multikills with those kinds of weapons,
and it makes deathmatch combat more interesting. Of course sp with monsters 
could also be more interesting too with the new tactics....


==
Cobalt

Re: [Quake-C] manual and spec - html linked version 3.4

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

Took me awhile to plow through all the docs and figure out where to put 
this stuff...

https://six-of-one.github.io/quake-specifications/index.htm

Needs some editing, but that is the last major revision.
This is where I go for most of my reference.

Mostly for answering questions, I code qc by instinct now.

Re: [Quake-C] Counting hits in FireBullets ()

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

Multifrag is an interesting idea for a statistic.

Part of my painkeep 3.0 release / code update calls for some advanced DM 
stats:

first kill
last kill
most kills on one spawn
most kills in first 6 secs of DM
highest kill rate (frags /sec)
accuracy (hits vs. misses)
highest railgun instant hit count

A shotgun multi hit would be a good add.

Programming anything like this in qc is always quirky.
Some kind of loop to count any number of hits
(up to potentially every pellet hitting a diff target.)
would be nice...

There are some simple updates.

You dont need a test for "!= world" as world is entity 0 - the "zero" 
case.
Likewise, the opposing case.

          if (a != world && b == world && c == world)

can be:

          if (a && !b && !c)

This does reduce compile size if you are into the whole assembler coder 
thing.
Some C purists might point out it doesnt "read" as well.  Which is true.
Code wise it is logically the same, so its a matter of aesthetics.

As far as counting hit ents, I'd likely dispense with the locals and use 
.chain
and a loop.  As long as this is done inside one function.
The point being any findradius call can set some ents .chain.

something like:

// entry

local entity e;
self.chain = world;

// hit an ent

e = self.chain;

if (trace_ent.flags & FL_CLIENT) // only count humans (dm bots can set 
this flag, but all the code has to be checked!)
if (!e)
{
    self.chain = trace_ent;
    trace_ent.chain = world; // make sure each new link has a 0 in .chain
}
else
while (e)
{
    if (e == trace_ent) e = world;  // we hit the same ent (even if we 
just added it), exit loop
    else
    {
       if (!e.chain) // didnt find this ent and hit end of chain, so add 
it
       {
          e.chain = trace_ent; // link into chain and cause loop exit
          trace_ent.chain = world;
       }
       e = e.chain;
    }
}


Note that "while (e)" has no loop safety.  "trace_ent.chain = world" 
should be make the loop safe.
Personally I never like loops without a definite exit.

// end of function

self.aflag = 0; // reused ammo flag - only used in ammo box touch, 
*beware of other mods re-use
e = self.chain;
while (e)
{
    self.aflag = self.aflag + 1;
    e = e.chain;
}

// self.aflag now contains # of unique (player) ents hit with shotgun 
pellets.

This could work with splash damage as well.  I wouldnt value that as 
highly as shotgun multi-hit, however.
Splash damage is much easier to get.

Also note - that loop could have a logic bug.  It looks solid, but I 
find entity chains of any kind to
have the potential to get messed up.


When I find a loop that can go infinite, I solve it with this:

local float sf; // loop safety - if you do a lot of this "sf" can be a 
global with the mandate it only gets used one instance at a time

sf = 1000; // rough over estimate of max number of hit-able ents, this 
could be calculated exactly
            // dont forget monsters, health triggers, etc also count as 
targets


// later

while (e && sf > 0)
{
    sf = sf - 1;

// rest of loop code

}



On 2015-12-24 15:51, Cobalt wrote:
> Experimenting a little trying to tell if the shotcount winds up 
> contacting
> multiple players / clients to give credit for possible multifrag.
> 
> Came up with this so far....seems to sort of work, but not sure if it 
> can be
> improved?
> 
> 
> 
> void (float shotcount, vector dir, vector spread) FireBullets = {
> 
>    local vector direction;
>    local vector src;
> 
> 
>    local entity a,b,c;
> 
>    makevectors (self.v_angle);
>    src = (self.origin + (v_forward * MOVETYPE_BOUNCE));
>    src_z = (self.absmin_z + (self.size_z * 0.700));
>    ClearMultiDamage ();
>    while (shotcount > 0)
>    {
> 
>       direction = ((dir + ((crandom () * spread_x) * v_right)) + 
> ((crandom
> () * spread_y) * v_up));
>       traceline (src,(src + (direction * FL_WATERJUMP)),FALSE,self);
>       if (trace_fraction != 1)
>       {
> 
>       if (trace_ent.flags & FL_CLIENT) // count hits for a player
>    {
>                       if (a == world)
>     a = trace_ent;
>           else
>           {
>      if (trace_ent != a && b == world)
>                                          b = trace_ent;
>               else if (c != a && c != b && c == world) c = trace_ent;
>           }
>    }
> 
>    // heres where it gets buggy maybe ? max is 3 players  hit
>    if (a != world && b != world && b != a)
>                bprint ("Hit 2 players\n");
> 
>          if (a != world && b == world && c == world)


** you didnt make sure this was a player, what about monsters & 
shootable triggers?


>          bprint ("Hit 1 player\n");
> 
>          if (a != world && b != world && c == trace_ent)
>                 bprint ("Hit 3 players\n");
> 
> 
> 
>          TraceAttack (MOVETYPE_STEP,direction);
> 
>       }
>       shotcount = shotcount - 1;
> 
>    }
>    ApplyMultiDamage ();
> 
> };

Re: [Quake-C] Axe frames bug & variable bounds checks

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

http://www.moddb.com/groups/qc/forum/thread/axe-frames-bug

Details the fix for the axe frame overrun issue.