note: suppressed 262 more warnings about unreferenced variables, as you clearly don't care about the first 10.

too funny. i need to go clean up this code... 

@preach
1) yes, it avoids going through each func+trigger spawn function to ensure that there's a precache_model(self.model) line. I guess it depends how lazy you are.
it'd be nice if engines supported precaches any time, but this implies mid-game downloads and possible reliable-vs-datagram races and things (which would crash vanilla before any illegible server messages), both of which are nasty enough that the qcc(+maybe engine) should still warn if something isn't explicitly precached.

2) by all means wrap precache_model so that it doesn't crash outside spawn functions. wrapping setmodel will just hide things so that compilers cannot reliably detect it.
Ideally the server would only error if the precache is actually new... but considering how many people use crippleware engines, this ideal is admittedly laughable.

3) it would be better to make a 'presetmodel' function that does both, or something. at least then the compiler won't see either the precache or the set.
you'd still need a precache_model if you do an explicit setmodel elsewhere.

4) qcc trying to detect missing precaches is a nice idea, but also still a hack that can only see immediates, with hardcoded function names.
I fully admit that I'm biased towards one of those hacks. :P

@necros
you can use the verbose(aka: -v) option if you want a list of all of them instead of just the first ten.
or you can use #pragma noref 1 and #pragma noref 0 around them if you want the qcc to (mostly) ignore any unimportant defs, like unused builtins etc that you might find in dpextensions.qc (note that this is the mechanism used by fteextensions.qc to silence warnings about all that unused stuff).
Of course, you should only really use this if its meant to be maintained by someone else. 

thanks spike! yeah, i was doing them 10 at a time... this is much faster.

also, thanks for the noref pragma... where is the documentation for all these little tricks? the wiki i linked to earlier doesn't seem to have any other pages? 

Is there some good article describing how Quake's Lightmapping works? I tried to understand it from BSP format docs, but it looks like some black magic. 

lightmaps are basically just textures.

there are 64 'styles'

each face in a map can have at most 4 styles on it.

typically there's only one style, style 0 which is always on.

then there are 11 other styles that flicker and pulse and such. these are the ones you can select in the editor.

each time you make a target/targetname switchable light, the light utility reserves a new style number.
qc then changes the style via lightstyle function. these numbers start at 12.

it's important to note that the target/targetname has nothing to do with anything other than letter the QC pick up the style value that light.exe has added to the entity after compiling. 

not light styles.

e.g. the lightmap visualization of dm2 for instance:
http://scampie.net/etc/lit2compare/dm2_1_lit_lm.jpg

This article maybe? http://latchup.blogspot.com/2015/06/quake-lightmaps.html?m=1 

I believe, switchable light styles start at 32 

Is this hard to do from the engine? Could an extension be made so it can be done in QC ? 

A static entity, with a precached sound runs a 11000hz wav in the right order.
Another setup with the same statements remarks the sound wav isn't looped.

I can't remember I looped the first sound. I start Cool, load the sample, save it as looped. Same outcome, not looped.
Audacity the same, saved looped, same error.

What is the cause of this well or not looped sound? 

I seem to remember once if the sound was in the /ambience folder, it always seemed to loop no matter the type. Try that and repost here. 

 

I had this earlier, but then Cool-150 adjusted the loop function.
Now I even can save the wav. 

Revised the code and got them sticking to ceilings, with occasional bloodshowers, however if the ceiling is sloped, we need to probably check its angle and apply gravity in a "reverse" direction in some cases possibly. How to get the engine to do that, id say is a challenge.

But I went with MOVETYPE_NOCLIP to get it to slide straight down on the wall, and checkbottom works well to break it out of noclip so far. Im using Darkplaces with setmodelrealbox, so the model actually has what I refer to as a "mass" m basicly its not point size anymore...so you can set larger gibs so slide faster for realism. I updated the code here if anyone wants to take a peek or collaborate / add a tweak:

http://collabedit.com/phw6e 

Trying to get a brutal quake going? 

yea, Brutal Doom was maybe where I first saw this back when I tried it. Curious how it looks in Quake. So far that code seems to work kinda well, but sloping surfaces need to be addressed. 

Updated the code again. Hopefully now it will know when its not in contact with the surface if its moved to a corner while traveling down, which does not rest on a floor. It ought to detach now and become a regular gib. Still need to test it though...yea all this for a Giblet, right ? :) 

i'm pretty out of it right now...... but can someone confirm this..?

basically, whenever there's a collision, in your .touch, you will have a normal of whatever the collision was??

i think with maths, you can generate a downward vector with that normal and gravity and set the movement that way with a MOVETYPE_FLY instead of noclip. 

I experimented with that a couple of years ago, thought it made sense and it does seem to return the right normal....at least in Darkplaces engine , not sure about others.

When you think of it, the collision code has to be ran to confirm a collision, and since the eng is likely using some kind of tracelines to determine collisions, makes sense they applied the results to trace_plane_normal somehow.

I ran it by Spike a couple years ago, he said he believes traceline is the best way to get the normal , and in some cases I guess so..but so far in my experiments for what I am crudely doing seems to work ok. 

Well, my new modified EntitiesTouching() code did not work too well to detect if the gib was no longer in contact with the surface it was sliding down, so I created a new function which seems to do the trick, and updated the code here [
http://collabedit.com/phw6e ]

For now I commented out the .pusher reference as maybe later we can account for moving BSP objects and handle those cases.

Right now seems to mostly work ok except perhaps the sticking ought not rely solely on its velocity , but also its vectoangles of (gib.velocity) with respect to the surface its hitting? So I suppose we could formulate a tolerance where if the angle is perhaps within +/- 15% of the angle the surface normal is at, then we can have it stick, otherwise make it bounce normally.

Anyone have an idea how to start on this ? Feel free to edit the code, the site lets you collaborate. 

The Serious Engine (Serious Sam 1) is on Github https://github.com/Croteam-official/Serious-Engine 

so... there's a +/-use... how can we (if possible) use this? 

There's a bit of hacky code in a func_togglewall and I wanted to understand why it's safe. The togglewall is turned non-solid by directly adding '8000 8000 8000' to its origin by, always putting it outside the maximum coordinate range (at least until some newer engines came along).

This violates one of the normal golden rules of QC, which is to always use the setorigin function to move an entity. Clearly in this case we get away with the trick, and I wanted to check if I understand why:

The purpose of setorigin is to make sure that when an entity is moved, the engine correctly links the entity. My layman's understanding is that linking makes sure that the entity is correctly renderer and collided against. The point for a togglewall is that we neither care if it renders correctly (it's invisible) or that it collides correctly (it's non-solid).

Getting right into the details of the collision stuff, normally entities are linked into particular regions of the map. Regions are an efficiency feature, so the engine can skip testing for collisions between entities far apart in the map. When we skip the call to setorigin the togglewall remains linked to the region it started in, which may be wrong for its new location. But this is OK: things in the region it started in keep checking if they collide with it, but never do because it's so far away. Meanwhile, it's not in the region for its new location, but in theory nothing should be in that region anyway, and we don't need those collisions either.

If the above is correct, then I assume when we reactivate the togglewall to move it back, the original region link is still in place. So we go back to colliding with things in the vicinity, without needing setorigin here either.

Am I somewhere near the mark? I know I've glossed over the case where entities straddle regions, and I'm sure some of the terminology is different. I really just want to be sure why we get away with it here, to check if the same trick is OK in similar circumstances. 

Like, a mod for weapons,another for monsters, in a single game? FTE or Darkplaces wise...
Is that possible? 

 

yes. it is possible with FTE. whether its practical is a different matter.

the addon* cvars allow you to name addon dat files to load within the ssqc vm. these addons can interact with other dat files with the externset+externvalue builtins, or entirely via fields+new spawn functions.
the catch is that the engine's builtins are only able to understand one set of globals, which means you tend to need to use externvalue(0, "&whatever") to get a pointer to the global from the main progs, along with some preprocessor magic to hide the uglyness of this.
function types are just references in qc, this means that addons can query+replace function 'variables' in other dats in order to hook them to do whatever the addon needs them to do.

(make sure you don't compile your addon.dat files with -O3, as this strips needed string information)


tldr: so yeah, you can do it in fte. whether its actually practical to do so is a different matter. generally its only usable if you can make your addition entirely self-contained.