Annual Roundup 1

It’s been just slightly over a year since any substantive post.  Again, as the sole resource on Guildsmanship (Ikosa Framework), I get more from the coding than from promoting to the small set of people who are even slightly aware I have been coding the D20 system (v3.5) for the past decade (or so).


Last January: more furnishing things (mostly model generation)

February: even more furnishing things such as drawers and doors opening, UI workshop, in-game manipulation actions; ended with some drawing optimizations in the workshop and client

March: continuing on optimizations

April: even more optimizations (it’s easy to get addicted to performance numbers!)

May: got back into furnishing movement (push/pull/slide/rotate); also got into climbing, moving on furniture; and UI bound jump-down and hop-up actions

June: (slow month) but I added a new ModelCacheSelector; and here’s a quoted comment from a check-in: “Furnishing default implementations tend towards solid convex cuboids
overrides for hollow/cabinet/surface mainly change covered face exposures” (which I think was a refactoring to a base-class so I didn’t have to copy/implement certain geometry features)

I’ll add some more later today while I’m on a roll.

Latest Model Pics

TFS Changeset Count

Lest I appear idle due to a lack of posts…

2016-01-27 (2)

And a small sample of the check-ins over the past few weeks:

2016-01-27 (3)

Splash of Color

Putting all the fragments together gives the basic shape of a meta-model, but doesn’t explain how to get to this:


The first thing to do is to define the set of brushes that can be used to paint the miniature.  This is done by opening the “brushes” node for the meta-model in the package explorer.


Resulting in the brushes editor:


From within it is possible to add colors, images, gradients and stacks.  Colors are pretty self-explanatory, they are solid colors.  Images are images available to the model either bound directly to the part, or referenced as a resource in the package.  Gradients are linear gradients based on WPF gradient brushes.  Stacks are sets of brushes that are overlain on top of each other (assuming that the upper brushes have some transparency.  Stacks allow multiple directionalities to gradients within a brush.

Next, opening a gradient brush shows the gradient editor:


The directionality of the gradient is selected via the array of buttons with arrows.  The gradient stops are modified in the list box and buttons on the right side.  The slider to the left of the gradient stop list box specifies the gradient stop relative location for the currently selected gradient in the list.  The striping effect of the gradient is controlled by the “spread” combo and the slider next to the combo (which determines how the pattern repeats when it ends and how often the pattern repeats).

Now, to the actual painting back in the meta-model editor.


The “brushes” tab lists all the named areas that can have brush references mapped, and the currently mapped reference.  Right-clicking one and selecting “assign” brings up a visual list of all the brushes that can be applied.5b-assign brush

These references are the “global” (for the meta-model) brush references.  It is possible to apply variations to individual fragment instances; and this applies to brushes as well as “parameters” such as lengths and radii, and to place more than one fragment in a reference connector.

For example, on the left arm, the first “arm.xaml” segment connected to the torso doesn’t have anything mapped for the “arm” brush, but the “arm.xaml” mapped in it’s “connector” has it’s “arm” brush overridden to be sleeve, which is effectively a reverse direction of the “shirt” brush so that the visual jump at the elbow isn’t so jarring.


Also, I mapped another segment “balljoint.xaml” to the left-arm slot on the torso to create the slightly bulging shoulders.


Finally, to reduce the relative thickness of the forearms, I select the forearm segment, switch to the “doubles” tab, unselect the “yield” checkbox for arm-diameter and freely adjust the diameter.

Some Assembly Required

This post I’ll demonstrate a constructing a meta-model; a model made out of little fragments of 3D models snapped together, scaled and rotated.  I’ll follow up with a model painting post.  Somehow I have managed to emulate all the tedium and time-consuming nature of painting miniatures for table-top RPGs, and put it into software, while retaining the tedium and time-consuming nature of working with miniatures.  It’s actually not that bad since I created a “duplicate miniature” function.

Anyway, within a resource manager, we need to create a new meta-model and base it off a XAML file that has “fragment references” (I use one called RootBase.xaml).  Fragment references are a XAML extension I created that indicate where a fragment can be included in a model.  The technique is recursive so that fragments themselves can contain fragment references.  Think of a fragment reference as a placeholder.

<Model3DGroup xmlns=""
<uzi:FragmentReference Key="Core" OffsetZ="{uzi:DoubleVal Key=CoreElev,Value=2.1,MinValue=0,MaxValue=5}"/>

just need to pick a model file with fragment references

just need to pick a model file with fragment references

When we open the meta-model in the editor (built on the Helix Toolkit) we can see that it is empty.  Evidence that there is a reference in the file shows in the “Root Node” of the tree-view.  There is a single reference called “Core” which is a placeholder (literally, a location reference point about 2.1 feet above {0,0,0}), that can be adjusted in a variety of ways.

haven't added any fragments yet

haven’t added any fragments yet

Since my resource package already has my collection of fragments included, I only need to assign parts to begin constructing the meta-model.  In the following image I’ve assigned “RootLegs.xaml” to the Core reference.  This provided two more reference points, one for each leg, which I went ahead and assigned “Leg.xaml” to each.  Leg.xaml has a connector reference so we can build downward to another leg part, and then a foot part.  It also has a VisualEffectMaterial called “Leg” which is a texture reference to be explained a little more in another post.

I've skipped ahead just a little bit

I’ve skipped ahead just a little bit

What I also did was Cloned the Core reference so I could get a second fragment anchored to the same spot.  When cloning, I have to supply the fragment that will be held in that spot; in this case I chose “Belt.xaml“.  Belt has a Buckle reference at the front, and a Stack reference onto which a torso is usually placed.

After a bit more of this, I get pretty close to a complete (unpainted) miniature.

now I've skipped ahead a lot

now I’ve skipped ahead a lot

I left the right hand off, so now I assign it.

any part can be added to any reference spot

any part can be added to any reference spot

Knowing the hand is a little bit big, I need to adjust it down.  The hand model contained another extension called a DoubleRef, which provides me a way to adjust it in the workshop.  Actually, the entire conic mesh is programmatically generated (and cached) via a markup extension as well!

<GeometryModel3D Material="{uzi:VisualEffectMaterial Key=Hand, VisualEffect={uzi:SenseEffectExtension}}"
Geometry="{uzi:ConeMesh CacheKey=1, Origin={uzi:Point3DVal}, Direction={uzi:Vector3DVal Z=-1}, Height={uzi:DoubleVal Key=HandLength,Value=0.4},BaseRadius={uzi:DoubleVal Key=WristRadius,Value=0.18},TopRadius={uzi:DoubleVal Key=FingerRadius,Value=0.12},ThetaDiv={uzi:IntVal Key=HandTheta,Value=8},BaseCap=true,TopCap=true}">

the hand was bigger than the sleeve until I adjusted it

the hand was bigger than the sleeve until I adjusted it

Both the “Doubles” tab and the “Ints” tab control the value of all references to the named integers and doubles in the miniature.  ArmTheta, for instance, controls the number of “sides” for an arm cylinder.  You can guess what the other ones do.

I have a separate utility to construct head models, I'll explain that sometime if I get around to it

I have a separate utility to construct head models, I’ll explain that sometime if I get around to it

Next I put a staff in the wizard’s hand.  Naturally this doesn’t orient and position neatly into my customized model.

the rest of the miniature had been rotated into place already

the rest of the miniature had been rotated into place already

So, I select the staff, and adjust the pitch.  I had been adjusting the rest of the model to this point in a similar way, and gave the right arm a slight downward pitch, which I have to overcompensate for by applying a 95 instead of a 90 degree pitch.

aligned, but too high

aligned, but too high

Also, the staff is running a little high, so I adjust the Z-Origin up a bit; origins are relative to the fragment reference point for the fragment.  Offsets are in “final” model-space and can be more tricky to work with.  I also assigned a fragment to the “Focus” reference of the staff fragment.

almost done

almost done

I fix this by Rolling the staff fragment 180 degrees, then I adjust the scale of the Ball fragment (since I don’t have separate radius parameters for a sphere mesh).

not to scale

not to scale

Next time (perhaps), painting a miniature.


When I first started working on the Ikosa Framework, I had the idea of a local folder system to hold system-shared and “module” resources; and also for players to have their own sets of resources, like pre-painted miniatures and character data.  I also wanted to be able to package up resources into easily portable format.  I eventually learned how to use the .NET API for open-packaging convention (OPC) files, and built my own little system of management around it that included a “parts” namespace that could reference object structures within a single serialized stream and across streams in the package.

Every time I did something major to the structure of the map object model, or some other major infrastructural change to the model space, I had to rebuild any test map I had.  Most of this was simply in reloading icons, images, and models (of which over the years I had created a fair number).  Even the improvements I made in the workshop UI to allow multiple-simultaneous import wasn’t quite cutting it; setting up a meta-model is a fairly time-consuming that is done almost entirely in the workshop.  (I’ll post on that a little later).

Ergo, I eventually defined resource references that could be added to the resource resolution space of the system and defined in a resource container (of which a local map maintains an instance).

I've already added quite a few

I’ve already added quite a few

Image resources are used to source image textures for terrain and faces (I’ve conveniently labeled my references as to which one I intended for which).  Icon resources are used 2D XAML images used for the UI selection and presentation, and can be added to treasure troves markers to indicate what’s in the treasure pile.  Models are just that: 3D models used for characters, doors and furnishings…basically anything that has an ObjectPresenter to show itself in a local view.  Fragments are pieces available to construct meta-models (a type of model composed of fragments…obviously) allowing some in-workshop editing and customization.  Finally brush-sets are collections of texture brushes that can be used to paint the terrain.  The Brushes resources is a single brush set for texture resolution, which I think I should probably deprecate.  I believe it’s utility has been superseded by newer texture mapping features in the models and meta-models; or perhaps it is a fall-back texture resolution system?  I’ll have to look into it.

Both the “Faces” images reference and the “Fragments” Fragments reference point to the same Ikosa package, so I’ll give a quick peek into what’s inside:

Package contains a resource container

Package contains a resource container

Images are all faces (duh!).  The fragments are a mix of body parts and weapons.  I haven’t created a good way to visualize what the fragments look like.  If I ever get around to it, I’ll have to add some meta-data streams to the fragments with preview images, it’s either that or hoist them into a meta-model to render them (which leaves open the problems of scale, rotation, and textures; so previews seems like a better choice).

Next up is the terrain Ikosa package, which is the source of references for “Terrain” images, the “Models” model resources, and the “Terrain” brush set.

Some of the images support the models, some support the brush sets

Some of the images support the models, some support the brush sets

Finally, the icons; I’ve included images of these before, but I’ve expanded the set by a few icons lately so figured I’d add them in and put them in context of a post that explains Ikosa framework resources just a little more:

A couple of design scaffolding icons in there as well...

A couple of design scaffolding icons in there as well…

...I need to clean up that "rod"

…I need to clean up that “rod”

Since August…

Spell components (component pouch, devotional symbol and verbal).

Map redraw on invisibility state changes.

Creatures: bugbear, hobgoblin, orc, kobold, half-orc, gnoll, ogre, grimlock (light-sensitivity, weapon proficiencies, giant-type)

Classes: barbarian, rogue, ranger

Tacticals and class-features: evasion, improved evasion, rage, trap-sense, sneak-attack, uncanny-dodge, flanking, overrun, legal-position checks

Prerequisites now part of LocalViewer instead of a docked tool window, fixed some minor problems with responsiveness of controls,

Made single option, check and save prerequisites work with button arrays instead of combo-boxes.

Fixed poisonous natural weapon process flow and binding on spider’s bite attack.

I also spent some time working on trying to work out non-tactical settings and regional settings; but nothing that I can add into the core of the experience just yet.

One Shiny Ring to Rule them All

After playing around with tactical movement (which I’ll hopefully be getting back to shortly), I spent a few weeks playing around with magic item creation.  Rather than go through the litany of development, I’ll cut to the finale: the ring of invisibility; a somewhat classic trope of fantasy.

I’ve had basic support for invisibility built-in for quite some time as the creature awareness system needs to be able to determine what can and cannot be seen.  What I hadn’t completed (or worked on) until the past week weeks was the invisibility spell, nor magic items (nor apparently any in-game actions to put on or take off body-slotted items).

So here we are now:


The power to turn invisible comes from a command-word spell activation associated with the ring. Currently, this doesn’t express itself in the context menu of the ring in the equipment panel.

The command-word activation isn’t currently running through an environment interaction, I haven’t completely normalized how the sounds propagation works or which actions require verbalizing (apart from spells with verbal components).  One of the many things on my to-do list.

One of the oddities of the invisibility spell is that it requires a will-save:


Prerequisites to finish actions do not automatically pop-open the client UI at the moment. Also, since I’m testing with the time-tracker instead of the initiative-based turn-tracker; I can still move while this “dialog” is unmodally waiting for me to send the will save.

Well, if I saw myself before, I don’t see myself now…


I have to force a refresh by ending the turn. I’ll need to add a “general” refresh step to the client-server communication stream to signal client refresh for any actor with awareness so far.

Just to get an outside perspective, I’ll switch to another viewer, Spidey the spider…


I’ve had a multi-actor client UI for awhile. Certainly makes it easier to test.

Probably should add some portraits to these guys!

Probably should add some portraits to these guys!

Looking through spidey’s eyes and checking his awarenesses, the Wiz is definitely gone…


The Wiz should be right about in the middle of the display

Removing the ring will deactivate the invisibility effect…


Not exactly explicitly spelled out in the core-rules, but since a 3rd level casting would have a duration of 30 rounds (3 minutes), removing the ring causing deactivation seems a reasonable way to prevent one ring from enabling an entire party of four. Also, this ring only supports the “personal” spell mode, not creature/object touched mode.

I don't have multi-grip holding slots at the moment, in which you can juggle multiple things in one hand.

The ring has to go somewhere, so I add it to a holding slot. If there were no holding slots, it would fall to the ground or into a treasure trove (if there was already treasure in the cubic cell).

Well, I can obviously see myself again, now to check Spidey…

One little problem, magic torch should say torch

I can even select the Wiz in Spidey’s targeting queue.

I have that loosing awareness doesn’t clear the targeting queue in the UI.  That’s a minor problem since on the server you still won’t be able to target directly.  Mostly needs some client UI work since the targeting system is all client-side.


It’s been a few months since I’ve posted, but I’ve had over a hundred code check-ins since then.  A quick round-up is in order:

For the first week after my last post I was debugging, performance tweaking and refactoring a lot, trying to cleanup some code and get the system to behave more like I’d expect as a user.  One of the major “new” accomplishments from that week was getting the spider to climb on the ceiling, and before two weeks were out, climbing around corners and fixing some client window issues.

Early June had some fixes to the workshop (and support functions in the core) for room editing and light propagation through room links.  The bulk of June into early July was working on movement-related things such as multi-step movement targeting which involves picking a cell in the distance (using target selection) and moving towards it with a single UI command; as both an alternative to single-stepping, but as a requirement for overrun and tumble through (as well as jump).  I basically had to rework the single-step movements to be a “degenerate” case of multi-step to get the whole system to be relatively streamlined.

June also saw the beginnings of my refactoring for VS 2015 (using the Community Edition Release Candidate).

By about July 26th I was experiencing a small amount of movement burnout (since I still hadn’t completely worked through overrun, tumble and bull-rush like I intended, let alone jump, run or charge).  And moved on to some other things.


D = 500 (in Roman Numerals)

500th Check-In since moving to TFS

500th Check-In since moving to TFS

A change to ITrackTime interface (and implementations and usages) so that a distinction can be made between the “beginning” of a time-tick and the “end: of a time-tick.  Basically I want some things to happen as the time is changing to something else as opposed to when it is changing from something else.  Ah, prepositions!