Pyrel dev log

[Magnate]

Originally Posted by Derakon

This will get trickier if we decide to start making monster powers more exotic. For example, how do you consider the power of a monster whose melee attacks have a 10% chance of setting off a radius-2 fireball?

That's actually an easy example because it equates to 10% of the fireball's damage ... but the real issue is, is there a better metric than converting things to damage-equivalent values. You're right that we'll need to equate a lot of wonderful but not directly damaging effects.

More generally, there's nothing that says that the minimum rarity must be 1. Pyrel supports floating-point, so we could have values ranging from e.g. .001 to 1000 and still have that "common thing is a million times more common than rare thing" range. If ints are needed code-side then the code can simply apply a constant scaling factor based on the smallest value used in the data file.

Well yes, but the original context was an allocation table - your random number line. The minimum number of entries on such a line is one, so something a million times more common must have a million entries.

But yes, there's no reason your number line can't use intervals of 0.00001 or whatever.

[emulord]

You dont need a million entries, just have the entries be like
[ (1, The One Ring's ID number),
(100000, Lembas wafer's ID) ...]

And when you generate the random item number you subtract the allocation value of the first entry, then move on to the next until allocation value > random number. Then you found your item. To speed it up put larger numbers up front.

[ekolis]

ID numbers? Eww, how about strings?

[Derakon]

That would be purely on the code side of things, so more likely it would be a reference to the ItemFactory instance that generates that particular item. Rarity specification from the user's perspective would be a part of the item record; it wouldn't be gathered together in any one place.

[Magnate]

Originally Posted by emulord

You dont need a million entries, just have the entries be like
[ (1, The One Ring's ID number),
(100000, Lembas wafer's ID) ...]

And when you generate the random item number you subtract the allocation value of the first entry, then move on to the next until allocation value > random number. Then you found your item. To speed it up put larger numbers up front.

We are violently agreeing with each other. I didn't mean you need a million items in a python dict, I meant that the conceptual number line / allocation table has one entry for The One Ring and a million entries for a Ration of Food (or whatever).

P.S. Derakon: we've reached the point where this thread no longer displays nicely in the Oook software (it says "More replies below current depth" and requires extra clicks and scrolling) - so please could you start a new thread? Thanks.