Template Issues Updates

$LocalDateChanged: 2006/07/18 EDT$

The internal documentation in your copy of the Template should cover most issues. Those covered here are mostly ones that arose with a version after it was released; some long-standing matters, especially Athena-based or tool-based ones, may also be covered.

Versions earlier than the earliest one that we think is still alive (being used by someone) will not be considered here.

• Patches
• Standing Issues
• Version 1.5d
• Version 1.6.0

New material (issues or treatments) on this page will often be announced to template-gms@mit.edu, to which you can add yourself at the Athena prompt with

blanche template-gms -a $USER

• Discordia (discordia-gms), Czar dvp, v1.5d

Patches

When a patchfile exists for a problem, it will be distributed from ~jemorris/Template/patches/. Please see the README there for how to apply the patches you need.

The published Template is usually updated for each patch just before the patch is released as a patchfile, so you usually only need to apply patches yourself that come out after you get your copy. However, the published Template is not necessarily updated with small, non-critical patches, to keep the number of versions finite. Check your html/version.html for the exact version specification and check below for mention of patches relevant to it, even when grabbing the latest version, if you want to be sure of having these tweaks.

Standing Issues

Issues Believed Still Active (i.e. for modern versions on modern Athena)

Recent entries are topmost.

• The Guild is not yet exempt from the Athena Rules of Use despite our obviously higher status. Hence the Template production scripts, which the Template in no way requires you to print with, won't hog public printers. Of course, all normal Unix commands work just fine on the postscript files the scripts have first generated for you; if you decide to violate the Athena Rules of Use yourself with those, please don't do so in the Guild's name. (As soon as the High Council has I/S's written waiver exempting the Guild from the printer RoU, the scripts will go hog-wild.)

• Packet contents may not print in order and I don't know why; can't reproduce the damn thing. If you can, let us know. Seems more likely to happen when printing at least 100 things or so at once. (Does lprng guarantee that queue order reflects order of completed calls to lpr? If not, this is probably a spooling subtlety, in which case I'm not sure there's a client-side solution beyond an extra pause after each lpr.)

• Internal forward cross-references in sheets rely on the .tex being latex'd more than once (first time puts the info in the .aux, next time reads it out of there---nothing to do with the Template, just latex). The Template scripts and docs always call for a single dose of latex, hence will produce sheets with not quite all the info (cross-refs, index, ToC) if you write some using such mechanisms. As these are damn rare in game files (or this would have actually come up, instead of just being something that occurred to me), solving this issue is deferred til v1.7 or later.

• latex to html: latex2html is meant only for conversion of some very basic latex documents, and is documented not to deal reliably with, e.g., plain tex, classes beyond "article," nontrivial new latex macros, etc. Expect it to explode in a shower of red gore if pointed at Template files.

Issues Believed Inactive (at least for modern versions on modern Athena)

• N-pages-per-page printing: may be OK as of October 2003, when Athena psnup was apparently upgraded, but just in case...
  Problem: The psnup utility, found in the postscript locker, the psutils locker, and /usr/athena/bin, is used for n-up printing. The /usr/athena/bin version used to malfunction semi-reliably on some kinds of documents, including most Template sheets as well as random non-Template stuff. The postscript locker's version has always worked reliably AFAIK. Anyway, the modern /usr/athena/bin just runs psnup out of the psutils locker, whose modern psnup has the same syntax as the postscript locker's (old one didn't!) and produces identical output for Template packets' sheets in test cases. You can run psnup.old out of psutils (dunno how supportedly) if you want to observe the old general lossage (a bit worse in v1.5 than v1.6) and syntax clash.
  Solution: As stated, modern Athena seems not to suffer from this. If you do find psnup giving you grief with Template (or other) documents, try the other version(s), i.e. run psnup out of the postscript locker, run it out of psutils, run it out of /usr/athena/bin in case that's different on your machine for some reason. If you want you could even add -f postscript or add -f psutils in your ~/.environment, but since the former's an older, smaller binary and the latter's become the default anyway I wouldn't be gung-ho about it.
  Caveats: I've tested 2-up and 4-up only, with postscript psnup, psutils psnup, and psutils psnup.old, on Linux and a cluster Sun and a dialup Sun but not on an SGI.
  Et Caveat: If the postscript icon you supply for sheets to include (typically put in LaTeX/Postscript/icon.eps) is sufficiently badly generated postscript it can cause problems for psnup or any other post-processing tool. If your icon was made on a Windows machine (or maybe a Mac) and psnup vomits, try omitting it (\useicon{} at the bottom of sheets.sty).
  If you find a (Template) case where psnup still screws up, please do send it to us so we can test it and update this information! (Send a copy with Secret GM Stuff sanitized out (or postgame), we wanna play.)

• Overflowing memory pools: shouldn't be an issue at all with v1.6 and later, but just in case...
  Problem: TeX has limits on how much memory it can use for various things, and you can exceed one of them in the current Template implementation if
  #C * #F * (c + f + 1)
  gets too big, where #C is the number of character macros, c is their average length ("\Ccorpse" is length 8), #F is the number of charinfo fields, and f is their average length. If you hit this limit, you'll get complaints about memory pool size being exceeded (there are other memory pools that'd give similar complaints; this is the only one we've actually seen hit, by two games).
  But: V1.6, having dropped newtex, enjoys the greatly expanded limits of the tetex distribution, so you've got a lot more room before you hit any walls, enough that this is pretty much considered a v1.5 issue now. Whatever your Template version, if you do hit it, then
  Solution: You can set your environment to enlarge the relevant limits. Wait until you actually have problems; you don't want to mess with these settings unnecessarily. Then try
  setenv pool_size.latex 2500000
  (in each GM's ~/.environment) and that'll likely suffice. If it doesn't, send email and we'll experiment with other limits, or dig around in texmf.cnf to find limits to experiment with. Actually, send email if you hit these problems at all, even if it's after you've solved it, as we'd like to know that it's actually still an issue.
  Alternative: If you're worried and really want to avoid this ever coming up (reasonable if you're using v1.5 or older), just keep your charinfo field names short. (Obviously keeping char macros short also helps, but there's a lot more of them and you edit that list more, so it's easier to just have short field names.)

Version-Specific Issues

Newer versions are topmost; v1.6.0 is the current release.

Please note lack of a feature is not a bug, even if it's a feature you really want. So while user feedback does drive the Template to-do list, not everything that's on the to-do list appears here while it's pending.

When there are patch releases, the list of "issues that were in this version" (but are fixed in the subsequent patch) will often include improvements that aren't true issue solns (which hadn't been listed here as issues) so that people musing over whether to take the patch will have the extra information. But see the html/version.html of the later version if you want more changelogs.

Version 1.6.0

Version 1.5d

• The newtex locker is required. Ewww.
• The psnup issue above may bite these older versions more harshly, in the event that it actually bites at all.
• The memory overflow issue above is much more likely to come up in these older versions that still use newtex. Both the solution and the avoidance-of-problem mentioned should work.
• Rules template may lag the Standard Rules: this matters if and only if you (a) are using the SR and (b) are using LaTeX/Central/rules.tex as a skeleton. The comments/checklist there aren't as useful as those in ~jemorris/Rules/rules-template.tex (which is updated jointly with the SR, and sometimes more), so you ought to glance at the latter when you go to fill in the former.
• The injector script emits harmless but annoying warnings about use of undefined values when injecting empty extractable lists into charsheets (with perl versions more recent than it was developed under, which is most perl you'll find now), and also gratuously inserts a newline in empty lists (though only once). There is an isolated patch to suppress both of these effects.