Tweet
I haven't given this enough thought to claim anything concrete, but my parsing delimiters concepts could probably be ported to Quake. I went looking in dpextensions and found this:
That could be all I need to turn my string to object system into a string to entity system. The code will probably be a mess.
Why would I do this? Well, I see it like this: Currently, if you want to include an (ex) monster in your QC you have to write an entire "class" for it and that class has to be compiled into the QC. By using external objects you just need a QC mod that can handle parsing it into the game. So maybe you would have something like this:
Of course it would include all of the stuff I left out, including animation frame numbers. That object would reside as a text file somewhere. When QC loads it checks for files, or maybe just gets all the text files that are present within a specific folder. Then it parses the files out to their proper entity description and finally "injects" them into the game wherever the corresponding ent resides in the map.
I'm not saying that I intend to build this. I am simply sharing something that has crossed my mind a few times. There's probably reasons why this would even be bad (cause all my specialty QC turns out to be "bad") and I am all ears on these potential reasons as long as you know what you are talking about.
---
Completely lacking a RegEx system is a bummer. I'm assuming there is no RegEx in QC cause there is no RegEx type. That being said, a string to entity parser in QC is gonna be a procedural, loopy mess. I'm also not positive that the string manipulation features in dpextensions are even sufficient.
I saw tokenize in dpextensions. I am curious if it could be used very creatively to help achieve this goal.
Everything should only be one layer deep, so I don't really have to try and worry about never-ending nesting. It should all be pretty much where the main object container represents "self". Instantiating a self goes one dot deep. The possible use of arrays on an entity means I might have to go one dot and an index. Since I'm pretty sure it would be retarded to shove entities into an array that is a member of an entity, self.array[num] is probably as far as I will ever have to parse. This means that no one nesting possibility can ever happen inside of itself. No multi-dimensional arrays, no entities inside of entities, and the rest obviously cant have more versions of itself within it cause it never could.
Code:
float(string s) stof = #81; // get numerical value from a string float(string filename, float mode) fopen = #110; // opens a file inside quake/gamedir/data/ (mode is FILE_READ, FILE_APPEND, or FILE_WRITE), returns fhandle >= 0 if successful, or fhandle < 0 if unable to open file for any reason void(float fhandle) fclose = #111; // closes a file string(float fhandle) fgets = #112; // reads a line of text from the file and returns as a tempstring void(float fhandle, string s, ...) fputs = #113; // writes a line of text to the end of the file float(string s) strlen = #114; // returns how many characters are in a string string(string s1, string s2, ...) strcat = #115; // concatenates two or more strings (for example "abc", "def" would return "abcdef") and returns as a tempstring string(string s, float start, float length) substring = #116; // returns a section of a string as a tempstring vector(string s) stov = #117; // returns vector value from a string string(string s, ...) strzone = #118; // makes a copy of a string into the string zone and returns it, this is often used to keep around a tempstring for longer periods of time (tempstrings are replaced often) void(string s) strunzone = #119; // removes a copy of a string from the string zone (you can not use that string again or it may crash!!!)
Why would I do this? Well, I see it like this: Currently, if you want to include an (ex) monster in your QC you have to write an entire "class" for it and that class has to be compiled into the QC. By using external objects you just need a QC mod that can handle parsing it into the game. So maybe you would have something like this:
Code:
player:
{
health:100;
takedamage:DAMAGE_AIM;
solid:SOLID_SLIDEBOX;
movetype:MOVETYPE_WALK;
show_hostile:0;
max_health:100;
}
I'm not saying that I intend to build this. I am simply sharing something that has crossed my mind a few times. There's probably reasons why this would even be bad (cause all my specialty QC turns out to be "bad") and I am all ears on these potential reasons as long as you know what you are talking about.
---
Completely lacking a RegEx system is a bummer. I'm assuming there is no RegEx in QC cause there is no RegEx type. That being said, a string to entity parser in QC is gonna be a procedural, loopy mess. I'm also not positive that the string manipulation features in dpextensions are even sufficient.
I saw tokenize in dpextensions. I am curious if it could be used very creatively to help achieve this goal.
Everything should only be one layer deep, so I don't really have to try and worry about never-ending nesting. It should all be pretty much where the main object container represents "self". Instantiating a self goes one dot deep. The possible use of arrays on an entity means I might have to go one dot and an index. Since I'm pretty sure it would be retarded to shove entities into an array that is a member of an entity, self.array[num] is probably as far as I will ever have to parse. This means that no one nesting possibility can ever happen inside of itself. No multi-dimensional arrays, no entities inside of entities, and the rest obviously cant have more versions of itself within it cause it never could.
Comment