So you've got a bunch of mechanics that rely on encoding information in the item number. (Or badge number, or....) Maybe you've decided every item should have a unique four-digit number; magic items should have second digit odd, and its value should be the recharge time for magic items but irrelevant for non-magic items; for psionic items, the middle two digits sum to a multiple of three; if the last digit isn't greater than the first, the item isn't especially old, but if it is, the difference is the age in centuries. And since GMs will want to make new items in runtime, we'll reserve items whose first digit is 0 for that. That's a bunch of fairly typical encodings, though most games wouldn't have quite that many. Oh, and the numbers should be random otherwise.
You may, of course, generate the numbers that satisfy all of these one at a time, or write your own magic to do it --- none of the stuff here is at all mandatory. But if you want to avoid the pain of doing it all by hand, you can.
The numbers script both places and seeks files in LaTeX/Numbers/ by default. If you use the optional .structure to change this, make sure to keep it somewhere in TEXINPUTS, as game.cls has to be able to find some of the output files.
Once you've decided your encoding mechanics (not necessarily once and
for all; you can change them later), your Czar writes an itemnum-spec
file in LaTeX/Numbers and runs numbers on it, all as per
numbers-generate. Some of your encodings
are put in the spec as 'flags' --- those that are either on or off, like
magic, psi, or ingame; encodings whose values are numbers (nonnegative
integers only) are put in the spec as 'values'.
The script will create a bunch of itemnum.* files in LaTeX/Numbers. Each combination of the flags gets its own file: ingame ones go in itemnum.ingame, magic in itemnum.magic, psi in itemnum.psi, etc; magic psi items go in itemnum.magic.psi, ingame magic psi items go in itemnum.ingame.magic.psi, etc. Those that don't satisfy any of your special flags go in itemnum.plain.
Within each file, the items are sorted by the 'values' values, producing chunks of items will the same flags and values, headed by lines that tell you what the values are in that chunk. Within each chunk the numbers are ordered randomly.
Now, when you want to give Fred a magic psionic sword, with long recharge time, made recently, you go to the itemnum.magic.psi file, search for the values header line "recharge=9, age=0" which begins the chunk of magic psi items with those values, put "Fred's sword" next to the first number in that chunk that's not already taken and use that for Fred's sword. Ta-da!
The part where you mark in the file what you took the number for is important --- without that, you'll screw yourselves up with multiple allocations and not remembering where you need to change things when numbers change. Also, if you decide to use auto-assignment it can't avoid your manual allocations if you don't mark them in the files.
When you mark the allocation, you should only edit the line the number is on, and only by adding your remark to the left of the number. You should not edit other lines, add lines, or otherwise edit the file, in case you decide to use the auto-assignment script. Also, do not say "AUTO" in your remark, as that is reserved for the auto-assignment script.
The script will also create an itemnum-allocations file. This lists, in order, all the numbers allocated either manually or automatically, with the allocation note, the flags, and the values. You probably want printouts of this during runtime. (Czar note: this is created at the end, after both generation and assignment, but it happens even if you say 'no' to both.)
We highly recommend the use of the "ingame" flag (first digit zero in the above example). This reserves a set of numbers so that when during runtime you create an item, you can be sure it won't trigger anyone's memory packet. It's ok for it to be a fairly small set; as long as the whole range of other flags and values is present, you don't need a lot of entropy, since it's OK if you make a whole bunch of items ingame with the same number --- they're not going to trigger memory packets anyway.
The Czar should read numbers-generate now if you're going to be using this.
First you should read the above material about manual use of generated random numbers. Now, if you've decided to use that material, you can decide to always allocate numbers manually as described above. That can cause some pain, though. If you put item numbers (or whatever) from the RNG output into your charsheets etc by hand, and then suddenly change your item number mechanics and have to regenerate the numbers, you'll have to change all the numbers in the charsheets etc by hand.
If you wish, you can use some more magic to do auto-assigment. This is completely optional, even if you're using the random number generator. Further, if you do use it, you can also do manual allocations and the auto-assignment will not conflict with them.
Once you've decided to use this, your Czar tells custom.sty you'll be using "itemnum" numbers. This causes the latex macro \itemnum to automatically be created for you. When you refer to an item number in a charsheet or item card or whatever, put \itemnum{unique id}{properties}, e.g. \itemnum{fred's sword}{magic, psi, recharge=5}. If you refer to the same number more than once, you leave the properties blank in all but one --- e.g. other references are just \itemnum{fred's sword}{ }. A number with no interesting properties is declared as \itemnum{my pen}{plain}. Each 'value'-type property of the number is considered zero if you don't mention it ('age' in the fred's sword example).
Actually, you could give a number's properties more than once, and the script will notice if they contradict each other. Also, if you have nothing encoded in the numbers at all, you don't have to say {plain} all the time --- you can leave the description blank and {plain} is assumed.
Now the Production Czar can run the numbers script and do the 'assignment' phase, as per numbers-assign. This will go through all the .tex files in your game (skipping Prep directories, as those are all duplicate information from charsheets) looking for places you said \itemnum{...}{...}, and try to assign appropriate numbers to each. You'll notice two results.
The first is that in the LaTeX/Number/itemnum.* files, where you may have had some manual allocations marked already, will be marked the automatic allocations. That is, if it took number 12345 for \itemnum{fred's sword}{whatever}, the line "12345 AUTO: fred's sword" will be in the appropriate file. The assignment script does not touch manual allocations you have made, as indicated by the notes you made in the files; that's why it's important that you make those notes carefully. Old "AUTO" allocations go away whenever the Czar re-runs the script.
Second, the file LaTeX/Numbers/itemnum-assign.tex is created. You don't need to look at this file and certainly shouldn't edit it by hand, but it's there. Because of it, when you latex a .tex document that mentions \itemnum{unique id}{whatever}, it will get the number that's been assigned to that unique id. If no number has been assigned --- because the script hasn't been run since you invented that id, or because you gave invalid properties, or because it ran out of numbers --- it will come out as "UNASSIGNED." The Czar always gets messages about things going wrong when they run the assign script, so they should be able to fix things like invalid properties.
If you change your itemnum encoding mechanics, the Czar just re-runs the numbers script to re-generate and then re-assign numbers. You only need to touch the \itemnum declarations in your .tex files if you'd used properties that you just got rid of, or if you feel like adding some new property to an item. Of course, if you also had manual allocations, you'll still have to go and re-do those by hand.
The Czar should now read numbers-assign if you're going to be using this.