Help me make my new variant! (please!)

[will_asher]

...Those errors eventually stayed gone, so I'm assuming they're nothing to worry about.
EDIT:...and those error messages are back.

Another question: Why are the newer vaults not allowed in the classic mode of dungeon generation?

[Nick]

Another question: Why are the newer vaults not allowed in the classic mode of dungeon generation?

IIRC it was because some of the new vaults did not connect nicely with the classic generation algorithm, or at least I suspected they might not. backwardsEric has done quite a bit of work recently on connectivity of vaults, so it's likely that this is not a problem any more.

[Julian]

Today when I opened up Visual Studio to work on RubberBand, it gave me a ton of errors saying "pointer to incomplete class type is not allowed". These errors weren't there yesterday. I hadn't changed anything before those errors appeared and it seems to build and run just fine. Does anyone know why it might suddenly give me all these errors that weren't there when I closed VS yesterday?

EDIT: So I went on working on Rubberband ignoring the errors for now, and after a while they disappeared for no discernable reason. weird.
EDIT: ...and then they reappeared. wth?

I don’t use Visual Studio, but that sounds like a C++ error, so it may be getting confused about the nature of your project.

[will_asher]

Good to know.

[will_asher]

(This isn't really a coding question, but whatever)
IIRC, in 3.4.1 if you were targeting (say) a pile of rubble, you could press 'r' to recall a description for rubble, but that isn't working in the current version. Why was that removed? (I want it so people can easily see descriptions for the new terrain I'm adding)

[Nick]

(This isn't really a coding question, but whatever)
IIRC, in 3.4.1 if you were targeting (say) a pile of rubble, you could press 'r' to recall a description for rubble, but that isn't working in the current version. Why was that removed? (I want it so people can easily see descriptions for the new terrain I'm adding)

I can't see any reference to this in the code for 3.3 or 3.4 - it seems you could only do this for objects, same as now.

[will_asher]

I can't see any reference to this in the code for 3.3 or 3.4 - it seems you could only do this for objects, same as now.

Oh. I guess I'm remembering wrong. Maybe I can add it in anyway...
(Maybe I did that for DaJAngband and that's what I'm remembering.)

[will_asher]

I've been finding a unusually high number of (waaaaay OOD) rods of drain life and restoration in my last several games of Rubberband alpha.
I'm coming to suspect it has to do with me changing the max_obj_depth in constants.txt from 100 to 110 (as I'm doing several things in an attempt to make the levels past dL100 a little more interesting). Quickly going through object.txt revealed that the rods of drain life and restoration were the only objects that I had set their maximum allocation level at 110.

I can easily go through object.txt to fix the maximum allocation levels of objects to 110 instead of 100, but I'd like to figure out why the generation level of objects is being set to maximum this often.
I guess it might just be because of this weird (as noted) calculation in get_obj_num followed by the enforcing of the min and max levels, which makes me wonder why we're using this calculation at all if it gets set to maximum as often as it does?

	/* Occasional level boost */
	if ((level > 0) && one_in_(z_info->great_obj))
		/* What a bizarre calculation (max_obj_depth was 100, now 110) */
		level = 1 + (level * z_info->max_obj_depth / randint1(z_info->max_obj_depth));

	/* Paranoia */
	level = MIN(level, z_info->max_obj_depth);
	level = MAX(level, 0);

[backwardsEric]

I've been finding a unusually high number of (waaaaay OOD) rods of drain life and restoration in my last several games of Rubberband alpha.
I'm coming to suspect it has to do with me changing the max_obj_depth in constants.txt from 100 to 110 (as I'm doing several things in an attempt to make the levels past dL100 a little more interesting). Quickly going through object.txt revealed that the rods of drain life and restoration were the only objects that I had set their maximum allocation level at 110.

I can easily go through object.txt to fix the maximum allocation levels of objects to 110 instead of 100, but I'd like to figure out why the generation level of objects is being set to maximum this often.

With that configuration, any attempt to make an object that set level to be more than 100 would only have generated one of those rods or an artifact since all other objects were excluded for levels greater than 100. Besides the level boost you quoted in get_obj_num() (roughly a 50% chance, after passing that 1/20 test, for at least a factor of 2 gain; 1/40 objects targeting level 50 would end up being generated at level 101 to 110 instead; 1/2200 targeting level 1 would end up being generated at level 110), there's a boost of +10 if the object is good in make_object(), +3 to +20 for some items placed in vaults, and +10 for items placed in pits or nests.

[Julian]

I've been finding a unusually high number of (waaaaay OOD) rods of drain life and restoration in my last several games of Rubberband alpha.
I'm coming to suspect it has to do with me changing the max_obj_depth in constants.txt from 100 to 110 (as I'm doing several things in an attempt to make the levels past dL100 a little more interesting). Quickly going through object.txt revealed that the rods of drain life and restoration were the only objects that I had set their maximum allocation level at 110.

I can easily go through object.txt to fix the maximum allocation levels of objects to 110 instead of 100, but I'd like to figure out why the generation level of objects is being set to maximum this often.
I guess it might just be because of this weird (as noted) calculation in get_obj_num followed by the enforcing of the min and max levels, which makes me wonder why we're using this calculation at all if it gets set to maximum as often as it does?

	/* Occasional level boost */
	if ((level > 0) && one_in_(z_info->great_obj))
		/* What a bizarre calculation (max_obj_depth was 100, now 110) */
		level = 1 + (level * z_info->max_obj_depth / randint1(z_info->max_obj_depth));

	/* Paranoia */
	level = MIN(level, z_info->max_obj_depth);
	level = MAX(level, 0);

I can’t speak to the mechanics of object allocation because, like so many things in Angband, it’s complex and I haven’t looked at it at all recently, but that calculation isn’t going to max out all that often at low levels, and increasing max_obj_depth makes it less likely.

It’ll be equal or greater to max_obj_depth whenever the random roll is equal to or greater than the current level.

[Pete Mack]

That would definitely increase odds. Arod of speed (depth 95), it only has a 6 percent chance at dl 1 of even being possible for an OOD roll. In your variant, it has a 16/110 = 15% chance. So yeah, you will see more deep objects at shallow depths.

[will_asher]

I think I'll have to change the way object levels are boosted then.

[will_asher]

I'm looking at the code and having trouble figuring out exactly how lashes work. I just noticed that it chooses the type of lash before scanning through the blows with this line:
type = mon->race->blow[0].effect->lash_type;

How does it know which blow to take the lash type from?
Does blow[0] mean it always takes the type from the 1st blow?

I would think a SPIT ranged attack should take its type from a SPIT melee blow.
I'm adding a gaze innate 'spell' (short ranged like spit), and I want it to take its type from the GAZE melee blow, but I'm not sure how.

[Nick]

I'm looking at the code and having trouble figuring out exactly how lashes work. I just noticed that it chooses the type of lash before scanning through the blows with this line:
type = mon->race->blow[0].effect->lash_type;

How does it know which blow to take the lash type from?
Does blow[0] mean it always takes the type from the 1st blow?

I would think a SPIT ranged attack should take its type from a SPIT melee blow.
I'm adding a gaze innate 'spell' (short ranged like spit), and I want it to take its type from the GAZE melee blow, but I'm not sure how.

This is a bit confusing - I'll try to explain clearly. Blows consist of effect, method and damage. Damage is clear. Blow effects are things like POISON, FIRE, HURT (just pure damage), etc; they're defined in blow_effects.txt, and make a great deal of difference to the attack. Blow methods make some difference to the attack (see the explanation at the top of blow_methods.txt), but are largely for flavor.

The LASH effect uses the blow effect from the monster's first blow to determine a projection type (see projection.txt, and the lash-type lines in blow_effects.txt for which effect gives which projection). The LASH effect in fact just produces a short beam.

WHIP and SPIT are monster 'spells' defined in monster_spell.txt, both of which use the LASH effect.

GAZE and SPIT (yes, having the same names for two different things isn't ideal) are blow methods, so don't have any influence over the LASH effect.

So if you want a gaze innate 'spell', you need to think which projection type (projection.txt) you want it to use, then see which blow effects produce that projection type (lash-type line in blow_effects.txt), and then make sure that your monster has a blow with that effect as its first blow. Then add a new GAZE spell to monster_spell.txt - the WHIP and SPIT spells should give you guidance about what entries to put in.

[will_asher]

Does it have to use the first blow though?
I mean, couldn't it check for a SPIT/GAZE blow method when using a ranged SPIT/GAZE, then use the blow effect used by the melee version?
That's what I'm trying to figure out how to do.

(I've already added a couple other blow types and blow effects, and monster spells, so I know basically how those work.)