News | Forum | People | FAQ | Links | Search | Register | Log in
Coding Help
This is a counterpart to the "Mapping Help" thread. If you need help with QuakeC coding, or questions about how to do some engine modification, this is the place for you! We've got a few coders here on the forum and hopefully someone knows the answer.
First | Previous | Next | Last
 
sv_gameplayfix_blowupfallenzombies defaults to 0 in current builds (along with other such gamecode-changing settings), but the old value might linger via configs. Probably the easiest thing to do is to detect dp at load time somehow (to avoid warning messages in other engines) and just cvar_set it to 0.
(use solid_corpse instead of solid_not if you want to be able to shoot/find zombies, I guess)

but yeah, its probably better to simply use some other field like .enemy or .owner instead of .chain 
Blogging Back 
So I took the idea I posted above, along with some other thoughts which have been coagulating for the past few months, and made a blog post. It's all about the engine config system, written mostly for someone who's writing a mod and wants to know what to do - and not do!

http://tomeofpreach.wordpress.com/2013/09/05/quake-rc-and-being-a-good-citizen/

There's a nice bit of copy-paste code at the bottom for controlling darkplaces cvars, although it covers both the opting-out and opting-in cases so users may need to tweak it slightly to suit their needs. 
Locals Conflicting With Func Args? 
Is it possible for a local to conflict with arguments to a function? I noticed that with a (clean) progs106, the SpawnMeatSpray function (maybe more) takes two vectors, org and vel; but in the function itself has a local named org. SpawnMeatSpray uses org only when calling setorigin and it seems to be using the argument org, not the local (assuming, can't check atm). 
Qc + Locals 
arguments ARE locals.
dupe defs are ignored.
initialising a dupe is an error (vanilla qc initialisers make it a constant).

qc doesn't support scoped locals, other than to the function. unlike C+Java+etc, blocks don't have private locals, and locals are still valid beyond the end of the block that they were defined in. 
Thanks, Spike 
 
Buzzsaws 
Does anyone have usable buzzsaw code? For some reason the buzzsaw.qc file I have doesn't work and the saws don't match up with path_corner's. I've tried rewriting the code to use SUBCalcMove but it starts moving off at an angle instead of following a path, but the "original" I have cause it to jump around in my map. I've tried custents buzzsaw.qc but it does the same thing. It'll follow the paths in r2m7 but be offset vertically from the actual path locations and do a kind of jiggle up jump.

What am I missing? 
... 
Okay, I found the original doe_qc.zip source code online: http://www.gamers.org/pub/idgames2/more_idstuff/doe_qc.zip

Copied buzzsaw.qc into my code and ran it. Buzz saws still hovering about 16 units above the tracks they should be in the Last Bastion (r2m7). Found doe progs.dat (dated 2008 from when I copied it off the CD, verified the same size as in the pak0 under rogue directory) and it does the SAME THING!!

Is this Darkplaces only related? 
Okay Yep. 
it's a darkplaces bug. Buzzsaws work fine in WINQUAKE.EXE. Is there a gameplay console var fix for this?? 
Okay... 
what's happening with the buzzsaws is that they behave like monsters. They change their movetarget when their bounding box touches a path_corner, not when their origin reaches the path_corner's origin. Now then...to figure out how to ignore path_corner.touch functions.... 
Buzzsaws Solved! 
No code modifications required.

Just positioned my buzzsaws outside of the tracks such that they have time to move and get inline with the path_corners. (had to bsp_to_map the r2m7 map and see what they did to make it work, the buzzsaws were about 64 units away in both x and y directions from their starting path_corner.) There are still a few glitches if the path_corner's are positioned a distance away from eachother that Quake doesn't like, or if the speed of the buzzsaw isn't just right. (10 usually works and is default) 
Sounds Good! 
 
Keeping Score 
Any mod out there that can count damage done in a level and give a total at intermission?
I think it would be fun. Make a replay of the original game interesting. Timing a quad damage would be very important I suspect. 
Stealth Damage 
I added damage done to my ITS mod, there is a stealth stats screen you can check at anytime during play of a map. 
Sock 
That's the idea. A mod that can take e1m1 and give a score at the end without modifying anything else. Vanilla Quake with a score card at the end. I'm sure it could get complex give points for health, armor and ammo and suck points off for total time. 
 
I've added damage given, and damage taken to my multiplayer mods. It's not difficult at all.

I then get a survival skill score by this
score = damage_given / (damage_taken+damage_given)

:D 
 
I kinda hope that some day more engines will support sqlite and we could use that to track and record all kinds of things locally. FTEQW supports it. 
 
sql is only really useful for single player, and even then you can often get away with frik_file instead.

when it comes to deathmatch you probably want some central server recording matches in aggregate, which would likely be programmed in something more php-ey instead of qc. naturally this avoids sql in the game server, but does require some sort of communication to said server... 
Extract Vertexes From .MAP/.BSP 
Is there an easy way to heist the vertex/mesh data from a Quake map? I'm trying to whip up some C# for using Q1 brushwork inside of Unity3D, and I'm hitting a wall.

Since I don't care about the lightmaps or vis data, I figured I'd try to divine the vertex data from the .map, but converting from the brush based geometry (calculating planar convergence) is beyond my skill. It'll probably be easier to let a compiler do the lifting on that and just read the data I want out of the resulting .BSP Are there any libraries available for working with Q1 .BSP? 
 
i think the bsp is a better choice as it is more mesh-like, and is already cleaned of things like tjunctions, overlapping polygons, etc. 
 
 
when it comes to deathmatch you probably want some central server recording matches in aggregate, which would likely be programmed in something more php-ey instead of qc. naturally this avoids sql in the game server, but does require some sort of communication to said server...

The most obvious solution is to program the central server to mimic a client connection to the game server! Sure you waste a client slot on your stats bot, but who plays 16 player deathmatch anymore anyway...Of course you'd communicate directly from the QC using SVC messages to ensure your code runs on every engine. Just write, lets say byte-by-byte UTF8 encoded JSON, wrapped up as a sprint statement to the bot.

Preach goes off to write a web server in QC and is never heard from again 
 
my inner nerd has been awakened. this sounds like such a cool idea :D 
 
@preach
I know you jest, but there are bots that connect to QuakeWorld servers to scrape scores already...
That said, QuakeWorld does at least support explicit spectators so you don't need qc code to make them non-solid to avoid interfering with the game with free frags.

@ALLCAPS
walk the surface list. each surface has a list of edge indicies (either positive or negative). each edge has two references to each vertex. if the edge index was positive, take the first vert refered to by the edge, if negative then take the second (negate the edge index so its positive, but no bias as 0 is always invalid, and -0 can thus never happen). Walk the edges to get the list of verts for each surface.
To determine texture coords, you'll need to do some maths based upon the texinfo[surf->texinfoid] stuff:
vert.s = (dotproduct(texinfo->vecs[0].normal, vert.xyz) + surf->texvec[0].dist) / texturewidth;
vert.t = (dotproduct(texinfo->vecs[1].normal, vert.xyz) + surf->texvec[1].dist) / textureheight;
where dotproduct is of course ((a.x*b.x)+(a.y*b.y)+(a.z*b.z))

the texture index used is refered to via the texinfo object, which is of course refered to by the surface object.
the texture/miptex lump inside the bsp has this form:
int32 numtextures;
int32 offsetintolump[numtextures];
the start of each actual miptex is a 16 byte name, followed by the width and height as int32s, and if you're using unity or whatever then you should probably just use replacement textures and skip parsing beyond those fields, but if you do, there's an additional 4 offsets to the 8bit paletted image data after the height, expressed as offsets from the start of the texture and not the lump, one for each of the 4 mip levels that software rendered quake supported. You can likely just use the first and ignore the others. 
Q3 BSP Header Parsing 
I decided to swap from using Q1 BSP to Q3 BSP, because there is a lot more documentation on Q3 BSP specs. I'm reading in the bytes for the header and everything looks good except for the first entry in the directory.

The length isn't a multiple of 4. At first I thought it was my code, but I checked the .bsp with a hex editor and it really isn't a multiple of four in the .bsp, and I checked multiple maps. Is this normal?

Is it because it's the entities node, and they're stored as strings/char[]? The spec says each directory's size should be a multiple of 4, and it doesn't say anything about the entities directory being exempt from that. 
Noticed 
That if I "round up" the size of the entities lump to four bytes it then matches with the beginning of another lump, so perhaps it on specifies how many single character bytes there are, instead of how many four-byte dwords it takes up? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.