memorable randarts

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • Derakon
    replied
    Originally posted by Timo Pietilä
    I don't see how this is intuitive: "how rare is the thing? One." One what? You need to know the source to understand the limit. If you have it other way around IE one time in <rarity> then that's very intuitive to use to me.
    Except that then you can't handle monster drops as "this monster drops up to N items". That is impossible to do if you want to specify rarity in terms of "this item has a 1 in X chance of dropping."

    There's a large pool of items, and they all have different rarities relative to each other. Then the game picks from that pool. You don't really need to understand the source, but you do need to know what the total size of the pool is (i.e. the summation of all rarity values).

    If there's only 1 droppable item, then it doesn't matter what its rarity is; it'll drop every time. If there's 2 droppable items, one has a rarity of 99, the other has a rarity of 1, then the latter will drop 1% of the time. Et cetera.

    Leave a comment:


  • Nick
    replied
    Originally posted by Derakon
    Keep in mind that the only reason Magnate doesn't want to see this thread closed is because reading it is unpleasant using the threaded view. He has nothing against the thread content.
    I like the way that in discussing why Magnate dislikes the thread, we are making it longer

    Leave a comment:


  • Timo Pietilä
    replied
    Originally posted by Magnate
    It's 1-1000 in v4, which is a lot better, but you can't really have arbitrary rarity while you're limited by integers.

    I don't think I understand the need to have rare items have a high number though; alloc_proc seems equally if not more intuitive to me (number of occurrences on the number line).
    Well, as I said you could then make hyper rare insane things without having any limits (except length of the integer bitwise).

    I don't see how this is intuitive: "how rare is the thing? One." One what? You need to know the source to understand the limit. If you have it other way around IE one time in <rarity> then that's very intuitive to use to me.

    Leave a comment:


  • Timo Pietilä
    replied
    Originally posted by Derakon
    ...is anyone else on the forums using the threaded view?
    I'm using hybrid. I have tree in top of the screen and I see all the posts from starting point in that tree below it. That way I can see who answers to who and all the posts thereafter.

    Leave a comment:


  • Derakon
    replied
    Originally posted by Estie
    Nooooo dont you lock my favourite thread. I love what Magnate has done to the randarts and all, but regardless, swinging the thread-close hammer when the topic is unpleasant isnt fair! Dont go there!

    Of course I mostly hope to see awesome randarts posted here.
    Keep in mind that the only reason Magnate doesn't want to see this thread closed is because reading it is unpleasant using the threaded view. He has nothing against the thread content.

    ...is anyone else on the forums using the threaded view?

    Leave a comment:


  • Estie
    replied
    Nooooo dont you lock my favourite thread. I love what Magnate has done to the randarts and all, but regardless, swinging the thread-close hammer when the topic is unpleasant isnt fair! Dont go there!

    Of course I mostly hope to see awesome randarts posted here.

    Leave a comment:


  • krazyhades
    replied
    "Night of the living thread"

    Leave a comment:


  • Magnate
    replied
    Originally posted by Timo Pietilä
    Which btw reminds me conversation with Magnate. I think this should go other way around, most common item should have lowest number and rarest arbitrary high number.

    Maybe something like

    Code:
        /* Artifact "rarity roll" */
            if (randint1(a_ptr->alloc_prob) != 1) continue;
    Would be better. Then you could make insanely rare "game breaking" artifacts. Now the whole range is 1-100 and that's it.
    It's 1-1000 in v4, which is a lot better, but you can't really have arbitrary rarity while you're limited by integers. Pyrel has infinite rarity gradations because alloc_prob can go down to .0000001 etc.

    I don't think I understand the need to have rare items have a high number though; alloc_proc seems equally if not more intuitive to me (number of occurrences on the number line).

    I also don't understand why people won't let this bloody thread die. Ho hum. Perhaps pav could lock it :-)

    Leave a comment:


  • Timo Pietilä
    replied
    Originally posted by Derakon
    I just checked, and here's the One Ring's entry in artifact.txt:
    ....
    Specifically, note the A: line. Rarity of 1. Meanwhile, Grond has a rarity of zero because it's never supposed to be generated "naturally", only by being forced into Morgoth's drop.
    Ah, too old, I used old info.

    Code:
    # 'W' is for extra information. Depth and rarity are not currently used,
    # weight is in tenth-pounds and cost is the item's value.
    Phew. I started to think that I don't understand angband code at all. Good to know that this is just having wrong initial assumption.

    Which btw reminds me conversation with Magnate. I think this should go other way around, most common item should have lowest number and rarest arbitrary high number.

    Maybe something like

    Code:
        /* Artifact "rarity roll" */
            if (randint1(a_ptr->alloc_prob) != 1) continue;
    Would be better. Then you could make insanely rare "game breaking" artifacts. Now the whole range is 1-100 and that's it.

    Leave a comment:


  • Derakon
    replied
    Originally posted by Timo Pietilä
    That's other way around. Rarest items have highest rarity rating, most common have lowest. The One rarity rating is 100.

    Or does that "continue" mean that it fails, which means I have understood this wrong way around?
    I just checked, and here's the One Ring's entry in artifact.txt:

    Code:
    N:13:'The One Ring'
    I:ring:55
    W:100:100:2:5000000
    A:1:100 to 127
    P:0:0d0:15:15:0
    # F: DRAIN_MANA | DRAIN_HP | 
    F:LIGHT_CURSE | HEAVY_CURSE | PERMA_CURSE
    F:AGGRAVATE | DRAIN_EXP | SEE_INVIS | REGEN | TELEPATHY
    F:IM_FIRE | IM_COLD | IM_ELEC | IM_ACID
    F:RES_FIRE | RES_COLD | RES_ELEC | RES_ACID | RES_DARK
    F:RES_DISEN | RES_POIS | RES_NETHR
    F:SUST_STR | SUST_DEX | SUST_CON |
    F:SUST_INT | SUST_WIS |
    F:INSTA_ART
    E:BIZARRE:200+9d50
    M:{name} glows intensely black...
    L:5:STR | INT | WIS | DEX | CON | SPEED
    Specifically, note the A: line. Rarity of 1. Meanwhile, Grond has a rarity of zero because it's never supposed to be generated "naturally", only by being forced into Morgoth's drop.

    Leave a comment:


  • Timo Pietilä
    replied
    Originally posted by PowerWyrm
    Seems correct to me: randint1(100) = 1d100, so if 1-100 > 1 (allocation for rarest items), which happens 99 times out of 100, the item is not generated.
    That's other way around. Rarest items have highest rarity rating, most common have lowest. The One rarity rating is 100.

    Or does that "continue" mean that it fails, which means I have understood this wrong way around?

    [edit]... can't be like that. It clearly makes comparison to 1d100 > alloc_prob which will never be true. Unless alloc_prob is calculated somewhere else so that it reverses the value of artifact.txt.

    [edit edit]

    Code:
    /* Enforce maximum depth (strictly) */
            if (a_ptr->alloc_max < p_ptr->depth) continue;
    That clearly makes same kind of comparison for item level and allows continue only if alloc_max is less than depth.

    [edit, edit, edit] This makes less and less sense to me. God, I need coffee.

    if item max depth is 50 and depth is 51 continue (meaning stop creation). Makes sense.

    if 1d100 is greater than artifact rarity 100 continue (never, so create always). Doesn't make sense.

    You are right, it should be small number, not high. But in artifact.txt that's other way around.
    Last edited by Timo Pietilä; March 27, 2014, 15:28.

    Leave a comment:


  • Nick
    replied
    Originally posted by Timo Pietilä
    Started to calc what that would be for The One and from code I found this:

    Code:
    /* Artifact "rarity roll" */
            if (randint1(100) > a_ptr->alloc_prob) continue;
    The One has rarity of exactly 100. Doesn't that mean that it can't be created at all?
    The thing is (as PowerWyrm was indicating) it is if it doesn't pass this that the One has a chance of being generated. Its alloc_prob is 1, so if the randint1(100) roll is 1 (a 1 in 100 chance), it goes on to the next stage; in the other 99 out of 100, it has already failed.

    Leave a comment:


  • PowerWyrm
    replied
    Seems correct to me: randint1(100) = 1d100, so if 1-100 > 1 (allocation for rarest items), which happens 99 times out of 100, the item is not generated.

    Leave a comment:


  • Derakon
    replied
    Oh, good catch. That is strange.

    Leave a comment:


  • Timo Pietilä
    replied
    Originally posted by Derakon
    I'm pretty sure randint1 is an inclusive random number generator from 1 to the specified cap. It's like rolling a 1d(whatever); 1d100 in this case. In other words, the One Ring has exactly a 1% chance of passing that particular check.
    My point was that there is ">" not ">=" which would indicate that that roll should be greater than rarity to pass the check. Max from 1d100 roll is equal to The One rarity which would mean that it can't pass the check ever.

    If that is something like 1-100 +1 (IE. 2-101)then it's 1/100 chance and anything with rarity 1 are guaranteed to pass (which actually makes sense, Grond has rarity 1). Don't know what that randint1 actually does.

    Leave a comment:

Working...
😀
😂
🥰
😘
🤢
😎
😞
😡
👍
👎