I don't get what you're asking.
An undefined variable would be a compile-time error. 

In code.

When defining a local value in a function, it defaults to 0 until I set it, correct?

I might be missing the gist of the post entirely. 

The QCVM initialises locals on return rather than on entry. This means that locals *typically* default to whatever the qcc assigned for them, with 0/null/world if it was uninitialised.
The exceptions are when recursion is involved, in which case it starts with the value it has in the earlier instance of the function on the stack (even when its not the direct caller).
Or when the qcc bugs out and tries to reduce local use even when its unsafe to do so, in which case the locals will have pseudo-random values depending upon the values in the same slot in the caller.

Note that:
float a=5;
is technically an initialisation and not an assignment. This means that if you stored something else into a in a parent function, the value of a will NOT start as 5.
Note that vanilla qcc also then considered 'a' to be a constant and then merges it with other constants with the same value, which can mess stuff up quite a lot and is just unsafe however you look at it.

FTEQCC will internally use assignments instead of initialisers if the local is a variable and not a const. If you want the broken behaviour back, you can just define the local as 'local const float a=5;' instead.
Assuming var and using assignments instead of initialisers also allows 'float speed = vlen(self.velocity);' as valid and well-defined code, which is the main reason for the behaviour change. :P 

I use FTEQCC and also the broken format, just because that's what I've learned from looking at other code. 

yeah, that last paragraph was to say 'except in fteqcc, initialised locals work as expected', so no worries.
might not be 'standard' (if such a thing even still exists), but its more useful and intuitive. 

I have a suspicion that the answer is going to be no going into this one, but here goes. Does anyone know of an engine-neutral trick to distinguish BSP models from non-BSP models in QC. Apart from the obvious way of trying to make them SOLID_BSP and checking to see if you've crashed...

I can think of a few heuristics that might imply BSP models based on the maxs and mins, but none that would be anywhere close to reliable enough. Mins and maxs have also varied in the past between different custom engines, so it doesn't seem very safe.

You might try incredibly ugly hacks in QC to increment the pointer to the modelpath string one character at the time. By running a few string comparisons at each step you should eventually get a match to one of the file extensions. Apart from the danger of making a mistake in the pointer arithmetic and causing a segmentation fault, this method would fall foul of someone who lied about the extension of their model!

It turns out Quake engines don't actually rely on the extension for determining the model format - instead they read the magic number at the start of the file. This is a piece of good fortune for people who create md3 replacement models for advanced engines, as they can match the names of the original files yet use the replacement format.

I did scour the codebase a little while looking for any places the crucial difference between a .mdl and .bsp format model poke their heads out, but I couldn't see anything. Any thoughts? 

About the only thing I can think of is testing the model for crashes while not running in a live environment, but that's hardly a helpful solution.

I'm wondering now why this might matter, though. About the only plausible guess I have is that you're trying to make Quoth's .mdl box items lit properly. 

Vanilla NQ code will *always* set mdl format's size to '-16 -16 -16' '16 16 16'. A poor choice, but lovely and consistant. Failure to do so still breaks mods.
This size is distinct from all vanilla .bsp models, which have a mins of '0 0 0'.
Sadly, third-party engines fix that (no more dodgy frustum culling), but gain qc bugs as a result.

In DP, you'd need to set sv_gameplayfix_setmodelrealbox to 0 first. Its now the default but wasn't in slightly older versions.

In QW, setmodel *only* does setsize for actual bsp models. mdl models are not actually supported/loaded by QW servers. Sadly it uses the extension to see if it should try to load a bsp... But, if its foo.bsp you can use this to check its actual type.

There's a couple of extensions lying around like DP_QC_GETSURFACE's getsurfacenumpoints(ent,0) that will return 0 for non-bsp formats, until it gets extended to work with other formats too... :s

Other than that, a model format is a model format. QC defines the physical size of the object (to avoid bugs), and the model itself provides just the mesh.
The only time you'd need to be able to tell the difference is when you have something like func_trains which expect bsp objects. I suggest you use spawnflags or something to say 'non-solid' instead. You'd need to modify the qc code to add a non-inline precache anyway. 

The only time you'd need to be able to tell the difference is when you have something like func_trains which expect bsp objects. I suggest you use spawnflags or something to say 'non-solid' instead.

That's exactly the scenario I had in mind. It seems like it would be annoying to users that even though you've obviously specified a non-BSP model, you also have to manually tell it "this is a non-BSP model" again. It would be nice to have the mod take the hassle out, or at least practice look-before-you-leap, but I suppose the crash is instant at least so people would catch and fix places where they forgot more or less instantly.

I have a plan in mind now that's slightly neater than a spawnflag...watch this space. 

some engines support non-bsp objects as SOLID_BSP pushers (even if its just a bbox). A non-solid flag should thus not be implied by the model type alone.
You wouldn't be saying 'this is a non-bsp model', you'd be saying 'this isn't solid', which might apply for evil trains too (mwahaha). The fact that the engine doesn't support solid trains isn't the mod's fault, its the engine's fault. That said, the mod probably should take efforts to ensure the bbox size is also tweakable if its a solid mdl. 

I think the plan will work just fine with that - people will be able make something that works in all engines or opt for taking advantage of a new engine's features - if they don't mind they've excluded classic engines in the process. 

I just want to make sure I'm doing this correctly, before I begin my bug-hunt.

To find the leaf the player is in, you take the root node, and see what side of that node's plane the player is on. If they're on the positive side, do the same using node children[0], if they're on the negative side, do the same using children[1]. During this "walking" you'll come to a point where the child you're told to check is a negative number. Discard the negative sign and add one. This is the leaf the player/camera is in, and using that leaf's PVS will render all leafs visible from that point.

Is this right, or am I making a poor assumption or oversimplification somewhere? 

Discard the negative and subtract one, if you're using that order of operations.
-1 maps to leaf 0, not leaf 2.
Remember to decompress your pvs. 

Got my bsp walking working. I can tell what leaf the camera is in now. Struggled for hours, then on a whim tried inverting the plane normal, and it now works as it should.

Nearly 100% of the stumbles I've run into have been in converting Quake-space to Unity-space, and the trend continues.

Working on decompressing and using PVS now. So close I can taste it. I keep saying I need to work on lightmaps, but this is more interesting. Lightmaps should (should) be pretty trivial, so blazing through that will hopefully be my reward for getting PVS working. 

I'm reading all over trying to get a handle on reading and decompressing PVS data, but I'm having a hell of a time.

I have some embarrassingly elementary questions.

I read out the bytes in the vis data lump, and for the tiny map I'm using to debug this renderer, I get this:
255 10 255 2 207 10 207 10 243 2 243 2 255 10 255 10 0 1 15 255 15 0 1 7 205 11

What is the correct method for decompressing this? I'm not even sure I'm reading it out correctly, because looking at this it looks like there's going to be way too much data. This map only has 13 leafs, so something is wrong. Should I be reading these as shorts/ints instead of raw bytes?

This is an area where examining bspfile.h hasn't really helped, as there's no lump defined for this. 

look at Mod_DecompressVis in the source, that's where quake decompresses it.

Basically non-zero bytes are uncompressed. Every run of zeros is run-length encoded, a zero followed by a second byte which is a count.

And once uncompressed, there is 1 bit for every leaf. 

I've tried looking over other source for this, but I'll admit I don't know C well at all, so I can't really follow what's happening. 

It's time for another episode of Allcaps' Assumptions.

I have a very small map I made for testing. It has 13 leafs. The visibility lump for this map is 26 bytes.

This means that in order to store a bit for every leaf, each leaf's PVS will be two bytes of data. (13 bits needed, add 7 then divide by 8 to find the number of whole bytes needed) Right?

Parsing the lump, should each byte be interpreted as a char, or an integer? I know that it represents bitfields, but no matter how I read this in it doesn't look at all like I expect it to going by various docs I can find. Reading the small map above's vis lump as chars gives me this:

10 2 10 10 2 2 10 10 0 1 15 15 0 1 7 11 0 105 0 0 123 10 34 115 112 97

This looks kind of okay. So I break it into two-byte sets (since each leaf's pvs is 13 bits, needing two bytes) and get:

10 2
10 10
2 2
10 10
0 1
15 15
0 1
7 11
0 105
0 0
123 10
34 115
112 97

Now it looks less okay. How can there be a set that is 0 0? How can there be 0 105? So there's a hundred and five zero bytes in that set? I'm going wrong somewhere pivotal and I'm really lost as to where. 

For the thousandth time, tronyn's is NOT BSP2, it's 2PSB.

Heh.

heh heh heh.

:-D 

Yeah, people ARE still talking about rmq even if this bug is the only legacy. Congratulations. :-) 

 

Heh. =)

=) 

Honestly though, gb, why bully me? 

I've work on a few other things, like some groundwork for lightmap import, and BSP2 support, but I'm still totally lost on deciphering this PVS information.

C# has a bitarray datatype that would make this really easy to implement if I could just get the PVS data read and decompressed.

I feel like real doofus for asking but does anyone have a page with detailed information on reading and handling the PVS information? I've found so many pages that are just "here's how you do it" with a lump of C source that is a web of pointers, bitshifting, and variables with undescriptive names.

This is the last feature needed before the real fun stuff can begin. 

My only question is will it support bsp2 :>

Sorry, don't have a link for what you're looking for.