News from 20 July 1999

[randi]

ZDoom 118test8 is now available. Changes from test7 are:

• Incorporates a modified version of the hacked ptc.dll I put out a few days ago. This should hopefully fix any problems some people were reporting with earlier versions. (But since I only got feedback from three people, I won't guarantee it.)
• Fixed a crash problem with the "burn" screen wipe.
• Fixed a crash problem with playing non-assigned sound sequences (such as polyobjects that reference an undefined sound sequence number). They should just be silent instead.
• Fixed a crash problem related to trying to shutdown the music subsystem twice.
• If you try to add more coop bots than there are coop starts, the extra bot leaves quietly instead of ending the game.
• Weapondrop is now a "server" cvar, which it should have been in the first place.
• The nodetable file format has been changed to be more compact. If you made any with test7, you will have to delete them and recreate them from scratch.
• Bots can now be recorded in demos. Anyone with test8 can watch the demo without worrying about whether or not they have the same nodes for the map as you.
• Bots work in multiplayer games. Sort of. If you add multiple bots, you need to wait a while between adding each bot or else you will experience consistancy failures. Also, the bots seem to have trouble finding a target with more than one human player in the game; eventually they all start spinning around wildly.

No, savegames are still not done. Assuming that I don't get any additional bug reports for test8, I will probably add the savegame code to it and release it as the "official" 1.18, even though DoomScript isn't ready yet. There are enough changes here to warrant a new version number, and this codebase uses a publicly available version of PTC instead of the now-defunct PTC 0.72b. That and the integration of the Cajun Bot is reason enough for doing another official release earlier than I had originally intended.

DoomScript will have to wait until 1.19. Thanks to the conversion to C++, I now have a decent base for plugging it into the game code when it's ready, so it shouldn't be too much trouble. I say "decent" and not "good," because supporting Dehacked with a "good" implementation is difficult without already having a working DoomScript setup in place.

So what is DoomScript?
I'm hesitant to go into much detail at this point, but I will say that
it is not DDF. DDF and DoomScript serve similar purposes, but they go about very different ways of accomplishing them. DDF is in many ways just a different way of representing the same data (and then some) that could be manipulated with DeHackEd. DoomScript is a full-fledged object-oriented scripting language and represents a radically different approach to Doom editing. (That said, I hope I didn't scare anybody away who was interested in it. If you can figure out ACS or DDF, you shouldn't have much trouble with DoomScript. And if you know UnrealScript, you should feel right at home.)

DoomScript represents different game elements as "objects." New objects can be created by "extending" existing ones. Suppose you want to add a new monster, and there is already a monster that is similar to what you want. Instead of creating an entirely new monster from scratch, you can take the existing monster and extend it so that it behaves the way you want it to. I'll have some concrete examples of this once DoomScript is actually ready.

At one point, I was considering integrating the DoomScript compiler with ZDoom itself. Instead, I have decided to keep it a separate program like the QuakeC compiler, qcc. There are several advantages to this approach:

• Smaller file sizes. Compiled code will almost always be many times smaller than the source code it came from. As an example, the ZDoom source is around four megabytes uncompressed, not including any of the support libraries, yet the executable is only about 730k.
• Smaller executable. The DoomScript compiler is already over 100k, and it's not even fully functional yet. I prefer not to increase the game's size so drastically when the majority of users won't even use DoomScript directly.
• Faster loading times. Compiling takes time. Better to spend the time compiling once than each and every time you start the game.

The only advantage I can see to putting the compiler into ZDoom directly is that mod authors wouldn't need to manually recompile any changes they make, and even that can be got around by using a batch file to launch the game.

A DDF->DoomScript converter will be available so that people can both see how something done in DDF relates to something done in DoomScript, and also so that DDF mods will work with ZDoom. A DeHackEd->DoomScript converter might also be made, although doing anything with DeHackEd outside the original doom.exe is very problematic, and it might not be realistically possible to convert it to DoomScript with an automatic tool.

Initially, ZDoom will come with DoomScript code that implements the Doom game. Later, I plan to also have Heretic and Hexen implemented. Maybe I will also convert SailorScout's Check Quest patch to DoomScript.