Menu
News
All News
Dungeons & Dragons
Level Up: Advanced 5th Edition
Pathfinder
Starfinder
Warhammer
2d20 System
Year Zero Engine
Industry News
Reviews
Dragon Reflections
White Dwarf Reflections
Columns
Weekly Digests
Weekly News Digest
Freebies, Sales & Bundles
RPG Print News
RPG Crowdfunding News
Game Content
ENterplanetary DimENsions
Mythological Figures
Opinion
Worlds of Design
Peregrine's Nest
RPG Evolution
Other Columns
From the Freelancing Frontline
Monster ENcyclopedia
WotC/TSR Alumni Look Back
4 Hours w/RSD (Ryan Dancey)
The Road to 3E (Jonathan Tweet)
Greenwood's Realms (Ed Greenwood)
Drawmij's TSR (Jim Ward)
Community
Forums & Topics
Forum List
Latest Posts
Forum list
*Dungeons & Dragons
Level Up: Advanced 5th Edition
D&D Older Editions
*TTRPGs General
*Pathfinder & Starfinder
EN Publishing
*Geek Talk & Media
Search forums
Chat/Discord
Resources
Wiki
Pages
Latest activity
Media
New media
New comments
Search media
Downloads
Latest reviews
Search resources
EN Publishing
Store
EN5ider
Adventures in ZEITGEIST
Awfully Cheerful Engine
What's OLD is NEW
Judge Dredd & The Worlds Of 2000AD
War of the Burning Sky
Level Up: Advanced 5E
Events & Releases
Upcoming Events
Private Events
Featured Events
Socials!
EN Publishing
Twitter
BlueSky
Facebook
Instagram
EN World
BlueSky
YouTube
Facebook
Twitter
Twitch
Podcast
Features
Top 5 RPGs Compiled Charts 2004-Present
Adventure Game Industry Market Research Summary (RPGs) V1.0
Ryan Dancey: Acquiring TSR
Q&A With Gary Gygax
D&D Rules FAQs
TSR, WotC, & Paizo: A Comparative History
D&D Pronunciation Guide
Million Dollar TTRPG Kickstarters
Tabletop RPG Podcast Hall of Fame
Eric Noah's Unofficial D&D 3rd Edition News
D&D in the Mainstream
D&D & RPG History
About Morrus
Log in
Register
What's new
Search
Search
Search titles only
By:
Forums & Topics
Forum List
Latest Posts
Forum list
*Dungeons & Dragons
Level Up: Advanced 5th Edition
D&D Older Editions
*TTRPGs General
*Pathfinder & Starfinder
EN Publishing
*Geek Talk & Media
Search forums
Chat/Discord
Menu
Log in
Register
Install the app
Install
Community
General Tabletop Discussion
*TTRPGs General
O.G.R.E: Online Generic Randomizer Engine
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="PaleMage" data-source="post: 6197410" data-attributes="member: 34768"><p><u>Scripting Primitives</u></p><p>{loop: X}: in my personal experience, loop accept variables if given in the appropriate format.</p><p></p><p>My <strong>Great Knowledge Library</strong> generator gets form user input a variable $Quantity, and passes it to a {loop: $Quantity} without any problem... </p><p></p><p>The current real problem is that {loop: X} has 3 BIG limitations, for scripting purpouses:</p><p>a. X cannot be greater than a <em>signed-integer</em> (-127/+127), and SHOULD be insteal a <em><strong>long-integer</strong></em> (there is no use of a negative loop);</p><p>b. {loop: X} has no way to control an exit condition while looping, so we need at least an <strong>{/exitloop}</strong> statement;</p><p>c. Best of all would be if we could get an additional <strong>{loopfor: condition}</strong> the same you get for an <em>{if: condition}</em>: this way you can exit loop whenever you meet that condition.</p><p></p><p><u>Additional features needed (Portal)</u></p><p>Ability to set an <strong>Hidden Flag</strong> for Tables/Generators. Subroutines created as <em>generators</em> 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.</p><p></p><p><u>Additional Field for Tables</u></p><p>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.</p><p>For example:</p><p>(CURRENT) Result: 1-3, Contents: {$key: MyKeyValue}MyContent, Output: MyContent</p><p>shoud become</p><p>(DESIRED) Result: 1-3, Contents: MyContents, Operations:{$key: MyKeyValue}, Output: MyContent</p><p></p><p>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.</p><p></p><p>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.</p></blockquote><p></p>
[QUOTE="PaleMage, post: 6197410, member: 34768"] [U]Scripting Primitives[/U] {loop: X}: in my personal experience, loop accept variables if given in the appropriate format. My [B]Great Knowledge Library[/B] 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 [I]signed-integer[/I] (-127/+127), and SHOULD be insteal a [I][B]long-integer[/B][/I] (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 [B]{/exitloop}[/B] statement; c. Best of all would be if we could get an additional [B]{loopfor: condition}[/B] the same you get for an [I]{if: condition}[/I]: this way you can exit loop whenever you meet that condition. [U]Additional features needed (Portal)[/U] Ability to set an [B]Hidden Flag[/B] for Tables/Generators. Subroutines created as [I]generators[/I] 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. [U]Additional Field for Tables[/U] 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. [/QUOTE]
Insert quotes…
Verification
Post reply
Community
General Tabletop Discussion
*TTRPGs General
O.G.R.E: Online Generic Randomizer Engine
Top