Help me make my new variant! (please!)

[Nick]

If I want to import changes from newer V to my variant, I made a pull request on github, but how do I exclude certain files and tell it which changes I don't want?

This is not completely straightforward. What I do for FAangband is to use git cherry-pick to pull individual git commits in. Another way is to use git rebase to take current V and then replay the changes you've made on top of it (note that this doesn't remove changes you don't want).

Sorry there isn't a simple answer - I see a bunch of learning about git in your future

Also, I noticed the old_class.txt file has changed. I thought that file was no longer used?

I am attempting to keep it updated so that people can still use it with current V if they prefer to. I'm not sure how well I'm doing with that, but I haven't had any recent complaints (which is my only current measure).

[Julian]

If I want to import changes from newer V to my variant, I made a pull request on github, but how do I exclude certain files and tell it which changes I don't want?

You can use git to cherry-pick which parts of a merge you want to take, but most of the time you’re just going to want to merge the two branches, and anything that’s a merge conflict you just resolve in favor of your code.

[will_asher]

If I want to import changes from newer V to my variant, I made a pull request on github, but how do I exclude certain files and tell it which changes I don't want?

Also, I noticed the old_class.txt file has changed. I thought that file was no longer used?

[will_asher]

You can. The blow names are stored as strings, so you can search through them.

ugh. I'm not good at dealing with strings, but I can probably figure it out looking at other stuff.

[Julian]

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.)

You can. The blow names are stored as strings, so you can search through them.

[Nick]

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.

You could do that; assuming you'e making a new effect like LASH, you'd have to either hard-code in to look for that blow method, or pass that in to the effect via a parameter (probably context->other).

[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.)

[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]

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.

[will_asher]

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

[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.

[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.

[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.

[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);

[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.)