Reply to thread

Message: <blockquote data-quote="Janx" data-source="post: 5904794" data-attributes="member: 8835">I probably wouldn't use the word Generator, but that's because I have a specific meaning for Block.Both a Table and a Block produce a result.  Tables by default generate a short fragment of text (due to the way 1 line defines 1 result in the table definition, there's just no room.A Block is a big pile of text, rich text, html, vBulletin formatted text, makes no difference.  Think of putting a whole statblock in there or Monster Manual entry, including image tag for the picture.  You can't fit that in a table, but you can make table entry 2 for orc point to [OrcStatBlock] which would cause the Parsing Engine to getch the block and return that as the result for the table.As for working with vBulletin, I don't have experience coding for it.  But generically speaking, we define the Parsing Engine (or Generator as it is do-er of things) to recieve some text (from a wiki, vbulletin post, new web form, whatever), and it parses for those [] and {} tags.  It then does whatever we mean for those to do.The parsing action is a recursive behavior.  Meaning that it reads a string "Results from the dragon table = [dragon]" and it finds the dragon table, rolls on it and then parses THAT result which might refer to another table or block (so we can display the stat block).  From the parsing engine's perspective, each result, is new content to parse and deal with.  This is how the nesting of tables works in any of these table systems.Now for explaining the infinite loop-check concept (which is a rough idea I made up and if it was unique and clever I'd patent):First off, we know EVERY table is going to have a unique name.  and each result row in the table MIGHT refer to another table.  Ideally, we want to avoid a circle or infinite loop.  When we're in the editor for a signel specific  table, we should perform a number of validation checks.  Make sure the table name is unique in the system.  Fix any other tables that refer to this one if we renamed it (that's called Refactoring in programmer speak).  We also want to see if our table is called anywhere else in our chain of tables.Let's make up some fake tables.  Pretend that MyTable is the one we're currently editing and thus will be checking for infinite loops from its perspective.[code]TABLE MyTable: 1d21: [Devils]2: [Demons]ENDTABLETABLE Devils:1d31: Satan2: Santa3: BeelzebubENDTABLETable Demons:1d41:Balor2:Baatezu3:Sucubus4:[Ridethebus]ENDTABLETABLE Ridethebus:1d31:Short2:Long3:[MyTable]ENDTABLETABLE Unrealted:1d11:Dude, this is totally unrelatedENDTABLE[/code]Let's pretend all this is defined as 1 file per table (ex. MyTable.txt).  Before I save MyTable.txt, I can scan all the files for the previous name of the table (let's say I just renamed it from JanxTable to Mytable).  I can find all instances of [JanxTable] and replace with [MyTable].  That will make sure tables don't break when somebody renames a table for whatever reason makes sense at the time.  This is a HUGE problem in code, and very valuable to help with.Using a similar trick, with the help of the Parsing Engine put into a debug mode, we can get a list of ALL the tables that chain from MyTable.Here's what we find, aranged as a tree:MyTable..Devils..Demons....Ridethebus......MyTableIf we find our table name "MyTable" undeneath the top of the tree, we have an infinite loop scenario.the idea is that you do this detection IN the editor, before it saves, allowing you to nip the problem in the bud.You can also use this trick to validate that a table refers to other valid tables, preventing dead-ends that won't resolve.Though, as I explained about the Parsing Engine, it is recursive (self-referencing).  Each tag instantiates a nested call to itself.  The operating system handles the problem quite well if it goes too deep, so it will throw an exception (an error that is trappable so we can gracefully terminate the work, without completely dying).  An infinite loop of this sort hits that limit much sooner than infinity and won't hog all your CPU or memory.</blockquote>

Verification