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
*Geek Talk & Media
[ d20statblock.org ] a grammar
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="tarchon" data-source="post: 358094" data-attributes="member: 5990"><p>CRGreathouse's question on another board got me looking at this. I think it is a good idea to have a standard format guide, but the restrictive way it's implemented seems excessive.</p><p></p><p>For instance, should we restrict <em>string</em> to a particular character set? Does that add something useful to the grammar? Sure, you need to keep out non-quoted delimiters, but why rule out, say, feat names like "Rock & Roll"? Another problem with the way this is done is that you haven't defined a character set. Very commonly, non-American platforms (even in English speaking countries) and even many older US computers will use different code pages from Latin-1 or alternative typefaces for localized encoding. If one of those is being used, you might be excluding half the alphabet and including any number of punctuation elements.</p><p></p><p>Also, if you do use UTF-8 (as someone recommended, and it's not a bad idea), restricting your characters the way you've done it will utterly hork with the encoding system. The only safe way to filter UTF-8 with single byte characters is to allow all 8-bit characters with the MSB set (see <a href="http://czyborra.com/utf/" target="_blank">http://czyborra.com/utf/</a>).</p><p></p><p>Personally, as an ex-software internationalizer, I would be inclined to recommend against any restriction on the makeup of strings besides what you need to avoid delimiter conflicts, which as far as I can tell excludes only ',' and ';' (and perhaps '(' and ')'). Maybe creating a field to indicate the character encoding would be good, but I think it's best left to the applications programmers to decide what they want to their apps to do with like Latin-4. Pass it through, don't mess with it if you don't have to mess with it.</p><p></p><p>Similarly, the capitalization restriction is unnecessary and potentially interferes with localization of the format. Many languages don't even have letter cases, and virtually all of those that do have different capitalization rules from English. Plus you again run into the problem that Ï in Latin-1 may not correspond to the capital of ï in a random character set.</p><p></p><p>Also, should <em>type</em> be restricted? If this is a general d20 format, I think it's safe to say there's a good chance that somebody with some d20 setting will want to use a different monster type someday. Same goes for Elemental subtypes. Dust, shadow, steam elemental, I've seen those in many contexts</p><p></p><p>It might be best not to wed the format to the 9-point alignment system either. </p><p></p><p>As a general rule with something like this, it's usually best not to restrict the options for the various fields any more than necessary.</p></blockquote><p></p>
[QUOTE="tarchon, post: 358094, member: 5990"] CRGreathouse's question on another board got me looking at this. I think it is a good idea to have a standard format guide, but the restrictive way it's implemented seems excessive. For instance, should we restrict [i]string[/i] to a particular character set? Does that add something useful to the grammar? Sure, you need to keep out non-quoted delimiters, but why rule out, say, feat names like "Rock & Roll"? Another problem with the way this is done is that you haven't defined a character set. Very commonly, non-American platforms (even in English speaking countries) and even many older US computers will use different code pages from Latin-1 or alternative typefaces for localized encoding. If one of those is being used, you might be excluding half the alphabet and including any number of punctuation elements. Also, if you do use UTF-8 (as someone recommended, and it's not a bad idea), restricting your characters the way you've done it will utterly hork with the encoding system. The only safe way to filter UTF-8 with single byte characters is to allow all 8-bit characters with the MSB set (see [URL]http://czyborra.com/utf/[/URL]). Personally, as an ex-software internationalizer, I would be inclined to recommend against any restriction on the makeup of strings besides what you need to avoid delimiter conflicts, which as far as I can tell excludes only ',' and ';' (and perhaps '(' and ')'). Maybe creating a field to indicate the character encoding would be good, but I think it's best left to the applications programmers to decide what they want to their apps to do with like Latin-4. Pass it through, don't mess with it if you don't have to mess with it. Similarly, the capitalization restriction is unnecessary and potentially interferes with localization of the format. Many languages don't even have letter cases, and virtually all of those that do have different capitalization rules from English. Plus you again run into the problem that Ï in Latin-1 may not correspond to the capital of ï in a random character set. Also, should [i]type[/i] be restricted? If this is a general d20 format, I think it's safe to say there's a good chance that somebody with some d20 setting will want to use a different monster type someday. Same goes for Elemental subtypes. Dust, shadow, steam elemental, I've seen those in many contexts It might be best not to wed the format to the 9-point alignment system either. As a general rule with something like this, it's usually best not to restrict the options for the various fields any more than necessary. [/QUOTE]
Insert quotes…
Verification
Post reply
Community
General Tabletop Discussion
*Geek Talk & Media
[ d20statblock.org ] a grammar
Top