Opportunistic attacks are now working fairly well. I’ve managed to trigger them off on movement from a threatened cube and by trying to use a ranged weapon in a threatened cube. Also tested: not being able to make an opportunistic attack if the target has cover, and only being able to attack when wielding a weapon that can make such an attack. Haven’t played with reach weapons yet.
I also discovered (and fixed) a problem with some of the attack handlers, in that I had a handler chain defined for a base class (AttackData) that prevented the chains for more specific attack types (MeleeAttackData, ReachAttackData and RangedAttackData) from activating. I ended up changing the interaction handler chain matching algorithm to work with exact type matches, rather than IsAssignableFrom(). Had to also make sure I wasn’t orphaning any use cases.
Lastly (and I still have to fix this), I discovered that a target standing on a low step could trigger a Cover alteration, resulting in a +4 to Armor Rating for the target. This is because the cubic region’s lower corners are blocked by the solid material of the cell. I’m going to look into using adjusted coordinates for determining extents for a target (rather than blindly using the cube corners) based on the IPhysical properties and intra-locator positioning (including Offsets)…and I’m going to put some stuff in to account for low barriers (2′ high or less) by trying some alternate point testing under “certain” conditions.
Finally got (most) of the client-side features back together under a more MVVM-like pattern (still haven’t adopted the RelayCommand style yet…). Now, I can more easily get additional data into the Opportunistic Inquiry Prerequisite dialog, since I won’t have to climb through data contexts and control-bound properties to find the data from the framework. I can just bind it in…
I also inched the “bio” part of my Kickstarter project a little bit farther. Every day I see more and more games on Kickstarter, quite a few of which are sandbox and adventure games. There’s an upside and a downside to that, the downside is in launching my project too late (which is comical to me as I “launched” about 7 years ago with the code, or 30+ years ago with the concept), and getting lost in the sea of games. The upside is that the project funds sought looks like they are realistic to keep the developers eating (which is a requirement of mine as well), without having to work in a factory.
I started the client UI (and proxy code) for the Ikosa Framework quite some time ago. Since the whole framework has been under development since early 2006 (six years) the client UI is probably no younger than about early 2007 (I could look it up in my Vol 1 or 2 of my notebooks if I had the inclination).
Anyway, WPF hit the scene with .NET 3 in late 2006, so I was working in unexplored territory (with my mental models at least, if not in accepted “best practices”). Correspondingly, much of the client-side framework was (and still is) fairly hodgepodge. I slowly came around to RoutedCommands (fantastic things), and DataTemplates (and DataTemplateSelectors!), and some data-binding.
Mainly what held me back from pervasive data-binding was that most of the instances I had to visualize were coming from the proxies as DataContracts. These were not implementing INotifyPropertyChanged, or INotifyCollectionChanged, and it wasn’t obvious (in my bone-headed way) how to make this “work” with a data-model controlled on the other end of the WPF channel. I may also have been reluctant to wrap data-contract classes (yet again) for WPF, since I already had to pack and unpack them in the host-side for processing in the Ikosa setting.
However, once I got around to the opportunistic attack prerequisite, I saw that to visualize the options well, I needed to provide useful information from elsewhere in my data “model”, which could be “found” scattered in a loose-confederation of DataContexts, POCO properties (set via constructor or assigned after an event fired) and some DependencyProperties mostly all parked on various controls of the UI, some templated, some not.
Then I decided to change all that…(or most of it)…over Easter Weekend, while also trying to assist two black belts testing for second degree next weekend, driving back and forth to Reading, PA twice (about 5 hours total), and having a rather pleasant Easter at my parents.
So far, I have a stable build. But am seeing that I’ll have to deal with some ObservableCollections that I (now) understand won’t work across threads. And I have some server-side debugging to do (I also altered the hosting model to allow a single user to control multiple actors, in theory). What I have started as a MVVM, but I started adding more “C” (as in Controller) type functions, since I was moving them off of the UI controls where they were before.
All in all, despite the fact I broke my system (client and host), I am satisfied that the foundation is becoming better.
Finally became a part of the Facebook nation. Mainly to help with proving to people who may eventually pledge on Kickstarter that I am real.
Reworked some of the GetTargets() code in the host when unpacking attack aim targets from the client. Given that a melee attack provides a target cell, I was able to automatically select a target if no explicit target ID was given. (I still have to work the code to “randomly” pick a target if two targets are in the same cell, but that’s a minor detail). This makes automatic melee attacks much easier to perform, as the client no longer has to select the target in order to make a melee attack.
I also got automatic ranged attacks up and working (but the client must select a target, since ranged attacks are not typically into the adjacent cell). I had to fix some things with the critical damage multiplier for projectiles/ammunition, but all should be good now.
Even though opportunistic attacks have been on my “tactical radar” for awhile now. They are now the next thing to tackle directly.