SavageWorlds4 -- is it going to ever happen?

[phantomwhale]

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).

[Ikael]

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.

[Viz]

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.

[Moon Wizard]

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

[phantomwhale]

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!

[Ikael]

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

[Ikael]

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

[Ikael]

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.

[Doswelk]

Looking at your screenshots what it will break is every theme I've ever done

[phantomwhale]

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-)