log in or register to remove this ad

 

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

Bagpuss

Hero
Getting a load of 502 Bad Gateway errors at the moment.

I have had them occasionally before but it is virtually constant at the moment. Just trying to update a table to correct errors in it.
 

log in or register to remove this ad


Bagpuss

Hero
Only hitting a save. I tried some minor edits and sometimes they would be okay. There was a particular switch command I was trying to fix that didn't seem to take, once it did then the problem had gone. Not sure if that was related or not.
 


Pelldom

First Post
Actually, that's almost the exact behavior I've seen too. Hitting save and get the error, go back and I get ONE chance to make any corrections. If I get a 502 error a second time, it will clear all but the first two lines of the table and I have to start from scratch. And I recall making edits to switches when this happens too. I've got to the point that unless I've got a full hour or so to build a single table, I don't bother because I now expect it will take me a couple tries.
 


Pelldom

First Post
I got the 502 error again. I did have a typo in a {switch} on one entry. Could it be part of the error checking to do with switches? I fixed the error and it worked fine.
 

Morrus

Well, that was fun
Staff member
O.G.R.E.

I haven't seen the error myself, and I've tried editing a bunch of tables. I need to narrow down when it happens before I report it.

So our best working theory so far is switch typos?
 


Pelldom

First Post
Something else I thought of that might cause the issue is whatever the process is that runs the switch (or other functions) in order to generate the preview view of the table. Just a thought
 

Bagpuss

Hero
Not sure if this is a bug, but the loop function doesn't work with a variable. So you can't do something like....

Code:
{$num: {1d2+1}}{print: $num} events occur.  {loop: $num}{Bagpuss(543C)|firstcap}{/loop}

As it only ever does one result.
 

Pelldom

First Post
that must be something new. I've used dice scripts in loops before and it worked fine. Tried to find an example but didn't get a chance...
 


Bagpuss

Hero
|firstcap command is a little faulty and can lead to lower case letters.

I tend to write my tables starting with a lowercase letter, so that if needed I can have some lead in to the sentence. Then if I don't have a lead in I use the |firstcap command.

Now some times the table result will be more than one sentence, in which case it is written like so.

"the first sentence starts lower case. The second with a capital but no full stop"

So I can fit it in the middle of a generator if need be. Unfortunately |firstcap does this to the sentence.

"The first sentence starts lower case. the second with a capital but no full stop"

This is a bug as |firstcap should do this The first letter of the first word in the sentence is capitalized like this. but all it actually does is swap the case of the first letter in every sentence.
 

Morrus

Well, that was fun
Staff member
firstcap make the first letter of an entity (ie a table entry) uppercase and the rest lowercase. The use of 'sentence' is misleading - it doesn't know what a sentence is.

I have an update from the developer re. user inputted variables:

I have not fully completed the user-input system; I still have to add the functionality to grab variables from generators within generators within generators, etc., but the useage of user-input variables and the setting of them is completed, so I have uploaded that part to Enworld.

To add a custom user-input variable, start creating a generator, then click the "Add A User-Input Varibale" link. This will make some forms appear.


The "Name" form will change how you refer to the variable in the generator. For instance, if you entered "gender" into the name form, you would refer to the variable in the generator with "{print:$gender}" or "{if:$gender=male}" etc. The "Name" form will also be the title of the variable when it's displayed on the view_block page.


Each "Option" form will change what the variable's value will be. For instance, if you made a variable named "gender" and gave it the options "male" and "female," {print:$gender} would either output "male" or "female' depending on which is selected by the user.


The "Add Option" link will add another option to the variable it is in. You must have at least two options for each variable. The page won't let you submit if you don't.


Clicking the "Preview" link inside each user-input variable will change the forms into a select box, so you can preview how the generator will output with the different options. After you clicked the "preview" link inside a variable, it will change into an edit link, which will let you edit the options and add/delete options again.


If you don't click the preview button inside a variable, it will output as "Variable Value" when you previewing the generator.


After you've submitted or edited a generator with custom user-inputs, each variable will appear as a select box for the user to choose from in the view_block page.




Please let me know if it works correctly for you or if you have any questions about the functionality.


I'll probably be done with the rest of the user-input functionality pretty soon.
 

Bagpuss

Hero
firstcap make the first letter of an entity (ie a table entry) uppercase and the rest lowercase. The use of 'sentence' is misleading - it doesn't know what a sentence is.

Any chance we could have a firstcap2 then that only changes the first letter to caps and leaves the rest as they are?

I have an update from the developer re. user inputted variables:

Looks cool I will give it a go.

Edit: Spotted a little error already...

"Add A User-Input Varibale"

Varibale?
 
Last edited:

Bagpuss

Hero
Okay I've made one has Culture as the input variable with four possible options then gives a random occupation and it seems to work.

I did have one problem with it while making it, seems there were some hidden COLOR formatting commands that ended up in the code, not visible in the editor but the code still read them so the switch command did recognise the word as matching the selection from the input. I copied the code into notepad then copied it back to remove all the formatting and then it worked fine.

I've just edited it:
It calls a table in which I've put a {print: $Culture} command, and it appears the variable is printed correctly. Which is nice.

Here's the code...

Code:
{print: $Culture} occupation {switch: $Culture}{case: Primitive}{Pelldom(420A)} {case: Nomad}{Pelldom(421A)} {case: Barbarian}{Pelldom(422A)} {case: Civilized}{Pelldom(423A)} {case: default}Something has gone wrong.{/switch} {Bagpuss(testing)}

And the table it calls at the end.
 
Last edited:


Bagpuss

Hero
Latest testing results....

Generator
Code:
{switch: $Race}{case: Japanese}{if: $Sex=Male}{$Name: {Bagpuss[Japanese Names - Male]}}{else}{$Name: {Bagpuss[Japanese Names - Female]}}{/if}{case: Spanish}{if: $Sex=Male}{$Name: {Bagpuss[Spanish Names - Male]}}{else}{$Name: {Bagpuss[Spanish Names - Female]}}{/if}{case: default}Arse!{/switch}

{print: $Race} {print: $Sex} {print: $Name}

{Bagpuss(Test of Name string)}

Note: Switches need a default value otherwise it acts weird, I use it to test if the entry has gone wrong.

Test of Name string table values

1 - {print: $Name} works in a dime store. {if: $Sex=Male}He's a prick!{else}She's a bitch!{/if}
2 -
I know a celebrity lawyer called {print: $Name}. {if: $Sex=Male}He's a prick!{else}She's a bitch!{/if}

Works like a charm.
 


Level Up!

An Advertisement

Advertisement4

Top