Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Vanilla

Reply
 
Thread Tools Display Modes
Old September 27, 2017, 10:41   #301
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 4,143
Donated: $40
Pete Mack is on a distinguished road
Re: detecting traps.
Intuition suggests trap detection should be logarithmic with time and distance.
The cheapest way to do this is to do a trap check every turn, but reduce efficiency by 1/distance.
If you're within 1 or two squares of an awake monster, add 10 to the denominator: fleeing/fighting players should have a significant degradation for detection.
If you want to add a 'search' action, make it sneaky. Reduce movement by 2x, and add an extra trap check per move. At the same time, increase stealth by 6 (i.e 2x, when you factor in the slower movement). At the same time, make all 'wandering monsters' (i.e., spawned after dungeon creation( awake. This adds significant risk to just leaving search permanently enabled-- especially with the new pathfinding code.
Pete Mack is offline   Reply With Quote
Old September 27, 2017, 12:31   #302
Estie
Veteran
 
Join Date: Apr 2008
Location: Germany
Posts: 1,412
Estie is on a distinguished road
Quote:
Originally Posted by Pete Mack View Post
Re: detecting traps.
Intuition suggests trap detection should be logarithmic with time and distance.
The cheapest way to do this is to do a trap check every turn, but reduce efficiency by 1/distance.
If you're within 1 or two squares of an awake monster, add 10 to the denominator: fleeing/fighting players should have a significant degradation for detection.
If you want to add a 'search' action, make it sneaky. Reduce movement by 2x, and add an extra trap check per move. At the same time, increase stealth by 6 (i.e 2x, when you factor in the slower movement). At the same time, make all 'wandering monsters' (i.e., spawned after dungeon creation( awake. This adds significant risk to just leaving search permanently enabled-- especially with the new pathfinding code.
That doesnt solve the issue that you either want to search everywhere you go or nowhere. Dreembeard wanted to place traps in player-recognizable places before re-introducing search, more so than they already are.
Turning on search before every crossing and turning it off after you passed it doesnt sound like machanic that would improve the situation.

Last edited by Estie; September 27, 2017 at 12:35. Reason: typo´d Dreembeard´s name
Estie is offline   Reply With Quote
Old September 27, 2017, 15:39   #303
kandrc
Adept
 
Join Date: Dec 2007
Posts: 221
kandrc is on a distinguished road
@Sideways

No, the panther is not on rubble.

@PowerWyrm

Yes, I am targeting it correctly.

Code:
      #.#
      #<#
      #.#
      #.#
      #.+
      #f#
      #@#
      ###
kandrc is offline   Reply With Quote
Old September 27, 2017, 15:46   #304
dreembeard
Scout
 
dreembeard's Avatar
 
Join Date: Sep 2017
Location: Netherlands
Posts: 46
dreembeard is on a distinguished road
Quote:
Originally Posted by Estie View Post
(...) Dreembeard wanted to place traps in player-recognizable places before re-introducing search, more so than they already are. (...)
Right.
Estie's post - and that of Pete Mack who he replied to - made me realize that I criticized the ideas behind no-search trap perception in current vanilla, without saying much about the alternative that I have in mind for my own (very future) angband variant. Which differs from what Pete Mack proposed in the way pointed out by Estie, but is very similar in some other ways (eg, an 'S' command that boosts both perception and stealth, at the cost of speed). Another difference is that I envisioned search for and perception of traps to be limited to the character's current light radius (or to adjacent visible tiles if you have no light).
But I am reluctant to go into more detail in this thread, because that feels as off-topic: the details of what I have in mind for my own variant are something I'd really like other forummers to shoot at, and some details may well be relevant for vanilla, but it's not stuff that I propose for 4.1.x or even 4.x. So I'll open a separate thread for it (soon).

Pete also brought up player stealth (in connection to search).
Quote:
Originally Posted by Pete Mack View Post
(...) At the same time, increase stealth by 6 (i.e 2x, when you factor in the slower movement). At the same time, make all 'wandering monsters' (i.e., spawned after dungeon creation( awake.
Ah, yes. All those sleepy monsters! That is something I do consider an issue of 4.1.0. See my next post in this thread.
dreembeard is offline   Reply With Quote
Old September 27, 2017, 17:22   #305
dreembeard
Scout
 
dreembeard's Avatar
 
Join Date: Sep 2017
Location: Netherlands
Posts: 46
dreembeard is on a distinguished road
Lightbulb sleepy monsters in 4.1.0

I may be misperceiving things, but I have the impression that monsters in 4.1.0 wake up much more slowly than in previous versions. So much that it feels boring at times.
At first, I thought that it was due to my h-elf rogue having very good stealth. However, the same thing now happens with a h-troll paladin whose stealth is labelled as BAD. Yet he is able to approach a kobold shaman from far away and kill him in his sleep. That should not happen, I'd say.
I saw no complaints about this from other players yet, but I guess complaints usually come pouring in about where the game is too hard; not where it is too easy.
And I did notice some mumbling in Changes.txt about a new way of dealing with player stealth and monster wakeup. Could that explain my impression of excessive monster drowsiness?

A related issue is that of the sound asleep newcomers.
In previous versions, the frequent appearance of wide awake newcomers (that started to spawn immediately after you entered a level) often annoyed me. Especially in case of hounds showing up at the far end of a very large room with me half-way the center, while detection just before entering had revealed that there were none. So I 'm glad that this was changed.
However, finding all newcomers sound asleep (except for the always vigilant races) is the other extreme. How about the happy medium:
If monster race r has sleep counter S, then give individuals generated during level generation that value, but use 1dS - 1 for newcomers with S>0.
Or better still, something like 1d(S-K) - 1, where K is the number of kilo-gameturns you spent on the present level.

Another great idea (IMCO):
if the game thinks it's time for a new monster when the player happens to be close (<200 ft) to a stairway (but not on it), let the monster appear on the stairway now and then. Of course, in that case the newcomer is awake. Do let the player hear "something coming up/down a stairway" if it is not in LoS. Unless he is deaf (stunned?), or has low perception skill, of course.
That would give angbandians a better understanding of the concept of stairway. It's not there just for you, you know...
__________________
Two monsters to turn cavers into cadavers,
But only when together,
With the small one in front.

A hard one for poor Sméagol, who has never played angband.
dreembeard is offline   Reply With Quote
Old September 27, 2017, 21:56   #306
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 52
Posts: 6,563
Donated: $60
Nick is on a distinguished road
Quote:
Originally Posted by kandrc View Post
I've got a young @ mage with his back to the wall in a corridor and a panther pounding on him from the north. My frost bolts miss it, whether I target it explicitly or simply fire north; it's as if it isn't there. Any tips where I should set a breakpoint to debug this?
Frost bolts are handled through effect_handler_BOLT(), project_aimed() (effects.c), project() (project.c), project_m(), project_monster_handler_COLD(), project_monster_hurt_immune() (all project-mon.c).

I have no idea what's going on.
__________________
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them.
Nick is offline   Reply With Quote
Old September 28, 2017, 00:36   #307
Estie
Veteran
 
Join Date: Apr 2008
Location: Germany
Posts: 1,412
Estie is on a distinguished road
Quote:
Originally Posted by Nick View Post
Frost bolts are handled through effect_handler_BOLT(), project_aimed() (effects.c), project() (project.c), project_m(), project_monster_handler_COLD(), project_monster_hurt_immune() (all project-mon.c).

I have no idea what's going on.
I suspect either the panther or @ are standing on brush, or possibly in rubble that got created in the spot of a creature.

I had it happen to me once that some melee monster was walking around me and dint attack, exactly like Morgoth when your rune is active, and after killing it and making a move I saw that I was standing on : . This cant normally happen, so I suspect it must have been placed by a trap in my spot.
Estie is offline   Reply With Quote
Old September 28, 2017, 01:06   #308
kandrc
Adept
 
Join Date: Dec 2007
Posts: 221
kandrc is on a distinguished road
I've confirmed that neither the @ nor the f are on rubble. @ is, in fact, on down stairs. I've also observed frost bolts and magic missiles beam through and past f, without hitting it. Wands in @'s possession can't hit it, either (MM, TO, I forget what else). Pretty sure I haven't tried stinking cloud.

I'd already located and traced execution through project(). Didn't see anything there. The game is running on another machine that I don't have access to now, but I'll look into the other functions tomorrow.
kandrc is offline   Reply With Quote
Old September 28, 2017, 16:27   #309
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 4,143
Donated: $40
Pete Mack is on a distinguished road
More on traps: right now the trap detection is a simple state model: failed detection, unknown, or known. When it first comes into LOS it moves from unknown to one of the two other states. It moves from failed to known when you either trigger it or cast the mage detection spell.
Instead of the flag value for "failed", I propose turning it into an integer representing distance. You get another check at each nearer distance. That prevents the whole "searching" dilemma, while still rewarding players with bright light or who use rods of light. Further, make detection probability go down with distance. You can use 1/d (giving logarithmic behavior) or a sum of fractional powers, with a fixed upper limit on detection probability. ( E.g. 1+.5+.25+... <= 2.)
The other issue is that detection probability for certain classes (*cough* Paladin) is simply too low given the unavailability of a spell. It's no fun to be triggering essentially every single trap.
Pete Mack is offline   Reply With Quote
Old September 28, 2017, 16:33   #310
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 7,938
Derakon is on a distinguished road
Quote:
Originally Posted by Pete Mack View Post
More on traps: right now the trap detection is a simple state model: failed detection, unknown, or known. When it first comes into LOS it moves from unknown to one of the two other states. It moves from failed to known when you either trigger it or cast the mage detection spell.
If I understand it correctly (Nick, please correct as needed), there's already an analog value; if the trap has not been seen, then your search power is compared against the trap's "hiddenness" power or whatever, and if search power is greater, then the trap is permanently revealed. In other words, there's no "failed to detect" state, just traps that haven't been detected yet --
and won't be, unless you improve your search power somehow. Search power varies with race/class/equipment; I see no particular reason why it couldn't vary with light level and distance to trap as well.
Derakon is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Some Sil issues fph Sil 12 January 4, 2013 00:41
Gear Issues Monkay AAR 1 February 25, 2012 17:32
Compilation issues. Tiburon Silverflame Development 8 March 1, 2010 20:34
DaJAngband Issues Prismatic Variants 12 February 15, 2010 15:08
Compiling Issues Gregian Vanilla 13 July 2, 2008 14:35


All times are GMT +1. The time now is 00:55.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2017, vBulletin Solutions, Inc.