WowAce

This is a big change idea, inspired by the recently-added content from RPHelper2.

Currently in SS 4.0.3.05 you can use a character-specific profile, or share that profile for all of your characters. This is a data set called EventTable.

I would prefer to have multiple overlapping profiles (separate EventTables) where I can separately edit subsets of my event triggers and speech lists, in order to share subsets of those speeches among all my toons, while still retaining some toon-specific speech triggers.

This should include separate profiles (data sets) for:

• specific characters - speeches you only want to use for this character
• all characters - triggers and speeches shared by all your characters
• per class - shared by every toon you play that is the same class, i.e. all mages
• per race - shared by every toon that is the same race, i.e. all dwarves. This is the main inspiration for the feature idea
• per faction - shared by every alliance character, or every horde character
• per realm - shared by every character on a given realm server, but not used on other realms
• per guild(?) - shared by every character in a given guild, but not used by characters you have in other guilds
• user-defined profiles, such as my "roleplaying" data set, or my "evil" data set.

Each character would have the option to enable/disable the set of profiles you want that character to use. You wouldn't be forced to use all of the EventTables that apply to that toon's race, class, faction, realm, and guild.

The default settings for a new character would enable the profiles that apply to your race, class, realm, faction, and guild... the player would still have the option to turn some of these on or off per-character.

That's basically what it does now (SS 4.0.3.05) but it does that by copying all of the applicable defaults into your single EventTable (which is either character-specific or shared) ... so the enhancement suggestion here is to keep those data sets separate, to be able to share them properly between different characters, rather than merge them all together into one active EventTable.

Behind the scenes, the data will have to be merged together in some way in order to get the find the enabled triggers from all of the content packs, and get the right kind of random selection of speeches.

Data structure design...

I have always wanted to bring the data structure of DefaultSpeeches-xxXX.lua in line with the data structure of the SavedVariables.

So I'd like this to use the "template" data structure from DefaultSpeeches, because that includes the Template.Attributes table, which declares that a given content pack (each "template") is intended to be used for a declared race, class, or faction.

This would make it easier for people to create custom content packs and share them, and it would be a much easier copy-paste from SavedVariables into DefaultSpeeches to begin included someone's content pack within the defaults.

(TBD) Character names should not be included in the attributes table. Which characters use this content pack is not an attribute of the content pack itself - it's an optional setting for that specific toon. The content pack is still intended for a certain race/class/faction (and I always had in mind to add a "good for roleplaying" attribute, or we call it an "in-character" vs. OOC attribute) and the character's options override those attributes. This my initial assessment of the idea, but it merits more thought per GUI design considerations, as well as backend operation in the speech engine.

GUI design...

Message Settings - would need a way to select which content pack you want to edit. This concept will make it harder to find a speech trigger that you want to change. "/ss recent" can still get you there easily, but what if you're just browsing? It calls for a way to select "the active content" merged content pack in the GUI. That would be a GUI-layer illusion that needs to be able to get to the underlying separate data tables and present them in the GUI as if it's actually one data table... and save the changes to the correct place.

Create New - needs to make you choose where to store the new event trigger: in which content pack or profile - or in a new separate content pack?

Import New Data - needs to make you choose where to store the imported event triggers or speeches. It should also support the ability to bring in the entire content pack as a content pack, which you can then enable/disable per toon - keeping that content pack as its own content pack.

New content pack management window - needed to create/delete whole content packs, and to select which content packs you want the current character to use. TBD: consider whether this new window should let you manage which content packs are used by all your other toons, or just the one you're logged into right now. I'm thinking you should be able to select and manage a toon other than the one you're logged into.

Speech Engine Core...

I think it demands a unified EventTable behind the scenes which contains all of the active triggers and speech lists that are pulled in from all of the selected content packs. The code (SS 4.0.3.05) is all funneled through a a subroutine called GetActiveEventTable() which can easily be changed to return this merged table, instead of returning the "raw" table from your SavedVariables (with logic to choose either the table for that one toon or the shared table for all toons)

I'd like to support freely defining the same trigger in multiple content packs, possibly with some overlapping speeches. For example the "Dire Lemming's Paladin" content pack vs. the default rez speeches may include some overlap, and this should be resolved behind the scenes, rather than restricted in the GUI.

So the merged EventTable needs to work that out, exclude duplicate speeches, and check for conflicting random chances and cooldowns.

For example it would become theoretically possible to set one content pack to announce a spell with a 10% chance and no cooldown, while the other announces it with a 100% chance but 5 minute cooldown... what do we use in the merged table?

Conflicts could also arise with chat channels if a trigger is set to use /say in one content pack, but /party in another.

Dependencies also come into play with <randomwords> if a speech in one content pack is using <randomword> defined in a different content pack.

<randomword> lists are easy to merge, but will the results be desirable?

Giving this a low priority because it's a huge change that needs to be cut down into smaller baby steps.

I'm re-assigning all my tickets to Duerma

Unassigning tickets that are not actively being worked on