Closed evesala closed 6 years ago
No, it does not. It is actually counting through an entry's multiplicity until the rolled result is reached. E.g., consider:
m: 10, v: x m: 10, v: y m: 10, v: z
This would implicitly roll a virtual D30. We might get 17. It then starts with the first entry and checks (currentIndex = 0) <17 (yes) and (currentIndex + m = 10) >= 17 (no), steps to the next entry (increases currentIndex by last m) and checks (currentIndex = 10) < 17 (yes) and (currentIndex + m = 20) >= 17 (yes), and has found the rolled entry.
Thanks for clearing that up and confirming my expectations about a well-behaving implementation. Closing the ticket.
I may be overcautious here, but was wondering about the implementation of the multiplicity feature. When I specify a multiplicity value for a table entry, say:
I know the maximum multiplicity value is 255, but is this just a relative value used when computing the total number of lines in the table (as I have presumed), or would the system for some reason actually allocate 30 instances of that line?
Normally this would not matter to the user, but with huge tables using several layers of nested table calls this might at some point become at least a theoretical issue for speed or memory considerations.
So, when writing complex generators, using d100 comes naturally to me. But should I really use smaller values if that extra precision is not needed?