Reply to thread

Message

<blockquote data-quote="Janx" data-source="post: 5904588" data-attributes="member: 8835">most definitely, every table/block will have to be uniquely named.&nbsp; It's the only way this will work.TableSmith appears to have some advanced namespace naming schema so they can specify [Treasure.Art]But in simple terms, all that really means is they made a table called Treasure.Art and another table called Treasure.JewelryI definitely advice against allowing spaces.&nbsp; Spaces should be delimiters for parameters, values, and whatever else we need.&nbsp; Just like spaces are delimiters in normal writing (that means it seperates the words).that means [MORRUS EVIL DRAGON COLOURS] should really be [MORRUS_EVIL_DRAGON_COLOURS] or [MORRUS.EVIL.DRAGON.COLOURS] or [MORRUSEVILDRAGONCOLOURS] as examples.though I really like being able to use variables to recieve the value from a table or calculate a table name by concatenating variables, the refactoring and recursion check is happiest when it is guarranteed that we can search all text for [MORRUS EVIL DRAGON COLOURS] and replace it with [MORRUS.EVIL.DRAGON.COLOURS]any extra wierd crap in there makes it harder to do that with.this might be why TableSmith uses [] to denote a table reference and {} to do logic or dice notation.&nbsp; Basically clearing delineate the name of an asset (table or block) versus logical bits that have to be computed (like dice notation or if.else logic).Normal people are going to use the table notation.&nbsp; Keep it simple.Advanced users are going to use the logic notation, that needs to be robust enough for the job.</blockquote>

[QUOTE="Janx, post: 5904588, member: 8835"] most definitely, every table/block will have to be uniquely named. It's the only way this will work. TableSmith appears to have some advanced namespace naming schema so they can specify [Treasure.Art] But in simple terms, all that really means is they made a table called Treasure.Art and another table called Treasure.Jewelry I definitely advice against allowing spaces. Spaces should be delimiters for parameters, values, and whatever else we need. Just like spaces are delimiters in normal writing (that means it seperates the words). that means [MORRUS EVIL DRAGON COLOURS] should really be [MORRUS_EVIL_DRAGON_COLOURS] or [MORRUS.EVIL.DRAGON.COLOURS] or [MORRUSEVILDRAGONCOLOURS] as examples. though I really like being able to use variables to recieve the value from a table or calculate a table name by concatenating variables, the refactoring and recursion check is happiest when it is guarranteed that we can search all text for [MORRUS EVIL DRAGON COLOURS] and replace it with [MORRUS.EVIL.DRAGON.COLOURS] any extra wierd crap in there makes it harder to do that with. this might be why TableSmith uses [] to denote a table reference and {} to do logic or dice notation. Basically clearing delineate the name of an asset (table or block) versus logical bits that have to be computed (like dice notation or if.else logic). Normal people are going to use the table notation. Keep it simple. Advanced users are going to use the logic notation, that needs to be robust enough for the job. [/QUOTE]

Verification