Reply to thread

Message: <blockquote data-quote="Janx" data-source="post: 5904833" data-attributes="member: 8835">more hopefully clear techno-babble:I may have missed a point, given this stuff gets long and hard to see the scope of my own thesis...The Parsing Engine is a generic piece of code that should be fed input from any source. Be it Wiki, chat room post, new post from the forum, etc.  It should not be cognizant of where the text came from, it just parses it and performs the actions the Lookup and Script tags tell it to.As I explained in the long-winded example, with the way this thing will be implemented, you're not likely to suffer a problem from an infinite loop as 2 tables refer to each other.  The recursive nature of the parsing will cause a stack overflow and the Try..Catch block wrapping the entire thing will clean up the mess.Scripting is where you are likely to have security risks and true infinite loop problems.  Once the scripting languages get into being able to define loops, that's where it will get nuts.But don't worry about that yet.  Depending on what the scripting language enables, will determine your risk.When I say scripting, I mean any of the wierd stuff that people who like Programming will use, that normal people may not fully understand.calling for a dice roll is probably the simplest.  It requires a notation that is a directive to execute and produce a result. {1d6} is pretty easy, and the internet should be chock-full of code that can parse that and produce the result.Things get more complicated when you need to lookup on a table 1d6 times.{1d6 [Dragon]} would tell it to roll 1d6, and lookup the Dragon table that many times.Just that simple fragment has complexity.  The space between 1d6 and the [Dragon] tag is easily detected and we can tell that a quanity is required.But what of the results.  Say we roll a 4.  How do you want me to display the results?  Comma delimited?  Or one per line.  That's not so obvious.  And remember, this markup may be in the middle of a sentence.  One per line would wreck the sentence.  Comma delimited would work best for simple results.ExampleLet's see {1d6 [Dragon]} right now.produces:Let's see Ancient Blue Dragon, Young Red Dragon, Old Yellow Dragon right now.But what if the Dragon table produces stat blocks, not just name of dragons.we might need a way to indicate that we want comma delimited, or a new line per result.That's where functions might come in (just making this stuff up, so it may be rough):{1d6 Commatize([Dragon])} would produce the results with comma seperators{1d6 NewLine([Dragon])} would produce the results with a new line after each result.Then, let's get into variables.  Variables let us temporarily stash a value and then use it someplace else.  Including to construct the name of another table.Let's say we have a CR1Monster table and stat blocks for each (i'm onluy going to do one).[code]TABLE CR1Monster:1d41: Orc2: Elf3: Goblin4: FlumphENDTABLEBLOCK OrcStatblockOrcLikes eating elf meat.  Uses a sword.AC: 8Attack: +2, 1d8+2HP: {1d8}ENDBLOCK[/code]With that table and stat blocks created, I can do cool magic in a wiki or forum post.I can type up flavor text in a PBP game like:[GM]You enter the room and see a {$monstername=[CR1Monster]}.  It is ready to attack.  Here are it's stats:{Lookup($monstername+"StatBlock")}[/GM]and after the Parsing engine manipulates it before it saves to the forum, it would then show up to everybody in my post as:[GM]You enter the room and see a Orc.  It is ready to attack.  Here are it's stats:OrcLikes eating elf meat.  Uses a sword.AC: 8Attack: +2, 1d8+2HP: 7[/GM]If you follow what's happened, I stashed the result from looking up a CR1Monster into a variable called $monstername.  I then used that to programmatically declare the next thing to lookup which was "OrcStatBlock".I can't do that without a variable.</blockquote>

Verification