log in or register to remove this ad

 

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


log in or register to remove this ad

Morrus

Well, that was fun
Staff member
Update from the developer:

I have completed the functionality for calling generators to grab the input variables from the generators they call. Now when you view a generator on the view_block page, all of the input variables from all of the generators it uses, including itself, should be a available to you.

One note:
If the calling generator happens to have an input variable with the same name as one that of the generators it uses has, the options in the calling generator will take precedence over the options in the called generator. So, for instance if you had a generator called [my_car] with a variable named "car" and the following options:

-Honda
-Ford
-Chevrolet

and [my_car] also happened to use a generator called [special_car] that a variable named "car" that had the following options:

-Ford
-Accord
-Dodge

you would only have the following options when viewing [my_car] on the view_block page:

-Honda
-Ford
-Chevrolet
 


Morrus

Well, that was fun
Staff member
New update! Tags/similar generators. These will form an important part of the process of finding generators and tables as the database gets bigger and bigger.

There is now an option to add tags when you create/edit a generator or a table. When you view that generator or table, the system will use its tags to look for matches with other generators or tables depending on which type you are viewing. If you are viewing a generator, it will look for generators with matching tags; if you are viewing a table, it will look for tables with matching tags. Tags are the crucial part of this system, so if a generator has no tags or if no other generator has matching tags, no similar generators will be found.
 

sevenbastard

Adventurer
This is a great tool! Can someone point me to a resource where I can learn more about Scripts? I am creating a random character generator for my house rules. Step one was easy, roll randomly for Race and then I want to set up a second role that takes the race value rolled and references a second table that then rolls for the class based on the race.

I was able to make this work by having the second table referenced as the result of the first table, but I would like to put this in the generator if that possible I believe that is what scripts are for but I’m a rookie at this.
 


Morrus

Well, that was fun
Staff member
So some minor updates:

1) I'm having an INT (and roundup/roundown) function quickly added.

2) Then it will be the mobile API, so you won't see any changes here for a while.

3) Then we can look at the bugs/feature requests.
 

Morrus

Well, that was fun
Staff member
Hey [MENTION=3987]Bagpuss[/MENTION], have you guys given up on converting that book of tables?
 



Morrus

Well, that was fun
Staff member
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
 


PaleMage

Explorer
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.
 
Last edited:

Morrus

Well, that was fun
Staff member
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

Explorer
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.
 
Last edited:

Morrus

Well, that was fun
Staff member
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

Explorer
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
 
Last edited:

Morrus

Well, that was fun
Staff member
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

Crusty Old Meatwad (he/him)
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

Explorer
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.)
 
Last edited:

Level Up!

An Advertisement

Advertisement4

Top