News:

SMFNew Installed

+-+-

User+-

Welcome, Guest.
Please login or register.
 
 
 

Login with your social network

Forgot your password?

Site Stats+-

Members
Total Members: 728
Latest: Cho
New This Month: 0
New This Week: 0
New Today: 0
Stats
Total Posts: 10932
Total Topics: 795
Most Online Today: 389
Most Online Ever: 854
(September 18, 2024, 07:49:37 am)
Users Online
Members: 0
Guests: 281
Total: 281

Author Topic: Generating Random Numbers  (Read 1745 times)

0 Members and 133 Guests are viewing this topic.

Generating Random Numbers
« on: »
(Thanks to @Chthon for giving some pointers, though there was still a bunch of trial and error to figure out that there's a TL2 quirk behind this.)

For anyone curious:

SET STAT with different MIN and MAX can generate random numbers, between MIN and MAX-1 (inclusive).

But with one caveat:
It must be called from an inline EFFECTS block.  Calling it from an affix will cause TL2/GUTS to only ever choose MIN!

Share on Bluesky Share on Facebook


Re: Generating Random Numbers
« Reply #1 on: »
 :o?  Well, this is good to know!

Re: Generating Random Numbers
« Reply #2 on: »
It's rather counterintuitive, given that stat stuff is sometimes buggy with inline EFFECT blocks, and that affixes are preferred for that. 

But it looks like this is one exception where it's reversed!

Re: Generating Random Numbers
« Reply #3 on: »
Topic for further investigation:

Several of the item affixes exhibit similar buggy behavior. As best I can tell, what's happening is that there's an extra division by 100 where there shouldn't be, so you end up with "min + random_roll(0, max - min)/100" (or at least that's my best guess), which the item tooltip display usually rounds up to min+1. Someone -- I think it was RnF -- figured out that you could fix them by overriding the graph with a custom graph that maps all inputs to 100. I wonder if the same bug -- or a similar bug -- might be at play here, and whether it could be fixed in the same way?

Re: Generating Random Numbers
« Reply #4 on: »
Using SET STAT in an affix and setting the MAX to something really large (and also making sure the stat's max is also really large) still doesn't change the result - it still always chooses MIN.  So looks like there's no obvious divisor in this case...

Seems like TL2 has two independent sets of logic/code for inline effects vs. affixes, which really makes little sense to me.
« Last Edit: June 16, 2016, 05:01:23 pm by Khazad »

 

Recent Topics+-