[Announce] Poschengband 3.0.0 Released

[chris]

A beta version is available for Windows and Souce Code.

Please be kind as I made some rather aggressive and risky changes ... hopefully I've found all of the crashes.

What has changed?

* The wilderness is now continuously explorable. As you move about, the wilderness will "scroll". I also added a few scripted encounters. In general, the wilderness is more difficult than before, so be careful!

* Ego items have been massively overhauled, particularly for rings and amulets. Lots of new stuff here! (I've liberally borrowed ideas from other variants including the latest Hengband, Angband and TinyAngband.)

* Dungeon generation has been massively overhauled with the addition of 165 new types of rooms! (Rooms can be added to v_info.txt rather than created in source code. New submissions would be welcome! But don't look in v_info.txt unless you want the game to be "spoiled" ...)

* I added a new command to list nearby monsters ('['). This is useful if you play on a small screen like I do.

[HugoVirtuoso]

I just tested the new 3.0.0 beta... I must say that the *new* wilderness changes are very interesting. I just started up a new Possessor (Hugo$oul 341) and the mere attempt of getting a single Green naga was tricky. Soon after, a mysterious vault suddenly appeared on the wilderness map...*interesting*.

Of note, version 3.0.0 beta never crashed on me, but has some bugs (if not features).

Version 3.0.0 bug(s) found [these might even be features]:
1) Known pseudo-IDed {cursed} items can be sold at stores despite being cursed. Bug or intentional?
*Edit* I figured it out - This depends on severity of negative modifiers....

2) Auto-destroyer doesn't auto-destroy IDed and Pseudo-IDed {cursed} ARMOR/WEAPONS. For obvious {cursed} potions and junk items...these get auto-destroyed as usual. NOTE - I'm playing a melee-based Possessor
*Edit* - I figured it out...the auto-destroy kicks in when the weapon/armor is IDed and auto-destruction depends on how bad the negative modifiers are.

3) The *Destroy known worthless items* option is not working 100% as it should....when I attempt to destroy a known {cursed} WEAPON/ARMOR the game prompts, yes/no...it's supposed to destroy without the extra prompt. NOTE - I'm playing a Melee-based Possessor
*Edit* - Apparently, the easy-destroy depends on the severity of the negative modifiers.

4) Possessors gain XP much faster now...Is this new?


My suggestions for version 3.0.0 onwards
1) When vaults appear in the wilderness, they should contain items that are AT LEAST {good} or better and/or have somewhat challenging monsters. Example if the wilderness vault spawns near Outpost, it should generate along with a few Swordsmen, for example.
2) The Wilderness should have LATE GAME high-level monsters to inhabit the wilderness in SPECIFIC regions, period! After characters reach a certain high-level, you know...character level 40, they're basically unstoppable in the wilderness, and the wilderness just becomes dull after that.... So, there should be plenty of Star-Spawns of the C near R'lyeh, Great Wyrms of Power near Mt. Olympus, Iron Liches near the Graveyard, Great Storm Wyrms near the Dragon's lair, and so on. There should be a certain niche of monsters to inhabit certain regions. With a GWoP guarding Mt. Olympus, good luck attempt to scum it!!

[getter77]

Congrats on landing the big release so soon!

[chris]

I did some interesting things with cursed items. In general, just because an object is cursed does not mean you won't want to use it. You probably should identify cursed items if you can. (And conversely, just because an object isn't cursed doesn't mean you will want to use it ... You'll see!)

Possessors gain XP at the same rate as before, but the wilderness no longer penalizes player experience. You probably just became used to the old nerfed XP ... Really, I'm puzzled that you've leveled up in the old wilderness

My suggestions for version 3.0.0 onwards
1) When vaults appear in the wilderness, they should contain items that are AT LEAST {good} or better and/or have somewhat challenging monsters. Example if the wilderness vault spawns near Outpost, it should generate along with a few Swordsmen, for example.
2) The Wilderness should have LATE GAME high-level monsters to inhabit the wilderness in SPECIFIC regions, period! After characters reach a certain high-level, you know...character level 40, they're basically unstoppable in the wilderness, and the wilderness just becomes dull after that.... So, there should be plenty of Star-Spawns of the C near R'lyeh, Great Wyrms of Power near Mt. Olympus, Iron Liches near the Graveyard, Great Storm Wyrms near the Dragon's lair, and so on. There should be a certain niche of monsters to inhabit certain regions. With a GWoP guarding Mt. Olympus, good luck attempt to scum it!!

Wilderness encounters aren't vaults. They're just interesting (or boring) encounters that you run into from time to time, like stumbling upon ruins or finding a Hermit's House. I'll design more encounters in the future but ran out of development steam for the time being (thus the release!). I spent *alot* more time designing new dungeon features than I put into the wilderness, but I am by no means finished with either.

I like the idea of more difficult wilderness monsters and dungeon guardians. Perhaps as you approach a dungeon entrance, monsters from that dungeon should leak out to get you! (e.g. dragons near the dragon's lair, undead near the graveyard, etc.)

[Arjen]

I like the idea of more difficult wilderness monsters and dungeon guardians. Perhaps as you approach a dungeon entrance, monsters from that dungeon should leak out to get you! (e.g. dragons near the dragon's lair, undead near the graveyard, etc.)

Great release Chris, when I've time I'll give it a shot. About the dungeon monsters leaking out, with the new layout in mind, give them a maxium radius around said dungeon. So you won't have problems with those long range Spectral Wyrms/Cyberdemons killing you in town just because you were walking around in them.

[clouded]

Looks cool, I'll make some new rooms when the mood takes me. I've hit a major bug with the new inventory size however, playing in gcu mode the game crashes when it tries to display an inventory with 24 or more items. Default terminal size is 80x24, but even with a larger term the main window will always be 80x24 (and the rest taken up by subwindows).

[chris]

Looks cool, I'll make some new rooms when the mood takes me. I've hit a major bug with the new inventory size however, playing in gcu mode the game crashes when it tries to display an inventory with 24 or more items. Default terminal size is 80x24, but even with a larger term the main window will always be 80x24 (and the rest taken up by subwindows).

Good catch. Is there any reason the terminal size has to be 80x24 in this day and age? Personally, I find Angband unplayable in these dimensions

I fixed main-gcu.c to force 80x27. Ideally, the user could set the desired size of the map area but I wasn't feeling that ambitious.

Also, I fixed the code to bounds check (show_inven in object1.c) but its possible there are other places in the code that should add bounds checking. Ideally, the terminal code would check but it doesn't.

Finally, I fixed the Windows resizing to not go below 27 rows. Hmm ... perhaps other Linux ports will need this as well?

Fixes are in code only at the moment. If you are running Windows, don't resize your window below 27 rows or you will blow up! I'll push a new executable later once a bunch of bugs have queued up.

[clouded]

Is there any reason the terminal size has to be 80x24 in this day and age?

Well, I suppose this is a little cutural thing. Though when 'x'ing a big stack of items you can scroll it with enter, would it be difficult to do the same for inventory?

Anyway, a few other things: lite town and vanilla town both seem to have problems, lite crashes randomly and vanilla crashes after character creation.

I've started making some rooms but there seems to be a problem, we've ran out of space in v_info! Or so it seems? When I just added mine to the end the game complained about 'out of memory' something or other. If I delete a bunch of vaults I can test mine fine. I see there is a limit to rooms in /lib/edit/misc.txt but changing it doesn't seem to help.

Is there a reason why this shape would cause level disconnections frequently? It seems half the time it generates the corridors leading to it just dead end into the sides of it.

M:%%%%%%%%%%%%%%%%
M:%..............%
M:%..............%
M:##............##
M: ###........### 
M:   ###....###   
M:     ##..##     
M:   ###....###   
M: ###........### 
M:##............##
M:%..............%
M:%..............%
M:%%%%%%%%%%%%%%%%

I think room frequency should be lowered a little, I'm a little wary of too much reliance on premade (and especially non-randomised) content. I think about 6 per full sized floor is plenty. Though is it just me or are lesser vaults really rare in poscheng? They seem rarer than greater vaults even.

[Nick]

Is there a reason why this shape would cause level disconnections frequently? It seems half the time it generates the corridors leading to it just dead end into the sides of it.

M:%%%%%%%%%%%%%%%%
M:%..............%
M:%..............%
M:##............##
M: ###........### 
M:   ###....###   
M:     ##..##     
M:   ###....###   
M: ###........### 
M:##............##
M:%..............%
M:%..............%
M:%%%%%%%%%%%%%%%%

I believe the tunneling code requires %s around the edge to make doorways.

There is actually some really nice info here, courtesy of Leon Marrick and Bahman Rabii - the vault stuff is in the V_INFO.TXT section.

[chris]

Though when 'x'ing a big stack of items you can scroll it with enter, would it be difficult to do the same for inventory?

Yes. Take a look at how the source implements this and you will see why (target_set_aux in xtra2.c around line 3795). Basically, items on the floor are in a linked list. When you press enter, the code removes the first item from the list and adds it to the tail of the list. Display code is hard coded to display the first 23 items (show_floor in object1.c around line 3286).

Making assumptions about display size was probably OK in the 1970's and 1980's but is now extremely poor practice. Ideally, all code would query the display size at run time and offer facilities for handling more choices than can be fit on the screen. Making design decisions (Pack size is 23 because displays at the time where 24 lines) is idiotic beyond words.

I could come up with cleaner display code I guess, but it's a rather low priority for me at the moment. The current code is a mess ...

Anyway, a few other things: lite town and vanilla town both seem to have problems, lite crashes randomly and vanilla crashes after character creation.

Fixed.

We've ran out of space in v_info! Or so it seems? When I just added mine to the end the game complained about 'out of memory' something or other.

I'll look into this. The initialization code uses a fixed size string buffer for all the various ?_info.txt files. The size chosen is just a guess for the biggest possible amount of string space required.

[clouded]

Here are some rooms. Anyone can of course use and modify however they see fit.

[chris]

Here are some rooms. Anyone can of course use and modify however they see fit.

Awesome ... Do you mind if I incorporate these into the next release?

Were you aware of the DEBUG attribute during design? Basically, if you add this attribute (3rd field on the T line) it forces the room picker to pick that choice every time. For example:

N:575:Small Connected Rooms 6
T:ROOM:NORMAL:DEBUG
W:1:*:1
L:0:MON(*, 5)
M:%%%%%      
M:%..0%      
M:%0..%  %%%%
M:%%%+%%%%..%
M:  %..0.+.0%
M:  %0...%%%%
M:  %%+#%%   
M:   %..%    
M:   %.0%    
M:   %%%%

Of course, you then need to remove the DEBUG attribute when finished.

[half]

I really like the modifications to the vault syntax, and have enjoyed looking through clouded's room file. I've added a lot of his previous rooms to the next version of Sil and might add even more from here. I might also borrow some ideas from the new syntax. I had already realised I could have flags to (among other things) allow selected vaults to be rotated. I also want to have some ways of setting symbols to represent different ranges of items and monsters on a vault by vault basis like this does and like crawl does. I'm not sure what syntax to use though, and this is unlikely to make it into the next Sil release.

I'm also glad to see you got rid of those ridiculous height/width numbers that always cause parse errors! I did that recently too. It was about 5 easy lines of code and it should always have been like that.

[Nick]

I really like the modifications to the vault syntax, and have enjoyed looking through clouded's room file. I've added a lot of his previous rooms to the next version of Sil and might add even more from here. I might also borrow some ideas from the new syntax. I had already realised I could have flags to (among other things) allow selected vaults to be rotated. I also want to have some ways of setting symbols to represent different ranges of items and monsters on a vault by vault basis like this does and like crawl does. I'm not sure what syntax to use though, and this is unlikely to make it into the next Sil release.

I've been messing privately with vault encoding to try and get V vaults and room templates and FA vaults all interchangeable; FA already has the ability to add particular item and monster types to vaults, and V room templates have an item parameter. I like the idea of rotation, too. Maybe we should try to coordinate so all these are interchangeable?

I'm also glad to see you got rid of those ridiculous height/width numbers that always cause parse errors! I did that recently too. It was about 5 easy lines of code and it should always have been like that.

*facepalm*

Good job guys, will copy

[half]

Good job guys, will copy

I do it with the following changes to parse_v_info():

	/* Process 'X' for "Extra info" (one line only) */
	else if (buf[0] == 'X')
	{
		int typ, depth, rarity;
		
		/* There better be a current v_ptr */
		if (!v_ptr) return (PARSE_ERROR_MISSING_RECORD_HEADER);
        
		/* Scan for the values */
		if (3 != sscanf(buf+2, "%d:%d:%d", &typ, &depth, &rarity)) return (PARSE_ERROR_GENERIC);
        
		/* Save the values */
		v_ptr->typ = typ;
		v_ptr->depth = depth;
		v_ptr->rarity = rarity;
		v_ptr->hgt = 0;
		v_ptr->wid = 0;
	}

	/* Process 'D' for "Description" */
	else if (buf[0] == 'D')
	{
        
		/* There better be a current v_ptr */
		if (!v_ptr) return (PARSE_ERROR_MISSING_RECORD_HEADER);

		/* Get the text */
		s = buf+2;

        if (v_ptr->wid == 0)
        {
            v_ptr->wid = strlen(buf+2);
        }
        else if (v_ptr->wid != strlen(buf+2))
        {
            return (PARSE_ERROR_VAULT_NOT_RECTANGULAR);
        }
            
            
		/* Store the text */
		if (!add_text(&v_ptr->text, head, s))
			return (PARSE_ERROR_OUT_OF_MEMORY);

		// note if there is a forge in the vault
		if (strchr(buf, '0')) v_ptr->forge = TRUE;
        
        // we've added another row of the vault
        v_ptr->hgt++;
        
        /* Check for maximum vault sizes */
		if ((v_ptr->typ == 6) && ((v_ptr->wid > 33) || (v_ptr->hgt > 22)))
			return (PARSE_ERROR_VAULT_TOO_BIG);
        
		if ((v_ptr->typ == 7) && ((v_ptr->wid > 33) || (v_ptr->hgt > 22)))
			return (PARSE_ERROR_VAULT_TOO_BIG);
        
		if ((v_ptr->typ == 8) && ((v_ptr->wid > 66) || (v_ptr->hgt > 44)))
			return (PARSE_ERROR_VAULT_TOO_BIG);
	}

I can't remember exactly what it looked like before this change, but you can probably work out the diff yourself. As an extra bonus, differing length D: lines cause a parse error instead of trashing the dungeon layout and having to be spotted in debug testing. That said, with the DEBUG attribute that would get easier!