I’ve been keeping up the gca5.xsd for saved character files, and the current version of that is available here for the curious. There’s also an example character that shows some of that in an actual save file.
One primary bit
b104
* Edit Modes dialog
I have implemented the first draft of the Edit Modes dialog. This allows for editing, adding, and removing attack modes for traits. You can also drag the columns around to rearrange the order of the modes.
* Edit Items dialog
Added a button to launch the Edit Modes dialog.
* Advanced Edit dialog
Mode-enabled tags have been removed from the tag list in the Advanced Edit dialog.
With the mode tags removed, I had to add some code to preserve the mode data when moving in and out of this dialog.
Added an Edit Modes button to the bottom of the form, so that you can get to the Edit Modes dialog from here as well.
* Miscellaneous
Fixed a typo on the Options dialog.
Reverted a change I had made to where some event handlers for characters were enabled, due to that change resulting in dialogs and such being called two or more times for some events.
Given the reversion above, I have changed the updating of the UI for Unified view a bit to keep it updated correctly when changing to it when a character was opened in a different View.
Updated the character tab images so that the ‘unsaved’ icon should show when new traits get added to the lists.
Added some Interface references to some of the objects to allow simplifying things in some areas of code.
Made a small visual change to the attack modes in the Simple Edit display.
A mess of bits splattered about
b103
* Accessibility
I have just begun adding proper accessibility names and descriptions for things where I can. This will take time, but the excellent Windows Narrator built into Windows 10 is helping me identify the many places where I need to improve things.
The interface in GCA5 is pretty busy for screen readers. I’ll probably have to offer a stripped down version at some point.
* Miscellaneous
Added some code to let my controls display styled text if I want to update them to do so.
Added some additional error traps.
Restructured some code.
Repaired the code in Updater for integrating libraryupdates.xml into the new system that uses fileupdates.xml. The intent was that the old library update generator would still work for updating library specific book files, while the new general file update generator would allow for all files, including the library files if specified. At some point, the code for actually integrating the libraryupdates.xml information into the process was bypassed, but now it should be included correctly again.
Closing characters in the UI should trigger slightly less chaotic UI refresh behavior.
Characters should no longer be getting marked as Dirty every time they are loaded into GCA.
Having fixed the ‘Dirty’ issue mentioned above, I found that there was also an issue with how tabs were changing the ‘dirty’ or ‘clean’ image for the tab, so I changed how that is set.
Discovered a problem with where I was assigning certain event handlers for characters in the UI. Changed where they are assigned.
Changed some of the graphic elements for the third toolbar, to help clarify which ‘buttons’ are checkbox style, which are either-or radiobox style, and which are selected.
Changed the images used on the character tabs for ‘dirty’ and ‘clean’ characters.
Slightly improved some of the drawing code for trait boxes when drawing traits, group headers, and header information.
Added a character option for “No default level discount,” which effectively turns off the ability to improve skills from the default level, and requires every point spent to buy levels normally, ignoring any discount defaulting might have provided.
Added a button to Unified View which provides a horizontal override, similar to the existing vertical version. This mode limits boxes to the height of the display area, and turns off flow-wrapping of boxes in the worksapce. This allows for a horizontally scrolling workspace, and limits scrolling to within the lists themselves, rather than scrolling the entire workspace to move within long trait lists.
* Plugins
Recompiled for changes in interfaces and structures.
* Trait Viewports
Viewports are a new way of organizing traits for interaction and display. Basically, a Trait Viewport (Viewports for short) is a list of a particular type, such as Spells, that only includes those traits that meet specific criteria, such as all being Druidic. This new way of handling traits allows for much more freedom in what can be displayed and how the user can interact with it, over the previous way of being restricted to one list per type of trait.
In addition, with each Viewport being its own thing, it’s possible to match that up with particular display preferences based on the Viewport, so users can customize how they view different Viewports without it affecting other data of the same type.
GCA still organizes all traits internally by trait type (spell, skill, advantage, etc.), but each character will also track and manage all the viewports that are defined for it, so that they can be carried along whereever the character goes. Importantly, the Viewports are only saved in the character by definition, which is the criteria used to create it; the traits are not saved in the character file with that information actually applied to trait or list data, so you will not be able to just read the XML file to get a list of a Viewport’s traits; the Viewport will have to be created and filled somehow (which GCA does automatically while managing the character).
The display information for each Viewport, however, is user specific, and is not saved with the character at all. Different users or different computers or whatever may call for different display options, so those Viewport display options are maintained with the other user settings for your GCA installation. GCA has default settings for each type of trait, so loading a character with a Viewport that you’ve never specified settings for will result in the default settings for that type being applied.
I have created new trait boxes for Unified View, based on Trait Viewports. These new boxes embrace the whole new Viewport structure, including display options. Because of the changes, I’ve also changed how ordering is indicated in the column headers for the lists. Although the three standard color options (grey, red, yellow) are still provided, since they’re drawn into the header area using transparency, you may find the results often aren’t quite what you’d expect. The default ‘gray’ option tends to look best.
Trait Viewport Usage Notes
When building a Display Template for a Viewport:
You can format the TAG column of a Column two ways, if TagIsFormatted is True. If TagIsFormatted is False, then only the Tag name may be specified and only that value retrieved.
1) You can support String.Format() style substitution by including {X} markers where X is 0 through whatever.
Then include a comma separated list of values that will be inserted into the {X} markers. This list is counted from base 0, so the first item goes into {0}, second in {1}, etc.
This allows you to format the Tag field with whatever values you like, so long as the following list of values are valid Tags.
For example, you could use “{0} lbs, weight” for the Weight column of Equipment, where the value of the Tag ‘weight’ is inserted for {0}.
2) You can specify a numeric format for tag values that are themselves numeric values. If you do this for a non-numeric value, results will be unexpected.
You do this by including the keyword #format followed by the numeric format to use, best enclosed in quotes or braces (required if the format includes a comma).
The format uses the .Net Numeric Format strings, so there’s online docs for that out there.
For example, our Weight column could use “{0} lbs, weight #format {#,0.00}” to build on our example above, which formats the weight value to use commas to separate thousands, and always include two decimal places.
You can use the tag numeric formatting without the substitution, such as “weight #format {#,0.00}” to just show the weight without including the ” lbs” from our example.
Only one Tag can be specified, unless you use the substitution method.
Viewport Development Note
Right now, it looks like Viewports are too much for me to get done, UI wise, for other parts of GCA. So, I’ll probably not be rolling them out to Classic or anywhere else for initial release. However, they’re supported internally.
For this build, and maybe the future (we’ll see), they’re the way the Unified view displays traits. Since the default Viewports are the same as the standard way of doing things, that shouldn’t change anything for you. However, the tools for changing the display outputs, and the viewports themselves, are basically half-baked. They usually work for the first change you make, but then don’t, for some reason. If I can fix that, maybe I’ll keep Viewports here for now. Otherwise, I’ll roll them back in Unified as well.
However, regardless of how that works out, Viewports can still be used programmatically for output sheets if authors want to use them.
Looking back at 2018
This year was basically a failure. I got very little of what I wanted to get done, actually done.
Every time I thought I was getting back to work on GCA, life kicked sand in my face. Work has been stalled for months, and the multiple times I dove back in to get back to it, I was quickly pulled right back out again.
I’m sorry about that, I really am. I did not foresee this kind of downtime.
I’m really hoping I can turn this around next year.
My current plan, once I get some traction again, is to roll back the UI stuff for the last big thing I was doing. I think it’s cool, but it’s not required, and the UI takes a lot of work to make it properly useful for people. The internal stuff is there, and appears to work, so I’ll leave that there for the future; maybe sheets can make use of it as an option for organizing certain outputs.
Anyway, once that’s rolled back, I’ll return to my previous plan: finish, fix, and polish; get everything that is already there ready for public consumption. Then we’ll see what we might do about a larger scale beta to shake things down properly.
Boggage
I’m in a place where I have day job stuff to do, but I have time for GCA. But I’m in a place in GCA where the major things that need doing just take a long time, so I get bogged down and progress slows to a crawl.
So, basically, that’s what’s happening. Sorry for the lack of progress for a while. Just bogged down is all. I’m going to try to break things down into smaller chunks to get updates moving again.
A gap in time
Yeah, sorry about that. My day job tends to get busiest through the tax season, and I kind of got lost in work for a bit there.
It’s not a great look for things here, when I post that I’m still working away and then disappear for a while without another update. But, I’m getting back into some GCA headspace, and hope to get back to what I was working on as soon as I can make my brain work again.
Still working away
I haven’t posted an update for a bit, but since it may be another little bit before I have anything to post, I wanted to let folks know that work hasn’t stopped. In fact, I’m currently spending more time than usual on GCA. However, I’m rejiggering things to support something new and different* in how the data is managed and presented, and I won’t be posting new build notes until that’s all working the way I need it to. At least mostly.
So, still here, still working away.
Next build notes will be up when I’m done with this thing, and I promise you that the build notes will not even remotely reflect the amount of work that this rejiggering represents.
* new and different in GCA, anyway
Addressing some broken bits
b102
* Miscellaneous
If you click on one of the point boxes in the Status bar, and you’re in Classic view, GCA will change to that tab.
When saving a trait to a GDF file, GCA was erroneously deleting the step() tag for attributes. Deleting the tag for other trait types is correct, but it is required for attributes to function correctly. That is now fixed.
Fixed a crash bug in the Save as Book function of the Build Campaign Book window.
Some bugs were identified in the new updater code in GCA, so those have been addressed.
The XML writing code for GCABonus overlooked writing out target name extensions, turning all specific bonuses into general bonuses for all saved and re-loaded characters. That has been fixed.
When pasting traits into a character, GCA was not correctly handling a temporary parent-child relationship tag that was being created automatically as part of XML processing, but wasnt’ needed for the pasting process. This caused problems when the character was saved and loaded again later. That temporary tag is now being removed during processing.
* GCA5.XSD
Updated with the missing ‘targetext’ element for GCABonus.
Updated Data File Info Doc
A while back I posted a document covering lots of the changes to the data file spec. I have just updated it for changes incorporated since then.
Here it is:
Bits of 101
b101
* Miscellaneous
GCA now creates a charbulk() tag for the weapon’s character-specific bulk(). It uses the simplest math version, which means bonuses can be targeted to ‘bulk’, but GCA expects it to be just simple integer math stuff. All places where GCA displays weapon info have been updated to show charbulk().
I have changed how GCA applies the maximum applicable ST cap for muscle-powered weapons. Normally, three times the weapon’s ST value is the maximum, and GCA was doing that for melee weapons, but not for thrown weapons. GCA will now apply a ST cap to all muscle-powered weapons, melee or thrown or whatever. However, because it’s now easier to apply this to weapons that perhaps aren’t actually meant to be capped (either by RAW or in your campaign), GCA now supports a new stcap() tag (mode-based and math-enabled) to turn off capping, or to change the multiplier value if desired. Use stcap(no) to turn off the max ST cap, or use stcap(X), replacing X with a value, to replace the 3*ST cap with an X*ST cap.
GCA should save/load the new stcap() and charbulk() data.
Fixed the oversight in Loadout Manager that caused sorting by the values in the Qty or Wgt columns to be done incorrectly.
Made a small change to the Protection Box paint routine.
Updated a bunch of places in code to perform explicit type conversions, rather than implicit ones, and to change some instances of late-binding to early-binding where possible.
With loadouts, characters now have the option of having all unassigned items treated as if they’re part of the currently active loadout. The default behavior requires that for any item to be included in a loadout it has to be specifically added to that loadout. This new option will include the unassigned items as part of the current loadout for purposes of encumbrance and activation/deactivation (if you’re using that).
Updated the Encumbrance & Move box to show “Loadout (+ Unassigned)” for the current loadout if the IncludeUnassignedItemsInCurrentLoadout option is enabled.
I have added an interface to Options for GCA’s automatic duplicate trait refusal, so it can be turned on or off by trait type. I have also changed the default settings to begin with auto-refusal of dupes turned off, except for attributes (where duplicates are never allowed), and for spells and templates, where IMO auto-refusing dupes still makes more sense.
* GCA5.XSD
Updated to support ‘charbulk’ and ‘stcap’ elements.
Updated to support IncludeUnassignedItemsInCurrentLoadout option.
* TagDefs.XML
Updated to include bulk(), charbulk(), stcap(), highlight(), and drnotes().
Fixed some XML character encoding errors.
* Plugins
Sheets were updated to show charbulk() instead of bulk() for attack blocks.
Fixed a couple incorrect labels for weapon data in SimpleTextExport.
Fixed a reference in testOfficialCharacterSheet to the /graphics/ folder, which is no longer being used.