Notes on latest commits

[jens]

Some notes after reading the latest commits to GitHub:

1)
DSM:
In 'object_base.txt' the entry for DSM has HATES_ACID.

In 'object.txt' every DSM entry has this line:
F:IGNORE_ACID | IGNORE_ELEC | IGNORE_FIRE | IGNORE_COLD
- thus nullifying the entry in 'object_base.txt'

In the new section for DSM in ego_item.txt the IGNORE_* flags are sometimes repeated.
- I guess you can say it's protection against future changes, but it does seem a bit strange ;-)


2)
Suggestion:
Could you add a bunch of empty numbers in the ego file, plus increase the max nr of ego's? Would make it easier to add your own ego types :-)


3)
Commit 821f59dd413062c90885, adressing issue #1394:
This commit fixes so pvals can now be negative. That is great. However, if I read the comments correctly, a very nice feature we could get quite easily is not possible. I would much prefer to have a different token than 0 stand for "do not apply a minimum". Then we could create ego items with properties like:
L:-2M4:0:STR:CON
IIRC the minus would work in one location of the randomizer, but the other would remain positive, so -2M4 would be a negative value in most instances in the early levels, but start being predominantly positive later on. Allowing a min to be set to 0 means we can make not only mixed blessing items, but also items that have more variation. You think you know what an ego type does, then suddenly you find a new version of that ego type that boost your stats as well. And since this would not come into play until late in the dungeon game balance is maintained.

A setting like
L:-9+1d10:0:SPEED
L:-9+1d10:0:STEALTH
L:-9+1d10:0:STR
L:-9+1d10:0:CON
Would allow us to basically add random stats etc. to ego items. I'm not saying that we should go ahead and construct unbalanced items, I'm saying more variation in what content producers can produce is good.

[takkaria]

1)
DSM:
In 'object_base.txt' the entry for DSM has HATES_ACID.

In 'object.txt' every DSM entry has this line:
F:IGNORE_ACID | IGNORE_ELEC | IGNORE_FIRE | IGNORE_COLD
- thus nullifying the entry in 'object_base.txt'

In the new section for DSM in ego_item.txt the IGNORE_* flags are sometimes repeated.
- I guess you can say it's protection against future changes, but it does seem a bit strange ;-)

Thanks, fixed.

2)
Suggestion:
Could you add a bunch of empty numbers in the ego file, plus increase the max nr of ego's? Would make it easier to add your own ego types :-)

Is increasing the limit in limits.txt so hard? We're aiming to remove the need for the limit anyway, but in the meantime, if you want to edit, you can easily make room for them yourself.

3)
Commit 821f59dd413062c90885, adressing issue #1394:
This commit fixes so pvals can now be negative. That is great. However, if I read the comments correctly, a very nice feature we could get quite easily is not possible. I would much prefer to have a different token than 0 stand for "do not apply a minimum". Then we could create ego items with properties like:
L:-2M4:0:STR:CON

OK, so you're confusing 'applying a minimum' (applied using the M: line) with the random pval (specified on the L: line). You're right that you still can't do -2M4, though (there's a bug filed if you want to watch the progress on this, #1451).

[jens]

Is increasing the limit in limits.txt so hard? We're aiming to remove the need for the limit anyway, but in the meantime, if you want to edit, you can easily make room for them yourself.

I guess I have always been wary of changing there, with the idea that I might break something else. So when I have made new ego items I've always used holes in the current set. There are 16, so it works for a while ;-) Another issue is that I would prefer to place my additions in conjunction with the others of the same type, so having the holes appear at the end/start of each section would be even better. But I guess that is a bit of work not very many will appreciate...

OK, so you're confusing 'applying a minimum' (applied using the M: line) with the random pval (specified on the L: line). You're right that you still can't do -2M4, though (there's a bug filed if you want to watch the progress on this, #1451).

No, don't think so, the M: line gives:
M: min to-hit : min to-dam : min to-ac
- probably changed in conjuction with adding multiple pvals.

The L: line is now the one responsible for minima for pvals
L: pval : min pval : flag | flag | etc.

But which line it's on is not relevant for my issue. I want to be able to set 0 as a minima, because that allows for a lot of variation. Of course, this only become relevant after #1451 has been resolved.

[takkaria]

I guess I have always been wary of changing there, with the idea that I might break something else. So when I have made new ego items I've always used holes in the current set. There are 16, so it works for a while ;-) Another issue is that I would prefer to place my additions in conjunction with the others of the same type, so having the holes appear at the end/start of each section would be even better. But I guess that is a bit of work not very many will appreciate...

The reason they are already not so arranged is because doing so would break savefiles. Increasing the number of ego-items won't, though, so that's safer.

No, don't think so, the M: line gives:
M: min to-hit : min to-dam : min to-ac
- probably changed in conjuction with adding multiple pvals.

The L: line is now the one responsible for minima for pvals
L: pval : min pval : flag | flag | etc.

But which line it's on is not relevant for my issue. I want to be able to set 0 as a minima, because that allows for a lot of variation. Of course, this only become relevant after #1451 has been resolved.

Oh, yeah, sorry, you're right.