Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

Week 48/2012: Loose ends and Config

edited 2012 Dec 4 in Developers
skyjake's notes:

Last week I was tying up loose ends in preparation for the impending candidate phase, and did a lot of progress with Doomsday Script.

Tying loose ends:
  • Fixing regressions due to recent changes (e.g., UnixInfo paths, reading saved .cfg). If you've noticed that your settings aren't being saved, this should now be fixed.
  • FluidSynth on Linux: music volume control is now applied correctly, making it possible to use FluidSynth for audio output on its own (e.g., SDL_mixer + FluidSynth).
  • The fixed-precision collision tests are not used with the player any more, only non-player mobjs. This will hopefully prevent the player from getting stuck in tight spaces.
  • Continued code reorganization and moving to shared libraries (vector math, etc.).
Before the candidate phase locks in, I took the opportunity to push in a few significant improvements to libdeng2. My goal was to start integrating Doomsday and the new libdeng2 script engine, and start building some of the infrastructure for scripting.
  • Cleaner log output by abbreviating parts of the messages. (Mostly helpful for developers, debugging.)
  • Fixed a bug when writing ZIP archives.
  • Doomsday Script: added "export" statement and keyword.
  • Doomsday Script: number values can be marked with a 'boolean' flag so they appear as boolean True and False.
  • Doomsday Script: fixed a bunch of parser bugs.
  • Added "/home/persist.pack" for storing the application's persistent data into. The future equivalent of console variables (de::Config) is stored here.
  • Doomsday Script: added TimeValue for manipulating time in expressions.
  • Doomsday Script: added Record(), a built-in function to make copies of Records.
  • Switched the automatic updater and window manager to use de::Config for settings.
  • Replaced the "/config" folder with "/modules".
  • Renamed to (sets up the Config namespace with default values).
  • Created the first module of the Doomsday Script Standard Library:
This week we're going to start the candidate phase for 1.9.10. In practice this means that once again we'll try to put the long-term, big tasks aside for a while and focus on bug fixing and polishing.


  • I remember the following mentioned before, but I kind of forgot what it means when a new build is uploaded and it says 'issues' and then lists the number of issues with the number itself contained inside a red or yellow box (border). Does it mean that the build itself is extremely buggy? If it is in a red box, then the build may not even be clickable, therefore not downloadable. I remember Dani saying it had to do with the number of issues with uploading the new build, but that doesn't make sense and I couldn't see how that would affect anyone downloading it. Maybe I misunderstood and it means the number of 'critical' issues in the new build itself and not the uploading process itself, like fatal bugs or show stoppers in the build.
  • Does it mean that the build itself is extremely buggy?
    Unstable builds should always be considered potentially buggy. The yellow issue counter means that the code has compiler warnings -- there's code that the compiler thinks is a little ambiguous or potentially faulty. More often than not it just means the code is a little messy and needs to be cleaned up.

    So the issue count is not directly related to bugs or 'critical' issues or the stable to-do list; they measure the quality of the source code.
Sign In or Register to comment.