It looks like you're new here. If you want to get involved, click one of these buttons!
Hi, I use Rolemaster for my RPGing and they use percentile dice (1d100) and if you roll a 96 or above, you get to roll again and add the 2 results.
Actually, it goes on with dice roll after dice roll until you roll less than 96 and they're all added together.
How would I be able to simulate these types of rolls?
Thanks.
Comments
Without actually creating the code (which I'll probably try to do in the next few days), I'd structure it along these lines:
Set base_roll={1d100}
Set result = base_roll
Set next_roll={1d100} ... then create a loop
When base_roll >95 then Do
... result = result + next_roll
... set base_roll = next_roll
... set next_roll = {1d100}
Else end loop
Now that's not the IPP syntax, and I'm not even sure the loop is really possible (I haven't done much with When - Do statements). There should be a way to output each {1d100} to check what it's really adding. Please post if get some code to work.
I've more or less got it now. Here's the output for 10 tries, with rerolling on a 70 or higher:
Here's the code. Looks simple now, but there was a lot of trial and error getting it to run:
And, of course, the user is prompted to enter the threshold for when to add dice together and reroll.
Now that it works, could streamline the output to be silent on "Total Score is..." So it really just lists raw dice scores sequentially, then provides the Final Score. And yes, it does always roll one time too many the way I wrote it, but never adds in more rolls than intended.
Here's the streamlined output:
And the code:
Excellent - thanks. I can see it goes on beautifully.
Now, how do I apply this result to a Lookup Table?
Well, I'd start by replacing the prompt input with a straight "96". Just dump the prompt, dump the "Define", and replace {CRIT} with a 96. And, "==" all the other stuff, if you want to suppress all output of any rolls or Total_Score.
Then, just try [#{@Total_Score} NewTable] to use the value of Total_Score in your new lookup table.
By removing the prompt, this could also be as standalone dice roll, located in the "Common" folder, and you could call it in a different generator using a "Use" command. Then it just creates the Total_Score and brings it into your new generator.
A few ways to make it happen, depending on the overall application.
The crit is set to 96 always, but I'm not sure what you mean by '==' all the other stuff.
Sorry, I'm not so good at this - Your code works but I have no idea why,
When you use:
{Bonusnumber=1d100}
It outputs the rolled number - visibly on the generator results screen. If you want the roll silent (not output on the generator) then use:
{Bonusnumber==1d100}
That will set the variable "Bonusnumber" to whatever the d100 result is, but not output it to the screen.
The code in Table: Total_Score was kinda crazy. Not surprised if it's hard to follow. But in the end, it creates that variable {@Total} which is the final die roll result. Put double equal signs "==" everywhere there is a single equal sign, and the value will be silently calculated and saved in {@Total}
Then just use it when calling your lookup table. The code should be something like:
[#{@Total} NewTable]
(I think I said {@Total_Score} earlier, which was wrong)If the die roll result was, say, 214, then that table call would in effect be saying, "Lookup a die roll of 214 on table NewTable".
And take it slow and don't lose hope - I've only been at this for a few months now. There are some limitations in IPP, but what it can do is pretty amazing.
This outputs just the final die roll value, {@Total}
This uses that value in a lookup table:
Wow - thanks for your help with this, I still can't work out how it works; I understand the 'When/Else' commands but not how the variables work (which is the major part of the code).
Fortunately, the Treasure generator is just lots and lots of tables and subtables. It's not hard, just time-consuming copying and pasting and then I'll have to add the refs to the other tables instead of 'roll on table 14.47'.
However, I do see one problem - the Open-Ended dice roll code referenced your 'NewTable'. There is an option to add this code again and again but changing the Variable code names (as I know that Variables are set until you hit 'generate' again).
I'm still a long way off completing it and I've only pasted a few tables to show how there's a table referenced in a table in a table (and it goes deeper still). Not all tables go above 100 (so I can keep the 'Roll: 1d100' for those) but there are a lot of them still.
As you may notice, I'd used a 'Roll: 1d400' but this gives an equal possibility of getting something awesome when the difficulty should be so much harder in reality.
So this may not be to hard... You have:
76–80: [@T-14-16_RND_Master_Magic_Items]
Which says go roll on table T-14-16_RND_Master_Magic_Items. Once there, the table says to roll a d400.
Instead, insert the "open rolls" code. Then make your call look like:
76–80: [#{@Total} T-14-16_RND_Master_Magic_Items]
Which says, go to table T-14-16_RND_Master_Magic_Items and find me the item that matches up to number 214 (if 214 is the value saved in @Total when it is calculated). The "Roll:1d400" line should be removed from T-14-16_RND_Master_Magic_Items as well.
It might even work to ONLY change the Roll:1d400 to:
Roll:{@Total}
But in table T-14-16_RND_Master_Magic_Items, you always need a default statement, in the incredibly rare event that the "Open roll" returns a value greater than 400. So something like:
That way if @Total exceeds 400, you get item 400 rather than an error or blank.
This seems pretty sound, blending the "opens rolls" code with part of your tables. I'd certainly do the prompt1, prompt2 thing from the other thread rather than using 26 letters to determine quality of items and quality of wealth. Then, I think you're well on your way!
Here's the logic behind the open roll...
Initial (primary) die roll is Basenumber. It's a 1d100 in the opening SET commands.
Bonusnumber is the next d100, in case the first die roll is high enough to need a next die roll.
We also set Result equal to Basenumber (equal to the first d100 roll; this will be our Total if the first die roll does not exceed 95).
Now table Total_Score is called from Main with those variables above already set.
The first When-Do says... make the value of @Total = 1st die roll + 2nd die roll if the first roll is greater than 95, otherwise set @Total to just the first die roll. Simple enough if there is only ever 2 die rolls at most.
The second When-Do is where things get fun. If @Total is greater than Result (this is only ever the case if we were able to add the first two die rolls together, otherwise they would be equal - both equal to Basenumber) then...
Rerun (loop back again to the start of) Total_Score, but first before you do:
1. make Basenumber (the first die) equal to Bonusnumber (the second die value). We're shifting the dies up in priority, because if we're looping back, then we're ready to see if die two is greater than 95.
2. We set Bonusnumber equal to a new d100 roll. Here we're creating a third die roll, and placing it in the second position - the value that we will add if the new Basenumber (which was/is Roll_2) exceeds 95.
3. Set Result equal to @Total. Result is our running total. Remember, if Roll_2 exceeds 95, then we want to add Roll_3 to the sum of (Roll_1+Roll_2), not just add Roll_3 to Roll_2.
4. Now we can loop back with a [@Total_Score] table call.
We keep doing this to keep our running total increasing as long as the next die roll exceeds 95, always storing the running total in the variable @Total.
When we fail the check @Total>Result (i.e. the new Total is the same as Result... we didn't add to it, because the latest die roll failed to exceed 95), then we END the loop and return to from Total_Score to Main with an accumulated dice roll value stored in @Total.
In all likelihood, Result could be eliminated completely and it could all be done with Basenumber, Bonusnumber, and Total. But, the code is working, so why bother messing with it.
Back in the day (and I mean seriously ancient times) we always had to use a line that went something like "set N = N +1" to increment our counter before looping back to the start of a routine. The second When-Do is just accomplishing something similar by incrementing the die rolls to the next higher priority (Roll_2 becomes primary, Roll_3 becomes bonus; if the rolls continue to exceed 95, then Roll_3 becomes primary and Roll_4 is made as the bonus, etc.) . It's a hack of creating a WHILE-Do or an UNTIL-Do statement.
Thanks for the huge reply and explanation - I've not managed to read it yet, I suffer from chronic migraine and things have been bad but I didn't want you to think I'm ignoring you on purpose.
Now to do the full open ended for skill rolls (many RM rolls can go negative)
Now to add this to my common & do some tweaking
added a created by line
Started adding the variables (FAIL, Failnumber), realized that I may have to set a fail switch
in fact, implementing a fail switch may be the best method
For those that are trying to play along
the open ended low only triggers once, on the first roll when it's below a 6 (1-5)
If it triggers, subsequent rolls continue to be open ended 'high', but they are subtracted from the total
So did it a little different, used tables
yes you can call the table from within its self (made a test for it)
Only problem is that I get a null value every once in a while, suspect it's generating 0 and displaying a blank entry, probably a really simple fix for it.
Have not seen values that break -100 or +200, yet.
And I just got an error: (Invalid expression: Basenumber-)
I think it tried to do this: 0-0
So, Need to test for 0?
after further testing, using a simpler table to test syntax and values, and it should work, so I'm missing something
maybe it's reusing the variable, might need a temp var to hold the total until it's done iterating
added a temp var
Well, it will break 200, got a roll of over 1000 (?)
but I'm still getting nulls
and, as it's calculations, the console doesn't help
New version:
Those lines that say "Roll is Basenumber" and "Roll is Bonusnumber" are possible table results, and when added to things have a value of 0.... that's causing those null values.
You also seem to have a lot of extraneous lines, Set commands, and assignments that aren't adding anything but make it harder to debug. It works fine if you cut it back to just:
Nothing better to do then to troll nbos for RM material? (me too)
saw your user name on the "Issues & wishlist" thread and wasn't sure whether it was another dale, then I saw the comment on RM.
If done correctly, I believe that roll is a keyword,
Found the reference I used:
https://forum.nbos.com/discussion/2003/subtracting-from-die-rolls#latest
So IPP is _supposed _to treat 'roll:' and 'roll is' as keywords
The snippet from the thread is:
The question is: are we applying the basenumber or the bonusnumber to the tables to determine whether those values meet the OE criteria, or is some other random being applied
But, maybe the second version would be a better solution, as IPP is less likely to confuse whether it should be treated as a keyword or not, and it's more obvious what is going on then the simpler format
Tried changing, got some weirdness going, but, got a little data out of the console
Also, for a bit, it stopped adding the results, which allowed me to see what values it was outputting.
The short answer is that 'roll is' is not being treated as a keyword
one of my results was 64 -100, that tells me that it passed on to the bonusroll while outputting a 64, and the bonusroll returned 100
It's possible that it rolled 96, then 4, but since the first roll was 64, which is greater then the negative cutoff, I doubt it.
And I couldn't find 'roll is' in the guide, so it might have been removed at some point, or the code isn't implementing it right.
Too bad, it would have been a simpler, and easier to understand, way to implement it
I did figure a few things out, I think.
It stopped adding the values together and just passed them as a concatenated string
The variables set to 1d100 are defined as unsigned ints and it was attempting to change the sign and throwing an error. I changed the script slightly to {Basenumber+((-1)*[@BonusRoll])} and that seemed to clear some errors, the code was more agreeable to that.
I'm not sure if the bonusroll table was working properly, as it now occassionally throws an error when it calls a second time. I don't think it was actually adding the values together (in bonus roll) and was passing a string back to D100OE
but now, it's not adding anything together
I think that they should overload the 'Roll:' keyword so that valid expressions or values can be passed as the roll instead of a variable roll. would allow for targeted troubleshooting of specific parts of tables, like these. I would be able to set 'Roll: 96', and other values to make sure it was working right. And it adds utility to an existing keyword.
The Roll: command is for lookup tables when you want the table to use a built-in die roll. The example from the help file (repeated below) shows a table that normally uses a 1d10 roll. You can invoke the table using [@Humanoid] and it'll use the built-in 1d10 roll. Alternatively, whether or not a lookup table uses a Roll: command, you can specify your own lookup value, such as [#2 Humanoid] or [#{1d7+2} Humanoid].
roll:#96 is being evaluated, but it's generating other values in the tables
Dropping the # seems to work, if I do 96 or higher, it rolls bonus, lower, it doesn't
Changed it a little to troubleshoot
it outputs 46 -20
it seems to be stuck on the first selection
Still not sure why it's treating it as text (which might be part of the problem)
I'm going to assume that this is not currently possible to use tables this way, mainly because 'Roll:' and '#' apparently does not like variables that are not actual die codes.
I was hoping to make it more human friendly, but it looks like I'm going to have to stick with the when-do structure.
I'll do a search in the help file, I was primarily referencing other tables and the pdf
off to do more research
BTW, I am using 3.01, in case anyone was wondering
the built in help is the same as the pdf
doing 'Roll:[#Basenumber]' kicks the default (which is the null lines I was getting earlier, now it kicks 'bad' so I know default was passed to display)
Yes, it should work, but it doesn't
My problem is that the roll is not only used as the lookup, but as the result as well, that's where the hiccups are coming from.
I think I know a workaround, but I'm not sure if I want to test the numbers from 1 to 100 individually; especially since I'm not sure if I'll have the results passed as a string instead of a value
Well, we knew I was going to do it once I posted it
It does seem to be working
It was still casting as bonusroll back as text, until I enclosed them in brackets '{96+([@BonusRoll])} vs {96+[@BonusRoll]}, this seems to recast text as a val (? ?)
Well, it's not pretty, or short, buts it's legible and it works
got a result of 237, so bonusroll is iterating correctly
I'll clean it up and add comments before uploading it
Turns out, not only did I make a d100OE generator, but the bonusroll table was a D100OEH generator, so, two-for
uploaded it to the VOX page too
But I would still like to get the shorter form working
so more suggestions are welcome