prf documentation

[tumbleweed]

Is there such a thing as a guide or comprehensive explanation somewhere on how to touch these files (in)appropriately or do I just have to stare at the prf files and the Angband source code real hard?

I feel like fiddling around with tiles, but adding rudimentary support for a new tile set seems like a metric fuckton of effort for relatively little effect, to the point where it's probably easier to copypaste new tiles into one of the existing sprite sheets.

[Nomad]

I feel like fiddling around with tiles, but adding rudimentary support for a new tile set seems like a metric fuckton of effort for relatively little effect, to the point where it's probably easier to copypaste new tiles into one of the existing sprite sheets.

That's basically how I made mine, to be honest...

What I figured out by poking about is that each tile set has three associated pref files. For my tile set, those are:

graf-nmd.prf
flvr-nmd.prf
xtra-nmd.prf

The "nmd" there stands for Nomad. The suffixes for the five current tile sets are:

xxx - the original tile set (8x8.png)
new - Adam Bolt's tiles (16x16.png)
nmd - Nomad's tiles (8x16.png)
dvg - David Gervais tiles (32x32.png)
shb - Shockbolt's tiles (64x64.png)

The simplest way to create and test a new tile set without having to monkey with the code is to choose one of those tile sizes, replace the existing png tile sheet in lib/xtra/graf/ with a new one of the same dimensions, and then alter the tile mappings in the associated set of pref files as appropriate. If/when you've got a complete tile set, you can then rename the files to something else and make all the code alterations to include it as an additional set instead of just replacing one of the existing ones. (Or, as I did, get some very nice person who actually knows what they're doing with the graphics code to do that bit for you.)

How the Pref Files Work

Most of the tile mappings are contained in the main "graf" prf file: dungeon features, non-flavoured objects, special effects for spells, and monsters. The "xtra" file contains special mappings for the player character (so you can have a different tile for every class/race combination) and "flvr" is for flavoured objects (so you can have different tiles for, say, diamond ring vs. emerald ring).

The tiles are, for reasons completely past my understanding, numbered in Y:X format from the top left, in hexadecimal starting at 0x80:0x80. i.e., if this is your tile set:

A1 A2 A3
B1 B2 B3
C1 C2 C3

0x80:0x80 is tile A1
0x80:0x81 is tile A2
0x81:0x80 is tile B1
0x82:0x82 is tile C3
etc.

The "flav" pref file for flavoured items is probably the easiest to understand at a glance. It's full of statements like this:

# Plain Gold ring
flavor:1:0x84:0x8A

# Alexandrite ring
flavor:2:0x84:0x84

So, essentially "use the tile at 0x84:0x8A for flavor 1 (Plain Gold ring)" and "use the tile at 0x84:0x84 for flavor 2 (Alexandrite ring)".

All of the statements in the pref files are basically minor variations on that same type:serial number:Y:X format. They're annotated with #comments to tell you what each serial number stands for, and in some cases use names rather than numbers anyway. (The format for standard non-flavoured objects, for instance, looks like: "object:light:Wooden Torch:0x89:0x80", which is pretty self-explanatory.)

A few tile types have slightly more complicated formats. For instance, with dungeon features there's the capability to assign different tiles depending on lighting level:

# open floor
feat:1:torch:0x80:0x84
feat:1:los:0x80:0x84
feat:1:lit:0x80:0x82
feat:1:dark:0x80:0x83

(Probably fairly easy to make sense of, but, anyway, the options available for tile lighting are "torch" - when lit by the player's torch, "los" - when in line of sight, "lit" when illuminated, "dark" when dark, or you can just use "all" if you want to use the same tile for that feature every time regardless of the lighting conditions.)

Spell effect assignments look like this:

GF:NETHER:0:0x98:0x94
GF:NETHER:135:0x98:0x97
GF:NETHER:45:0x98:0x96
GF:NETHER:90:0x98:0x95
GF:NETHER:static:0x99:0x95

The numbers 0, 135, 45 and 90 there are angles, corresponding to the ascii equivalent where a spell effect will look like | \ / or - depending on the direction it's shot in or * when it hits a target.

And finally, the player tiles in the "xtra" pref file have a bit of additional code to distinguish between the races and classes, but it's fairly easy to understand what means what:

?:[AND [EQU $CLASS Warrior] [EQU $RACE Human] ]
monster:<player>:0x9B:0x80
?:[AND [EQU $CLASS Warrior] [EQU $RACE Half-Elf] ]
monster:<player>:0x9B:0x81

TL;DR Summary

Each tile set has three pref files, graf, flvr & xtra, the three letter suffix tells you which tile set a given pref file belongs to, and tile coordinates are specified in Y:X format where the top left tile on the sheet is 0x80:0x80.

[AnonymousHero]

This is sort of off-topic and kind of hijacking, but as maintainer of a variant, I want to get it off my chest: I really wish the .prf could be removed -- the code to maintain this incredibly user-unfriendly stuff is absolutely ridiculous both in terms of LoC and complexity.

I tought I'd ask here because the T2 forums are all but dead: What are the .prf features that people actually use these days?

(It's fine to list "marginal" features, etc., but I'm really interested in the 80/20 type thing )

[tumbleweed]

<snip>

Thank you for the lengthy explanation, but that much was obvious from looking at the prf files and ui-prefs.c

What I am wondering about right now is:

1. Is there any kind of program at all that helps you pick tiles for the possible entries in the prf files, be it visually or otherwise?
2. Is there any way at all to simply specify default tiles for certain entities, eg "all dragons should use Generic Dragon A" and then just tell the game about the select few kinds of dragons you actually have a specialized tile for? As far as I can tell, I have to manually set Generic Dragon Tile A for every single possible dragon, which is... err... (same for traps etc)

This is sort of off-topic and kind of hijacking, but as maintainer of a variant, I want to get it off my chest: I really wish the .prf could be removed -- the code to maintain this incredibly user-unfriendly stuff is absolutely ridiculous both in terms of LoC and complexity.

No kidding, I just wanted to teach Angband how to use (parts of) a VERY simple generic roguelike tile set for shits and giggles, and... <expletives>

[Nomad]

What I am wondering about right now is:

1. Is there any kind of program at all that helps you pick tiles for the possible entries in the prf files, be it visually or otherwise?
2. Is there any way at all to simply specify default tiles for certain entities, eg "all dragons should use Generic Dragon A" and then just tell the game about the select few kinds of dragons you actually have a specialized tile for? As far as I can tell, I have to manually set Generic Dragon Tile A for every single possible dragon, which is... err... (same for traps etc)

1. Somebody created a tile picker program in this thread, but that was a while back, so I don't know if it will still work.

2. Nope. Manual setting of individual tiles all the way, I'm afraid. (That said, you don't need to have all tiles assigned for the game to work - the game will just substitute the correct ASCII for any that are missing. So you can literally delete the entire contents of the pref files and only assign tiles to a small handful of features and the game will still run quite happily, just with a mix of tiles and ASCII.)

Tile support has not really been a priority over the years, as you can probably tell...

But hey, at least the pref files don't still look like they did when I was making my tile set, giant uncommented, undocumented blocks of numbers like this:

S:0x30:0x91:0x88
S:0x31:0x91:0x89
S:0x32:0x91:0x8A
S:0x33:0x91:0x8B
S:0x34:0x91:0x8C
S:0x35:0x91:0x8D

Good times!

[Nick]

This is sort of off-topic and kind of hijacking, but as maintainer of a variant, I want to get it off my chest: I really wish the .prf could be removed -- the code to maintain this incredibly user-unfriendly stuff is absolutely ridiculous both in terms of LoC and complexity.

I tought I'd ask here because the T2 forums are all but dead: What are the .prf features that people actually use these days?

(It's fine to list "marginal" features, etc., but I'm really interested in the 80/20 type thing )

You are, of course, completely right, but actually doing something about it takes time, and is not currently my highest priority. Before I hijack this thread any more, I'm going to start a new one and open a can of worms I (mostly) prepared earlier.

[nppangband]

This is sort of off-topic and kind of hijacking, but as maintainer of a variant, I want to get it off my chest: I really wish the .prf could be removed -- the code to maintain this incredibly user-unfriendly stuff is absolutely ridiculous both in terms of LoC and complexity.

I tought I'd ask here because the T2 forums are all but dead: What are the .prf features that people actually use these days?

(It's fine to list "marginal" features, etc., but I'm really interested in the 80/20 type thing )

The soon-to-be-finished NPPQT port does away with pref files completely.

I think a couple of them are essential for handling keystrokes on different ports, as well as having the alternate rogue like keyset.

As for all of the tile coordinates, I think they would work much better as a part of the edit files. Each monster/object could have a line with the coordinates for the tile on each of the tilesets. To have the tile coordinates in a completely different folder in a completely different format was always a pain. (Not to mention keeping them in hex format with 128 added to the row and column of the actual coordinates).

[tumbleweed]

1. Somebody created a tile picker program in this thread, but that was a while back, so I don't know if it will still work.

Still kind of works after some hackfixing to make it behave with my browser.

I see there's also some kind of tile picker in the knowledge base that looks somewhat useful, I'll give that one a prod first (after restoring all the lines I commented out from the my graf prf file).

From a first glance however it looks like the built-in tile picker has issues with flavored items...

Still, it seems like the built-in picker and the Great Axe of Reg are going to be the weapons of choice for now.

Y'know, in my naive mind I was hoping I'd be able to do something like this:

trap:*:*:0x8B:0x80
trap:16:*:0x8B:0x81
trap:17:*:0x8B:0x82
object:food:*:0x90:0x80
object:food:Pint of Fine Wine:0x90:0x81
object:food:Flask of Whisky:0x90:0x81
object:sword:*:0x8F:0x80
object:sword:Dagger:0x8F:0x81
object:sword:Main Gauche:0x8F:0x81
object:sword:Zweihander:0x8F:0x82
object:sword:Executioner's Sword:0x8F:0x82

(or "all" or whatever other wildcard character/expression you like)

At least object names are less opaque than that silly trap numbering game. Heh.

[Nick]

Y'know, in my naive mind I was hoping I'd be able to do something like this:

trap:*:*:0x8B:0x80
trap:16:*:0x8B:0x81
trap:17:*:0x8B:0x82
object:food:*:0x90:0x80
object:food:Pint of Fine Wine:0x90:0x81
object:food:Flask of Whisky:0x90:0x81
object:sword:*:0x8F:0x80
object:sword:Dagger:0x8F:0x81
object:sword:Main Gauche:0x8F:0x81
object:sword:Zweihander:0x8F:0x82
object:sword:Executioner's Sword:0x8F:0x82

(or "all" or whatever other wildcard character/expression you like)

At least object names are less opaque than that silly trap numbering game. Heh.

Looks like you want to add to my list

[tumbleweed]

Looks like you want to add to my list

Oho.

Well, I haven't looked closely enough at the source to be able to tell whether the kind of wildcard support (or hierarchical tile assignment) I was looking for is even feasible or makes sense from a programming point of view.

[AnonymousHero]

The soon-to-be-finished NPPQT port does away with pref files completely.

I think a couple of them are essential for handling keystrokes on different ports, as well as having the alternate rogue like keyset.

Yes, I've noticed the keystroke bits when trying to convert T2 to Qt... that can hopefully be avoided by just having a cross-platform toolkit (Qt).

(@Nick: Yes, I didn't expect this would magically have been addressed during The Refactor. It's one of the nastiest bits of code ever (at least on old-Angband, which T2 is based on)).

[Nomad]

Oho.

Well, I haven't looked closely enough at the source to be able to tell whether the kind of wildcard support (or hierarchical tile assignment) I was looking for is even feasible or makes sense from a programming point of view.

Something similar actually seems to be being done with the player tile already: looking at the pref files, there's an entry for a 'default' player tile in graf-xxx.prf:

monster:<player>:0x8C:0x80

Which is overridden by the mappings in xtra-xxx.prf - delete the code for a given race/class combo from that file, and you'll see the specified default player tile instead. So something similar may be possible to implement for other types of tiles if you can see how that's done.

Objects seem fairly well set up for hierarchical assignments already, if you could add code to handle assigning a tile to a major category like "object:sword" that's overwritten by subcategories like "object:sword:Rapier".

Monsters are a completely different kettle of fish, though, since they're just one long list in depth order - but now we have monster base types, perhaps it's feasible to rewrite things to use "base" for monsters the same way we use "type" for objects? So instead of the current state of:

monster:Filthy street urchin:0xB1:0x94
monster:Scrawny cat:0xA5:0x96
monster:Scruffy little dog:0xA1:0x92
monster:Farmer Maggot:0xA7:0x8C
monster:Blubbering idiot:0xB1:0x96

You'd have a subcategorised list like:

monster:canine:Scruffy little dog:0xA1:0x92

monster:feline:Scrawny cat:0xA5:0x96

monster:humanoid:Farmer Maggot:0xA7:0x8C

monster:townsfolk:Filthy street urchin:0xB1:0x94
monster:townsfolk:Blubbering idiot:0xB1:0x96

...Honestly, that seems like a worthwhile change just for the sake of logical categorisation and neatness even if hierarchical tile assignment isn't introduced. The current situation of a list of over 500 individual entries sorted by a value that's only mentioned in the separate monster.txt edit file is not exactly ideal.

[tumbleweed]

<SNIP>
...Honestly, that seems like a worthwhile change just for the sake of logical categorisation and neatness even if hierarchical tile assignment isn't introduced. The current situation of a list of over 500 individual entries sorted by a value that's only mentioned in the separate monster.txt edit file is not exactly ideal.

Or consider the following:

monster:<canine>:0x8F:0xC8
monster:Scruffy little dog:0x8F:0xC9

It's also rather insane that all these tile mappings are basically a big cluster of fuck spread across a mere three files per tile set, when the infrastructure is perfectly prepared for subdirectories and as many files as you feel like creating. Heck, you could even create separate prf files for each monster template.

[Timo Pietilä]

actually use[/B] these days?

Class-specific keymaps and fonts&colors changes.

I would do without latter if the UI for tweaking those were even close to useful, but unfortunately it isn't. Keymaps prf, however, I really need. I have crapton of different keymaps which are different for each class, and I change spell-sets when I find related spellbook by uncommenting and commenting lines from those prf-files. Way way faster than game UI.

[Carnivean]

Something similar actually seems to be being done with the player tile already: looking at the pref files, there's an entry for a 'default' player tile in graf-xxx.prf:

monster:<player>:0x8C:0x80

Which is overridden by the mappings in xtra-xxx.prf - delete the code for a given race/class combo from that file, and you'll see the specified default player tile instead. So something similar may be possible to implement for other types of tiles if you can see how that's done.

Objects seem fairly well set up for hierarchical assignments already, if you could add code to handle assigning a tile to a major category like "object:sword" that's overwritten by subcategories like "object:sword:Rapier".

Monsters are a completely different kettle of fish, though, since they're just one long list in depth order - but now we have monster base types, perhaps it's feasible to rewrite things to use "base" for monsters the same way we use "type" for objects? So instead of the current state of:

monster:Filthy street urchin:0xB1:0x94
monster:Scrawny cat:0xA5:0x96
monster:Scruffy little dog:0xA1:0x92
monster:Farmer Maggot:0xA7:0x8C
monster:Blubbering idiot:0xB1:0x96

You'd have a subcategorised list like:

monster:canine:Scruffy little dog:0xA1:0x92

monster:feline:Scrawny cat:0xA5:0x96

monster:humanoid:Farmer Maggot:0xA7:0x8C

monster:townsfolk:Filthy street urchin:0xB1:0x94
monster:townsfolk:Blubbering idiot:0xB1:0x96

...Honestly, that seems like a worthwhile change just for the sake of logical categorisation and neatness even if hierarchical tile assignment isn't introduced. The current situation of a list of over 500 individual entries sorted by a value that's only mentioned in the separate monster.txt edit file is not exactly ideal.

Just do this, but separate out the tiles into individual files. Shockbolt doesn't like the big image file format, finding stuff in the big file is horrid, and if you want to replace a single image you risk breaking it.