NPP-Moria and NPPAngband 7.0.0 Beta 2 uploaded

[nppangband]

NPPMoria 700 Beta-2 has been uploaded. This fixes multiple bugs with Beta-1. So far the biggest bug has been that the game crashed when attempting to start a new character based on a previous one. Unfortunately, part of that bug lingers in the savefiles from Beta-1, so the game will still crash if the previous character was created in Beta-1, but for characters started in Beta-2, that feature will work now. Character file dumps now show the game as Moria instead of Angband, and they can be uploaded at the .oook ladder.

The links are:

Souce Code:

http://download.nppangband.org/npp-7.0.0beta-2-src.zip

Windows Binary:

http://download.nppangband.org/npp-7.0.0beta-2-win.zip

Github respository:
https://github.com/nppangband/NPPAngband (work-in-progress branch)

[kaypy]

Various cloud type spells seem to have no effect at all. Even a pitiful beggar was able to laugh off a shard storm with no damage. At least I assume it would have laughed if it had woken up...

In spells1.c/project_x, do you really mean to explicitly deny all ball effects other than create traps?

	if (game_mode == GAME_NPPANGBAND)
	{
		/* Allow traps, but that's all */
		if (typ != GF_MAKE_TRAP) return FALSE;
	}

Or maybe you mean only traps in NPPMORIA?

---

Since number keys are interpreted as arrow keys in selection menus, item inscriptions become useless.

[nppangband]

Various cloud type spells seem to have no effect at all. Even a pitiful beggar was able to laugh off a shard storm with no damage. At least I assume it would have laughed if it had woken up...

In spells1.c/project_x, do you really mean to explicitly deny all ball effects other than create traps?

	if (game_mode == GAME_NPPANGBAND)
	{
		/* Allow traps, but that's all */
		if (typ != GF_MAKE_TRAP) return FALSE;
	}

Or maybe you mean only traps in NPPMORIA?

Good catch, thanks.

Since number keys are interpreted as arrow keys in selection menus, item inscriptions become useless.

This is an extremely frustrating bug. I am torn between getting rid of macros and having hotkeys instead, and fixing this code. I think the first option is easier.

Odd numbers work, though (non-directional keys).

[kaypy]

With most *bands I tend to wind up with something like AutoHotKey doing half the work anyway...

---

Is the use rate of lantern fuel right? Mine seemed to last an awfully long time...

Of course, I now have a phial, so barring my horrid demise, I won't know the difference for a while...

edit: Experimenting with a torch, it looks like there's a mechanism in place whereby fuel isnt used if the player is on a lit square. Which is presumably deliberate.

---

Ancestor ghosts are awfully chatty. It might be an idea to tone it down a bit. Ideally I might aim for:
* once on level start/load
* once when the ghost first starts tracking the player
* when the ghost enters LOS, provided they have been out of LOS for N turns (where N is a number that prevents them talking too much in the case of blinks or maneuvers)

More expediently, I swapped the one_in_(50) to one_in(1000) which should at least mostly shut em up for me 8-)

---

It would be really nice if the game would pick up the correct mode from the save file, or have a command line to preselect it, or something other than entering it in every time

---

The speed display issues as mentioned over here:

http://forum.nppangband.org/viewtopic.php?id=1523

are because you are using the calculated energy gain where you mean to use p_ptr->state.p_speed in xtra3.c/prt_speed

[nppangband]

Is the use rate of lantern fuel right? Mine seemed to last an awfully long time...

Of course, I now have a phial, so barring my horrid demise, I won't know the difference for a while...

edit: Experimenting with a torch, it looks like there's a mechanism in place whereby fuel isnt used if the player is on a lit square. Which is presumably deliberate.

Yes, that is it. I don't remember exactly when this feature was added, but now it seems strange that the adventurer would extinguish his lantern or torch every time they walk into a lit dungeon room. Maybe it should only happen in town. Putting out a torch makes sense when talking through a town in broad daylight.

Ancestor ghosts are awfully chatty. It might be an idea to tone it down a bit. Ideally I might aim for:
More expediently, I swapped the one_in_(50) to one_in(1000) which should at least mostly shut em up for me 8-)

I changed the frequency of the check from once every 100 game turns to once every 500 turns (plus the one-in-50 check). I had just wanted to give the player an occasional reminder that they are still there. But agreed it happened much too often.

It would be really nice if the game would pick up the correct mode from the save file, or have a command line to preselect it, or something other than entering it in every time

I know. This is possible, but it requires a major re-write of the game. My hackish way of reviving Moria is to have the two games share one binary. There are two sets of edit files, pref files, etc. The first thing the game does is load the edit files, so the game mode has to be specified before that happens.

I am holding off because part of me wants to write a whole new, modern front end for the game, in which case I can make it so it isn't an issue.

Or, I could always just compile two binaries, each with a slightly different line (game_mode == NPPMORIA or NPPANGBAND). Then the player just has to select which executable file they want to play.

The speed display issues as mentioned over here:

http://forum.nppangband.org/viewtopic.php?id=1523

are because you are using the calculated energy gain where you mean to use p_ptr->state.p_speed in xtra3.c/prt_speed

RL put an unexpected stop to NPP development about 3-4 weeks ago. I should start up again soon. In the meantime, your tracking down of a couple of these annoying bugs is a great help. Much obliged.

[Derakon]

Or, I could always just compile two binaries, each with a slightly different line (game_mode == NPPMORIA or NPPANGBAND). Then the player just has to select which executable file they want to play.

This is honestly what I was expecting. Hell, I thought you were just making a new variant outright, branching off from the current NPP. But I suppose that having it be basically a commandline compile switch makes it easier to keep NPPMoria up-to-date.

(But imagine what the main Angband codebase would be like if we did this for all variants...)

[nppangband]

Considering that 99+% of the code is identical between NPPMoria and NPPAngband, it makes things infinitely easier on me to have everything in the same binary, but eventually I do need to work out a way for the player to seamlessly pick one or the other. Right now it is an annoying distraction from the user experience.

[nppangband]

This is honestly what I was expecting. Hell, I thought you were just making a new variant outright, branching off from the current NPP. But I suppose that having it be basically a commandline compile switch makes it easier to keep NPPMoria up-to-date.

It isn't even a comandline compile switch right now. It is a global variable that the player picks from a startup menu, before the edit files are read.

[kaypy]

RL put an unexpected stop to NPP development about 3-4 weeks ago. I should start up again soon. In the meantime, your tracking down of a couple of these annoying bugs is a great help. Much obliged.

Anything I get really specific about means something I wound up patching in my local version. If you leave em long enough I'll get around to forking off github and sending proper pull requests...

edit: I see you already got to them

I now have a commandline switch on windows, but it breaks all other ports until they are set up to match. (It works by only running the selection menu if the game_mode is unset, but this requires initializing game_mode in the per-port code)

It's on my github, but I'm not sure about sending a pull for it, given the breakage...

edit2: OK, now have linux switches, and a dodgy workaround so things have a reasonable chance of working if game_mode is garbage.

[kaypy]

OK, this ones probably bad enough to double-post and bump the thread:

*identify* is now completely nonfunctional.

In the NPPMoria Beta-1 changes, in spells2.c/identify_fully, you removed

	/* Mark the item as fully known */
	o_ptr->ident |= (IDENT_MENTAL);

and only put in similar code in the moria branch of plain-old-identify...

edit:

Another possible biggie: Are stats supposed to fully max out at 18/100 in angband mode? The docs say 18/220...

<digs through code>

Spot what is wrong with this snippet from calcs.c/calc_bonuses

		/* Stats max out at 118 in Moria */
		if (game_mode == GAME_NPPANGBAND)
		{
			if (use > 117) use = 118;
		}

[nppangband]

OK, this ones probably bad enough to double-post and bump the thread:

*identify* is now completely nonfunctional.

In the NPPMoria Beta-1 changes, in spells2.c/identify_fully, you removed

	/* Mark the item as fully known */
	o_ptr->ident |= (IDENT_MENTAL);

and only put in similar code in the moria branch of plain-old-identify...

Definitely an accidental, careless deletion. Thanks.

Another possible biggie: Are stats supposed to fully max out at 18/100 in angband mode? The docs say 18/220...

<digs through code>

Spot what is wrong with this snippet from calcs.c/calc_bonuses

		/* Stats max out at 118 in Moria */
		if (game_mode == GAME_NPPANGBAND)
		{
			if (use > 117) use = 118;
		}

Wow, that's bad. Part of the reason I still enjoy coding is that it is a good humbling reminder how wrong I can be sometimes.

Notice this mistake occurrs twice.....a couple lines apart.

My apoloiges for the state of the codebase. I have never had RL slam me this hard right after uploading so many changes to the game.

[kaypy]

Maybe you should have put out a beta first 8-)

But more seriously, it compiles and its playable and I can fix things as I go. Sure it'd be nice if everything always worked first time, but then why have a beta?

(Although technically I'm now playing a slightly mutant gitfork rather than the beta)

--

This time I, uh, broke the experience system.

Drinking an !exp while drained resulted in having cured exp but an apparently still drained level. Neither a !RLL or a save-reload fixed it. When I get back to town I may try a !LoseMemory/!RLL cocktail. Sort of a hair-of-the-vampire-wolf thing.

Note to self- check the exact !LoseMemory code before doing something dumb.

...

OK, it seems that any level loss will trigger this, not just my wacky circumstances. p_ptr->max_level is getting set to 50 for some reason.

...

Got it. Fix should be on github, along with a somewhat hacky 'cure' for afflicted characters

--

Github is starting to include a bunch of my mutant tweaks, so you probably want to be choosy in what you import...

--

Another minor bug- stat modifiers weren't shown correctly on the character screen. A fix is on github.

--

Minor but annoying: after loading the game, it does not figure out that you have any inventory until after the first time you try to use something. Heading off to try to figure it out now...

...

It needs item_tester_swap = TRUE; to be set somewhere. I'm dumping it just after the game mode check for now.

--

Looking through monster2.c/calc_monster_speed:

A default monster has a base speed|energy of 110|10.
So having SLOWER or FASTER flags will modify the base speed by +- 10 (calc_energy_gain(r_ptr->r_speed))
So it could be as slow as 100|5 (half speed) or as fast as 120|20 (double speed)

Another example, a faster-by-default monster (120|20) could be +- 20 giving quarter speed (100|5) through to not quite double speed (140|38)

Is this desired?

Hmm. Also note that since rand_spread(a,b) is goes from a-b to a+b, both SLOWER and FASTER flags have exactly the same effect!

...

OK, I have a tweak on github that gives a simpler distribution:

FASTER gives +1 to +7, SLOWER the opposite, and normal critters get -2 to +2

So the examples above would give

110|10 -> 103|5 (50%) .. 117|17 (170%)
and
120|20 -> 113|13 (65%) .. 127|27 (135%)

Alternatively, if you wanted to keep things in proportion to the critters speed, then you could scale things by (|r_speed-110| + 10)/10

[nppangband]

Again, thanks. I poked around your branch and saw plenty of good stuff. Hopefully over the next couple days I can take your changes and add put out a beta-3 sometimes this week.

I think you have the start of the the game automatically choosing between nppmoria and npp when a savefile is loaded here:

https://github.com/kaypy/NPPAngband/commit/33c502e41d6eeec0ffcfdfaf7818825f92ce125f

If, before that, the game opened the savefile and read the first couple bytes, it could get the game mode from the savefile, and then maybe that menu could be bypassed.

[kaypy]

That's a good idea

*hack hack hack github*

--

Tested what I have in Linux & Windows. Should theoretically work on others I think

[nppangband]

Minor but annoying: after loading the game, it does not figure out that you have any inventory until after the first time you try to use something. Heading off to try to figure it out now...

...

It needs item_tester_swap = TRUE; to be set somewhere. I'm dumping it just after the game mode check for now.

Thanks for the fix! I think I will be raiding your npp fork when RL settles down.

Looking through monster2.c/calc_monster_speed:

A default monster has a base speed|energy of 110|10.
So having SLOWER or FASTER flags will modify the base speed by +- 10 (calc_energy_gain(r_ptr->r_speed))
So it could be as slow as 100|5 (half speed) or as fast as 120|20 (double speed)

Another example, a faster-by-default monster (120|20) could be +- 20 giving quarter speed (100|5) through to not quite double speed (140|38)

Is this desired?

Another great catch, thanks. The lines involving "calc_energy_gain"hould have '/10' in the formula, so the speed variance is small.

Hmm. Also note that since rand_spread(a,b) is goes from a-b to a+b, both SLOWER and FASTER flags have exactly the same effect!

Wow, it has been like that for years, and nobody noticed. I guess the gameplay effect is exactly the same, but it definitely does not work as intended.

Both those lines should be rand_range instead of rand_spread.