I've gotten into the habit of altering every bit of code I touch, and when I came across the NPC packages, I decided that having a list of 3000+ names was more hassle than I care to deal with; so I wrote a small package to handle it for me.
There are two invocations of the system (which I'll go into later) but they all perform the same operations, with slightly different foci. After recieving their parameters, they read a config file to find:
- The nameset corresponding to the one passed to the script.
- The user-defined algorythms to form the name.
The algorythms can be very simple, if you wish to simply write a new command for every sound-set; or very complex if you wish to make use of the subcommands. Each command is seperated by a period (.)
I highly reccomend that you stay away from the subcommands. They can be used more-than-one at a time, but the wrong ordering or placement can yeild unexpected results.
The simplest command in the package is the "Escape" command. This works much like it does in POL or just about any programming language, but instead of just the letter after it, it interprets the entire command that follows as a literal. This way, a default can be put in:
Code:
Formula \Lizardman
This would simply yeild "Lizardman" as the result. If it were broken up into chunks, ( \Liz.\ard.\man ) it would still yeild the same result, because it's still a literal. This is pretty useless on its own, but can ease the process later.
A good example is a lizardman:
Code:
NameGen ConfigList
{
...
CF v,f,th,z,s,zh,sh,ck,x,h
V a,au,ae,e,ea,ee,ew,i,ie,o,oo,ou,u,ow
VH ai,i,oo,au
...
Cu c,ch,f,h,k,p,q,s,sh,t,th
Vf a,ae,ai,e,ee,ei,i,ea
...
}
NameGen lizardman
{
...
Formula VH[f].CF.CF[u].\s
...
}
First, the possibilities are mapped out:
Code:
V: {a,au,ae,e,ea,ee,ew,i,ie,o,oo,ou,u,ow}
VH: {ai,i,oo,au}
CF: {v,f,th,z,s,zh,sh,ck,x,h}
This would give unsatisfactory results by itself (Oockckoo doesn't sound very snake-like, now does it?)
So, the subcommand filters are applied:
Code:
VH => {ai,i,oo,au}
[f] => {a,ae,ai,e,ee,ei,i,ea}
VH[f] => {ai,i}
...
CF => {v,f,th,z,s,zh,sh,ck,x,h}
[u] => {c,ch,f,h,k,p,q,s,sh,t,th}
CF[u] => {f,th,s,sh,h}
This leaves us with the possibility of:
Code:
{ai,i} {v,f,th,z,s,zh,sh,ck,x,h} {f,th,s,sh,h} \s
This, alone, yeilds 100 unique names, similar in sound and structure to:
Aisths. However, you still get "ck" and "x" in the list, so this is where "Replace" filters come in.
Code:
NameGen lizardman
{
...
Replace ck>h,x>h
}
Will replace "ck" and "x" with h. It could also be done as "ck>x,x>h". However, ck>x>h is invalid at this time.
Replace filters can be placed globally inside the main section, or specific in the name category where it would be applied to. In the case of a "Space",
^s is used instead, and replaced with a space just before the name is leaves the script.
The two easiest methods to invoke the package are:
Code:
NG_NameGen( [UObject] )
NG_NameGenerator( [UObject] , [Name Group] )
NG_NameGenerator is the more complex script. This is the script that does the bulk of the work for NameGenerator.ECL, and can be called by itself to perform similar functionality; the main difference being that NG_NameGenerator returns a string for the name, whereas NameGenerator.ecl simply names the UObject that is passed to it by using:
Code:
include ":nameGen:nameGen";
This should be the only file you require, since it includes all other .INC files in the package.
The other command, NG_NameGen(), is just a convenient way to call the main script. You pass it the object you want renamed, and the name-group to use; and the object is automatically given the name to match. Included in the command is an error-check, and a log-to-file, should a problem arise. Other than that, it is identical to "Start_Script".
A seer-command is also included in the package,
.namegen [Name Group]. This command allows the seer to target an object, and give it a name abiding by [Name Group] algorythm.
I don't know how useful anyone else might find this, but I'm sure there's someone here who'd like to use it.
