Core Content Release Process

Jump to: navigation, search

It seems appropriate to start any section on ALFA's core content with explaining why we need it. ALFA's mission statement is, quite simply, incompatible with everything that exists by default. We cannot provide an immersive and persistent world designed for role playing and the Dungeons and Dragons game system in the canonical presentation of Forgotten Realms with any game right out of the box.

Neverwinter Nights and Neverwinter Nights 2 get us pretty close, and happen to be customizable:in Neverwinter Nights 2, "ALFA2" as we often call our project in it, we use of modules and hak packs, and these define the majority of ALFA's ruleset. In addition, the different nature of building and maintaining a world in Neverwinter Nights 2 meant that effectively maintaining a project with multiple servers would require modifications to the engine, which we achieve mostly through NWNx4, which is a program that runs alongside the server software and modifies it while it's running, mostly to create functionality which did not exist in Neverwinter Nights 2 by default-- such as changing subraces of creatures-- and allowing communication between our servers.

Separating these into discrete versions has a number of benefits to ALFA technically, mostly in that it means we can assume that, in any given version of the ALFA ruleset, everyone will be using the same version of the ruleset, and that reduces the time we have to spend working on our upgrades: which is incredibly valuable in an all-volunteer team.

Releases represent a lot of work for our individual servers, and typically means that the person primarily responsible for maintaining each server has to spend a day getting the server up to date and correcting any issues that core content upgrades revealed, and then must add the work of a typical module-level update at the end. We, similarly, need to give people who work on our core content enough time to work on larger projects and reduce the problems presented by people rushing projects through short releases.

What Players Need To Do During a Release

The only thing that players need to be aware of is that releases are often large downloads, as this will be when you download nearly every graphical adjustment that ALFAmakes, and these are typically very large files. When logging in after a release, try to connect to your server earlier than any scheduled events, to allow time to download.

What Servers Need To Do During a Release

The process of updating a server is a little bit more involved. Typically, these are the steps required of whoever is responsible for maintaining the module:

  1. Download a copy of the new haks and place them in a folder other than the one your live server uses on your host.
  2. Acquire the latest Advanced Script Compiler from the vault.
  3. Download a copy of the new alfa2_acr.hak onto whatever machine you use to compile your server's scripts, replacing your old alfa2_acr.hak, and then open the module.
  4. Reference the list of scripts to be deleted from modules, posted by the release's coordinator, and remove them from your module.
  5. Compile all scripts in the module.
  6. Stage any changes you've made to your module recently, as you typically would for a module update.
  7. Save the module and close the toolset.
  8. Open servers.xml with a text editor and update the download path for your haks to the new one posted by the release's coordinator.
  9. Open moduledownloadresources.xml with a text editor and update the resource elements to the values posted by the release's coordinator.
  10. Download the updated module to your host.
  11. Download the updated NWNx4 plugins to your host.
  12. Ask all players on to log off, and if any remain after a reasonable delay kick remaining players off.
  13. Shut down the live module's NWNx4 and nwn2server.
  14. Copy the downloaded haks and prepared module to the live server folders.
  15. Configure any new plugins; copy any updated plugins.
  16. Start the server again.
  17. Log in with a test PCand verify:
    • The autodownloader works
    • Logging in works, and PCs are appropriately validated
    • Performance is reasonable.
  18. Inform the release coodinator that the module is updated or modify your module's info text file to list the new hak version.
    • This is usually a good time to review the other things on your module's info page. If you've absorbed new areas into the module or the description has somehow meaningfully changed, that should be updated.

Ideally, servers should upgrade during the weekend of the release, though ALFA's release procedure offers limited support for staggered rollouts. If it is to be more than a few days' delay, it may become necessary to disable the server's portals until the upgrade is possible, as a way to reduce burden on the download mirrors.

What a Release's Coordinator Needs to do During a Release

The process of preparing a release must, for the most part, be done beforehand. Typically, these are the steps that must be performed the the person who has called the release:

  1. Post, with at least two weeks' warning, when the release cut will be taken and when the release is expected to take place in the Technical Staff forum.
  2. Bump the thread, with at least one week's warning, to verify that vital projects will be done on time.
  3. If any projects are not in minimum releasable condition, and would affect existing content, create a release branch and roll back the unfinished projects on it.
  4. Prepare release notes from the changelog in the repository
  5. Take a diff from the alfa2_acr.hak of the previous and new releases. Post the list of added .nss files as potential conflicts with module resources (separate original .nss files from copied ones).
  6. Compile the haks, and correct any compile errors.
  7. Update the versioning text files, and push them and the compile fixes to the repository, tagged for the release.
  8. Recompile the haks with the final contents.
  9. Compile a live module against the new haks, and investigate errors.
  10. Stage the haks, and upload them to the download servers.
  11. Post the new download path for the haks and the resource elements from the staging for the modules' reference.
  12. Update the mirror.
  13. Provide accessibly-compressed versions of the haks via the DMFTP(under /NWN2/HAK/<version number>) for access by builders and hosts.
  14. Include a text file which lists the modifications required to the server's XML files in the same directory as the haks provided on the DM FTP.
  15. Find the updated talk table (stored on the repository under /tlk/ ) and upload it to the DM FTP in the same place.
  16. Check for new NWNx4 plugins and provide them for the hosts via the same method.
  17. When modules update, ensure that the module info text files are updated

Typically, it is best for the coordinator and the tech team to remain available to support the servers as they upgrade to the haks.