O.G.R.E: Online Generic Randomizer Engine

[Morrus]

Just for reference, here's the current list of minor fixes being worked on before moving on to new functionality:

1) That generator/table list on the right to be split into two lists - tables and generators.

2) There's some issues with the CAPS control syntax. I can't quite work out what it is, but it doesn't always work as expected. What I think is happening is that nested (through tables/generators) caps control statements are conflicting with each other, making it impossible to fully control the outcome. The easy fix for that issue, I think, is to simply say that only the top layer caps control statement applies.

3) Change it so that non-registered members can execute generators.

4) {loop: X} - While loop will currently accept the dice script to run a variable number of times, it does not currently accept variables. For example {loop: {1d4+1}} is valid, while {loop: $value} is not. This makes it hard to use a variable multiple times, or print the variable for example You have X random encounters then run a loop X times.

5) Mathematical processes on numeric variables - I've noticed that {$age: {2d6}}{$trueage: {$age+16}} works to give a result between 18-28 for $trueage, you can even do something like {$trueage: {$trueage+10}} and that works. However you can't do something like {$a: {2d6}} {$b: {2d6}} {$c: {$a+$b}} {print: $c}, as it throws a wobbler when you try to add to variables. Variables need to be able to interact.

6) Generator category called "Testing" has been set up for folks to play around with. Will be set so items in that category don't show on the front page. Folks will need to move their generators to a more appropriate category for it to show up there.

And here's a potential list of future functionality:

Mobile API
Allowing images as table fields
Data lookups
Repetition prevention
Embedding generators
CMS widgets and forum sideblocks
Importing tables as comma delineated lists
Pre-populating the die roll column with a 1-x sequence of numbers

 

[Morrus]

The 6 listed items/fixes in my previous post have now been implemented.

 

[PaleMage]

Scripting Primitives
{loop: X}: in my personal experience, loop accept variables if given in the appropriate format.

My Great Knowledge Library generator gets form user input a variable $Quantity, and passes it to a {loop: $Quantity} without any problem...

The current real problem is that {loop: X} has 3 BIG limitations, for scripting purpouses:
a. X cannot be greater than a signed-integer (-127/+127), and SHOULD be insteal a long-integer (there is no use of a negative loop);
b. {loop: X} has no way to control an exit condition while looping, so we need at least an {/exitloop} statement;
c. Best of all would be if we could get an additional {loopfor: condition} the same you get for an {if: condition}: this way you can exit loop whenever you meet that condition.

Additional features needed (Portal)
Ability to set an Hidden Flag for Tables/Generators. Subroutines created as generators called without the proper $variables set could end up in strange behaviors... better if we can hide them form direct use by portal, having them being used only by Tables and other Generators.

Additional Field for Tables
For scripting purpouses, I've been force to add {$variables: x} to the Content Field of Tables: they are executed but not shown (correct), but this way tables are not so clean as a casual user would expect. I suggest to add an additional field (i.e. Operations) where to put {scripts, variable, and the like} not directly connected to the desired content output.
For example:
(CURRENT) Result: 1-3, Contents: {$key: MyKeyValue}MyContent, Output: MyContent
shoud become
(DESIRED) Result: 1-3, Contents: MyContents, Operations:{$key: MyKeyValue}, Output: MyContent

Adding a field to all existing Tables is not a problem, because we have only to add a Field, and the existing would not be touched in any way. Of course, the operation field has to be executed any time you get that record result, as currently happens if you put scripts or Table/Generators calls in the Contents field... the purpouse is to execute scripts that does not generates outputs, but only calculations or $variables management.

Let me know: I will do a very large use of these features, and any users with a little programming skills would agree with me.

 

[Morrus]

I don't fully understand your first item (the looping exits one) - could you explain that again for me? Thanks!

The second - hidden tables - well, we could just have a table category for them. They won't be hidden as in invisible, but they'd be in the "don't use these unless you know what you're doing" category. Would that work?

The third item - additional table fields; makes sense. I'll ask the programmer if that's easily implementable! Just to check I'm fully grokking what you mean - that's just an aesthetic modification for clarity of use, rather than an actual functionality thing?

 

[PaleMage]

This night I added 2 new Tables.

PaleMage(Dragon_Names_Elements)
PaleMage(Dragon_Names)

Both of them are from Dragon Names Table, by Owen K.C. Stephens, originally printed in Dragon Magazine, issue 260, on pages 56-58.
See tables for the original link.

 

[Morrus]

Incidentally, there's new functionality currently being worked on, as requested by @Mistwell :

Using variables in table rolls. Now, this turned out to be more difficult than expected, since we hadn't designed the original setup with that in mind - and nobody thought of it until Mistwell mentioned it! So we've had to create a workaround. Instead of using a variable directly in the table roll field (e.g. 3d6 + $level), which we're not able to do without some massive restructuring, we're adding a new way of calling a table.

This second way of calling a table (format yet to be decided) will call the table as normal, but will not roll on it. Instead, it will use a predetermined variable (which you have already defined or gathered elsewhere) and simply insert it. So you'll make your table roll separately, then call the table and tell it to use that number.

If that number results in an invalid result (higher or lower than the table range), you get an INVALID RESULT outpout in its place in your generator.

So. You could do this:

Input $level as a user variable
{$roll: {$level+{3d6}}}
Call table {Morrus:WildernessEncounters} and use the value of $roll instead of rolling on it

For that third line, we've yet to implement the formatting. We might use square brackets.

It's slightly less elegant than desired, but the amount of restructuring we'd need to do it the obvious way is quite significant.

 

[PaleMage]

I don't fully understand your first item (the looping exits one) - could you explain that again for me? Thanks!

An example does more than thousend words.
My Library generator loops $Quantity times until it reaches the amount of books desired, BUT it has to check also if the Running $Total of books produced has been exceeded. Currently I have no way to say to the loop to stop looping, because the second condition (Running Total) could happen before I generated all the $Quantity books. If I reach a condition while looping, I need a statement like {/exitloop} (usually is {/exit}) to say to the loop to stop and let me exit from looping. Currently I'm forced to run the remaining loops times (and, more important of all, use SERVER CPU TIME) to produce books that I will never show to users. This is what's for the {/exitloop} statement: save SERVER CPU TIME.

The second - hidden tables - well, we could just have a table category for them. They won't be hidden as in invisible, but they'd be in the "don't use these unless you know what you're doing" category. Would that work?

Yes that's it. If You run the Great Knowledge Books generator, You get a $variable not set warning, because this generator is meant only to be called by the Great Knowledge Library generator, not for direct users use. You got the point, anyway.

The third item - additional table fields; makes sense. I'll ask the programmer if that's easily implementable! Just to check I'm fully grokking what you mean - that's just an aesthetic modification for clarity of use, rather than an actual functionality thing?

Definetely YES. Both Contents field and the new Operations field has to be able to run scripts, call tables and the like, but the only field that produces output will be, as currently is, Contents. The presence of the new Operations field give developers a place where to make calculation and $variables operations aside of user output, leaving all more clean and understandable.

Feel free to continue asking for clarifications. PaleMage

 

[Morrus]

That makes sense - thanks! I'll get those on the list of things to do! The first one seems the most important. Might be a month or two, though.

 

[Mistwell]

Incidentally, there's new functionality currently being worked on, as requested by @Mistwell :

Using variables in table rolls. Now, this turned out to be more difficult than expected, since we hadn't designed the original setup with that in mind - and nobody thought of it until Mistwell mentioned it! So we've had to create a workaround. Instead of using a variable directly in the table roll field (e.g. 3d6 + $level), which we're not able to do without some massive restructuring, we're adding a new way of calling a table.

This second way of calling a table (format yet to be decided) will call the table as normal, but will not roll on it. Instead, it will use a predetermined variable (which you have already defined or gathered elsewhere) and simply insert it. So you'll make your table roll separately, then call the table and tell it to use that number.

If that number results in an invalid result (higher or lower than the table range), you get an INVALID RESULT outpout in its place in your generator.

So. You could do this:

Input $level as a user variable
{$roll: {$level+{3d6}}}
Call table {Morrus:WildernessEncounters} and use the value of $roll instead of rolling on it

For that third line, we've yet to implement the formatting. We might use square brackets.

It's slightly less elegant than desired, but the amount of restructuring we'd need to do it the obvious way is quite significant.

Cool thank you Morrus!

 

[PaleMage]

Three more management Portal function I suggest.

Import/Export Tables
Someone has already asked this, but it would be very useful if You could import table contents via CSV (Comma Delimited Files). Mass updating of tables would be more easy. The same way, You could have an exported backup of your tables to CSV files.

Sharing
Currently, everyone owns his/her exclusive sets of Tables and Generators, but this limits growth of the shared DB. It would be very useful to implement a shared view of generators code to users, so to enable others to understand how You got that things running. Currently, generators code can be seen only by the owner, and should be easy to enable registered users to look at code read-only. This would enhance any other users skill in coding, being able to look at how others have managed their needs via coding.

Backup Copy of Generators
Sometimes happens that we modify a generator, expecially during testing, and sometimes happens that things goes wrong in some way. An easy 'Restore previous version' button would save a lot of copy and paste work we currently are forced to do anytime we change a single statement in our code. It would suffice to have a Generator_Name.bkp version of the previous save, and all turns on again.

Yes, I know, to be one that in 8 years wrote only 4 post I'm a little pressing, but "so far the service has been flawless." (cit.)