quake-c-users

[Quake-C] qc++

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

Hey guys!

Finally took a minute out of my busy coding schedule to join.  :-)

Trying to get some version of quake-hack released by christmas...

I'll post here when I have updates on qc: http://www.moddb.com/groups/qc

------------------------------------------------------

As far as a clean version of qc.

I'm curious as to exactly what your "clean" is.  Kind of subjective.
Bug and warning free?

I have to caution you, fteqcc has freaking warning overload.  Any, 
little, thing.  Compile with "-Wall" to be amazed.


Years back I was doing a log of work with frikqcc and I eradicated all 
those compiler warnings.
The original release had a ton.  That fixes a few hidden bugs too.  And 
makes it easier to find new problems.


I've killed most of the bugs in the release I made: 
http://www.moddb.com/games/quake/downloads/quake-c-version-106
And hipnotic: 
http://www.moddb.com/games/quake/downloads/hipnotic-quake-c-release

But as we all know, there are still a few bugs hiding in there.


More recently I had to switch to fteqcc.  The Archon project: 
http://www.moddb.com/mods/chaos-archon
blew the 32768 global limit in quake under frikqcc.

When I moved to the new compiler I fixed many of the quirky little 
things with #define wrappers: 
http://www.moddb.com/games/quake/downloads/quake-c-version-106-recoded

Some things dont cause warnings, and arent bugs - just how quake-c was 
originally written.
"Fixing" them can potentially change game play, so I wrapped them.  Take 
out the main define and they come back.


I've focused a lot of my programming effort on a smaller size progs.dat 
with lower global usage.
I think I might be kind of obsessive about this.

I've come up with a method for "true" local variables.  Whether or not 
you realize, every local, every global,
every function parameter, every function declaration, every unique 
string, every unique literal - all take up global slots.

The "locus" method uses an entity and #define macros to store data in a 
special entity.
The same can be done with globals...  Think I'll call that method 
"globus".

The next method for reducing globals is the framer macro.  The old frame 
macro uses 1 global for every frame -
it makes a funciton declaration.  So I made a loop function in a macro, 
to cut down on that.

------------------------------------------------------

What I want to do next with quake-c once quake-hack is rolling along 
after the beta release, and I get back to
the Archon project.

A darkplaces only quake-c.  My mods have pretty much become dp only, so 
why not.
I'm piloting much of the code in qc++ right now.

This is going to be a radical re-code using darkplaces extensions 
heavily.
No attempt is going to be made to ensure complete v1.06 compatibility.

A reasonable effort will be made to ensure a very similar game play.

I'm planning on stripping out most spawn functions, using the new framer 
macro for all frame code
and eliminating much redundant code.  (v1.06 re-coded already has a bit 
of this)

Most large strings will be replaced with cvar_string (if I can get the 
damn intermission text to print...)

This will be a much different beast.

Stay frosty!

-6

Re: [Quake-C] qc++

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

Hi Six:

Great post, glad you made it here !


> I'll post here when I have updates on qc: http://www.moddb.com/groups/qc

Thats where I found you, lots of good stuff posted in the Quake C forum, 
looks like you been there alone mostly for a long while....not much 
activity, but I did add some stuff to try and revive it a bit.


> I'm curious as to exactly what your "clean" is.  Kind of subjective.
> Bug and warning free?

The first time I saw the "clean" reference is with a guy called Gnouc on the 
inside3d forums, (who I have invited here but so far a no show) he has 
improved alot of stuff and included I think some of the old Quake Info pool 
fixes, and he has used a string called "deathstring" to solve the problem of 
the obit leaking the wrong death message while the players death frames are 
running and the enemy happens to change weapons, it would display the wrong 
message. Thats one example, another is he included a makevectors2 () 
function that returns the correct _x value , plus likely some others I did 
not see yet. So bug free , yea...and improved as much as possible. However I 
noticed there is no table of contents or "index" for lack of a better term, 
that describes each item he has included. Your fix for the death bubbles 
leaving a spawner behind is definately one he has not put in, also there is 
a fix to not let armor get damage if you are drowning, which the original 
src codes have as a bug. So things like that, and if we can eliminate 
compile warnings, sure why not, but sometimes the warnings are unavoidable.


> I have to caution you, fteqcc has freaking warning overload.  Any,
> little, thing.  Compile with "-Wall" to be amazed.

Im trying to get Spike to come here but it may be futile. There are alot of 
options with the compiler that might solve some of that...not sure.

I have reported some unusual hiccups I have seen with his compiler over the 
years, the most recent one is :

.float corpseflag;
.vector bbox_plane;

 if (ref.corpseflag < 2 || ref.bbox_plane == 0)

...will not error with a type mismatch error, it lets you compile like that. 
Whereas take Frik's compiler, and it will find that instantly. (by the way I 
have also invited Frik here, but so far MIA just like Lord Havoc)



> Years back I was doing a log of work with frikqcc and I eradicated all
> those compiler warnings.
> The original release had a ton.  That fixes a few hidden bugs too.  And
> makes it easier to find new problems.

Feel free to post them here, we can perhaps collaborate a new clean src that 
we can offer here as our own monster so to speak. We should probably make an 
index of the things we are including, such as commented fields in progs.src 
for example. Most the things I have seen in Gnoucs src , he comments so we 
know hes changed something. Im terrible with commenting my work, but I am 
getting better at the habit.


> I've killed most of the bugs in the release I made:
> http://www.moddb.com/games/quake/downloads/quake-c-version-106
> And hipnotic:
> http://www.moddb.com/games/quake/downloads/hipnotic-quake-c-release
> But as we all know, there are still a few bugs hiding in there.

Didnt see these yet. Are they commented with the changes made? I took a quik 
peek at the 1.06 and it looks like Karmacs original 1.06 release but I didnt 
sift through it totally.

> When I moved to the new compiler I fixed many of the quirky little
> things with #define wrappers:
> http://www.moddb.com/games/quake/downloads/quake-c-version-106-recoded

#define is I believe a FTEqcc only tag? Its basicly the same as a comment 
field right?

 > I've focused a lot of my programming effort on a smaller size progs.dat
> with lower global usage.
> I think I might be kind of obsessive about this.

FTE compiler really optimizes better than any other I have seen.

I did recommend a new feature to Spike today about backing up src files 
perhaps as a compressed zip in a user specified folder nearby on every 
compile. The thought already crossed his mind, so maybe we will see that as 
a new feature.

> I've come up with a method for "true" local variables.  Whether or not
> you realize, every local, every global,
> every function parameter, every function declaration, every unique
> string, every unique literal - all take up global slots.
> The "locus" method uses an entity and #define macros to store data in a
> special entity.
> The same can be done with globals...  Think I'll call that method
> "globus".
> The next method for reducing globals is the framer macro.  The old frame
> macro uses 1 global for every frame -
> it makes a funciton declaration.  So I made a loop function in a macro,
> to cut down on that.

Saw some of this on the moddb forum, but was not sure I understood, feel 
free to explain more in detail here.


> What I want to do next with quake-c once quake-hack is rolling along
> after the beta release, and I get back to
> the Archon project.

Any videos / demos made of Archon yet?

Also a Quick way to show off your demos, is Webquake [ 
https://github.com/SiPlus/WebQuake ] as an alternative to the youtube thing.


> A darkplaces only quake-c.  My mods have pretty much become dp only, so
> why not.
> I'm piloting much of the code in qc++ right now.
> This is going to be a radical re-code using darkplaces extensions
> heavily.
> No attempt is going to be made to ensure complete v1.06 compatibility.

I use DP only strictly now, and you cant really ensure backwards 
compatability once you put the extensions DP offers anyway, without using 
them its just mostly vanilla Q.


> This will be a much different beast.

Feel free to post them here or show off using demos etc. The Moddb site, 
surprisingly is very feature rich, but lacks in some areas. ...such as an 
email list like we are using. The Sourceforge system seems to offer GIT type 
systems now and its Github compatable which I guess is a + , but Im still 
learning GIT, and I have told GitHub staff that their system does not 
officially recognize Quake C per say - but if its refered to as C# , most 
the tags and syntax highlightn seems to work.

Re: [Quake-C] qc++

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

Strange, I just noticed the function: T_BeamDamage () , is not even called 
in 1.01 or 1.06 src code sets.

Its using FindRadius, and if I recall someone had said that function is very 
very slow.

I have seen some other code in my travels that resembles this function, 
however they are not using Findradius, but nextent, for example:

float (vector pt, float damage) Calc_PointDamage =
{
 local entity head;

 head = nextent (world);

 while (head != world)
 {

  if (head.takedamage > 0)
  {

  if (vlen (head.origin - pt) <= POINT_GIB_RADIUS) // Gib radius  set as a 
global
  {
   if (damage > 0)
   T_Damage (head, damage);

   return 1;
  }

  }

  head = nextent (head);
 }
 return (0);
};


Were pt is the origin of the old findradius method. Apparently walking down 
the entity list is faster than findradius?
Also I have read where the findradius sets the .chain field even on entities 
not in the specified radius, so if true it can louse up some mods that rely 
on that field as being empty or world.

So if we do make our own clean src, I suppose we could eliminate / delete 
T_BeamDamage completely.

Re: [Quake-C] qc++

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

If you havent already, get v1.06 recoded: 
http://www.moddb.com/games/quake/downloads/quake-c-version-106-recoded

T_BeamDamage as well as 31 other instances are wrapped with

#ifdef unused

#endifdef

That will tell you what all the unused bits are.

I cant recall offhand how intense a test I gave that code set, but I'm 
pretty sure it involved a bunch of frikbots and several days of server 
time.

You could take all that out, along with debug and idtest #ifdef sets.

However, with the #ifdef there is no reason - it wont get compiled.

The main reason I left it in, is if you are using meld to merge other 
mods, it will only see the #ifdef (and you can teach it to ignore 
that...)
and match the rest.  Easier meld that way.

That was pretty much the whole point to v1.06 recoded - help clean up 
other mods built on v1.06.

I might eventually do a hipnotic recoded, but likely not as it will be 
in v1.07.


On 2015-12-19 19:53, Cobalt wrote:
> Strange, I just noticed the function: T_BeamDamage () , is not even 
> called
> in 1.01 or 1.06 src code sets.
> 
> Its using FindRadius, and if I recall someone had said that function is 
> very
> very slow.
> 
> I have seen some other code in my travels that resembles this function,
> however they are not using Findradius, but nextent, for example:
> 
> Were pt is the origin of the old findradius method. Apparently walking 
> down
> the entity list is faster than findradius?
> Also I have read where the findradius sets the .chain field even on 
> entities
> not in the specified radius, so if true it can louse up some mods that 
> rely
> on that field as being empty or world.
> 
> So if we do make our own clean src, I suppose we could eliminate / 
> delete
> T_BeamDamage completely.
> 

Re: [Quake-C] qc++

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

> If you havent already, get v1.06 recoded: 
> http://www.moddb.com/games/quake/downloads/quake-c-version-106-recoded

Started looking at it.

Looks like you commented alot of stuff, so thats good.

Whats the deal with crandom? Looks like you are saying the #ifdef means
that if the  mod used the crandom function, then use the alternate? Sorta 
lost on those #
 type references, thought they are just like the comment fields , ie: // ?

Re: [Quake-C] qc++

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

> Looks like you commented alot of stuff, so thats good.

If I dont, it is so freaking hard to figure out 3 months later - after I 
had to leave the code for a bit...
Learned commenting the hard way.


> Whats the deal with crandom? Looks like you are saying the #ifdef means
> that if the  mod used the crandom function, then use the alternate? 
> Sorta
> lost on those #
>  type references, thought they are just like the comment fields , ie: 
> // ?

#{precompiler code} are all interpreted by the compiler, very similar to 
various c languages.


I wrapped the function in "#ifndef opgrade".  So if opgrade is defined 
it uses the #define for crandom.
If opgrade is not defined it uses the old function.


#define crandom() 2*(random() - 0.5)

Is just like

float() crandom =
{
         return 2*(random() - 0.5);
};

Except - the define is a macro that plugs in the code "2*(random() - 
0.5)" for "crandom()".

So:

vel = normalize(dir + v_up*crandom() + v_right*crandom());

Compiles that way without opgrade defined.

With opgrade it compiles as

vel = normalize(dir + v_up*2*(random() - 0.5) + v_right*2*(random() - 
0.5));

I did that just an experiment to find out if it works the same.  Have 
the test data somewhere.


It does save a global slot and a function slot - some of these

    977 numfunctions (of 16384)
   3474 numglobaldefs (of 32768)
   3826 numpr_globals (of 65536)

At the expense of compiled code complexity.

Which could be important if you are approaching those limits.

What it does to the running c interpreter is hard to tell.  It avoids a 
function call, and runs the same math code,
so you would think it saves some ops here and there.  Certainly saves 
data on the stack.

Which means nothing on the hardware most of us have.  Could have meaning 
on the psp and other mobiles that run darkplaces.



fteqcc precompiler ops (these are in the fteqcc docs.)


#define opgrade

Gives opgrade a detectable existence for:

#ifdef opgrade

// opgrade defined

#else

// opgrade NOT defined

#endifdef

or

#ifndef opgrade

// opgrade NOT defined

#endifdef


#undef opgrade

Make opgrade undefined again.  This is also useful for a substitute that 
only gets used in one module.


#define crandom() 2*(random() - 0.5)

creates a substitue macro, where the text "crandom()" is replaced with 
"2*(random() - 0.5)".

You dont need the ()

#define a__		aflag

These can have function parameters:

#define framer(sframe,eframe,t_on,t_to,t_time,excode) void() t_on {if 
(self.think != t_on|| self.frame < sframe || self.frame >= 
eframe){self.frame = sframe - 1; self.think = t_on;} self.frame = 
self.frame + 1; self.nextthink = time + t_time; if (self.frame == 
eframe) {self.think = t_to;} excode;}

Also they can be very complex.  The compiler currently has a 256 byte 
limit on that - but unlimited substitutions.
So you can make a bunch of those and string them all together in a final 
one.
In fact if you want to print a literal string, like "Hey there" from 
that - you have to use multiple defines.


#include <incl/local_ent.qc>

Inlcudes the specified file.


#message         			-- version 1.07 qc++ quake-c -- compile 
with fteqcc

Dumps a message out from the compile about what sequence just compiled.
No idea how that will look here - I have backspaces to overwrite the 
"message:" tag that precedes it.


// turn off warnings for map spawn functions - most are normally only 
called by the engine
#pragma warning off F300

These control compiler behavior.  That stops it from complaining because 
spawn functions dont get
referenced directly in the qc code.  That seems like a very silly 
complaint given how qc works.


These are awesome - I can now do things with quake-c without a bunch of 
crap.

Like having to wrap all the warnings with some master variable, and then 
delete every one of them when I want to
find out how and / or if the code runs without them.

And for purists I can leave in the practically useless iD debug and test 
code.
(In fact, when I tried it, I found out some if it would not compile at 
all, and other bits fail or do nothing. I fixed some of it...)

It also makes the code more portable.  For darkplaces its easy to remove 
the un-needed precache (since it has dynamic).
If you want to move to another engine, you can just turn it back on.


Between this and some of the darkplaces builtin its like a dream.
I can do stuff now that just were not possible with out a lot of if 
thens, tons of literal strings, etc.
Code logic, that makes the old qc look like a dino!

I had been putting off learning the darkplaces extension (once I decided 
my mod was dp only a couple years back)
to finish the Archon mod.  Little did I realize it is the only way I'll 
ever finish the mod.

Now I'm slamming along with the new stuff.

-6

[Quake-C] Counting hits in FireBullets ()

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

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

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

[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] 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] 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] Frikbot, dynamic waypoints

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

Ok, found out that Frik actually made a "way studio" mod for Frikbot [ 
frikway1.zip ] , found it here:
https://www.quaddicted.com/files/mirrors/ftp.telefragged.com/inside3d/frikbot/

Im trying it now, and looks like -condebug is required as its probably not 
supporting frik_file, though I have not looked in the src just yet.

But turns out when you run the game, the menu is already up and looks like 
if you close it, you can see the waypoints being made.

>From what I can tell, seems to do alot better job than whats in my Frik qc, 
so will try it later with a non waypointed map and see how I do.

Also lots of Frik related stuff on that page...


==
Cobalt

[Quake-C] Quad Explosion radius

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

Should the explosion radius for the Quad case be a larger radius?

Heres what Im gonna try:

===================================================================
void (entity inflictor, entity attacker, float damage, entity ignore) 
T_RadiusDamage =
{
 local float points,rs;
 local entity head;
 local vector org;


          rs = damage + 40;

          if ((attacker.items & IT_QUAD) || (inflictor.items & IT_QUAD))
            rs = rs * 1.5;

 head = findradius (inflictor.origin, rs);


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

Bumping up the radius 50%....while more damage tends to be larger 
explosions, increasing it by 4x the normal radius would be an overkill.

Also perhaps takedamage entities closer to the blast take more damage than 
others at its perimiter? Perhaps something on the edge has a chance to save 
vs radius damage?


===
Cobalt

[Quake-C] Better Waterjump?

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

While Darkplaces uses a gameplayfix cvar that activated I believe QW's new 
improved waterjumping, there is still an issue it does not fix...you can see 
mostly only on the map DM5. If you go in the water and try to wj into the 
area that has the 666 and are to the extreme left or right , your head hits 
the top of the map....and it will perpetually waterjump you forever until 
you move more toward the center.

I came up with this new code which takes care of this case on DM5, however 
there is now a new problem on a map such as DM3, where if you are in the 
water and try to waterjump  onto the bridge near its end, its got a angled 
corner, so you wont be able to wj unless you are facing closer to the 
center.

Not sue if anyone wants to try the code, here it is, and if there is an idea 
for fixing the DM3 problem, would like to hear it. I suppose we could check 
only for the DM5 map and bypass the new check, and that would fix it, but 
maybe there is a better way because other maps can be made and possibly 
exhibit this same problem.



void ()
CheckWaterJump =
{

          if (self.cl[CL_CMD_FORWARD] <= 0) return; // For Proquake mostly, 
dont proceed unless we are traveling forward
          local vector start, end;
    // check for a jump-out-of-water
    makevectors (self.angles);
    start = self.origin;
    start_z = start_z + 8;
    v_forward_z = 0;
    normalize (v_forward);
    end = start + v_forward * 24;
    traceline (start, end, TRUE, self);

    if (trace_fraction < 1)
    {    // solid at waist

        start_z = start_z + self.maxs_z - 8;
        end = start + v_forward * 24;

        traceline (start, end, TRUE, self);
        if (trace_fraction == 1)
        {    // open at eye level
                              local float safe;
                              start = end;

                              traceline (start, end + v_right * 16, TRUE, 
self);
                              if (trace_fraction == 1) // clear this side
                              {
                               safe = safe + 1;
                              traceline (start, end + v_right * -16, TRUE, 
self);
                              if (trace_fraction == 1) // clear other side
                              safe = safe + 1;


                              }

                              if (safe == 2)
                              {
                              self.flags = self.flags | FL_WATERJUMP;
                              local float vj;
                              if (self.items & IT_SUIT) // Larger boost for 
suit - optional
                              vj = 1.1;
                              else vj = 1.05;
                              self.velocity_z = (vlen(self.velocity * vj)); 
// Different calc than ID had, better?
                              self.movedir = trace_plane_normal * -50;
                              self.flags = self.flags - (self.flags & 
FL_JUMPRELEASED);
                              self.teleport_time = time + 2;    // safety 
net
                              }

        }
    }
};

[Quake-C] New member

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

Just welcoming new guy - Specialbomb to the list.

Apparently he is seeking how to get started doing QC. I updated our 
reference section to include a link to Spikes
fte compiler which is supported in Win and Linux.

We have a active dl here for a clean progs 1.06 if you want to start fresh. 
Though there are some other places offering some clean src downloads,
we try to organize them here when possible, and at some point I may try to 
get our own clean src version going , as there are lots of new material
that can be useful even today considering Quake is nearly 20 years old, 
which is pretty astonishing.

Anyhow, we are here to assist.


==
Cobalt

[Quake-C] Roll Angle

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

Trying to figure out the roll value on an ent that I am basicly sticking to 
a wall, in this case its a gib. The code works pretty well,
and sticks the Gib to the wall, and gradually drops it down as a noclip 
type. Trouble is I am giving it an avelocity as a cheap solution
based on a calc from trace_plane_normal that I believe is sorta cheesy, but 
for the time being the rest eludes me.

I think it would be a matter of determining which value weather X, Y or Z 
would need to be applied because trace_plane_normal
will be different on walls that are up in different directions with respect 
to the world.

First part of the code is like:

       self.solid = 0;
      self.movetype = MOVETYPE_STEP; // thought I had it as noclip but I 
guess this works better
      self.avelocity = (vectoangles (trace_plane_normal) + self.size) * 
0.05;  // This is the main calc
      self.velocity_z = vlen (self.size) * -1.125;  // Downward depending on 
overall size


...Which gets it moving ok. Then I have it thinking and doing this calc:

self.avelocity = (random()) * (vectoangles (self.size) + vectoangles 
(self.velocity));


and that sort of slows down the overall rotation near the point it sort of 
looks ok, cept the rotation is not
usually happening horizontaly with respect to the wall its stuck to, thats 
the part I need to isolate.

Im only grabbing trace_plane_normal once in the gibs touch field, as 
Darkplaces accurately populates that field
in any .touch usually very accurately, but I think perhaps I would need to 
do a traceline continually as the gib falls
in its think because its possible the surface of the wall may change as well 
as it reaching a corner, in which case we can either
make it fall to the floor or just hang there and bleed for a while.

Yea, I know ....gross right ? Sorry if this ruins anyones lunch....

==
Cobalt

Re: [Quake-C] Roll Angle

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

On 2016-08-22 12:38, Cobalt wrote:
> Trying to figure out the roll value on an ent that I am basicly 
> sticking to
> a wall, in this case its a gib. The code works pretty well,


I gather what you want is the appearance of the gib "rolling" down the 
wall.

I know if you want to rotate around the Z axis, you set avelocity_y...
So what you likely want is some combination of _x or _z and the model 
facing.


You might also want:

MOVETYPE_TOSS			= 6;	// gravity

Dont gibs already have that set?


>       self.avelocity = (vectoangles (trace_plane_normal) + self.size) *
> 0.05;  // This is the main calc

Does this do what you want?


>       self.velocity_z = vlen (self.size) * -1.125;  // Downward 
> depending on
> overall size


This would move something in a negative z direction.  Not sure about 
using size to calculate the vector.

What about walls that shift away from a 90 degree vertical plane?
(This is the same issue as the corner problem.)

makevectors(trace_plane_normal);

v_up should now point vertically up along the face of the wall.
Negate that for a velocity_z.



> self.avelocity = (random()) * (vectoangles (self.size) + vectoangles
> (self.velocity));


This will impart some random rotational velocity.


> Im only grabbing trace_plane_normal once in the gibs touch field, as
> Darkplaces accurately populates that field
> in any .touch usually very accurately, but I think perhaps I would need 
> to
> do a traceline continually as the gib falls

You indeed must call traceline to populate the normal field.

> in its think because its possible the surface of the wall may change as 
> well
> as it reaching a corner, in which case we can either
> make it fall to the floor or just hang there and bleed for a while.


Some version of this "should" work:

self.angles = vectoangles(trace_plane_normal); // face the normal - note 
this will "jump" if not close to this facing
self.avelocity_z = 30; // or your size / velo based calculation -- 
negate if it rolls the wrong way

if that isnt it try self.avelocity_x.

You may also want to try setting angles to v_right
(you need makevectors(trace_plane_normal); to get them.)




Another thing to _possibly_ look into (it gets implemented in the HD 
pack) is the gyro
physics package.

http://www.quakewiki.net/quake-1/mods/gyro/

http://quakeone.com/forums/quake-mod-releases/finished-works/6076-small-mod-compilation.html

> Added adjustable Gyro physics: Monsters, gibs and backpacks interact 
> with liquids and weapon projectiles

Whether that will do what you want, I cant say.
Nor how it gets implemented.

You could install and load the small mod.
I know one feature is "kicking" gibs, by walking on them.
You could make some gibs, kick them around and see what they do near 
walls.

Re: [Quake-C] Roll Angle

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

> I gather what you want is the appearance of the gib "rolling" down the
> wall.

Pretty much.


> What about walls that shift away from a 90 degree vertical plane?
> (This is the same issue as the corner problem.)
> makevectors(trace_plane_normal);
> v_up should now point vertically up along the face of the wall.
> Negate that for a velocity_z.

This definately is what I was looking for. Only so far the rotation is 
always rolling backwards with respect to the direction
of the wall.

As for when it reaches the bottom corner of an overhead , say for example a 
spiked part of the bsp on the ceiling, or similar,
I dont know how to detect such. I am using checkbottom()  but apparently its 
got a height tolerance gap which is pretty big,
so there is a false positive and you can sometimes see the gib still rolling 
in mid air.