trimmed out the fluff to make testing easier
basenumber has the 1d100 commented out so that static values can be tried
the bonusroll calls have been changed to values so that the table can be omitted
Found out that the table isn't initializing right, it's set to 0, if you change the 0-5 back to 1-5 it outputs 'bad'
and I have tried multiple variations on the 'Roll:' line, the only thing that seems to work is putting an actual value instead of a variable
There are several problems with your notation. {Braces} enclose expressions. (Parentheses) are for overruling the order of operations within an expression. [Brackets] serve multiple purposes in IPP, but their only purpose within an expression is to call another table, such as {5+[@Some Other Table]}.
The Roll command is necessary only if you'll have the table roll its own dice instead of telling it which entry to look up. If you'll ever use [@D100OE], Roll:1d100 would have the table roll 1d100 and return the corresponding entry. If you'll always specify the lookup value, such as {roll==1d100}[#{roll} D100OE], the Roll command is unnecessary but harmless.
After all the comments that have accumulated on this thread, I'm losing sight of what you're trying to accomplish, so let me double-check. Roll d100. If it's 01-05, you subtract another open-ended roll from the current roll. If it's 06-95, the roll is the result. If it's 96-100, you add another open-ended roll to the current roll. Is that correct? You could, for example, wind up rolling 99, 99, 99, 01, and then 50, so your result would be 99 + 99 + 99 + 1 - 50 = 248, right? Something like the following would achieve that.
OldeMusicke: Open-ended rolls only go up, or down, not both. So that means the initial roll determines the direction, but for subsequent rolls you only consider the 96-100 add and not the 01-05 subtract.
NanoEther: Regarding the times when it was concatenating results instead of adding them, typically that happens because you have a stray space on the line. Once there is something non-numeric in there, it won't treat it like a number.
That could also be an issue on that "Roll:" line. If you put a comment on the same line like:
Set:Basenumber={60} //comment
...the part starting with // is ignored as a comment. But that space before it? That is part of what gets assigned to the variable. So Basenumber takes a value of "60 " and not just "60". And now the math won't work as expected.
Regarding the "roll is" thing, that's just sample output text. So in Ed's example:
table: example
roll is {2d10+1d6-2}
The output is something like:
roll is 14
The "roll is" is just part of that output like any other words.
And the D100OE isn't working right, noticed that when I referenced it from another table. I back tracked the problem to this table and did a bunch of test runs on the D100OE.
Recent generation gave me the following (with console calls added):
50 (Table: FirstRoll)
18 (Table: FirstRoll)
2927 (Table: FirstRoll, Table: D100OEH)
10 (Table: FirstRoll)
984 (Table: FirstRoll, Table: D100OEH)
There's no way these values should be possible, adding 100 to 95 should be max with one call of D100OEH.
There just isn't enough data, I'm not even sure if it's using the value being passed as the value it's supposed to be operating on or if it's generating a new value each time it runs across the variable.
got a third roll:
249039 (Table: FirstRoll, Table: D100OEH, Table: D100OEH)
Just realized that it's adding them together as strings, not values. Which points to another problem: the 2927 if is '29'+'27' then it's not using the 96-100 value that was passed to the table as the value. 984 could be '98'+'4' or '9'+84', the first is good, but the second is bad. 249039 has to be '24'+'90'+'39', none of which should trigger the D100OEH table.
Why wasn't this noticed earlier?
I did notice a few odd results earlier, but they were rare, the above results were more a matter of chance.
there's only a 10% chance, total, of D100OEH being triggered, no matter the source, and if the concatenation wasn't too extreme, it wouldn't be noticed.
I think I found the fix, just move the 'Bonusnumber' variable into the table, and used Set. Hopefully this means that it's using a different roll each time it's called, need to get a 200+ roll to check it.
And I noticed that I'd changed the set:basenumber to define
those two fixes seem to have cleared the problems
I'm still not sure D100OEH is doing what you intended. I'm thinking you're still not clear on the Set statement and lookup tables.
Given jdale's correction of my earlier example, I believe you're looking for something like this:
Table: Example
{newroll==1d100}[#{newroll} D100OE]//The first roll
;The first roll could send you in either direction.
Table: D100OE
Type:lookup
1-5:{oldroll==newroll}{newroll==1d100}{oldroll-[#{newroll} D100OE Lower]}
6-96:{newroll}
96-100:{oldroll==newroll}{newroll==1d100}{oldroll+[#{newroll} D100OE Higher]}
; If the first roll tells you to subtract, there's no minimum for how many times you'll subtract.
Table: D100OE Lower
Type:lookup
1-5:{oldroll==newroll}{newroll==1d100}{oldroll-[#{newroll} D100OE Lower]}
6-100:{newroll}
; If the first roll tells you to add, there's no maximum for how many times you'll add.
Table: D100OE Higher
Type:lookup
1-96:{newroll}
96-100:{oldroll==newroll}{newroll==1d100}{oldroll+[#{newroll} D100OE Higher]}
I don't think that's doing the recursion properly because you've got oldroll being overwritten by newroll in the final table.
The D100OE Lower table is also not right but that's because we didn't explain it properly. If you roll open-ended high it's exactly as you have it. You can roll for example 96+96+96+98+3.
But in the low case, you roll, say, a 3, and the subsequent rolls will all be subtracted, but rerolling is on 96-100. So for example 3-(96+98+2) is going to result in a total of -193. But if you roll 3 followed by 2, the total is 3-2 = 1 and then you stop.
I think most of my problem is thinking of it like a programming language
It's mark-up language, more akin to a scripting system, so there are a lot of things going on in the background that I'm missing.
Take Define, I'm used to it being a variable that changes as the code processes, but only changing when I tell it to. In IPP, anytime you call that defined variable, it can change, and will if it's associated with a random. Set is normally reserved for constants, variables that do not change. In IPP, the term constant is bit flexible, but it's more like defining a variable; there is nothing like IPP's define in the languages I've been exposed to. Well, not unless you define a class to handle that, but within that class, I'm telling it to change.
Figuring out what scope to put the variables in has been a bit of a problem, put the scope too high and things can get lost, to low and the data is freed before it's used.
It does appear that each time a table is called, new instances of the variables are made, and then those instances are deleted as the tables resolve themself.
I'm learning/relearning as I go, and I might have some things wrong (probably do); I may have to suggest some changes to documentation to help clarify things that I'm getting hung up on.
Psuedo code (maybe easier, maybe harder to understand)
class: rollOE
roll=1d100
if roll<6 then roll=roll-call:rollHigh
if roll>95 then roll=roll+call:rollhigh
output:roll
class: rollHigh
rollHigh=1d100
; this gets weird because of variable scope
if rollHigh>95 then rollHigh=call:rollHigh+rollHigh else return:rollHigh
Yes, Inspiration Pad is more akin to a regular expression engine than a programming language. The generator isn't run (procedurally) as much as its evaluated as a whole. Its just that, unlike a normal regular expression engine, randomness is built in.
Here's my debugging code from back in 2017... it works for OEH. Really no issues at all. And the output tells you what the rolls were and what the final total score is.
; OpenRolls.ipt
; created 10/22/2017 2:07:25 PM
Prompt: Enter d100 value to initiate a critical roll { } 96
Define:CRIT={{$prompt1}-1}
Set:Basenumber={1d100}
Set:Bonusnumber={1d100}
Set:Result={Basenumber}
Table: Main
Critical Roll is Greater Than {$CRIT}, Rolls are {$Basenumber}, {$Bonusnumber}, [@Total_Score]
Table: Total_Score
{@Total==[when] {$Basenumber}>{CRIT} [do]{{$Result}+{$Bonusnumber}}[else] {$Result} [end]} &
[when] {@Total}>{$Result}[do]{Basenumber=={$Bonusnumber}} {Bonusnumber=1d100}, {result=={@Total}} [@Total_Score] [else] Final Score is {@Total} [end]
I can't imagine that it would be too difficult to toss in a OE Low into this. I may give it a go this afternoon. I'll post something of I do.
I really think that second When-Do is key to making the loop continue to roll until failing to go again.
This seems to work for every scenario. Hope it helps!
; OpenRolls3.ipt
; created 3/7/2024 11:53:38 AM
Prompt: Enter d100 value to initiate a high critical roll { } 96
Prompt: Enter d100 value to initiate a low critical roll { } 5
Define:CRIT={{$prompt1}-1}
Define: FAIL={{$prompt2}+1}
Set:Basenumber={1d100}
Set:Bonusnumber={1d100}
Set:Result={Basenumber}
Table: Main
Critical Roll is Greater Than {$CRIT}, Failure Roll is Less Than {$FAIL}, Rolls are {$Basenumber}, {$Bonusnumber}, [@Total_Score]
Table: Total_Score
{@Total==[when] {$Basenumber}>{CRIT} [do]{{$Result}+{$Bonusnumber}}[else][when] {$Basenumber}<{FAIL} [do]{{$Result}-{$Bonusnumber}}[else] {$Result} [end] [end]} &
[when] {@Total}>{$Result}[do]{Basenumber=={$Bonusnumber}} {Bonusnumber=1d100}, {result=={@Total}} [@Total_Score] [else] &
[when] {@Total}<{$Result}[do][@ScoreLow][else] Final Score is {@Total} [end] [end]
Table: ScoreLow
{Basenumber=={$Bonusnumber}} {Bonusnumber=1d100}, {result=={@Total}} &
{@Total==[when] {$Basenumber}>{CRIT}[do]{{$Result}-{$Bonusnumber}}[else] {$Result} [end]}[when]{@Total}<{$Result}[do]{Basenumber=={$Bonusnumber}} {Bonusnumber=1d100}, {result=={@Total}} [@ScoreLow][else] Final Score is {@Total} [end]
Comments
trimmed out the fluff to make testing easier
basenumber has the 1d100 commented out so that static values can be tried
the bonusroll calls have been changed to values so that the table can be omitted
Found out that the table isn't initializing right, it's set to 0, if you change the 0-5 back to 1-5 it outputs 'bad'
and I have tried multiple variations on the 'Roll:' line, the only thing that seems to work is putting an actual value instead of a variable
There are several problems with your notation. {Braces} enclose expressions. (Parentheses) are for overruling the order of operations within an expression. [Brackets] serve multiple purposes in IPP, but their only purpose within an expression is to call another table, such as {5+[@Some Other Table]}.
The Roll command is necessary only if you'll have the table roll its own dice instead of telling it which entry to look up. If you'll ever use [@D100OE], Roll:1d100 would have the table roll 1d100 and return the corresponding entry. If you'll always specify the lookup value, such as {roll==1d100}[#{roll} D100OE], the Roll command is unnecessary but harmless.
After all the comments that have accumulated on this thread, I'm losing sight of what you're trying to accomplish, so let me double-check. Roll d100. If it's 01-05, you subtract another open-ended roll from the current roll. If it's 06-95, the roll is the result. If it's 96-100, you add another open-ended roll to the current roll. Is that correct? You could, for example, wind up rolling 99, 99, 99, 01, and then 50, so your result would be 99 + 99 + 99 + 1 - 50 = 248, right? Something like the following would achieve that.
OldeMusicke: Open-ended rolls only go up, or down, not both. So that means the initial roll determines the direction, but for subsequent rolls you only consider the 96-100 add and not the 01-05 subtract.
NanoEther: Regarding the times when it was concatenating results instead of adding them, typically that happens because you have a stray space on the line. Once there is something non-numeric in there, it won't treat it like a number.
That could also be an issue on that "Roll:" line. If you put a comment on the same line like:
Set:Basenumber={60} //comment...the part starting with // is ignored as a comment. But that space before it? That is part of what gets assigned to the variable. So Basenumber takes a value of "60 " and not just "60". And now the math won't work as expected.
Regarding the "roll is" thing, that's just sample output text. So in Ed's example:
The output is something like:
The "roll is" is just part of that output like any other words.
Thanks OldeMusicke for the explanation on how the brackets are used by IPP
Thanks JDale, so the text thing is a simple fix, once I get the the rest of it to work the way it's supposed to
So this seems to work, I slowly replaced things so, here it is:
The ipts,
D100OE is the short version
D100OE Long is, way bigger then it needs to be, but it works
And the D100OE isn't working right, noticed that when I referenced it from another table. I back tracked the problem to this table and did a bunch of test runs on the D100OE.
Recent generation gave me the following (with console calls added):
50 (Table: FirstRoll)
18 (Table: FirstRoll)
2927 (Table: FirstRoll, Table: D100OEH)
10 (Table: FirstRoll)
984 (Table: FirstRoll, Table: D100OEH)
There's no way these values should be possible, adding 100 to 95 should be max with one call of D100OEH.
There just isn't enough data, I'm not even sure if it's using the value being passed as the value it's supposed to be operating on or if it's generating a new value each time it runs across the variable.
got a third roll:
249039 (Table: FirstRoll, Table: D100OEH, Table: D100OEH)
Just realized that it's adding them together as strings, not values. Which points to another problem: the 2927 if is '29'+'27' then it's not using the 96-100 value that was passed to the table as the value. 984 could be '98'+'4' or '9'+84', the first is good, but the second is bad. 249039 has to be '24'+'90'+'39', none of which should trigger the D100OEH table.
Why wasn't this noticed earlier?
I did notice a few odd results earlier, but they were rare, the above results were more a matter of chance.
there's only a 10% chance, total, of D100OEH being triggered, no matter the source, and if the concatenation wasn't too extreme, it wouldn't be noticed.
I think I found the fix, just move the 'Bonusnumber' variable into the table, and used Set. Hopefully this means that it's using a different roll each time it's called, need to get a 200+ roll to check it.
And I noticed that I'd changed the set:basenumber to define
those two fixes seem to have cleared the problems
Edit:
A few moments later...
annnd removed the define statement.
Just got a few 200+, one of them was 283, which, if it's working right, can only be 96+96+1
Updated the files I posted earlier
I'm still not sure D100OEH is doing what you intended. I'm thinking you're still not clear on the Set statement and lookup tables.
Given jdale's correction of my earlier example, I believe you're looking for something like this:
I don't think that's doing the recursion properly because you've got oldroll being overwritten by newroll in the final table.
The D100OE Lower table is also not right but that's because we didn't explain it properly. If you roll open-ended high it's exactly as you have it. You can roll for example 96+96+96+98+3.
But in the low case, you roll, say, a 3, and the subsequent rolls will all be subtracted, but rerolling is on 96-100. So for example 3-(96+98+2) is going to result in a total of -193. But if you roll 3 followed by 2, the total is 3-2 = 1 and then you stop.
I think most of my problem is thinking of it like a programming language
It's mark-up language, more akin to a scripting system, so there are a lot of things going on in the background that I'm missing.
Take Define, I'm used to it being a variable that changes as the code processes, but only changing when I tell it to. In IPP, anytime you call that defined variable, it can change, and will if it's associated with a random. Set is normally reserved for constants, variables that do not change. In IPP, the term constant is bit flexible, but it's more like defining a variable; there is nothing like IPP's define in the languages I've been exposed to. Well, not unless you define a class to handle that, but within that class, I'm telling it to change.
Figuring out what scope to put the variables in has been a bit of a problem, put the scope too high and things can get lost, to low and the data is freed before it's used.
It does appear that each time a table is called, new instances of the variables are made, and then those instances are deleted as the tables resolve themself.
I'm learning/relearning as I go, and I might have some things wrong (probably do); I may have to suggest some changes to documentation to help clarify things that I'm getting hung up on.
Psuedo code (maybe easier, maybe harder to understand)
class: rollOE
roll=1d100
if roll<6 then roll=roll-call:rollHigh if roll>95 then roll=roll+call:rollhigh
output:roll
class: rollHigh
rollHigh=1d100
; this gets weird because of variable scope
if rollHigh>95 then rollHigh=call:rollHigh+rollHigh else return:rollHigh
I've done this in VB, but it's been years
Yes, Inspiration Pad is more akin to a regular expression engine than a programming language. The generator isn't run (procedurally) as much as its evaluated as a whole. Its just that, unlike a normal regular expression engine, randomness is built in.
Here's my debugging code from back in 2017... it works for OEH. Really no issues at all. And the output tells you what the rolls were and what the final total score is.
I can't imagine that it would be too difficult to toss in a OE Low into this. I may give it a go this afternoon. I'll post something of I do.
I really think that second When-Do is key to making the loop continue to roll until failing to go again.
This seems to work for every scenario. Hope it helps!