Ticket #310 (closed change: fixed)

Opened 3 years ago

Last modified 20 months ago

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) (diff)

Initially, comment 2 described the changes.

But things need changing again to allow gradients of likelihood between different levels.

Attachments

Change History

Changed 3 years ago by takkaria

  • owner set to takkaria
  • status changed from new to assigned

Changed 3 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.

Changed 3 years ago by takkaria

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

Changed 3 years ago by takkaria

see [410].

Changed 3 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

Changed 3 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?

Changed 3 years ago by takkaria

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

Changed 3 years ago by takkaria

  • description modified (diff)

Changed 3 years ago by takkaria

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

Changed 3 years ago by takkaria

  • milestone changed from 3.2.0 to 3.1.0

Changed 2 years ago by takkaria

  • keywords blocker added

Changed 20 months ago by takkaria

  • status changed from assigned to closed
  • resolution set to fixed

DROP_GOOD now means something again, and with that, this bug is being closed. r1092.

Add/Change #310 (New item allocation system with gradients)

Author



Action
as closed
Next status will be 'reopened'
 
Note: See TracTickets for help on using tickets.