Page 2 of 3 First 123 Last
  1. #11
    phantomwhale's Avatar
    Join Date
    Aug 2007
    Location
    Melbourne, Australia
    Posts
    1,349
    Quote Originally Posted by Ikael View Post
    Indeed, these small changes can be done with easy find/replace, or xslt etc. But like said, I don't know 100% how much things are different, but I expect not much
    Given modules are read-only, you cannot perform these changes automatically from the ruleset. This means all commercial modules will need to be republished, and any user created content will stop working until they apply similar changes.

    This was what I'm facing with SavageWorlds currently, after cleaning up some node naming in 3.4. Perhaps we need to understand if a compatibility break is required for SavageWorlds on CoreRPG, and if so open up the dialog with Smiteworks again about this work (as much of the effort and repercussions would sit with them).
    I no longer develop for Smiteworks

  2. #12
    Ikael's Avatar
    Join Date
    Jan 2008
    Location
    Finland/Joensuu
    Posts
    2,024

    Campaign codebase compatibility check

    I made overview codebase compatibility check on SavageWorlds3 campaign (windowclass defined in campaign folder) codes and here are my results:

    Compatible, can be left away since features provided by CoreRPG covers everything
    • Stories (listing and sheet)
    • Note Sheet
    • Image listing
    • Item listing
    • NPC listing


    Compatible with minor changes
    • Note listing
      • root database node "note" is "notes" in CoreRPG

    • Image sheet
      • SW3 has scalebar tool which needs to be implemented on top of CoreRPG

    • Item sheet
      • windowclass "mundaneitem" is "item" in CoreRPG
      • databasenode wihtin mundaneitem "text" is "notes" in CoreRPG

    • Combat listing
      • root database node "combat" is "battle" in CoreRPG
      • windowclass "combatsmall" is "battlesmall" in CoreRPG
      • windowclass "combatlist" is "battlelist" in CoreRPG


    Compatible with bigger changes
    • Combat sheet
      • windowclass "combat" is "battle" in CoreRPG
      • windowcontrol "actorlist" is "npcs" in CoreRPG (databasenodes "actorlist" -> "npclist")
      • windowclass "combat_actorlistentry" is "battle_npcmaplink" in CoreRPG
      • windowcontrol "maplinklist" is "maplinks" in CoreRPG
      • SW3 has visibility feature for each combatant entry which needs to be implemented on top of CoreRPG
      • windowclass "combat_npcmaplinkitem" is "battle_npc" in CoreRPG



    Needs to be re-build since CoreRPG doesn't have them

    • Armors
    • NPC sheet
    • Weapons
    • Vehicles


    New feature-bases granted by CoreRPG
    • Treasure Parcels
    • Tables


    Note that this is quick review, but changes/differences are not massive for campaign codes. However there are differences like mundaneitem's text -> notes db naming, and combat encounters database node differences, but otherwise the only real thing that needs rebuilding is Armor, Weapons, Vehicles and NPC sheet.
    Last edited by Ikael; January 5th, 2014 at 17:03.
    "Alright, you primitive screwheads, listen up: THIS... is my BOOMSTICK!" -- Ash Williams, Army of Darkness

    Post your SavageWorlds ruleset feature requests and issue reports here!

    Enhance your core Savage Worlds ruleset with SW Enhancement Extensions, get more to savage!
    Want to create SW NPCs quickly? Use SW NPC Maker extension!
    Want to prove your dices are cursed or blessed? Try out SW Roll Statistics

  3. #13
    Viz's Avatar
    Join Date
    Mar 2008
    Location
    Port Charlotte, Florida, USA
    Posts
    24
    I expect to start a Savage Worlds campaign next month and would like to contribute to any rules update. I will be creating a module for the campaign, so I could also test that.

    I've played Savage Worlds for about 7 years and am very familiar with the rules.

  4. #14
    You may not need to compatibility break due to node naming, just change the naming as needed using the windowclass merge attribute that is part of the ruleset layering. See the existing rulesets layered on CoreRPG for lots of examples of merge="join" and merge="delete".

    Regards,
    JPG

  5. #15
    phantomwhale's Avatar
    Join Date
    Aug 2007
    Location
    Melbourne, Australia
    Posts
    1,349
    Quote Originally Posted by moon_wizard View Post
    You may not need to compatibility break due to node naming, just change the naming as needed using the windowclass merge attribute that is part of the ruleset layering. See the existing rulesets layered on CoreRPG for lots of examples of merge="join" and merge="delete".

    Regards,
    JPG
    Interesting, I need to read up more on this, I think. If I'm understating what you are saying correctly, this could sort out my own SavageWorlds now migrations, as well as ones required to work on top of CoreRPG.

    Once I get a better handle on the scope of the change, I'll be in a better position to figure out how people can best help out. Testing / finding bugs is normally the hardest part. Hopefully I can make use of the "Test" release channel in Fantasy grounds to get many more playtesters involved once it's feature complete; previous releases get tested by 2-3 people before going live, and that puts on the pressure to get it totally right first time!
    I no longer develop for Smiteworks

  6. #16
    Ikael's Avatar
    Join Date
    Jan 2008
    Location
    Finland/Joensuu
    Posts
    2,024
    After getting better understanding of layering ruleset building, I would recommend NOT to rebuild SW ruleset, instead use SW ruleset as base and remove resources from it which Core RPG is offering. I did test on both rebuilding and stacking and replacing and later is much faster approach. There are several features that can be "dropped" from SW ruleset base. To name but a few: story, notes, items, library, options (requires rebuilding parts of code). Actually the biggest issue is to disable CoreRPG from overriding some templates and features. They can be overridden later, but to make development smoother, it should be processed with small steps

    Edit: there is no sense to break compatibility! It is not worth it atm
    "Alright, you primitive screwheads, listen up: THIS... is my BOOMSTICK!" -- Ash Williams, Army of Darkness

    Post your SavageWorlds ruleset feature requests and issue reports here!

    Enhance your core Savage Worlds ruleset with SW Enhancement Extensions, get more to savage!
    Want to create SW NPCs quickly? Use SW NPC Maker extension!
    Want to prove your dices are cursed or blessed? Try out SW Roll Statistics

  7. #17
    Ikael's Avatar
    Join Date
    Jan 2008
    Location
    Finland/Joensuu
    Posts
    2,024

    Progression...

    Small attachment picture about progression. I have been able to make remove story, images, notes, tokens and moduleselection code from SW ruleset so that the functionality comes from CoreRPG. My approach has been to mark all CoreRPG codes with merge="delete" attribute and slowly return pieces of it in use and at the same time remove pieces of code from SW ruleset to make it happen. This approach works only for few elements in ruleset, and I don't have plans how to proceed after that. Any ideas are welcome
    Attached Images Attached Images
    "Alright, you primitive screwheads, listen up: THIS... is my BOOMSTICK!" -- Ash Williams, Army of Darkness

    Post your SavageWorlds ruleset feature requests and issue reports here!

    Enhance your core Savage Worlds ruleset with SW Enhancement Extensions, get more to savage!
    Want to create SW NPCs quickly? Use SW NPC Maker extension!
    Want to prove your dices are cursed or blessed? Try out SW Roll Statistics

  8. #18
    Ikael's Avatar
    Join Date
    Jan 2008
    Location
    Finland/Joensuu
    Posts
    2,024

    Some time later

    So far I have been able to easily make conversion from SW ruleset to use CoreRPG layering and enable following features from CoreRPG (and removing them from SW codebase):


    • Stories
    • Images
    • Items
    • Parcels (NEW!)
    • Notes
    • Module Activation
    • Library
    • Tokenbag
    • Modifers
    • Light-mood selection
    • Pointer-color selection
    • Portrait selection
    • Tables (NEW!)
    • Calendar (NEW!)


    Next will be:
    • Party sheet
    • Options
    • Effects
    • Combat
    • Export
    • Dicetower
    • Character selection


    Then I might double-check how updated templates and windowclasses differ from original ruleset logic.
    Attached Images Attached Images
    "Alright, you primitive screwheads, listen up: THIS... is my BOOMSTICK!" -- Ash Williams, Army of Darkness

    Post your SavageWorlds ruleset feature requests and issue reports here!

    Enhance your core Savage Worlds ruleset with SW Enhancement Extensions, get more to savage!
    Want to create SW NPCs quickly? Use SW NPC Maker extension!
    Want to prove your dices are cursed or blessed? Try out SW Roll Statistics

  9. #19
    Doswelk's Avatar
    Join Date
    Jul 2005
    Location
    Surrey, UK
    Posts
    2,091
    Looking at your screenshots what it will break is every theme I've ever done
    My players just defeated an army, had a dogfight with aliens, machine-gunned the zombies, stormed the tower, became Legendary and died heroically

    Yours are still on combat round 6

    Get Savage
    Ultimate License Holder.
    First GM to post a game for the original FG Con!

  10. #20
    phantomwhale's Avatar
    Join Date
    Aug 2007
    Location
    Melbourne, Australia
    Posts
    1,349
    Quote Originally Posted by Doswelk View Post
    Looking at your screenshots what it will break is every theme I've ever done
    This is an interesting and key point.

    I have been learning CoreRPG by looking at Castles and Crusades (which may players have shifted to for a while) and formulating how to migrate SavageWorlds onto CoreRPG whilst maintaining backwards compatibility with pre-existing data (e.g. for adventure modules) and code (e.g. for extensions and themes). Some breaks will have to happen to get onto CoreRPG, of course, but this needs to be as small and manageable set as possible.

    Basically there would be no point writing a SavageWorlds ruleset on top of CoreRPG if it broke most published code / data for the ruleset, as we couldn't (and wouldn't) ever publish it.

    I think, given some little bugs that still exist in the existing version, I was planning to have to keep a small branch for another "non-CoreRPG" version, but this will be for bugfixes and any code refactoring WITHOUT breaking compatibility, to bring the code closer to CoreRPG. The other branch of code would be one where the breaking changes happen, and these will need to be well-documented so extensions can be more easily ported without a lot of guesswork and experimentation, which I feel is what's happened in the past.

    Happy to get involved in an e-mail chat about what's going on, if people would prefer. I know Aki is doing a lot of work on this, and really hope it's something we can use in the next version. Equally I know Kevin has a longer history on the SavageWorlds ruleset then even myself, and I also have a couple of other people keen to help out with a new version, but that would need some co-ordination and process, which may or may not be something we can achieve.

    Ben (-PW-)
    I no longer develop for Smiteworks

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