Oh good, the Junior Programmer Peanut Gallery is up to its antics again.
To clarify, and pay attention here because people have said this repeatedly and it isn't penetrating :
"Hard coded", and "being able to swap that data out without a source code recompile", are mutually exclusive concepts. One means NOT the other. Since the scripts, all that data and any logical functions in them, can be changed without recompiling the c++ game source code, they are, by the
very definition, not hard coded in. Which is the
exact fucking reason you use scripts in the first place, ffs, because you can include data and logic without hard coding them into the source.
1: This should be in a data format ( XML, YAML, JSON, ...) not source code.
A data format, you say? Wow, cause it wasn't in a "data format" in the TorqueScript eh?
You know what a data format is, yes? It's a set of rules for formatting data (generally in a file) to be interpreted by something (a piece of code or the human eye) which understands that format and knows how to read it into a data structure in memory. You know that a data format is just a thing you make up, right, a set of rules you lay out as a standard for laying out data. XML is a well known one, but you could make up your own if you feel like it (like the data format used in .pak files in Quake/Doom engine), and write parsers for it, etc etc, which is what Torque did, back in the Tribes 2 days when most of the original engine was created.
XML is a common format for storing data in a form of graph. An xml parser reads the file, understands the code language in it like this :
Code:
<xml>
<painting>
<img>
<caption>This is Raphael's "Foligno" Madonna, painted
in <date>1511</date>-<date>1512</date>.</caption>
</painting>
and turns that into a graph data structure.
Guess what is happening in the TorqueScript file? That's right, we have data (strings) formatted in a way Torque recognises to be an array data structure (actually a vector, but let's pretend it's an array) as opposed to a graph. The data structure is created in memory, the file is parsed by the executable and the data format read, interpreted according to the understood data format and placed in the memory data structure. Almost identical to if you'd read it out of an xml file, or an other data format. Except you can also put logic functions in script files, if you want. You don't have to though, a file filled purely with data is fine, the TS gui files are an example of this, they are pure data defining in game gui layouts.
Script files are great, they can contain both data AND script logic, neither of which are hardcoded (ie compiled into the game binaries). Isn't that neat! It's like, an .ini file that can contain not just data variables but dynamically bound logic! If either that data or the logic were "hard coded", you'd completely lose the benefit and point of having script files in the first place, ie that you can swap out that data and logic without recompiling the source code. (I'm repeating myself here because I think it will have gone in one ear and out another.)
So what is the difference between having a script file with an array definition in it and an xml file with an xml graph structure defined in it? Well, for one thing, the file ends in .cs instead of .xml. That's huge, right there.
Also, you have to have an xml parser to read xml data structures, whereas with Torque Script you need a TS parser to read TS data structures (and TS logic functions). Funnily enough, the Torque engine comes with a TS parser standard. Someone could, if they were silly and had a hard-on for xml, go and write an xml parser and make sure to define all their data in the xml format instead of the TS data formats. That would be great, not completely redundant at all. All that data, in files ending in .xml instead of .cs, it does the heart good to think of it. Worth the effort.
(If you really love xml, T3D offers an xml parser as well as a TS parser. Useful if you're brining data from another engine, you can use a standard format.)
The other difference, of course, is that parsing xml graphs is inherently slower and more computationally expensive than an array or vector. But it's a minor cost, so lets not mention it.
That's open to debate - hardcoding can be a relative term, but cyncynat provided context for his interpretation
No. It means that the data variable value cannot be changed without recompiling the source code, the executables and binaries. Scripts aren't built into the binaries. They are evaluated at run time and can be dynamically altered and swapped out without a recompile. It is not a relative term.
which completely misses what cyncynat said - he didn't even catch that cyncnat identified the snippet as coming from a script file.
No, Nick assumed Cyn was knowledgeable enough to understand that a script file is, by definition, not hard coded, ie it's a contradictary statement, this one : "I know it's script, but it's still hardcoded!"
No - at this point cyncynat responded with an example of what he meant - he also made the sensible, but wrong, assumption that no one would add a "feature" to a scripting language that automagically creates arrays out of variables with the same name and a number suffix.
You know what they say about assumptions.
but he jumps back into not understanding what a scripting language is
He understands. You don't. Back to java for you.
I think we've debunked most of this already. The inability to differentiate code and data - maybe we should blame XML? To anyone still setting on the bench - moving data out of compiled C code into something like TorqueScript is a great first step. Best practice, however, is to go one step further and put that data into a data-only format. Mainly because:
1) It's easier to edit, especially since you can quickly throw together a GUI interface to XML or SQLite.
2) It's a lot easier to validate a data-only format than a script source.
3) TorqueScript can do a lot more than assign variables. While VD can be trusted to not go playing with the docs and buttfuck the game. It would be nice to give a volunteer access to text entry chores without giving them access to all that power.
You've debunked nothing. And :
1) The correct statement is : XML is a lot harder to edit than simple "array0=" lines in a file UNLESS you throw together a gui interface. Which is extra work on top of building an XML parser for TGE, which is a complete fucking waste of time for a small set of properties stored in a file.
2) Except when you have ALREADY GOT THE FUCKING FUNCTIONALITY BUILT INTO THE ENGINE IN THE FIRST CASE, and not in the 2nd. 0 work versus some amount of work > 0.
3) Torque is awesome, you can pseudo-compile select script files into an intermediary byte-code, which prevents end users messing with any scripts you don't want messed with (besides deleting them, of course) while leaving others open for them to play. It's essentially a way of encoding the scripts into a non-human readable format if you don't want to give away your scritps to people, without hard-coding that stuff into the engine itself, of course.
Let's summarize, cyncynat was polite to a fault, offered honest criticism, responded to your initial doubts with real supporting examples to clarify, and then like neocons at a town hall meeting you and Nick screamed him down with idiocies about death panels and scripting languages.
Cyn has just enough knowledge to shoot himself in the foot and enough pride to ignore any attempts to enlighten him when he runs into a gap in his understanding. Nick was very patient with him.