Opened 12 years ago
Closed 11 years ago
#310 closed change (fixed (in master))
New item allocation system with gradients
Reported by: | takkaria | Owned by: | takkaria |
---|---|---|---|
Milestone: | 3.1.0 | Keywords: | tmj blocker |
Cc: |
Description (last modified by takkaria)
Initially, comment 2 described the changes.
But things need changing again to allow gradients of likelihood between different levels.
Change History (12)
comment:1 Changed 12 years ago by takkaria
- Owner set to takkaria
- Status changed from new to assigned
comment:2 Changed 12 years ago by takkaria
comment:3 Changed 12 years ago by takkaria
This requires deleting lib/data/object.raw, or you might get really weird things happening.
comment:4 Changed 12 years ago by takkaria
see [5852c1f] (SVN r410).
comment:5 Changed 12 years ago by takkaria
To closer resemble previous allocations:
- shooters and missiles need commonness boosting across the dungeon
- identify + *id* need a boost
- !*healing* + restoremana + speed needs more later in dungeon
- make sure we disallow sub-chests when opening chests (check opening_chest variable) -- or should we?
- randarts need fixing
comment:6 Changed 12 years ago by ctate
Wow, is it really a good idea to provide no gain/restore stat potions below dlevel 90? I see that the mushrooms still go down to dlevel 100, but isn't restoring a much-appreciated use for those potions in the endgame?
comment:7 Changed 12 years ago by takkaria
I'm not sure that it is, no. I might change that back next commit.
comment:8 Changed 12 years ago by takkaria
- Description modified (diff)
comment:9 Changed 12 years ago by takkaria
- Summary changed from New item allocation system to New item allocation system with gradients
comment:10 Changed 12 years ago by takkaria
- Milestone changed from 3.2.0 to 3.1.0
comment:11 Changed 11 years ago by takkaria
- Keywords blocker added
comment:12 Changed 11 years ago by takkaria
- Resolution set to fixed
- Status changed from assigned to closed
DROP_GOOD now means something again, and with that, this bug is being closed. [d556d14] (SVN r1092).
I'm not sure if these changes are best on the trunk, but given that I want to work on the object.txt file with these changes somewhere publically versioned, I'm going to commit them.
The first thing I did was add a "max" param to the allocation line, and trim it down so you can only specify one probability. Currently, the "rarity" part is converted to "commonness" via a simple calculation inside the code, so I moved that to the edit files too. The old line A:20:1 now looks like A:100:20 to 100.
This syntax may not be optimal, but I find it useful for editing. It's easy enough to change it something else, but right now I'm not convinced a {min,max,commonness} tuple is enough to fix the problem, so I'm not worrying too much, because I expect the format to change again.
There's a new, memory-gobbling (~50kB, vs. old ~20kB) system of object allocation which currently doesn't accomodate for OoD rolls at all, meaning things are going to be wonky for a bit, but generally more predictable (the probabilities supplied in object.txt are the whole story). It also doesn't distinguish "good" drops from "normal" drops, but I hope to be able to remove that distinction anyway. I suspect this system will be slightly slower on start up (but not noticeably on an 800Mhz machine), but generating an object now takes a single iteration over the object list, which is much faster than previously.
Arrows and missile weapons are a fair bit rarer than they used to be because of not having more allocation lines. I suspect that for a short while there will be *more* junk than usual, not less. Please bear with me through this, or don't update SVN for a while and play a decently-balanced version.