quake-c-users Mailing List for Quake C (Page 4)
Quake C mods and support - SSQC / CSQC
Brought to you by:
teknoskillz
You can subscribe to this list here.
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(26) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2016 |
Jan
(15) |
Feb
(17) |
Mar
(5) |
Apr
(7) |
May
(2) |
Jun
|
Jul
|
Aug
(5) |
Sep
(4) |
Oct
(6) |
Nov
(2) |
Dec
(1) |
2017 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Cobalt <co...@te...> - 2015-12-24 21:51:47
|
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 (); }; |
From: <qu...@ca...> - 2015-12-21 01:31:28
|
> 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 |
From: Cobalt <co...@te...> - 2015-12-20 23:08:35
|
> 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: // ? |
From: <qu...@ca...> - 2015-12-20 05:36:23
|
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. > |
From: Cobalt <co...@te...> - 2015-12-20 01:53:37
|
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. |
From: <qu...@ca...> - 2015-12-19 07:26:19
|
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. |
From: Cobalt <co...@te...> - 2015-12-19 07:13:54
|
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. > |
From: Cobalt <co...@te...> - 2015-12-19 03:16:59
|
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. |
From: Cobalt <co...@te...> - 2015-12-19 02:14:57
|
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 |
From: <qu...@ca...> - 2015-12-18 23:12:12
|
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 |
From: rien b. <cat...@kp...> - 2015-12-13 00:53:51
|
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? |
From: Cobalt <co...@te...> - 2015-12-11 01:11:01
|
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/ > ] |
From: rien b. <cat...@kp...> - 2015-12-11 00:54:38
|
I wondered why there's a discussion page. |
From: Cobalt <co...@te...> - 2015-12-09 23:01:44
|
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 > |
From: Cobalt <co...@te...> - 2015-12-08 19:36:08
|
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. |
From: rien b. <cat...@kp...> - 2015-12-08 18:57:16
|
cat...@kp... tried login, failed. |
From: Cobalt <co...@te...> - 2015-12-05 18:11:42
|
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 }; |
From: Cobalt <co...@te...> - 2015-12-03 17:56:46
|
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 |