Odd Request: Negative Damage Dice

[MaxAstro]

Can't remember if this has been brought up before, but would it be possible to add the ability to assign negative damage dice to a damage entry? This would widen the amount of damage effects that can be automated.

For example, if an effect deals 5d6 damage at 13th level and increases by 1d6 damage each odd level (15th, 17th, etc), it's currently impossible to automate the damage increase.

However, if it were possible to add negative damage dice, you could automate this by setting 1d6 damage per odd caster level (giving 7d6 damage at 13th level) and then applying -2d6 dice of damage. This is assuming that positive and negative dice of the same size would cancel each other out when the program is deciding how many dice to roll, of course.

[Trenloe]

This is assuming that positive and negative dice of the same size would cancel each other out when the program is deciding how many dice to roll, of course.

FG negative damage dice effects roll all dice and substract the result of the negative damage dice. This would be the same if negative damage dice were added to the damage editor window - as that's the presumed functionality. Working out if dice were to cancel other dice out would actually be a lot of complex code. So, I doubt you're going to get this particular functionality as it's an edge case and we're working on providing better heightened support in future anyway. i.e. you don't need to work out the maths to try to fit in within the current structure, you'll be able to specify exactly what happens at each level if you'd prefer to use that approach rather then the level based calculations that are there now (and won't be going away).

[Montis]

I would second this request, but maybe we can implement it something like this:



Of course this is a mockup and it might take maybe a bit of a redesign to make this line slightly more intuitive to read (e.g. separating the dice portion and the flat damage portion a bit better).

Also just btw: the "Dice Multiplier" and "(Max)" texts are kind of cut off.

[Trenloe]

As mentioned in post #2 - this is not a simple request and adds more complexity to cater for two different pieces of negative dice functionality (normalize dice or roll all dice). As also mentioned, dev work will concentrate on providing a less complex, more encompassing solution rather than add a piece of complex functionality that has a low level of use.

[myyra]

Would it be difficult to add Spell Level -1 as an option to the Dice Multipliers? I think that would take care of about 95% of the issues that negative dice could solve.

[Trenloe]

Would it be difficult to add Spell Level -1 as an option to the Dice Multipliers? I think that would take care of about 95% of the issues that negative dice could solve.

Can you give me some examples please?

[Montis]

Can you give me some examples please?

I have two from the Summoner I'm playing atm:

Eidolon's Wrath
Progression is ((2 x Spell Level) -1)d6

Elemental Burst
Progression is (Caster Level -1)d6

Edit for some more:
Dragon Breath
Progression is ((2 x Spell Level) -1)d6

Abyssal Wrath
Progression is 2x(Spell Level -1)d6

[Trenloe]

I have two from the Summoner I'm playing atm:

Eidolon's Wrath
Progression is ((2 x Spell Level) -1)d6

Elemental Burst
Progression is (Caster Level -1)d6

Edit for some more:
Dragon Breath
Progression is ((2 x Spell Level) -1)d6

Abyssal Wrath
Progression is 2x(Spell Level -1)d6

Thanks for the examples.

I'll investigate implementing the -1 to the Caster Level or Spell Level - with a resulting minimum of 0 dice - as mentioned previously, implementing actual negative dice is a significant amount of work.

[MaxAstro]

That feels like it might be a feature creep slope, since I read that and immediately think of a couple spells that could handled with SL minus two.

In my personal opinion, if dev time is going to be spent on changing the functionality, I'd prefer it be for a solution that works more generally. But that's just, like, my opinion, obviously.

[myyra]

In my personal opinion, if dev time is going to be spent on changing the functionality, I'd prefer it be for a solution that works more generally. But that's just, like, my opinion, obviously.

But it's not an equal amount of dev time if one option is much easier to implement.