1. #1
    dulux-oz's Avatar
    Join Date
    Jan 2012
    Location
    Brisbane, Australia
    Posts
    3,949
    Blog Entries
    14

    Question Names, Version & Release Numbers - How Do They Interact?

    Hi Guys,

    Sorry for the long post but I wanted to spell things out explicitly - there's a Summary at the end to speed things up, if you like.

    I've had a search through the Forums can I can't seem to find anything on this. If it already exists, could someone please point me to the relevant thread(s).

    In the start of each Ruleset's base.xml file we'll find a line such as (these are from v3.0.9 of the CoreRPG, 3.5E & Pathfinder Rulesets, respectively):
    Code:
    <root version="3.0" release="3" logo="logo.png">
    <root version="3.0" release="14" logo="logo.png">
    <root version="3.0" release="1" logo="logo.png">
    I understand that the "version" refers to the version of FG and that the "release" refers to the version of the Ruleset.

    Further down in a Cascaded or Child Ruleset we'll find lines such as (these are from v3.0.9 of the 3.5E & Pathfinder Rulesets, respectively):
    Code:
    <importinfo>
    	<acceptfrom ruleset="d20" />
    </importinfo>
    <importruleset source="CoreRPG" />
    
    <importinfo>
    	<acceptfrom ruleset="d20" />
    	<acceptfrom ruleset="3.5E" />
    </importinfo>
    <importruleset source="3.5E" />
    So I understand that because the Pathfinder Ruleset has the <importruleset source="3.5E" /> line it will "Cascade" down from the 3.5E Ruleset - in other words (in Pseudo-Code):
    Code:
    Rule 1:
    If Ruleset X has <importruleset source="Y" /> then
    	Ruleset X will Cascade from (be a Child of) Ruleset Y
    Endif
    In an Extension we may find lines such as (these are from the Wiki):
    Code:
    <root version="2.0">
    
    <name>d20</name>
    <minrelease>12</minrelease>
    <maxrelease>12</maxrelease>
    I understand that the "version" in an Extension is the version of the Extension - the same as the "release" of a Ruleset.

    I also understand that the "name" in an Extension refers to the name of a Ruleset or another Extension and that the "minrelease" and "maxrelese" refer to the Ruleset or Extension version - in other words (in Pseudo-Code):
    Code:
    Rule 2:
    If Extension A has <name>Y</name>then
    	Extension A will interact with Ruleset Y (as per which Tag the "name" Tag is a child of)
    Endif
    
    Rule 3:
    If Extension A has <minrelease>nRelease1</minrelease> and
    		Ruleset Y has <root version="nVersion" release="nRelease2"> and
    		nRelease1 >= nRelease2 then
    	Extension A will interact with Ruleset Y (as per which Tag the "name" Tag is a child of)
    Endif
    
    Rule 4:
    If Extension A has <maxrelease>nRelease1</maxrelease> and
    		Ruleset Y has <root version="nVersion" release="nRelease2"> and
    		nRelease1 <= nRelease2 then
    	Extension A will interact with Ruleset Y (as per which Tag the "name" Tag is a child of)
    Endif
    
    Rule 5:
    If Extension A has <name>B</name> then
    	Extension A will interact with Extension B (as per which Tag the "name" Tag is a child of)
    Endif
    
    Rule 6:
    If Extension A has <minrelease>nRelease</minrelease> and
    		Extension B has <root version="nVersion"> and
    		nRelease >= nVersion then
    	Extension A will interact with Extension B (as per which Tag the "name" Tag is a child of)
    Endif
    
    Rule 7:
    If Extension A has <maxrelease>nRelease</maxrelease> and
    		Extension B has <root release="nVersion"> and
    		nRelease <= nVersion then
    	Extension A will interact with Extension B (as per which Tag the "name" Tag is a child of)
    Endif
    In a Module we'll find a line such as (these are from v3.0.9 of the 3.5E-basicrules & CSRDbasicrules Modules, respectively):
    Code:
    <ruleset>3.5E</ruleset>
    <ruleset>d20</ruleset>
    Now, I understand that both of these Modules can be loaded into the Pathfinder Ruleset because the Pathfinder Ruleset has the <acceptfrom ruleset="d20" /> and <acceptfrom ruleset="3.5E" /> lines and the 3.5E-basicrules Module has the <ruleset>3.5E</ruleset> line and the CSRDbasicrules Module has the <ruleset>d20</ruleset> line - in other words (in Pseudo-Code):
    Code:
    Rule 8:
    If Ruleset X has <acceptfrom ruleset="S-String" /> and
    		Module L has <ruleset>S-String</ruleset> then
    	Ruleset X will be able to open Module L
    Endif
    So, have I missed anything?

    Is all the above correct?

    If so, why is the 3.5E Ruleset able to open the 3.5E-basicrules Module: they DON'T follow Rule 8, nor is there anything I can find in the CoreRPG Ruleset which would allow this to occur (the CoreRPG can't open the 3.5E-basicrules Module, btw)?

    Summary

    Interaction Rules for Rulesets, Extensions and Modules
    Code:
    Rule 1:
    If Ruleset X has <importruleset source="Y" /> then
    	Ruleset X will Cascade from (be a Child of) Ruleset Y
    Endif
    
    Rule 2:
    If Extension A has <name>Y</name> then
    	Extension A will interact with Ruleset Y (as per which Tag the "name" Tag is a child of)
    Endif
    
    Rule 3:
    If Extension A has <minrelease>nRelease1</minrelease> and
    		Ruleset Y has <root version="nVersion" release="nRelease2"> and
    		nRelease1 >= nRelease2 then
    	Extension A will interact with Ruleset Y (as per which Tag the "name" Tag is a child of)
    Endif
    
    Rule 4:
    If Extension A has <maxrelease>nRelease1</maxrelease> and
    		Ruleset Y has <root version="nVersion" release="nRelease2"> and
    		nRelease1 <= nRelease2 then
    	Extension A will interact with Ruleset Y (as per which Tag the "name" Tag is a child of)
    Endif
    
    Rule 5:
    If Extension A has <name>B</name> then
    	Extension A will interact with Extension B (as per which Tag the "name" Tag is a child of)
    Endif
    
    Rule 6:
    If Extension A has <minrelease>nRelease</minrelease> and
    		Extension B has <root version="nVersion"> and
    		nRelease >= nVersion then
    	Extension A will interact with Extension B (as per which Tag the "name" Tag is a child of)
    Endif
    
    Rule 7:
    If Extension A has <maxrelease>nRelease</maxrelease> and
    		Extension B has <root release="nVersion"> and
    		nRelease <= nVersion then
    	Extension A will interact with Extension B (as per which Tag the "name" Tag is a child of)
    Endif
    
    Rule 8:
    If Ruleset X has <acceptfrom ruleset="S-String" /> and
    		Module L has <ruleset>S-String</ruleset> then
    	Ruleset X will be able to open Module L
    Endif
    My Questions
    (Briefly Repeated)

    So, have I missed anything?

    Are the Rules as I've stated them correct?

    If so, why is the 3.5E Ruleset able to open the 3.5E-basicrules Module: they DON'T follow Rule 8?

    Cheers
    Last edited by dulux-oz; November 20th, 2014 at 06:34.
    Dulux-Oz

    √(-1) 2^3 Σ Π
    ...And it was Delicious!


    Alpha-Geek
    ICT Professional
    GMing Since 1982
    NSW, Australia, UTC +10
    LinkedIn Profile: www.linkedin.com/in/mjblack

    Read my FG Blog here.

    Watch our games on Twitch: www.twitch.tv/dulux_oz

    Support Ongoing Video, Ruleset & Extension Development: via PayPal (Send To: [email protected])

    YouTube Channel/Tutorial Playlists: www.youtube.com/c/duluxoz

  2. #2
    Didn't pick through it in detail, but looks reasonable from a scan-through.

    There is always an implied <acceptfrom> tag for the current ruleset name.

    Regards,
    JPG

  3. #3
    dulux-oz's Avatar
    Join Date
    Jan 2012
    Location
    Brisbane, Australia
    Posts
    3,949
    Blog Entries
    14
    Quote Originally Posted by Moon Wizard View Post
    Didn't pick through it in detail, but looks reasonable from a scan-through.

    There is always an implied <acceptfrom> tag for the current ruleset name.

    Regards,
    JPG
    Sorry, could you develop that point more fully, sir - is that how the 3.5E Ruleset is able to open the 3.5E-basicrules Module, because "3.5E" is the current (or, should I say "default") Ruleset name?

    Cheers
    Dulux-Oz

    √(-1) 2^3 Σ Π
    ...And it was Delicious!


    Alpha-Geek
    ICT Professional
    GMing Since 1982
    NSW, Australia, UTC +10
    LinkedIn Profile: www.linkedin.com/in/mjblack

    Read my FG Blog here.

    Watch our games on Twitch: www.twitch.tv/dulux_oz

    Support Ongoing Video, Ruleset & Extension Development: via PayPal (Send To: [email protected])

    YouTube Channel/Tutorial Playlists: www.youtube.com/c/duluxoz

  4. #4
    Each module can specify which rulesets that they are created for.

    Each ruleset can specify additional rulesets for which they are "module-compatible".

    When a ruleset requests a list of available modules through the FG API, any matching modules (those which have a ruleset tag matching the current ruleset or an importinfo tag in the ruleset) will be returned.

    Regards,
    JPG

  5. #5
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Denver, Colorado, USA (for a bit)
    Posts
    23,534
    As an example, the PFRPG ruleset has the following in it's base.xml file, allowing modules made for 3.5E and d20 rulesets to be opened in a PFRPG campaign (as well as modules made for the PFRPG ruleset itself):
    Code:
    	<importinfo>
    		<acceptfrom ruleset="d20" />
    		<acceptfrom ruleset="3.5E" />
    	</importinfo>


    FG Product Development status: Pathfinder Playtest Ruleset and add-ons: In development. Pathfinder Bestiary, Pathfinder Bestiary 2, Pathfinder Bestiary 3 (in store).

    Private Messages: My inbox is forever filling up with PMs. Please don't send me PMs unless they are actually private/personal messages. General FG questions should be asked in the forums - don't be afraid, the FG community don't bite and you're giving everyone the chance to respond and learn!

  6. #6
    dulux-oz's Avatar
    Join Date
    Jan 2012
    Location
    Brisbane, Australia
    Posts
    3,949
    Blog Entries
    14
    Quote Originally Posted by Trenloe View Post
    As an example, the PFRPG ruleset has the following in it's base.xml file, allowing modules made for 3.5E and d20 rulesets to be opened in a PFRPG campaign (as well as modules made for the PFRPG ruleset itself):
    Code:
    	<importinfo>
    		<acceptfrom ruleset="d20" />
    		<acceptfrom ruleset="3.5E" />
    	</importinfo>

    Yeah, I said that myself in an earlier post - but what I wanted to know was why the 3.5E Ruleset was able to open the 3.5E-basicrules Module when the 3.5E Ruleset DOESN'T have:
    Code:
    <importinfo>
    	<acceptfrom ruleset="3.5E" />
    </importinfo>
    Cheers
    Dulux-Oz

    √(-1) 2^3 Σ Π
    ...And it was Delicious!


    Alpha-Geek
    ICT Professional
    GMing Since 1982
    NSW, Australia, UTC +10
    LinkedIn Profile: www.linkedin.com/in/mjblack

    Read my FG Blog here.

    Watch our games on Twitch: www.twitch.tv/dulux_oz

    Support Ongoing Video, Ruleset & Extension Development: via PayPal (Send To: [email protected])

    YouTube Channel/Tutorial Playlists: www.youtube.com/c/duluxoz

  7. #7
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Denver, Colorado, USA (for a bit)
    Posts
    23,534
    Quote Originally Posted by dulux-oz View Post
    Yeah, I said that myself in an earlier post - but what I wanted to know was why the 3.5E Ruleset was able to open the 3.5E-basicrules Module when the 3.5E Ruleset DOESN'T have:
    Code:
    <importinfo>
    	<acceptfrom ruleset="3.5E" />
    </importinfo>
    Cheers
    You don't need to specify importinfo for the ruleset itself. It's assumed that a module made for the 3.5E ruleset will be able to be loaded in the 3.5E ruleset, for example. If you made a modified 3.5E ruleset, and perhaps called it MY_3.5E then you'd have to either modify all of your 3.5E modules to use MY_3.5E <ruleset> or use <importinfo> with 3.5E once in your custom ruleset.

    EDIT: the documentation on <importinfo> mentions: "This definition determines the list of other rulesets declared data compatible with the running ruleset."
    Last edited by Trenloe; November 26th, 2014 at 03:44.


    FG Product Development status: Pathfinder Playtest Ruleset and add-ons: In development. Pathfinder Bestiary, Pathfinder Bestiary 2, Pathfinder Bestiary 3 (in store).

    Private Messages: My inbox is forever filling up with PMs. Please don't send me PMs unless they are actually private/personal messages. General FG questions should be asked in the forums - don't be afraid, the FG community don't bite and you're giving everyone the chance to respond and learn!

  8. #8
    dulux-oz's Avatar
    Join Date
    Jan 2012
    Location
    Brisbane, Australia
    Posts
    3,949
    Blog Entries
    14
    Quote Originally Posted by Trenloe View Post
    You don't need to specify importinfo for the ruleset itself. It's assumed that a module made for the 3.5E ruleset will be able to be loaded in the 3.5E ruleset, for example. If you made a modified 3.5E ruleset, and perhaps called it MY_3.5E then you'd have to either modify all of your 3.5E modules to use MY_3.5E <ruleset> or use <importinfo> with 3.5E once in your custom ruleset.

    EDIT: the documentation on <importinfo> mentions: "This definition determines the list of other rulesets declared data compatible with the running ruleset."
    Yeah, and that's what I've come to understand during this discussion

    Cheers
    Dulux-Oz

    √(-1) 2^3 Σ Π
    ...And it was Delicious!


    Alpha-Geek
    ICT Professional
    GMing Since 1982
    NSW, Australia, UTC +10
    LinkedIn Profile: www.linkedin.com/in/mjblack

    Read my FG Blog here.

    Watch our games on Twitch: www.twitch.tv/dulux_oz

    Support Ongoing Video, Ruleset & Extension Development: via PayPal (Send To: [email protected])

    YouTube Channel/Tutorial Playlists: www.youtube.com/c/duluxoz

  9. #9
    The definitive answer to the original question should be put in the wiki…

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Log in

Log in