QuakeEd itself simply scanned the QuakeC game source for these comments directly and built its definition library from there. Everything else in the comment was treated as a descriptive docstring. Every comment block that opened with /*QUAKED was considered an entity class definition, whose first line was treated as a formatted metadata definition of name, size, color, and spawnflag names (point/brush status was inferred from presence or absence of a defined size). Id's original means of generating editor entity definitions was to overload block comments. Everything will work out okay in the end. The source is provided happily, because this is still better for Quake overall no matter what people may do with it. However, a great deal of the mapper features in Copper originate from Quoth, and had to be re-engineered from scratch on my part without any source code to work from, and I won't let any of my personal (and possibly selfish) reservations lead me to do the same to you. Kell released Quoth closed-source, and cited as a reason a desire to avoid such fracturing caused by "everyone compiling their own interpretations of Quoth." While I feel that's a little too protective, I understand the sentiment. Players could no longer take the presence of any one Copper feature as an indicator of the presence of any other, and while your mod may be that little bit more like the Quake you want others to play, such subtle but constant confusion would, I feel, make Quake a little worse for everyone. When you play a Quake add-on that includes them, how do you learn they're there? Is it in the readme? Does the game warn you? Or do you find out the hard way, the first time one shoots you in the face from an angle you thought safe? Now consider this problem of relearning part of the game as you play, but multiplied across every alteration in Copper. If every mod were to include a different subset of these, the play experience for each player would be muddled by a trepidatious series of accidental discoveries of which way the player should expect them all to function this time, rather than being able to take the entire package as a given every time.Ĭonsider the conventional Z-aware Ogres, the ones with perfect aim. Copper touches many aspects of the game in small but significant ways. This will avoid fracturing for players the 'gameplay base' that Copper strives to provide. When extending Copper for your own mod, I strongly encourage you to use the complete corpus of Copper gameplay tweaks if you use any, rather than sampling what may be your favorites. If you're unsure if your compiler will work, try it and it should tell you. Other compilers may work, provided they support a few syntax upgrades (such as field masking and not requiring the ' local' keyword) as well as #pragma autoproto. Compiling it requires FTEQCC (any version from at least 2018), by Spike. You may, and are encouraged to, use it as a base for additional mods, adopting or adapting features, or merely to learn from. A guide to compiling Copper into progs.dat, and some notes on making the best use of new methods in the code.įull QuakeC source is included with the mod.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |