The old fastqcc stuff with indexing fields and pretending to get dynamic arrays seemed a bit desperate and risky, particularly today with all the different and complex custom engines about.

What I really wanted was some way to do a static vtable in Quake, without needing an entity to store all the functions in. I thought I might be able to make some kind of jump table with a bunch of return statements, and use an integer parameter to select of many of them to skip over.

It doesn't seem to work though, even though the stumbling point appears to be confusing the variable holding the jump distance with a label name to goto. Is there a better way of doing that which I'm missing? Can you index a block of consecutive functions if you define them all in succession? 

you are totally crazy, you know. any sane man would just use entities and be done with it!!! 

i assumed you were trying to fake OO? 

void() foo = {code;};
is really this:
var void() foo;
foo = numfunctions;
functions[numfunctions] = {code;};
numfunctions++;

or in other words, for functions to be consecutive, it is the function bodys that need to be consecutive, not their prototypes.
this makes assumptions about function ordering quite annoying in practise.
QC has no variable-distance jumps. If you want static vtables you're probably best just making an array and indexing in to that. I'm unsure how you would cope with assigning offsets though. And of couse, touch and think functions wouldn't work very well with it.

Which is why fteqcc's class stuff just uses fields for its virtual functions, and in doing so it can cope with thinks, touches, etc with ease (including engine-specific extensions, so long as they've an appropriate .void() or whatever def outside of a class for them to inherit from). nonvirtual calls are still direct calls of course. however fteqcc does only provide single inheritance, and constructors are designed to mirror spawn functions rather than traditional constructors.

class foo : entity
{
string myname;
virtual void() think =
{
dprint("I'm thinking here\n");
};
void() foo =
{
if (!myname) myname = "unnamed";
dprint(myname, "'s spawn function\n");
nextthink = time + 1;
};
};
void() calledfromsomewhereelse = {foo bar = spawn(foo, myname:"TheTest");};

class members use some weird name mangling (unless inherited from the basic entity type), which can make them problematic in maps.

there's only one extension used, and that's that it uses 'spawnfunc_foo' to fill in the stuff and call the constructor. this is used so that you can just call spawnfunc_player() inside ClientConnect without any issues about any player classes (you shouldn't really use this trick unless its known to be a non-class entity, as it doesn't reset any class fields, and aliasing between classes would leave unpredictable values).

dammit, another essay. 

for functions to be consecutive, it is the function bodys that need to be consecutive, not their prototypes.

This sounds helpful rather than harmful, you don't need to worry that someone ahead of you in the compilation list prototypes one of your functions and mucks up the order. I hear what you say about entities being much more sensible for things with actual state, but I think there's a niche here which it could fill. Thanks for the post! 

non-quake question... say you are saving some data into a binary file. let's say preferences. somewhere along the line you may add in some new feature with accompanying preferences.

how do you deal with this when you need to read the old binary data and do a one time upgrade? do you just keep your old loading method and use the first byte to identify which loading method to use? is there a better way? 

you can create an extensible format... preferences are a list of key + value, so in theory you just want to add new key/value pairs over time. You either want a directory at the beginning of the file that first has "number of entries" and then an array of offsets to each entry, and then each entry can have a standard format, or you can have fixed size entries and just keep reading until you hit EOF, then you don't need a directory.

Either way, when reading the file, if it doesn't have all of the entries you expect you can just use the default value for the missing preferences.

Question: why do you want it to be binary? 

What can I do to prevent a new model,
that is jumping up and down to cause the

client.qc line : 849

void() PlayerJump =

sound (self, CHAN_BODY, "player/plyrjmp8.wav", 1, ATTN_NORM);

sound? 

Question: why do you want it to be binary?

I want it to be portable (eg: no registry keys) but I don't want the user messing with things. 

Actually I ment,
how do I stop the sounds h2ojump.wav / dland2.wav
for a new model playing in game? 

Google for flatbuffers. 

 

cvars...
sv_sound_watersplash ""
sv_sound_land ""
these two cvars exist in dp+fte, probably not other engines.

self.contentstransition = someemptybutnotnullfunc; can be used as an alternative for the watersplash sound, but its more awkward and probably no better supported.


@necros: just use base64 on a text file or something. key+value pairs are good for forwards compat (even if were to use key+valuelen+valuedata blocks in a binary format, embed the version of data as part of the key or something). 

I replace those sounds with silent .wav files! 

settled on a pretty simple method. i have just assumed that the order of stored prefs will always be the same, and anything new will be added to the end.

this way, i can just go ahead and read things in with default values if we're at EoF as in metl's suggestion. but this way i don't need any kind of headers or whatever.

FlatBuffers looks cool, but I like to avoid using extra libs when possible, although that looks like it'd be very useful for more complex systems (eg: games) so thanks for the heads up! 

Yeah, that sounds like proper YAGNI design ;-). However, I wonder why you don't want users to be able to edit the prefs? 

Of course they're still able to do so, you're just making it a bit harder for them. 

There's a thin layer of amusement in the concept of someone on a Quake editing message board talking about ways to prevent users from tinkering with their settings and preferences. :P 

What's it got to do with Quake? 

Advocating for removing console access for the player. 

Nothing, directly. But the openness of Quake and how it allows hacking at pretty much every level, which makes this community possible in the first place ... And then necros is determined to lock his users out.

THAT'S ALL! Just found it slightly amusing. 

Pfft entitled quakers thinking they should be allowed to change stuff 

Maybe the idea is to edit the prefs via the program interface (won't break things) instead of typing whatever in a text file? (will break things) 

You guys should see it soon anyway. :P 

I searched for the use of this statement, but didn't get much further in QCman or Quakewiki.
I have no idea how to use it or where I should place it in the qc to make the two sounds silent.

It's about a dopefish, that tumbles in and out of the water, but the side effect is, that it produces the landing bounce of the demonfiend and the watersplash in quiet an anoying way throughout the level.

I could replace these sounds with silent.wav, but then other use for entities gets lost and that is not my intention.