FAangband 0.3.6

[Pete Mack]

I have no idea about Dev-C++. In Visual Studio, see:

http://msdn.microsoft.com/en-us/library/350dyxd0.aspx

(I don't know why Visual Studio Express isn't the default non-gcc MS compile. You are almost crazy not to use it.)

For gdb, see (for example):

http://sources.redhat.com/gdb/current/onlinedocs/gdb_6.html#SEC35

OS X works the same way. If you are using XCode rather than gdb directly, use the gdb control panel.

[PaulBlay]

(I don't know why Visual Studio Express isn't the default non-gcc MS compile. You are almost crazy not to use it.)

Yeah, I suppose I'd better try and tangle with it again. I just seem to have spent a lot of time getting stuff to work with different compilers over the years.

[Nick]

Without knowing a thing about it, I will make a wild guess that it is related to generating two ghosts on the same level.

I think I have worked it out (although I haven't had a chance to check back in the code yet). The adjustments for race and class that I mentioned actually overwrite the values in the r_info array (as Pete warned against in another thread). This might still be fine, but they are not reversed when that ghost disappears (either by being killed or the player just leaving the level), so effects like HP inflation are cumulative.

If this is the case, saving and reloading should reset the values to what they should be.

The way I plan to fix this is to put a special entry in monster.txt (and thence into r_info) which can is completely overwritten by the selected ghost template, then race/class modified, whenever a ghost is generated. Then the actual ghost just needs to be pointed at that entry instead of the template. What have I missed?

[Pete Mack]

Overwriting nominally "const" templates in r_info will almost certainly break things. You can fix this by either having some non-const slots in r_info as you propose, or by using flag values, like -1, -2, ..., or like 100001, 100002, ..., to reference indexes in a non-const auxiliary r_info. Your proposal is preferred here, because it means that your use of "non-const-ness" is limited to one place (initializing a new ghost), rather than spread all over the code.

EDIT: (In Object-oriented programming, the second model is generally preferred, because the array(s) would be wrapped in getter/setter functions, and the monster indexes would be opaque.)

[Nick]

I think I have worked it out (although I haven't had a chance to check back in the code yet). The adjustments for race and class that I mentioned actually overwrite the values in the r_info array (as Pete warned against in another thread). This might still be fine, but they are not reversed when that ghost disappears (either by being killed or the player just leaving the level), so effects like HP inflation are cumulative.

If this is the case, saving and reloading should reset the values to what they should be.

Confirmed. I went back to the file where I'd generated one earlier, and the same one loaded as I'd said. Stairscummed until another one appeared based on the same bone file, and the mana and AC had increased. Quit and restarted; back to normal.

[jevansau]

Firstly, thanks for a great fun variant.

There does seem to be something a little suspect about shop valuations though.
The Magestaff of Aliman (1d3) (+14,+8) [4,+0] (+3 to stealth)
It increases your stealth and speed by 3, It makes you vulnerable to darkness(5%). It provides permanent light and speeds your regenerative powers. ...

is unsaleable.
It was never cursed or anything.
Is the minor vulnerability considered that major a negative? or does any negative render a randart unsaleable.

Thanks,
Jonathan

[Nick]

Is the minor vulnerability considered that major a negative?

It shouldn't be, but it is. I put code in to stop shops selling things like rings of resist cold with vulnerability, and this is an unintended consequence. I am planning a more unified (read sensible) system of item valuation net version. Thanks for the report.

[Psi]

Going back to the Anf58 debate. There are three issues here:

1. Dungeon generation
2. Autoscum
3. Stair scumming

The only thing that actually changed in 036 was that the autoscummer will now accept a larger number of the levels generated. The same levels would have been generated in 035 (and before) as we are seeing currently, but artifacts made such a small difference to the level feeling that many of the levels containing them would have been rejected by the autoscummer.

The easiest way to fix this particular issue is probably to give an implicit base rating to levels containing a dungeon entrance (of around dlvl/2 say). This could easily be added at the point the staircase is generated.

This obviously won't solve the problem of stairscumming or the root issue here of AR15, TD29, SV38 and Anf58 being special cases, but it should prevent Anf58 being comparitively such a gold mine compared to its surrounding levels when the autoscummer is used.

[Nick]

The easiest way to fix this particular issue is probably to give an implicit base rating to levels containing a dungeon entrance (of around dlvl/2 say). This could easily be added at the point the staircase is generated.

I like this, and I think your base rating sounds about right. It also removes the necessity for me to do immediate surgery on the autoscummer I don't know what to do longer term about autoscum - it is a big hack, but I guess people are used to it now. One solution is the one I mentioned earlier of generating monsters and objects to a target minimum difficulty rather than just generating stuff and seeing what happens, but I'm sure there are others. I suspect it needs to sit for a bit.

This obviously won't solve the problem of stairscumming or the root issue here of AR15, TD29, SV38 and Anf58 being special cases, but it should prevent Anf58 being comparitively such a gold mine compared to its surrounding levels when the autoscummer is used.

The special cases don't bother me - after all, they are special cases because they have dungeon entrances. The stairscumming does bother me a little, but if we solve the artifact explosion problem (and I think you just have), actually not much. Thralls were always supposed to be a kind of fringe activity, but they're such fun to play and there's the instant gratification ... it's like one-day cricket all over again ...

[PowerDiver]

Going back to the Anf58 debate. There are three issues here:

1. Dungeon generation
2. Autoscum
3. Stair scumming

I really don't understand stair scumming wilderness with disconnected stairs. If you want to go for "realism", then practically every single square at the edge of a non-mountainous wilderness area should be a step to the next. Once you ignore that, you might as well treat level changes precisely the same in the wilderness as in the dungeon.

Suppose you want to keep the current system and reduce stairscumming. I think that nothing should be generated on path squares or adjacent. Presumably most people take the paths, and any items have been picked up or traps set off etc. Or, perhaps better perhaps worse, the path squares should be generated at level 0 [or maybe dLvl - 20], and sqares can increase in level as they get away from the paths. Then if you want to find good and/or dangerous, you have to leave the paths, unless the danger hears and comes to you.

[PaulBlay]

Then if you want to find good and/or dangerous, you have to leave the paths, unless the danger hears and comes to you.

Smart, and aggressive, monsters would lay in ambush near the path. Smart monsters would hide far away

[Psi]

Smart, and aggressive, monsters would lay in ambush near the path. Smart monsters would hide far away

I considered implementing a change, so that wilderness monsters would try and avoid stepping on the paths. However I didn't get that done for 036.

[Seany C]

I Thralls were always supposed to be a kind of fringe activity, but they're such fun to play and there's the instant gratification ... it's like one-day cricket all over again ...

Heh, no wonder I feel more comfortable with the long game - I've always thought that only Tests are Proper Cricket. Mind you, now I'm getting paranoid that Psi, Evariste and Cave Man are going to be poached by the roguelike version of the IPL (lucrative contract offer from Dwarf Fortress?)...

[buzzkill]

One could always go with the Z+ style 'one big wilderness'. I prefer it over FA's 'single level wilderness'.

[Nick]

I really don't understand stair scumming wilderness with disconnected stairs. If you want to go for "realism", then practically every single square at the edge of a non-mountainous wilderness area should be a step to the next.

I did consider that as a possibility early on, along with the idea of having the whole area available not just various routes through. I may actually revisit that at some point. This is then a bit like the 'one big wilderness' idea of Z and it's children; one thing I didn't want was the travelling on the overworld map. The intention is for wilderness to be more fully integrated into the main game.

Once you ignore that, you might as well treat level changes precisely the same in the wilderness as in the dungeon.

There is a difference, in that your position on the edge of the wilderness as you leave currently matters. So if you are planning to leave your current level to the west, and then the next one to the south, getting as far south as possible on your current level will put you closer to where you want to exit the next one. But it could certainly be randomised a bit to give disconnected paths.

Suppose you want to keep the current system and reduce stairscumming. I think that nothing should be generated on path squares or adjacent. Presumably most people take the paths, and any items have been picked up or traps set off etc. Or, perhaps better perhaps worse, the path squares should be generated at level 0 [or maybe dLvl - 20], and sqares can increase in level as they get away from the paths. Then if you want to find good and/or dangerous, you have to leave the paths, unless the danger hears and comes to you.

This is a nice idea (or ideas). It would make the issue of how to represent objects in trees and rubble a bit more pressing - should the map show the terrain, or the object, or some third thing? And always indicate objects, or only when known about (seen drop or detected), or only when detected?

As for monsters being on or off the path, I guess it would depend on the monster and the situation (duh). Damn logic - always making things complicated.