Opened 10 years ago

Closed 8 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

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 10 years ago by takkaria

  • Owner set to takkaria
  • Status changed from new to assigned

comment:2 Changed 10 years ago by takkaria

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.

comment:3 Changed 10 years ago by takkaria

This requires deleting lib/data/object.raw, or you might get really weird things happening.

comment:4 Changed 10 years ago by takkaria

see [5852c1f] (SVN r410).

comment:5 Changed 10 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 10 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 10 years ago by takkaria

I'm not sure that it is, no. I might change that back next commit.

comment:8 Changed 10 years ago by takkaria

  • Description modified (diff)

comment:9 Changed 10 years ago by takkaria

  • Summary changed from New item allocation system to New item allocation system with gradients

comment:10 Changed 9 years ago by takkaria

  • Milestone changed from 3.2.0 to 3.1.0

comment:11 Changed 9 years ago by takkaria

  • Keywords blocker added

comment:12 Changed 8 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).

Note: See TracTickets for help on using tickets.