toneddu2000 wrote:frag.machine wrote:
a) sorry: float, pseudo-string (see below), vector and entity are not enough anymore;
b) no actual arrays, let alone collections;
Code: Select all
//*********** not JUST "4 types".. *************
int ammoType;
int inventorySlot[5];//this is an array
Fine,
FIVE data types (with the caveat that ints are supported only using the FTEQW/fteqcc combo). My point stands.
Also: your inventorySlot is not an actual array. It's a compiler hack (try using anything different from fteqcc). What you really have is something more like:
Code: Select all
int inventorySlot_0;
int inventorySlot_1;
int inventorySlot_2;
int inventorySlot_3;
int inventorySlot_4;
And this is
ugly, because not only this "array" needs to be previously dimensioned, but it cannot grow/shrink dynamically. Also, it's replicated in EVERY OTHER ENTITY because we don't have
actual classes. Remember your rifle you declared in the first example ? It will also have the .inventorySlot "array". Player gibs ? Same thing. Monsters ? Yup. Grenades ? yeah, they also have inventories. And .score. And .noise, .noise2, .noise3, .noise4. And EVERY OTHER FIELD declared in your code for a completely unrelated reason.
toneddu2000 wrote:frag.machine wrote:
c) no actual objects: having the same hundreds of disparate fields in every entity won't never scale (and it's a nightmare to keep sane);
I'll leave this alone because I didn't quite fully understood what you're saying. I'm not that advanced in programming to understand it.
I prefer Spike speaks for it. But, IMVHO, I never had problems with fields, as long naming conventions is good
See my comments above. When you have a few entity types it is manageable, but try to implement something really complex and you'll start reusing fields among different entity types for different things (.button1 is a classic example) and have to remember EVERY time you used .delay or .wait for something non-obvious and bam, suddenly chaos takes your project over.
TL;DR: what I am talking about is being able to declare a Weapon class that don't have a .th_pain member because the Monster class declares it. You cannot do that in QuakeC (even using fteqcc and FTEQW).
toneddu2000 wrote:frag.machine wrote:d) no actual inheritance: you cannot have a WalkingMeleeMonster super class so you can quickly write a new monster in 15 or 20 lines;
Code: Select all
//*********** CLASSES *************
class monster (...)
// BIG SNIP
Just take a look at what
Spike did with menusys. It' all OOP!
Nope, see above. It's a hack. Spike does a great job emulating those features mostly via compiler tricks, but they still are hacks, lipstick in the pig. He cannot truly implement OOP, actual strings and more datatypes without breaking compatibility with vanilla QuakeC. But frankly, what he manages to do it's awesome for a 20+ y/o game engine, so I am not complaining, just pointing the facts.
toneddu2000 wrote:frag.machine wrote:e) no actual string support, strzone/unzone/whatever hacks are not good replacements;
From defs.qc generated in FTEQCC via the command pr_dumpplatform
string(string s, ...) strzone = #118; /* Part of FRIK_FILE, FTE_STRINGS, ZQ_QC_STRINGS
Create a semi-permanent copy of a string that only becomes invalid once strunzone is called on the string (instead of when the engine assumes your string has left scope). This builtin has become redundant in FTEQW due to the FTE_QC_PERSISTENTTEMPSTRINGS extension and is now functionally identical to strcat for compatibility with old engines+mods. */
strzone, strunzone and other builtins are again hacks (you use them to manually write code to manage the allocation and deallocation of your strings in a separated memory space), because the standard QuakeC VM only supports immutable (read-only) strings or a single temporary string (through a single char buffer). FrikaC came with the strzone/strunzone idea, LordHavoc improved the standard temp string by using a fixed size string array (he also created some stringbuffer builtins to compensate the lack of operator overload for string concatenation - in other words, "Hello, " + self.netname ), and finally Spike improved the temp array string to the point you can (mostly) forget about this issue but you are still forced to resort to strzone/strunzone sometimes. Again, it's not their fault, they did what they could without breaking the ability to execute old progs.dat; knowing how those things work under the hood makes you respect their efforts.
My point haven't changed: QuakeC (including the fteqcc/FTEQW dialect) is just fine - for idtech2 engines. Newer engines with more features needs more powerful and versatile scripting languages, with real strings, more data types, at least some support to basic collections, an some real OO model for entities, not emulation using field arrays.