User:FIQ/DevTeam - Revision history

FIQ: DevTeam does not consider SYMBOLS oddities a bug

2019-10-25T22:31:36Z

DevTeam does not consider SYMBOLS oddities a bug

FIQ: Add previous mail asking if there is a good reason as to why curses force menus to be half-width, add DT responsiveness info for mails (maybe make mails public?)

2019-10-23T14:59:46Z

Add previous mail asking if there is a good reason as to why curses force menus to be half-width, add DT responsiveness info for mails (maybe make mails public?)

FIQ: proposed fix to SYMBOLS not working with curses implicit symset loading

2019-10-23T14:51:35Z

proposed fix to SYMBOLS not working with curses implicit symset loading

FIQ: clarify what year this article starts logging reports for

2019-10-14T11:41:40Z

clarify what year this article starts logging reports for

FIQ: proposed fix for better handling of cursesgraphics

2019-10-14T11:40:42Z

proposed fix for better handling of cursesgraphics

FIQ: DECgraphics in the curses windowport

2019-10-12T14:53:22Z

DECgraphics in the curses windowport

Phol ende wodan: /* Bugs reported by others */ New bug report

2018-08-11T14:52:04Z

‎Bugs reported by others: New bug report

Phol ende wodan: /* Bugs reported by others */ new report

2018-04-20T22:34:34Z

‎Bugs reported by others: new report

FIQ: Passive aggression and Elbereth

2018-03-19T19:45:23Z

Passive aggression and Elbereth

Phol ende wodan: /* Bugs reported by others */ New report

2018-03-15T14:19:47Z

‎Bugs reported by others: New report

@@ Line 49: / Line 49: @@
 (Sent 2019-10-18 00:55 UTC)
-Status: Replied, implied WONTFIX.
+Status: Replied. Implied WONTFIX.
 Hi!
@@ Line 78: / Line 78: @@
 (Sent 2019-10-23 14:51 UTC)
-Status: No reply yet.
+Status: Replied. WONTFIX.
 Hi.

@@ Line 3: / Line 3: @@
 == Sent via mail ==
 === Rogue starting inventory -- "+9" lockpicks ===
-(Sent 2017-08-27 22:19 UTC, fixed in 06d211f75c76a69dcb29e5c5a7c2c10f63cc7d4d)
+(Sent 2017-08-27 22:19 UTC)
 Hi.
@@ Line 11: / Line 13: @@
 === Wand of teleportation quirks in muse ===
-(Sent 2017-08-30 15:58 UTC, fixed in 8d1e0d17565ca7567cd6c75565a3e5c6e87f8db1)
+(Sent 2017-08-30 15:58 UTC)
 Hi.
@@ Line 22: / Line 26: @@
 === Own issues on the dev bugtracker ===
 (Sent 2017-09-24 01:52 UTC)
 Hi.
@@ Line 30: / Line 36: @@
 === Cursesgraphics as a proper symbol set ===
 (Sent 2019-10-14 09:18 UTC)
 Hi!
@@ Line 35: / Line 43: @@
 I could make another patch with such a fix.
 /FIQ
@@ Line 40: / Line 77: @@
 === regarding user-defined SYMBOLS ===
 (Sent 2019-10-23 14:51 UTC)
 Hi.

← Older revision		Revision as of 14:51, 23 October 2019
Line 35:		Line 35:

	I could make another patch with such a fix.		I could make another patch with such a fix.
		+
		+	/FIQ
		+
		+	=== regarding user-defined SYMBOLS ===
		+	(Sent 2019-10-23 14:51 UTC)
		+
		+	Hi.
		+	It was pointed out to me on IRC that the new Curses symset
		+	handling overrides SYMBOLS when it loads the curses symset
		+	as fallback. I also saw a reddit thread about this (which
		+	you seem to have replied to, actually). Would it be
		+	worthwhile to add a parameter to load_symset to still
		+	respect user-defined symbols, or would that be too
		+	invasive? That would allow windowports that want to change
		+	the symset default to still respect SYMBOLS in case the
		+	user changed it but didn't change the underlying symset?
		+
		+	Alternatively, create a new function whose purpose is to
		+	load user-defined symbols only and use it as post-processing
		+	after loading the options file (to also allow the player to
		+	define SYMBOLS before OPTIONS=symset without problems),
		+	reading from a saved user-defined symset loaded in memory.
		+	Basically, have a 3rd symset index (USERSET or something)
		+	that saves the SYMBOLS and just overrides PRIMARY after
		+	loading the options.

	/FIQ		/FIQ

← Older revision		Revision as of 11:41, 14 October 2019
Line 1:		Line 1:
−	Below is a list of messages sent to the DevTeam for anyone interested, starting from August 28th. Most, but not all, concern [[bugs in NetHack 3.6.0]].	+	Below is a list of messages sent to the DevTeam for anyone interested, starting from August 28th 2017. Most, but not all, concern [[bugs in NetHack 3.6.0]].

	== Sent via mail ==		== Sent via mail ==

@@ Line 25: / Line 25: @@
 Hi.
 It would be very nice if it was possible for someone to see a list of their own bug reports to the bugtracker, possibly authored by email. This would allow me to later reference my own reports to you without having to remember to save the report. For example, in my last report (potion handling in thitu), I accidentally backed out in my browser, making me unable to gather the bug ID and other relevant info for future reference. Another dev helpfully gave me the bug ID, but not having to do this would be great.
 /FIQ

@@ Line 853: / Line 853: @@
   ../nh/install/games/nethack --version
 Unix NetHack Beta Version 3.6.1-0 - last build Mon Mar 19 20:35:42 2018.
 /FIQ

← Older revision		Revision as of 14:52, 11 August 2018
Line 1,084:		Line 1,084:

	The intent seems to be that you can move into the adjacent pit without having to climb out of the first one, and this works properly - the only problem is that the pit gets triggered when you ought to have no distance to fall.		The intent seems to be that you can move into the adjacent pit without having to climb out of the first one, and this works properly - the only problem is that the pit gets triggered when you ought to have no distance to fall.
		+
		+	=== Panic when selection floodfilling large areas ===
		+
		+	Below is what you submitted to The_DevTeam on Saturday, August 11, 2018 at 10:49:05
		+
		+	The ID number for this message is '#H7352'
		+
		+	Subject:
		+	panic when selection floodfilling large areas
		+
		+	oldver:
		+	(please select version)
		+
		+	gitver:
		+	469fb27e2fc78a5f206d67974a9c2c92abbf0775 (latest)
		+
		+	nhfrom:
		+	Our git repository - please list branch and ref below
		+
		+	hardware:
		+	x86_64 laptop
		+
		+	software:
		+	latest 3.6.2-dev
		+
		+	comments:
		+	The panic("floodfill stack overrun") in selection_floodfill is being triggered when the floodfill area encompasses most of the level, even though the function is intended to support a full-level floodfill. To reproduce, add FLAGS:inaccessibles to the Bar-fila level which will trigger a floodfill from the stairs. Bar-fila is just a big open rectangle so it's ideal for making this happen, though it would probably also work in the Big Room too.
		+
		+	This is caused by points being added to the stack multiple times, which on a mostly open level will of course exceed ROWNO * COLNO. The way the function is organized, it refuses to add a point to the stack if it already exists in the /selection/ - but it doesn't check whether it's already in the stack.
		+
		+	Possible fixes are either adding that check for whether a point exists in the stack, or maybe just moving the "add to selection" code into SEL_FLOOD.
		+
		+	(And if anyone could tell me why there's a do... while(0) loop in there with no other control statements besides an if/else inside it, that'd be great.)

← Older revision		Revision as of 22:34, 20 April 2018
Line 1,059:		Line 1,059:

	The exact mechanism of what causes the "Click!" and the trap to be set off isn't made clear, but the fact that flying monsters are immune implies that it's a ground-based trap.		The exact mechanism of what causes the "Click!" and the trap to be set off isn't made clear, but the fact that flying monsters are immune implies that it's a ground-based trap.
		+
		+	=== Pit trap damage when moving between adjacent pits ===
		+
		+	Below is what you submitted to The_DevTeam on Friday, April 20, 2018 at 18:11:46
		+
		+	The ID number for this message is '#H7074'
		+
		+	Subject:
		+	Pit trap damage is triggered whem moving from pit to pit
		+
		+	gitver:
		+	01abfa8c3dfa5eb4da7275266ac49f7fdd057062
		+
		+	nhfrom:
		+	Our git repository - please list branch and ref below
		+
		+	hardware:
		+
		+	software:
		+	01abfa8c3dfa5eb4da7275266ac49f7fdd057062
		+
		+	comments:
		+	When moving from a pit into an adjacent pit, you "fall into" the pit and take damage. This happens even when you are walking back and forth between two pits, repeatedly, where you should have no way to fall.
		+
		+	The intent seems to be that you can move into the adjacent pit without having to climb out of the first one, and this works properly - the only problem is that the pit gets triggered when you ought to have no distance to fall.

@@ Line 819: / Line 819: @@
 and vice versa for some kind of strange animal. Not exactly
 a critical bug, just figured I'd suggest it.
 /FIQ

← Older revision		Revision as of 14:19, 15 March 2018
Line 999:		Line 999:

	(Note that the monster is in fact opening and stepping onto the door square; this can be confirmed by the presence of "The monster opens a door" message, and quaffing uncursed monster detection immediately afterwards will show the monster on the door. This might be a vision bug rather than a monmove bug - the message shouldn't display unless the monster passes a canspotmon() check.)		(Note that the monster is in fact opening and stepping onto the door square; this can be confirmed by the presence of "The monster opens a door" message, and quaffing uncursed monster detection immediately afterwards will show the monster on the door. This might be a vision bug rather than a monmove bug - the message shouldn't display unless the monster passes a canspotmon() check.)
		+
		+	=== Flying monsters are immune to boulder traps, flying players aren't ===
		+
		+	Below is what you submitted to The_DevTeam on Thursday, March 15, 2018 at 10:17:10
		+
		+	The ID number for this message is '#H6963'
		+
		+	Subject:
		+	Flying monsters are immune to boulder traps, flying players aren't
		+
		+	oldver:
		+	3.6.1
		+
		+	gitver:
		+	c28b44c27c7adb2f48bab495f12e81229f57a062
		+
		+	nhfrom:
		+	Our git repository - please list branch and ref below
		+
		+	software:
		+	c28b44c27c7adb2f48bab495f12e81229f57a062
		+
		+	comments:
		+	Rolling boulder traps behave inconsistently between monsters and players; specifically, a levitating or flying player will trigger the trap but a flying monster won't. (A monster that levitates but doesn't fly will in fact trigger the trap; however, I think the code assumes that all floaters have M1_FLY.)
		+
		+	The exact mechanism of what causes the "Click!" and the trap to be set off isn't made clear, but the fact that flying monsters are immune implies that it's a ground-based trap.