quake-c-users Mailing List for Quake C
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: <qu...@ca...> - 2017-02-22 23:49:18
|
This must have lost its way...resending -------- Original Message -------- Subject: Re: [Quake-C] Need help with surface lighting and RT lighting Date: 2017-02-20 12:45 From: qu...@ca... To: QC <qua...@li...> I think you are asking if the _surface emits light live in game. I gather it doesnt? Quake 1 never had surfaces emit light, point lights only. Quake 3 had surface light, and darkplaces loads q3 maps. I made one at least with surface lighting. I'll have to load it up when I get a chance - see what it does in both engines. Darkplaces does reference this: rtlight->static_surfacelist, r_shadow_buffer_surfacelist, rtlight->static_numsurfaces * sizeof(*rtlight->static_surfacelist) I have no idea what it does with all that... You might be able to emulate a surface emitter with a targeted light. If you dont use target, the lights will wash out the surface since they'll be very close to it. (the map editor will set the vector source.) { origin "{vector1}" classname "light" target "lt1" light "200" } { origin "{vector2}" classname "info_null" targetname "lt1" } Put in a bunch of those over the surface with the null targets towards the area you want to light. The closer the null gets to another surface, the tighter and more intense the spot will become. Play with the intensity until it looks good. On 2017-02-19 22:51, Jeff wrote: > a guess: _surface is used by light tool to generate the static > lightmap, but no light source information is retained in the bsp file. > > On Sun, Feb 19, 2017 at 2:52 PM, Sergeant PieFace > <ser...@gm...> wrote: > >> Hi, I am just getting into mapping, and would like to use surface >> lighting. I am able to do this fine for the most post with the >> _surface value for the light. >> >> However, when I use a client with RT world lighting (such as >> Darkplaces), Quake appears to ignore the surface lighting all >> together, and just draw light from the source light (which to my >> knowledge should not be ale to cast light if and _surface value is >> added). >> >> I may be missing something simple or it may not be possible to use >> RT world light and surface lighting together, but either way, I have >> reached the end of the path that my knowledge can take me. >> >> Please see the screen shots that compare my surface lighting without >> and then with RT world light (Darkplaces) enabled. |
From: Forest H. <bta...@gm...> - 2017-02-21 02:38:25
|
That's correct, rtlighting uses only the .rtlights file or imports light entities from the .bsp (in the case of q3bsp these only exist in the bsp if the _keeplights flag is set to 1 in worldspawn). You can freely create different lighting in the rtlights editor (r_editlights_help can provide some info). On Sun, Feb 19, 2017 at 9:09 PM Jeff <je...@qb...> wrote: > a guess: _surface is used by light tool to generate the static lightmap, > but no light source information is retained in the bsp file. > > On Sun, Feb 19, 2017 at 2:52 PM, Sergeant PieFace < > ser...@gm...> wrote: > > Hi, I am just getting into mapping, and would like to use surface > lighting. I am able to do this fine for the most post with the _surface > value for the light. > > However, when I use a client with RT world lighting (such as Darkplaces), > Quake appears to ignore the surface lighting all together, and just draw > light from the source light (which to my knowledge should not be ale to > cast light if and _surface value is added). > > I may be missing something simple or it may not be possible to use RT > world light and surface lighting together, but either way, I have reached > the end of the path that my knowledge can take me. > > Please see the screen shots that compare my surface lighting without and > then with RT world light (Darkplaces) enabled.[image: Inline image 2][image: > Inline image 1] > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > - The QC users mailing list - > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quake-c-users > Project Homepage: [ https://sourceforge.net/projects/quake-c/ ] > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > - The QC users mailing list - > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quake-c-users > Project Homepage: [ https://sourceforge.net/projects/quake-c/ ] |
From: Jeff <je...@qb...> - 2017-02-20 05:09:54
|
a guess: _surface is used by light tool to generate the static lightmap, but no light source information is retained in the bsp file. On Sun, Feb 19, 2017 at 2:52 PM, Sergeant PieFace <ser...@gm... > wrote: > Hi, I am just getting into mapping, and would like to use surface > lighting. I am able to do this fine for the most post with the _surface > value for the light. > > However, when I use a client with RT world lighting (such as Darkplaces), > Quake appears to ignore the surface lighting all together, and just draw > light from the source light (which to my knowledge should not be ale to > cast light if and _surface value is added). > > I may be missing something simple or it may not be possible to use RT > world light and surface lighting together, but either way, I have reached > the end of the path that my knowledge can take me. > > Please see the screen shots that compare my surface lighting without and > then with RT world light (Darkplaces) enabled.[image: Inline image 2][image: > Inline image 1] > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > - The QC users mailing list - > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quake-c-users > Project Homepage: [ https://sourceforge.net/projects/quake-c/ ] > |
From: Sergeant P. <ser...@gm...> - 2017-02-19 19:52:45
|
Hi, I am just getting into mapping, and would like to use surface lighting. I am able to do this fine for the most post with the _surface value for the light. However, when I use a client with RT world lighting (such as Darkplaces), Quake appears to ignore the surface lighting all together, and just draw light from the source light (which to my knowledge should not be ale to cast light if and _surface value is added). I may be missing something simple or it may not be possible to use RT world light and surface lighting together, but either way, I have reached the end of the path that my knowledge can take me. Please see the screen shots that compare my surface lighting without and then with RT world light (Darkplaces) enabled.[image: Inline image 2][image: Inline image 1] |
From: <qu...@ca...> - 2016-11-21 18:51:49
|
So, I had a look at white spikes. bf and cprint from the console dont - they must be client side only. I'd bet prints from csqc dont show either. You'll see one any time you collect an item: "You got the nails" I also saw a couple when I went through teleports, but not every teleport did it. Most didnt. Vanilla has very few prints of any sort. None seem like they could be a stray "\n" that sneaks out. I did see some white when killing a grunt. That must have been SVC_KILLEDMONSTER. So, maybe its one of the few MSG_ALL. I see none that operate without some player action though. If it isnt an item touch, or other message like "you need X key" perhaps a stray print snuck in modified code. If you are just sitting there doing nothing, it would have to be in the processing loop somewhere. Or in an active think. If you really want to try packet sniffing, a linux real box or virtual machine might be a good bet: # apt-cache search packet|g sniffer ettercap-common - Multipurpose sniffer/interceptor/logger for switched LAN hunt - Advanced packet sniffer and connection intrusion nast - packet sniffer and lan analyzer netsniff-ng - Linux network packet sniffer toolkit python-scapy - Packet generator/sniffer and network scanner/discovery sniffit - packet sniffer and monitoring tool I dont know whats on windows now, but when I did it in the 90's, I had to write my own. On 2016-11-18 14:25, Cobalt wrote: > I have a white dot appearing at a regular interval on the incoming > which is > more than likely a stray centerprint, but in the Quake C I am having a > hard > time finding whats doing it. I tried cl_shownet 2 in console but no > centerprint services seem to be listed in the breakdown. > > Any ideas on how to isolate the issue such as a way to inspect the udp > packets? |
From: Cobalt <co...@te...> - 2016-11-18 20:50:15
|
As per Lord Havoc, setting shownetgraph to 1 in console brings up the Darkplaces built in netgraph showing incoming and outgoing netpacket details for the current connection to the server. ============================================= Darkplaces Netgraph Color breakdown as per Lord Havoc : ============================================= Red vertical line - lost packet Yellow dot - choked packet (rate limiting, no packet created because of recent packets exceeding tolerances) Green dot - acknowledgement for receiving reliable message. White - reliable message (centerprint, chat, etc). Orange - unreliable message (entities, effects, etc). ============================================== I have a white dot appearing at a regular interval on the incoming which is more than likely a stray centerprint, but in the Quake C I am having a hard time finding whats doing it. I tried cl_shownet 2 in console but no centerprint services seem to be listed in the breakdown. Any ideas on how to isolate the issue such as a way to inspect the udp packets? |
From: Cobalt <co...@te...> - 2016-10-18 18:48:12
|
Already did this in DP using the grenades touch function, as trace_plane_normal is calculated in any kind of touch function. Sorta made it easier that way, but today decided to try it in POQ (plain ol Quake) using a Proquake based engine called Manquake. Finally got it to work as follows: // Place Code in GrenadeTouch (); if (other.movetype == MOVETYPE_PUSH && self.watertype == -1 && self.velocity_z < 1) { makevectors (self.velocity); trace_ent = nextent(self.owner); // Just to set trace_ent to something other than world because we may hit world traceline (self.origin, self.origin - '0 0 12', 0, self); if (trace_fraction != 1) { self.finalangle = vectoangles(trace_plane_normal); if (trace_ent.movetype == other.movetype) self.angles_x = self.finalangle_x - 90; } So no more grenades sticking at weird angles once they stop moving. Works on doors and plats too. This code should work in any engine, but if you throw it in DP you can probably discard the traceline here that is done to fill trace_plane_normal as the engine is populating that field correctly from the tests I have done so far. |
From: Cobalt <co...@te...> - 2016-10-12 17:42:55
|
True, however we still would need to calc a safe area with respect to who is spawning the Sham. Darkhelmet in our "Quakenerd" group on Discoord sugguested we perhaps use the code thats currently bombing, only break it up over 4 frames so it wont trip the runaway loop, and also save maybe the last 2-3 good known locations, and loop through them again just before we commit to a respawn. The other idea is to let the player aim to a spot, then do the calcs and print a go / nogo message. Then there would be a 'skill' of sorts to picking a good spot to activate the rune before using it. ----- Original Message ----- From: <qu...@ca...> To: "Cobalt" <co...@te...>; "QC" <qua...@li...> Sent: Wednesday, October 12, 2016 12:12 AM Subject: Re: [Quake-C] Safe spawn calc for Shambler in Runequake > On 2016-10-04 13:46, Cobalt wrote: >> Basicly the original code merely spawns a Shambler monster at the players >> origin, mo matter where they are. If theres not enough space, the >> Shamblers >> stuck in the wall. There is a Walkmove (0,0) check done someplace to try >> and >> help fix the issue but its not always being called at the right times. >> > > You could cheat the shamblers size: > > in void() monster_shambler: > > //setsize (self, VEC_HULL2_MIN, VEC_HULL2_MAX); > setsize (self, VEC_HULL_MIN, VEC_HULL_MAX); > > The consequence of this is that shamblers will push into walls with > various body parts. > |
From: <qu...@ca...> - 2016-10-12 04:36:29
|
On 2016-10-04 13:46, Cobalt wrote: > Basicly the original code merely spawns a Shambler monster at the > players > origin, mo matter where they are. If theres not enough space, the > Shamblers > stuck in the wall. There is a Walkmove (0,0) check done someplace to > try and > help fix the issue but its not always being called at the right times. > You could cheat the shamblers size: in void() monster_shambler: //setsize (self, VEC_HULL2_MIN, VEC_HULL2_MAX); setsize (self, VEC_HULL_MIN, VEC_HULL_MAX); The consequence of this is that shamblers will push into walls with various body parts. |
From: <qu...@ca...> - 2016-10-12 04:06:27
|
Wow. Just from fixing the timeset compile issue, I find a bunch of compiler stuff that fte does different! On 2016-10-11 16:06, Cobalt wrote: > One of my side projects is getitng the Runequake src to compile with > FTE, > and its been a long hard road as it was originally using qxxc to do the > fancy compiling stuff thats all over this mod. Fte does have a -Fqccx > mode Really? I thought I was running the latest version: ] fteqcc -Fqccx warning: Unrecognised flag parameter (-Fqccx) > string timeset = "5\{0}":"10":"15":"20":"25":"30"; > string timeset_gold = "\5\{0}":"\1\0":"\1\5":"\2\0":"\2\5":"\3\0"; > > defs.qc:1636: warning: Missing semicolon at end of definition > defs.qc:1636: error: ":" is not a type > defs.qc:1637: warning: Missing semicolon at end of definition > defs.qc:1637: error: ":" is not a type > But Im not sure that is a legit fix? This depends entirely on how the compiler was setup to handle array / string. That is what it looks like anyway, as I used it before. I was using frikqcc and that is the string array format. I dumped that crap when I went to fte as it wasnt supported the same way. I make no promises...but try defs.qc: string timeset[5]; world.qc: // in worldspawn timeset[0] = "05"; timeset[1] = "10"; timeset[2] = "15"; timeset[3] = "20"; timeset[4] = "25"; timeset[5] = "30"; This compiles and may even work as intended. YMWV (note the W = will) However... They use %{n} as an array reference - I believe fte does not. > Runequake uses a makefile / .mk4 preprocessor system, seems like an old > Unix > language, but cant make heads or tails of it except it seems to let you > compile the src for > either Proquake (poq IN_POQ) or Quake World (qw / IN_QW). Would be > great if > we could figure out a DP mode , IE: IN_DP, and I guess thats my job . . > .. Yuk :)~ Once you get married to a compiler, unless you built the code with the express purpose of using other compilers, qc coder life can be most challenging. As for head.m4 - these are some variety of define macros... This is a lot like a function, but the compiler spits out code to compile. m4_define([-IN_POQ-], [-m4_ifdef([-POQ-], $@)-]) Some places in code I saw: create_te_explosion (self.origin, IN_POQ(1, 0)); So, if POQ is set: create_te_explosion (self.origin, 1); and if POQ is not set: create_te_explosion (self.origin, 0); If I understand this correctly, this was done to merge the qw and poq source trees, then define a value for the one you want to compile. If you really intend to rip out all the IN_* stuff, you will have to leave the correct code behind. You will still face all the other issues. Maybe pick either the qw or poq source and avoid the IN_ marcros? Good luck! Stop by and see my new game design: https://www.patreon.com/six_gaming |
From: Cobalt <co...@te...> - 2016-10-11 21:13:20
|
One of my side projects is getitng the Runequake src to compile with FTE, and its been a long hard road as it was originally using qxxc to do the fancy compiling stuff thats all over this mod. Fte does have a -Fqccx mode that I am trying as per Spike, but its already started flagging stuff in defs qc as follows: string timeset = "5\{0}":"10":"15":"20":"25":"30"; string timeset_gold = "\5\{0}":"\1\0":"\1\5":"\2\0":"\2\5":"\3\0"; defs.qc:1636: warning: Missing semicolon at end of definition defs.qc:1636: error: ":" is not a type defs.qc:1637: warning: Missing semicolon at end of definition defs.qc:1637: error: ":" is not a type ************ ERROR ************ Errors have occured Last year when I got around this I changed it to: string timeset = "5\{0}:10:15:20:25:30"; string timeset_gold = "\5\{0}:\1\0:\1\5:\2\0:\2\5:\3\0"; But Im not sure that is a legit fix? Runequake uses a makefile / .mk4 preprocessor system, seems like an old Unix language, but cant make heads or tails of it except it seems to let you compile the src for either Proquake (poq IN_POQ) or Quake World (qw / IN_QW). Would be great if we could figure out a DP mode , IE: IN_DP, and I guess thats my job . . .. qccx1.0 can handle those, but only if you run from the already supplied poq or qw directories that come when you get its src. == Cobalt |
From: Cobalt <co...@te...> - 2016-10-04 18:46:56
|
Been messing with this issue for a long while, have made some progress but because there is no tracebox built-in on the engine we are using (Manquake) which is a Proquake derivitave, its been harder than expected. Basicly the original code merely spawns a Shambler monster at the players origin, mo matter where they are. If theres not enough space, the Shamblers stuck in the wall. There is a Walkmove (0,0) check done someplace to try and help fix the issue but its not always being called at the right times. Decided to redo the entire system with some code another Quaker made which is basicly doing what tracebox does but slightly different. Im doing this check alot, and since its using tracelines, and the code Im calling it from is basicly a while loop with more tracelines, I believe I am tripping the runaway loop counter so the eng crashes. If someone could take a look and maybe make some sugguestions, or even a completely new way of doing it, would appreciate it. Basicly the main function being called is: Rune_ShamblerReloc () on line 449 here in this file: https://github.com/odnarb/runequake/blob/master/src/runes40.qc The compiler being used is I believe qccx which is very old, so we have to use 'old fashioned' style Quake C for the time being. |
From: <qu...@ca...> - 2016-09-30 17:26:48
|
Quick followup. I saw a note stating the autoaim was for vertical aiming. I'd have to spend more time with the engine code than I want to verify that. Like a few things in the engine and quake-c iD likely had some plans to use the 'x' for a predictor of some kind. Like if a missile was moving at 1000 units, and the ent was closer than 500 or 600 units it could be discarded as a selection. I also should point out that it will pick the smallest deviation from v_forward if there are multiple valid entities within the cone provided by sv_aim and the dotproduct test. Support free code by Six gaming on Patreon: https://www.patreon.com/six_gaming On 2016-09-30 01:04, qu...@ca... wrote: > Best check that engine code. For this: > > On 2016-09-29 12:12, je...@qb... wrote: >> The Quake source code comment says it's missile speed, and the >> argument is read, but it's not actually used in the function. See >> PF_Aim in pr_cmds.c This function is loaded with various tasks, so >> overhead could be an issue if calling it a lot. >> >>> -------- Original Message -------- >>> Subject: [Quake-C] Using v_forward vs. Aim () function ? >>> From: "Cobalt" <co...@te...> >>> Date: Thu, September 29, 2016 12:19 pm >>> To: "QC" <qua...@li...> >>> >>> Recently discovered if you call makevectors and get a v_forward, >>> you basicly >>> wind up with the same result as if you did: >>> >>> aim (self, x); >>> >>> What exactly is the ' x ' float for in that function? >>> >>> > > > ------------------------------------------------------------------------------ > _______________________________________________ > - The QC users mailing list - > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quake-c-users > Project Homepage: [ https://sourceforge.net/projects/quake-c/ ] |
From: <qu...@ca...> - 2016-09-30 06:26:42
|
Best check that engine code. For this: sv_aim is "2" ["2"] maximum cosine angle for quake's vertical autoaim, a value above 1 completely disables the autoaim, quake used 0.93 That is used as a dotproduct result comparison. #define DotProduct(x,y) (x[0]*y[0]+x[1]*y[1]+x[2]*y[2]) VectorNormalize (dir); dist = DotProduct (dir, PRVM_serverglobalvector(v_forward)); if (dist < bestdist) continue; // to far to turn Quake one engine just checked every entity. Darkplaces uses traceline. Ents are checked for takedamage, teamsettings, etc. If valid: dir is tested as vector for every valid entity near your v_forward. If the dotproduct of dir and v_forward is > sv_aim cvar value, the vector pointing at the shootable entity is returned. Otherwise v_forward is returned. If sv_aim >= 1 v_forward is always returned. The autoaim feature was a holdover from doom which had vertical autoaim. I just do this in qc: // compile this with fteqcc #define aim(ign,igntwo) v_forward Happy coding! Support free code by Six gaming on Patreon: https://www.patreon.com/six_gaming On 2016-09-29 12:12, je...@qb... wrote: > The Quake source code comment says it's missile speed, and the > argument is read, but it's not actually used in the function. See > PF_Aim in pr_cmds.c This function is loaded with various tasks, so > overhead could be an issue if calling it a lot. > >> -------- Original Message -------- >> Subject: [Quake-C] Using v_forward vs. Aim () function ? >> From: "Cobalt" <co...@te...> >> Date: Thu, September 29, 2016 12:19 pm >> To: "QC" <qua...@li...> >> >> Recently discovered if you call makevectors and get a v_forward, >> you basicly >> wind up with the same result as if you did: >> >> aim (self, x); >> >> What exactly is the ' x ' float for in that function? >> >> |
From: <je...@qb...> - 2016-09-29 17:29:32
|
<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div><span style="font-size: 10pt;">The Quake source code comment says it's missile speed, and the argument is read, but it's not actually used in the function. See PF_Aim in pr_cmds.c This function is loaded with various tasks, so overhead could be an issue if calling it a lot.</span></div><div><br></div> <blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;"> <div id="wmQuoteWrapper"> -------- Original Message --------<br> Subject: [Quake-C] Using v_forward vs. Aim () function ?<br> From: "Cobalt" <<a href="mailto:co...@te...">co...@te...</a>><br> Date: Thu, September 29, 2016 12:19 pm<br> To: "QC" <<a href="mailto:qua...@li...">qua...@li...</a>><br> <br> Recently discovered if you call makevectors and get a v_forward, you basicly <br> wind up with the same result as if you did:<br> <br> aim (self, x);<br> <br> What exactly is the ' x ' float for in that function?<br> <br> <br> <br> ------------------------------------------------------------------------------<br> _______________________________________________<br> - The QC users mailing list -<br> <a href="mailto:Qua...@li...">Qua...@li...</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/quake-c-users">https://lists.sourceforge.net/lists/listinfo/quake-c-users</a><br> Project Homepage: [ <a href="https://sourceforge.net/projects/quake-c">https://sourceforge.net/projects/quake-c</a>/ ]<br> </div> </blockquote></span></body></html> |
From: Cobalt <co...@te...> - 2016-09-29 16:20:01
|
Recently discovered if you call makevectors and get a v_forward, you basicly wind up with the same result as if you did: aim (self, x); What exactly is the ' x ' float for in that function? |
From: Cobalt <co...@te...> - 2016-08-31 22:51:16
|
Ok fixed, exactly how not sure. Turns out there was a config file in /documents/mygames/darkplaces/modfolder that had alot of scr_ type commands set in it as well as some others that referenced Quake2. I commented them out and the problem went away. When I went back to look at the names of the cvars, the cvar had been overwritten and the comments were gone. I think what happened is I sometimes use another mod then manually browse to this one using the browse mode option in the DP menu. So I suppose the config file for the other mod may have been placed over the old one. == Cobalt |
From: Cobalt <co...@te...> - 2016-08-31 17:48:31
|
So I was playing with my new project "Creepiercam" , current QC src located here [ https://github.com/teknoskillz/Creepcam2/ ] There is 1 current issue where a high ping player apparently caused the whole server to crash, and its been sugguested that the while loops that use SVC_UPDATENAME to blank the players name from the scoreboard is too spammy and it pushed the buffer over the edge. My fix was to not blank the name at all if the client was currently a respawn type cam. At first , seemed to work, then I started correcting a parms problem and all of a sudden, the scoreboard dont pop up when you press tab, and no players are in it at all. Tried commenting out the name functions , and still cant figure out whats going on. Also if anyone wants to check out the mod on a real live server, less the most recent changes, its up here: [ http://dpmaster.deathmask.net/?game=quake&server=65.111.162.249:26111 ] As always any help on the issue greatly appreciated. == Cobalt |
From: Cobalt <co...@te...> - 2016-08-31 17:32:50
|
> 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. |
From: <qu...@ca...> - 2016-08-23 04:41:59
|
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. |
From: Cobalt <co...@te...> - 2016-08-22 17:57:36
|
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 |
From: Cobalt <co...@te...> - 2016-05-28 18:56:49
|
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 |
From: Cobalt <co...@te...> - 2016-05-16 18:46:39
|
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 } } } }; |
From: Cobalt <co...@te...> - 2016-04-18 20:03:03
|
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 |
From: Cobalt <co...@te...> - 2016-04-13 19:26:13
|
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 |