quake-c-users — Email support

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

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

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

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

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

On 2015-12-18 17:17, Cobalt wrote:
> Whats the definition of this solid? I thought I read somewhere , it was
> touch on bottom but not sides, or is it vice versa?
> 
> ==
> Cobalt

5.7 Collision detection

SOLID_NOT = 0;                 // no interaction with other objects
                                // inactive triggers
SOLID_TRIGGER = 1;             // touch on edge, but not blocking
                                // active triggers, pickable items
                                // (.MDL models, like armors)
SOLID_BBOX = 2;                // touch on edge, block
                                // pickable items (.BSP models, like ammo 
box)
                                // grenade, missiles
SOLID_SLIDEBOX = 3;            // touch on edge, but not an onground
                                // most monsters
SOLID_BSP = 4;                 // bsp clip, touch on edge, block
                                // buttons, platforms, doors, missiles


The first 2 of course are not solid.

BBOX are the explode boxes and some odd level architecture here and 
there.

SLIDEBOX are mostly monsters and players

BSP are all the doors, plats, func_walls, etc.

In darkplaces if you set:

r_showbboxes 2

it will show all those - colors in order are

0 white
1 purple
2 green
3 red
4 blue

As far as exactly what they are and do...that is buried in the engine 
code.
I know the BSP solid exactly follows the brush structure.  The others go 
by bounding box.
Darkplaces also adds some options.

And when I figure out how to upload it, I'll put up some of my html 
linked quake-c manuals.

Also, I covered this on the qc forum somewhere...I need to link that 
stuff in as well, so
this will likely be a continuing work.

Re: [Quake-C] SOLID_SLIDEBOX

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

Hi Six,

Yea I was actually just reading what you posted on indiedb, which is I guess 
the same as moddb:
http://www.indiedb.com/groups/quakedb/tutorials/quake-c-touch

When it says slidebox touches  , but not an onground, does that mean its not 
going to touch ground, and set FL_ONGROUND flags? It also blocks too I 
guess.

Also good info on the colors the boxes are for different solids when showing 
the bboxes.

I did experiment with SOLID_CORPSE and its quite adequate for corpses. It 
will show an orange color surrounding box.

Tricky part with the corpse solid, is tracelines will pass through it unless 
you make the ignore ent WORLD.

==
Cobalt



----- Original Message ----- 
From: <qu...@ca...>
To: <qua...@li...>; "Cobalt" <co...@te...>
Sent: Saturday, December 19, 2015 1:38 AM
Subject: Re: [Quake-C] SOLID_SLIDEBOX


> On 2015-12-18 17:17, Cobalt wrote:
>> Whats the definition of this solid? I thought I read somewhere , it was
>> touch on bottom but not sides, or is it vice versa?
>>
>> ==
>> Cobalt
>
> 5.7 Collision detection
>
> SOLID_NOT = 0;                 // no interaction with other objects
>                                // inactive triggers
> SOLID_TRIGGER = 1;             // touch on edge, but not blocking
>                                // active triggers, pickable items
>                                // (.MDL models, like armors)
> SOLID_BBOX = 2;                // touch on edge, block
>                                // pickable items (.BSP models, like ammo 
> box)
>                                // grenade, missiles
> SOLID_SLIDEBOX = 3;            // touch on edge, but not an onground
>                                // most monsters
> SOLID_BSP = 4;                 // bsp clip, touch on edge, block
>                                // buttons, platforms, doors, missiles
>
>
> The first 2 of course are not solid.
>
> BBOX are the explode boxes and some odd level architecture here and there.
>
> SLIDEBOX are mostly monsters and players
>
> BSP are all the doors, plats, func_walls, etc.
>
> In darkplaces if you set:
>
> r_showbboxes 2
>
> it will show all those - colors in order are
>
> 0 white
> 1 purple
> 2 green
> 3 red
> 4 blue
>
> As far as exactly what they are and do...that is buried in the engine 
> code.
> I know the BSP solid exactly follows the brush structure.  The others go 
> by bounding box.
> Darkplaces also adds some options.
>
> And when I figure out how to upload it, I'll put up some of my html linked 
> quake-c manuals.
>
> Also, I covered this on the qc forum somewhere...I need to link that stuff 
> in as well, so
> this will likely be a continuing work.
> 

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.

[Quake-C] SOLID_SLIDEBOX

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

Whats the definition of this solid? I thought I read somewhere , it was 
touch on bottom but not sides, or is it vice versa?

==
Cobalt 

[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

[Quake-C] email users

[rien b. <cat...@kp...>]

it seemed clear to me that when there's a discussion thread to use it.
not that I dislike email, but when I receive the email, 
why would I return to the sourceforge to read it?

Re: [Quake-C] email users

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

Hi Rinnie:

Yes, it comes as a default when you make a project on Sourceforge. I left it 
up just in case. I see you made a post there 2 days ago, I didnt know this.

In my admin options , there is a "Allow posting replies via email" setting 
for the forum / diuscussion feature, I have it set to on. Not sure if that 
will make forum posts come through to this list or not. I will try a reply 
in the forum to your post to see.

==
Cobalt



----- Original Message ----- 
From: "rien brouwers" <cat...@kp...>
To: <qua...@li...>
Sent: Thursday, December 10, 2015 7:54 PM
Subject: [Quake-C] email users


I wondered why there's a discussion page.



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


> ------------------------------------------------------------------------------
>


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


> _______________________________________________
> 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] email users

[rien b. <cat...@kp...>]

I wondered why there's a discussion page.

Re: [Quake-C] Clean qc src codes

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

Since we have some new members here, I wanted to bump this first post to the 
list up in case there is maybe an interest here in perhaps starting our own 
Clean QC version?

Otherwise, maybe an intro post, describing your "Quake" experience, skillz, 
or interests / mods worked on or working on would be a great way to break 
the ice here.

As for me, Im basicly a die hard Quake player since 1999, my original Quake 
name was Teknoskillz, but when I code or use forums I use the name Cobalt. 
Turns out Cobalt as a user name is used alot, so I have to switch names 
depending on where I am.

 I took a break in 2004-2008 then came back to continue working on my mod 
called TekbotCTF+ which is a mod based on CTFBOT+ released in the early days 
of quake, where bots are programmed to play ctf. Since then I have found 
Quake C very interesting, and its my strongest "Quake skill asset" out of 
everything. When I returned, I found the new Darkplaces engines very 
innovative,
so I have ported my old mod to work with the newer Darkplaces engines, and 
its strictly a Darkplaces Only mod now.

During my development, I decided to reopen an old Quake mod by Electro many 
years ago, called: Quake 1 Arena. Which puts Quake 3 type game play into a 
Quake 1 engine and brings deathmatch in q1 to a enhanced level.
Its using Frikbot which I thnk it the best q1 bot out there, and I have 
added Lightning Hunters "Ultimate Frikbot mappack" to the mod, so its now 
got 500+ maps in a rotation, many of them have Frikbot waypoints so they 
know alot of these great classic dm levels that the quake mapping community 
has made over the many years.

While I dont yet have an official downloadable release yet, I do have a live 
server up running most of the new features I put into Q1arena. I also 
recently signed up at moddb, and have a page there that describes everything 
including the server: http://www.moddb.com/members/teknoskillz

Hopefully we will get some more people here in the list as time goes on, but 
right now I see we have a total of (4) people including myself, so lets see 
what we can do.

==
Cobalt




----- Original Message ----- 
From: "Cobalt" <co...@te...>
To: <qua...@li...>
Sent: Thursday, December 03, 2015 12:38 PM
Subject: [Quake-C] Clean qc src codes


> Well, here is the first post to the new list, lets hope we wind up getting
> some more people here as time goes on.
>
> But for now, I guess its just you and me Jeff...so maybe we can start off
> with clean src as the starting subject.
>
> I think Gnoucs release is the most popular out there, and I have emailed 
> him
> about this list, hope he comes.
>
> First thought, and I did not look at all his code completely, is....is it
> well commented? I think I recall him tackling the Obit bug that was 
> probably
> one of the first things people did when they put improvements in which I
> think he now calls deathstrings.  The goal is to prevent the wrong death
> message from coming up in the event the attacker / self.enemy of the 
> target
> has changed weapons while the killed players "death scenes" are playing in
> player.qc
>
>>From what I remember his code is well commented on this in the Obit area 
>>in
> the QC, and I believe he made a Makevectors2 function that will correct 
> the
> pitch problem where a clients pitch is really its v_angle_x instead of its
> angles_x to get the right v_forward, v_right and v_up results.
>
> Im sure theres more to it if I looked more carefully at it.
>
> Also there is the old QIP sites fixes , so I wonder if hes has put them in
> as well.
>
> ==
> Cobalt
>
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple 
> OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> _______________________________________________
> Quake-c-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quake-c-users
> 

Re: [Quake-C] login

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

Hi Rinnie:

Glad you could make it !

Not sure what the login issue is, but for sourceforge, they have a login if 
you have an account with them, but I dont think you need it to access the 
Quake C project.

--
Cobalt


----- Original Message ----- 
From: "rien brouwers" <cat...@kp...>
To: <qua...@li...>
Sent: Tuesday, December 08, 2015 1:43 PM
Subject: [Quake-C] login


cat...@kp...
tried login, failed.

[Quake-C] login

[rien b. <cat...@kp...>]

cat...@kp...
tried login, failed.

[Quake-C] DeathBubbles bug

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

Found this over on the ModDb QC forum, by number6 -

Dont remember seeing it mentioned before

void() DeathBubblesSpawn =
{
local entity bubble;

if (self.owner.waterlevel != 3)
{
// new code - add a remove here, or the spawner stays on the server forever 
or until reload
remove(self); // v1.09 bug fx - previous logic left bubble spawners around
// end new code
return;
}

// rest of code
}; 

[Quake-C] Clean qc src codes

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

Well, here is the first post to the new list, lets hope we wind up getting 
some more people here as time goes on.

But for now, I guess its just you and me Jeff...so maybe we can start off 
with clean src as the starting subject.

I think Gnoucs release is the most popular out there, and I have emailed him 
about this list, hope he comes.

First thought, and I did not look at all his code completely, is....is it 
well commented? I think I recall him tackling the Obit bug that was probably 
one of the first things people did when they put improvements in which I 
think he now calls deathstrings.  The goal is to prevent the wrong death 
message from coming up in the event the attacker / self.enemy of the target 
has changed weapons while the killed players "death scenes" are playing in 
player.qc

>From what I remember his code is well commented on this in the Obit area in 
the QC, and I believe he made a Makevectors2 function that will correct the 
pitch problem where a clients pitch is really its v_angle_x instead of its 
angles_x to get the right v_forward, v_right and v_up results.

Im sure theres more to it if I looked more carefully at it.

Also there is the old QIP sites fixes , so I wonder if hes has put them in 
as well.

==
Cobalt