Open-Ended CoreRPG Tables Discussion

[Bale Nomad]

Since the statistics for open-ended d100 rolls aren't really flat, having a single table that includes all the result ranges expressed in the paper tables is not the same thing. I guess the main issue in using the CoreRPG table constructs is modified open-ended rolls.

Unmodified open-ended rolls could be handled through regular linked tables. For instance, a high open-ended roll would have results for the initial values from 1-95, and then a 2nd table would be the result for the 96-100 range, and then a 3rd table for the 96-100 range on the 2nd table. The same could be done on the opposite end, with the 1st "lower" table linked to the 1-5 result on the initial table, and subsequently "lower" tables linked to the 96-100 range of the previous level. How many tables have results beyond rolls totaling -300 on the low end or 300 on the high end?

[Dakadin]

That's a good idea for a workaround. I should be able to merge with the CoreRPG tables and add the open-ended rolls as additional options. The issue I might have is the open-ended rolls don't just have one dice landed result so I will need to make sure it actually works.

[JohnD]

I was also going to suggest multiple linked tables for the 1-5 and 96-00 results.

[Dakadin]

My only concern with that approach is I am sure someone won't be happy that it doesn't match the tables exactly. That doesn't mean I won't fall back to using this idea but I want to exhaust other options first.

[Bale Nomad]

Here's an example using the "Childbirth and Sibling Generation" procedures from Rolemaster Companion only for humans. It took a total of 10 tables; 4 tables to implement the high open-ended roll for the number of Conceptions, 3 tables to implement the high open-ended roll for the number of children in each conception, 1 table to determine the outcome of each conception, 1 table to determine the gender and mortality of each child, and 1 table to determine injuries to the mother or complications to the child(ren).

The last table, "Birth Injuries", is generic, can be used for any race, and doesn't include links to any other tables due to the complicated nature of each of its results. If the offspring are most likely healthy, then the user is directed to roll on the "Children" table for the appropriate race. This table is also the only one in the process that may be subject to a modification roll of +/- d50, based on the lifestyle of the mother. Given that, it may be appropriate to unlink it from the "Conception Outcome" table and direct the user to roll manually on it and adjust the outcome using the appropriate d50 result in the modifiers field below the chat box.

Unlike the RMC Table Resolver tables, it's my understanding that CoreRPG tables cannot be targets for player rolls or handle complications due to modifications of open-ended rolls across the linkages (modifiers are only applied to the initial roll).

There is a Story entry that lays out the basic calculations used to determine the range starts for each subsequent open-ended result table. It also includes calculations for the result ranges on the "Child - Human" table (gender/mortality). That table combines a couple of source tables to simplify the roll, because the required dice roll statistics can be treated as a flat line instead of a curve.

IMHO - This whole approach is most likely only appropriate for GM use, since these tables can't be targets of player rolls. Unless Dakadin can find a way to adapt the CoreRPG tables to behave more like the Table Resolver, then the Table Resolver remains useful.

[Dakadin]

Here's an example using the "Childbirth and Sibling Generation" procedures from Rolemaster Companion only for humans. It took a total of 10 tables; 4 tables to implement the high open-ended roll for the number of Conceptions, 3 tables to implement the high open-ended roll for the number of children in each conception, 1 table to determine the outcome of each conception, 1 table to determine the gender and mortality of each child, and 1 table to determine injuries to the mother or complications to the child(ren).

The last table, "Birth Injuries", is generic, can be used for any race, and doesn't include links to any other tables due to the complicated nature of each of its results. If the offspring are most likely healthy, then the user is directed to roll on the "Children" table for the appropriate race. This table is also the only one in the process that may be subject to a modification roll of +/- d50, based on the lifestyle of the mother. Given that, it may be appropriate to unlink it from the "Conception Outcome" table and direct the user to roll manually on it and adjust the outcome using the appropriate d50 result in the modifiers field below the chat box.

Unlike the RMC Table Resolver tables, it's my understanding that CoreRPG tables cannot be targets for player rolls or handle complications due to modifications of open-ended rolls across the linkages (modifiers are only applied to the initial roll).

There is a Story entry that lays out the basic calculations used to determine the range starts for each subsequent open-ended result table. It also includes calculations for the result ranges on the "Child - Human" table (gender/mortality). That table combines a couple of source tables to simplify the roll, because the required dice roll statistics can be treated as a flat line instead of a curve.

Impressive workaround. I like the approach but how do you handle when someone rolls a 98 and then rolls a 24 for a total of 122? Would they get the 22 result on the second table or get the 24 result?


IMHO - This whole approach is most likely only appropriate for GM use, since these tables can't be targets of player rolls. Unless Dakadin can find a way to adapt the CoreRPG tables to behave more like the Table Resolver, then the Table Resolver remains useful.

Just out of curiosity what do you mean by targets of player rolls? Does that mean that the players can't make rolls off of the CoreRPG tables? Sorry I still have to learn more about them. :)

[Bale Nomad]

That's a good point about the additive nature of the subsequent rolls. I simply adjusted the original ranges down by 95 for each subsequent table. More thought is likely required, especially since rolls of 96, 192, and all other multiples of 96 are impossible in an unmodified high open-ended d100 roll, and I may not have correctly accounted for those.

The RMC Table Resolver uses the results of rolls, including all applicable modifiers to determine a result. For some rolls, like crits or fumbles, the player can roll a d100 and the GM can drag the number from chat and drop it on the table in the resolver to get a result. With CoreRPG tables, the GM can share them out to players who can initiate a roll and adjust it with their modifier, but it will only adjust the initial roll, not the subsequent open-ended rolls. The open-ended roll is supposed to be modified after it reaches its ultimate total.

If the roll was made in the usual manner, even if the target table looked just like the original source table, the result cannot be dragged from the chat and dropped on the table to find the result. The roll must be initiated from the table. At least that's what I observe in my tests.

[Dakadin]

So if I can get the CoreRPG tables to support the open-ended rolls would that solve the issues even if you can't drag a roll to it?

[JohnD]

You may want to look at putting some of these tables into a Player module that the ruleset will make available to players to load when they connect.

The treasure generation stuff would still be in the GM side module of C&T.

[Dakadin]

If you are referring to me the Character Law, Arms Law and Spell Law modules are Player modules. There aren't any CoreRPG tables in Arms Law. Spell Law has the Healing Recovery tables. Character Law has the Healing Recovery and Background Options tables. Those are all accessible by the player.

Creatures & Treasures will be a GM module so any tables in it will be available to only the GM. Right now there aren't any tables in C&T but I do plan on adding them once I get the open-ended rolls worked out with the CoreRPG tables.

[Dakadin]

Hi Bale Nomad,

This is a way to get around that but it makes things messy with the number of tables needed.
33548

I just duplicated the table and added a -4 for 96, -3 for 97, -2 for 98 and -1 for 99. I didn't really have to do the 100 one since I could just use the original one.

Dakadin

[Bale Nomad]

Dakadin,

That does get messy. If you were to do it that way, the modifiers would start with 0 on the "96" table and increase to +4 on the "100" table, because the open-ended roll result for 96 would actually start at 97 (96+1). Doing it this way would also change the statistical probability of getting another high end roll, so that also would need to be taken into consideration.

I am not a statistician, so I don't know the math well enough, but if I were putting the tables together, I think I would live with the error of treating 96-100 the same and not adding the 2nd roll to the 1st roll. It may decrease the probability of 1-5 on the subsequent table (97-101 on a manual 2nd roll), but it simplifies the process.

This is really a FGC issue, at least for high open-ended d100 rolls, because FGU can handle them with the exploding die expression. A standard high open-ended roll would be expressed as "/die d100e96". Low open-ended rolls are still an issue.

I found a statistical discussion of open-ended rolls here: https://www.guildcompanion.com/scrolls/2009/jun/rmdicearticle.html

Bale Nomad

[Bale Nomad]

Should this discussion be moved to a new thread?

[Dakadin]

Should this discussion be moved to a new thread?

Yes, I moved them to a new thread so it doesn't sidetrack your random treasure module thread.

[Dakadin]

Dakadin,

That does get messy. If you were to do it that way, the modifiers would start with 0 on the "96" table and increase to +4 on the "100" table, because the open-ended roll result for 96 would actually start at 97 (96+1). Doing it this way would also change the statistical probability of getting another high end roll, so that also would need to be taken into consideration.

I am not a statistician, so I don't know the math well enough, but if I were putting the tables together, I think I would live with the error of treating 96-100 the same and not adding the 2nd roll to the 1st roll. It may decrease the probability of 1-5 on the subsequent table (97-101 on a manual 2nd roll), but it simplifies the process.

This is really a FGC issue, at least for high open-ended d100 rolls, because FGU can handle them with the exploding die expression. A standard high open-ended roll would be expressed as "/die d100e96". Low open-ended rolls are still an issue.

I found a statistical discussion of open-ended rolls here: https://www.guildcompanion.com/scrolls/2009/jun/rmdicearticle.html

Bale Nomad

Good points. What I need to do was adjust the 96-99 tables to be a range less based on the modifiers so 96 should have started at -3 (1-4) and maxed out at 96 (100-4). 96 would still link to the 100 table/unmodified table, 95 to the 99 table, etc. Then it would work like a high open-ended rolls. The problem then becomes the numbers won't look right when it continues to roll even though with that modification, it should work like a normal high open-ended roll.

An open-ended or low open-ended roll would be tough to do that way because of the nature of subtracting the results for all additional rolls when you start with a 1-5 result with the rerolls happen on 96-100 for the additional rolls.

Does the "/die d100e96" work on the tables? I definitely wish I could have used something that simple for the ruleset because coming up with the rolls in the CoreRPG version was a challenge.

[Bale Nomad]

No, the macro didn't work with the CoreRPG table. I started a new thread about it in the Unity playtest forum: https://www.fantasygrounds.com/forums/showthread.php?56121-Custom-Dice-Macros-for-CoreRPG-Tables&p=494819&viewfull=1#post494819

[Bale Nomad]

Dakadin,

Moon Wizard responded in the other thread that eventually the CoreRPG tables will work with more complex dice macros in FGU. The objective is to make sure everything from FGC works properly in FGU before introducing any such improvements on the old functionality.

Bale Nomad

[Dakadin]

Hi BaleNomad,

I modified the CoreRPG tables so that they will handle open-ended tables to the RMC ruleset. You don't have to add any dice. Just build the table and if the range of the table is greater than 100 it will figure out if the roll should be open-ended, high open-ended or low open-ended automatically and rolls the additional rolls if required then look up the appropriate table row and output it to chat like normal. It is currently on the test channel and will be released to the live channel on Tuesday. Here is a screenshot of the Human Conceptions and Children per Conception tables from Rolemaster Companion 1 that you used as an example. It took me a few rolls to finally get an open-ended high roll though. :)
39286

I already added the 4 missing tables from Character Law that involved open-ended rolls or were closely related to them. Those are in with the open-ended tables update. Here is the list of new tables:
* [Added] Character Law Table 04-03: Size Table as CoreRPG Table
* [Added] Character Law Table 04-04: Build Frame as CoreRPG Table
* [Added] Character Law Table 08-11: Purchase Price Chart as CoreRPG Table
* [Added] Character Law Table 08-12: Resale Price as CoreRPG Table

I am going to work on the Creatures & Treasures tables to try to make the following weeks release since most of those tables are open-ended I wanted to wait for this feature.

Please let me know if you have any questions.

Thanks,
Dakadin

[Bale Nomad]

Dakadin,

Very cool! Thanks for your hard work. I threw together a quick test table and it worked perfectly!

Bale Nomad

[Dakadin]

The C&T tables are taking more work than expected so they won't make the release this week. Hopefully next week. :)