Importing multiple parties and individual characters into 'Initiative Tracker'

[samcorcoran]

The issue (#17) of importing of characters into parties in the 'Party Manager' will allow pre-made characters to get into the initiative tracker, however it may be desirable to import them individually as well. Importing multiple parties may also be extremely useful to GMs who wish to import both the set of pre-made 'player characters', as well as the set of 'non-player character' enemies that have also been pre-prepared as a separate party. The GM would the be able to track initiative and turn order for all involved entities on the same screen.

As mentioned tangentially at the end of the first post of issue #19, the Initiative Tracker currently stores the characters it displays inside a PTParty object. Switching to a generic data structure, or to a possible new 'PTEncounter' object, would remove the current limitation of displayed characters being party-mates.

Currently parties are imported using the 'Reset Encounter' button, and selecting "Use Default", as instructed by the dialogues text. This approach seems a little non-obvious, and the reset button may be best used simply to reset the encounter's initiatives and nothing else. Individual

Existing functionality to create a new character directly into the encounter should remain, as it provides flexibility. This currently seem to add the new character into the PTParty but does not update this outside of the Initiative Tracker.

Also needed would be an import button (or two) for characters and parties. Possibly a single import button which opens a dialogue that offers the choice of 'Import Character' or 'Import Party', each leading the a second dialogue based on choice.

The consequence of importing a character multiple times must be considered: if a character is imported individually, and then again through the importing of a party, they need to be added only once.

The ability to remove individual characters/parties from the encounter is also a consideration. Offering no individual removal function would be easier (e.g. through a 'hard reset' type button), but would be frustrating if a character or party was accidentally imported into an already-bustling encounter. Removal of characters from the encounter list/object on a character-by-character basis (no bulk-removal of parties) would be a simpler way to go. This could be done through another top-bar 'Remove Character' button (opening a list of characters with check-boxes that to indicate the desire for removal). This creates a need for a remove character button image.

This view would no longer respect the 'selected party' in 'Party Manager' (as currently the selected party is used to dictate which party is imported). This may have some ramifications to consider.

[tsiemens]

Sounds like a good idea. However, I am concerned about ordering. The easiest way would just be to add an encounter order field to the party members, but this starts to add to the unnecessary info they have like the roll value.

I'm starting to think that we may want to break this up more hierarchically, as in have a base campaign character or something to store the stats, which party member and encounter participant extend from. This could simplify the database storage, and reduce unused information.

To clarify what I am thinking: Object model: campaign character (has stats only) ----> encounter participant (roll value, order value)

Database: CampaignCharacter(current party member table, minus roll value) Party(id, name) PartyMember(campaign character id, party id) EncounterParticipant(campaign character id, roll value, order value)

I'm not sure how much of your proposal this would satisfy.

[samcorcoran]

I think that sounds sensible. Avoids duplication of character variables for use in party-related views.

It would also pave the way for later association (should it be desired) of in-combat states, such as "prone", "blinded", or "dead". These could exist as properties of EncounterParticipant, allowing them to be tracked during an encounter. These states would not need to meddle with the underlying Campaign Character information (though implementation of states for CampaignCharacters outside of the initiative tracker, such as 'diseased', may also be useful for players).

I'll create a separate issue for in-combat states so that any discussion of that topic happens separately to this thread (about importing characters and parties into encounters).

[tsiemens]

I'd say you should just go ahead and start modifying the database and datamodel for this then, as long as you are comfortable with that. There is a pretty standard pattern to follow, but a patch will need to be written in the patcher to update the db.

[samcorcoran]

Yeah, I think I'll start having a go at this soon. I'm beginning to get a good feel for how things work now (reading the android tutorial certainly helped...!) so I'll hopefully be able to make the model changes in keeping with the existing pattern.

Regarding deprecation of the existing model, does it simply need to be duplicated in its current form into deprecated/v2/model/* and then have the 'live' version edited, and appropriate patcher functions added?

Should existing patcher functions (for patching from v1 of model to v2) be kept, with new, overloaded functions for patching v2->v3 added as additionals?

[tsiemens]

No, we are not doing any more deprecated datamodels. the only reason we resorted to that was because of the really bad database we wrote before.

You will need to update and make a new database repository classes, and update the existing data model to match. Updated table creation queries will also be necessary. For the patch, we will probably just need to run a few custom SQL queries to add tables, columns, and shift the data around. I am quite familiar with how SQL works, so I may need to do that part if you are not.