[Announce] Poschengband 3.3.0 Released

[HugoVirtuoso]

Another suggestion:
Add a specia large wilderness room type that generates an anti-melee or anti-magic field and fill the room with high level ego-crushing monsters.

I'd like to see the player ghosts/spirits being implemented. Also, add body-possessing monsters. You see a Legendary soul (dlvl 90) possessing an Ultimate magus...RUN FOR LIFE!!

[chris]

Upon reflection, I decided to release a quick update as 3.3.6 here. This is a minor release with a few bug fixes:

* Fixed bug with Ring of Archery quest reward. This was a show stopper game crash bug, so is the reason for this release!

* Nazgul egos are now only available from Nazguls. They are more powerful as well.

* Nazgul monsters are scary.

* Berserkers no longer auto-identify objects since they cannot read or use magical devices.

* 0d0 possessor attacks now do no damage at all. Display code updated to reflect this.

* Possessors get a new "Corpses" category in the monster knowledge menu (~4). This enumerates all corpses currently in pack, home or underfoot for easy comparison. Knowledge of a body's attributes can now be gained by *identifying* the corpse (in addition to probing or monster lore in the town).

* Monster knowledge now sorts descending on level.

* Possessors and Mimic's now track history of forms used and display these in the character dump.

As usual, source code and a list of changes are available.

[Nivim]

*Nivim presses 5 for implementation of upstairs in the wilderness.*

I think documentation tried to happen at the beginning of the file, but didn't get all the way; there's stuff like S apparently making black markets some kinda confusing reassignment with arguments going. Also, the entire file is really long and maybe has never really been organized; does the numbering thing prevent rearranging vaults in the list completely?

[HugoVirtuoso]

Arrrgh...Now, I have to create a new Hugo$oul for 3.3.6!!!

[debo]

Arrrgh...Now, I have to create a new Hugo$oul for 3.3.6!!!

I'm not sure that creating new Hugo$ouls has really been a problem for you as of late

[debo]

*Nivim presses 5 for implementation of upstairs in the wilderness.*

I think documentation tried to happen at the beginning of the file, but didn't get all the way; there's stuff like S apparently making black markets some kinda confusing reassignment with arguments going. Also, the entire file is really long and maybe has never really been organized; does the numbering thing prevent rearranging vaults in the list completely?

I actually had a local branch where I was rewriting a bunch of poscheng documentation and then ran out of everything RIP

[Nivim]

I might take the haphazard collection of text at the beginning of v_info, make a reference/credits of the apparent previous sources, then just rewrite it. I mean-- if I'm going to be figuring stuff out anyway...

[chris]

I have found that it is best to ignore code comments and edit file documentation. It's generally woefully out of date and even wrong in some instances. Most of it was written nearly 20 years ago anyway.

The best documentation at the moment is the source code. If you can read C, start with parse_v_info in init1.c (on my line 1648). This will give you a top down view of the format. For a bottom up view, start further up at _summon_specific_types in init1.c (on my line 1160 ... I don't think your line numbers will be different).

N:Index:Name
Sequence numbers *should* be automatically generated for this file. However, at the moment, you need to pick unused numbers by hand, and the order must be strictly increasing, but gaps are allowed. This is the N: line. By the way, the name on the N: line is only used while debugging, or perhaps with cheat_rooms.

T:Type:Subtype[:Flags]
Next is the T: line, which gives the type of the room template. The type may be VAULT (subtype LESSER or GREATER), ROOM (subtype NORMAL), WILD or AMBUSH (subtype is the terrain type: WATER, GRASS, SWAMP, TREES, LAVA, MOUNTAIN). Room flags may be any combination (combined with |) of GOOD (only generates good monsters), EVIL, FRIENDLY, NIGHT, DAY, NO_ROTATE (rooms are randomly rotated during generation, but sometimes you don't want this), FORMATION (this is special for monster groups ... look at examples), and DEBUG.

W:Level:MaxLevel:Rarity
This is allocation information, level restrictions and how often to choose this type of room. Should be obvious what the fields mean. You can use * for MaxLevel if you don't want any restrictions.

L:.:FLOOR(ROOM|ICKY):MON(DRAGON, 20):EGO(*)
Next are as many custom "letters" as you need to design your room in the map lines (below). Many "letters" are setup automatically elsewhere in pref files. Others are hard coded someplace, I believe. At the moment, you can add up to 10 additional custom letters. The format for each letter is as follows. Order is only important for the first field. Remaining fields use keywords to determine the type.

[1] The character to use in the map for this letter.

[2] Feature info. Example: FLOOR(ROOM | ICKY | GLOW) or GRANITE. Supported flags are ROOM, ICKY, GLOW, MARK (with their usual in game meanings). Supported features are determined in f_info.txt, I believe.

[3] Monster info. Examples:
MON(DRAGON, 20): Any dragon, 20 levels OoD
MON(*, 40): Any monster, 40 levels OoD
MON(ORC | NO_GROUP | HASTED): A hasted orc loner at current depth
MON(441 | CLONED): A Gachapin Clone
MON(442): A Black Knight

There is a ton of flexibility here. Best to view the source code to see what is available.

[4] Trap info. Example: TRAP(TRAP_OPEN, 25). The second arg is a probability.

[5] Object info. Examples:
OBJ(*): Any object
OBJ(*, 7): Any object, 7 levels OoD
OBJ(242): Potion of Healing
OBJ(POTION): Any potion
OBJ(RING):EGO(306): Ring of Speed
OBJ(RING):EGO(*): Any ego ring
OBJ(CLOAK, 20):EGO(*): Any ego cloak generated 20 levels OoD
OBJ(RING, 50):EGO(306): Ring of Speed generated 50 level OoD

Again, this format is very flexible and constantly evolving. See code for details.

Finally, add the map lines. These are simply M: followed by ASCII text using letters defined above, or built in letters.

Oh, and case always matters for the pref file parser.

Edit: If you are curious where the room templates are actually used in dungeon generation, it is in build_room_template_aux() in rooms.c (line 1916). There you will see the hard coded letters that are available. At some point, I'd like to move these into the pref files.

Edit: This is already out of date. See this instead.

[chris]

Room Templates (Continued) - Monster Formations

These are designed to replace the hard coded nest and pit rooms of yore. For example, this replicates the old code exactly (but is *much* more rare then before):

N:441:Monster Pit I
T:ROOM:NORMAL:FORMATION
W:20:*:100
L:0:MON(*, 5)
M:%%%%%%%%%%%%%%%%%%%%%%%%%
M:%.......................%
M:%.#####################.%
M:%.#7777777777777777777#.%
M:%.#7665544322234455667#.%
M:%.+7665544310134455667#.%
M:%.#7665544322234455667#.%
M:%.#7777777777777777777#.%
M:%.#####################.%
M:%.......................%
M:%%%%%%%%%%%%%%%%%%%%%%%%%

When using the FORMATION flag, you need only specify "letter" 0 for the type of formation you desire. Using the random wildcard * means the code will choose a formation type the way it used to (Orc Pit, Troll Pit, Graveyard, etc). But you could invoke, say, a formation of knights with a L:0:MON(KNIGHT) directive.

With the formation, you get "letter" 0 through 9 to refer to the placement of monsters in the formation. 0 is the most powerful monster and 9 the least, so arrangement should reflect this. Basically, the code picks 10 monsters that meet the type of formation and sorts them by level (descending). You don't need to use all letters, of course, and there may be duplicates in the sequence 0 .. 9 depending on the number of kinds of available qualifying monsters.

The old nests were ubiquitous in Hengband (there was even code to limit them to 2 per level since they were so common!) and also a bit repetitive. But now, there should be lots of variety, including smaller versions with more varied shapes:

N:447:ASC II
T:ROOM:NORMAL:FORMATION
W:20:*:50
L:0:MON(*, 3)
M: #%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%# 
M:%#5#4#4#3#2#2#1#0#0#1#2#2#3#4#4#5#%
M:%5#5#4#3#3#2#1#1#0#1#1#2#3#3#4#5#5%
M:#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#%#

N:494:Fortress III
T:ROOM:NORMAL:FORMATION | NO_ROTATE
W:30:*:50
L:0:MON(*, 10)
L:$:OBJ(*, 5)
M:%%%%%%%%%%%%%%%%%%%%%
M:%...................%
M:%......###+###......%
M:%....#+#66666#+#....%
M:%....#$#44444#$#....%
M:%.########+########.%
M:%.#9876#42224#6789#.%
M:%.+9876+42024+6789+.%
M:%.#9876#42224#6789#.%
M:%.########+########.%
M:%....#$#44444#$#....%
M:%....#+#66666#+#....%
M:%......###+###......%
M:%...................%
M:%%%%%%%%%%%%%%%%%%%%%

[chris]

Room Templates (continued) - Wilderness Encounters and Ambushes

Wilderness Encounters are specified with the WILD room type. The subtype indicates which terrain they should be used for and, in general, you should try to design something that is thematically appropriate (e.g having a lava field with demons might be OK for MOUNTAIN subtypes, but not for WATER). Wilderness encounters are generated randomly as the player moves about in the normal wilderness mode.

Example:

N:153:Thieve's Hideout
T:WILD:GRASS:FORMATION
W:1:*:16
L:.:DIRT(ROOM)
L:0:DIRT(ROOM):MON(THIEF, 5):OBJ(GOLD)
L:$:DIRT(ROOM):OBJ(GOLD)
M:###########################
M:#$.212...#.......#...212.$#
M:#$21012..+.......+..21012$#
M:#$.212..9#.......#9..212.$#
M:##########.......##########
M:#8.......................8#
M:#8.......................8#
M:#8.......................8#
M:#8...777...........777...8#
M:#############+#############

Ambushes (specified with the AMBUSH type), on the other hand, occur randomly when the player is using the wilderness travel mode. The player will be placed as indicated by the @ letter. Generally, the player is surrounded and in trouble. I like to use the FORMATION flag for these as it makes more sense to be ambushed by a group of like monsters than a swarm of random ones. I should mention that not every ambush will pick one of the scripted ambush types from v_info.txt. Sometimes, you do just get dropped into a crowded wilderness tile with lots of extra wide awake random monsters.

Example:

N:158:Dread of Night
T:AMBUSH:GRASS:FORMATION|NIGHT
W:1:*:1
L:0:MON(UNDEAD, 5)
M:      6   8   6  
M:                 
M:   0   8  @  8  0
M:                 
M:      6   8   6

This last example shows two things. First, using the NIGHT flag limits this encounter to nighttime. Second, by not specifying any terrain info, the encounter layers on top of the already generated terrain. This is in sharp contrast to dungeon based rooms which *must* specify terrain for every tile. In general, the wilderness encounters will look better if you don't specify terrain, unless it is thematically part of your encounter.

[debo]

Room Templates (continued) - Wilderness Encounters and Ambushes

Wilderness Encounters are specified with the WILD room type. The subtype indicates which terrain they should be used for and, in general, you should try to design something that is thematically appropriate (e.g having a lava field with demons might be OK for MOUNTAIN subtypes, but not for WATER). Wilderness encounters are generated randomly as the player moves about in the normal wilderness mode.

Example:

N:153:Thieve's Hideout
T:WILD:GRASS:FORMATION
W:1:*:16
L:.:DIRT(ROOM)
L:0:DIRT(ROOM):MON(THIEF, 5):OBJ(GOLD)
L:$:DIRT(ROOM):OBJ(GOLD)
M:###########################
M:#$.212...#.......#...212.$#
M:#$21012..+.......+..21012$#
M:#$.212..9#.......#9..212.$#
M:##########.......##########
M:#8.......................8#
M:#8.......................8#
M:#8.......................8#
M:#8...777...........777...8#
M:#############+#############

Ambushes (specified with the AMBUSH type), on the other hand, occur randomly when the player is using the wilderness travel mode. The player will be placed as indicated by the @ letter. Generally, the player is surrounded and in trouble. I like to use the FORMATION flag for these as it makes more sense to be ambushed by a group of like monsters than a swarm of random ones. I should mention that not every ambush will pick one of the scripted ambush types from v_info.txt. Sometimes, you do just get dropped into a crowded wilderness tile with lots of extra wide awake random monsters.

Example:

N:158:Dread of Night
T:AMBUSH:GRASS:FORMATION|NIGHT
W:1:*:1
L:0:MON(UNDEAD, 5)
M:      6   8   6  
M:                 
M:   0   8  @  8  0
M:                 
M:      6   8   6

This last example shows two things. First, using the NIGHT flag limits this encounter to nighttime. Second, by not specifying any terrain info, the encounter layers on top of the already generated terrain. This is in sharp contrast to dungeon based rooms which *must* specify terrain for every tile. In general, the wilderness encounters will look better if you don't specify terrain, unless it is thematically part of your encounter.

I am totally making a wilderness Huorn ambush!!!!!!

[HugoVirtuoso]

Is there a way to specify a minimum level for monsters in those encounters? I have ideas...

[chris]

Is there a way to specify a minimum level for monsters in those encounters? I have ideas...

Minimum level? No. But you can boost the Out of Depth factor as high as you like. What are your ideas? Perhaps I can add support for min depth in the MON() specifier.

[HugoVirtuoso]

I'm thinking of making a wilderness encounter with monsters with dlvl of at least 50...e.g. an Elder storm giant hiding near Dragon's lair entrance ...

[chris]

I'm thinking of making a wilderness encounter with monsters with dlvl of at least 50...e.g. an Elder storm giant hiding near Dragon's lair entrance ...

Well, you can always hard code which monster to use. For an Elder Storm Giant, use its identifier from r_info.txt: MON(1128).