Menu
▾
▴
#22 NZDGQm <a href="http://qpuzmqsczjnf.com/">qpuzmqsczjnf</a>, [url=http://kxtmmfejbshx.com/]kxtmmfejbshx[/url], [link=http://xvwhtytamdiv.com/]xvwhtytamdiv[/link], http://bveyqldowmaw.com/ Edit
NZDGQm qpuzmqsczjnf, [url=http://kxtmmfejbshx.com/]kxtmmfejbshx[/url], [link=http://xvwhtytamdiv.com/]xvwhtytamdiv[/link], http://bveyqldowmaw.com/
I need this for my own game usage so was more motivated than usual to implement the functionality. I've done some things in this patch that are a bit more bold than prior patches--mainly structurally. One of the my favorite techniques in working with WPF is to use MVVM to handle the disparity between data objects and supporting UI binding. I've been struggling with the lack of separation between view and data objects and simply couldn't resist the urge to add some MVVM with this update.
Now, in a project this big that has been going on for some time, changing core structure can be its own challenge and the last thing I want to do is try to force ya'll to adapt MVVM formally. Normally, I'd have discussed this beforehand but I'm not aware of any discussion forum for the project so I couldn't. I don't know the team's familiarity with or willingness to work with MVVM, and hate it when people try to force me onto their pet development techniques so I want to be up front with what this patch does and why. If you have any questions or concerns, please let me know. I'd be happy to tackle revamping some of the existing structure to MVVM on an ongoing basis if you'd find that valuable. And if you hate it, let me know and I'll refactor out what I've done here (however much it'd pain me to do so :).
As per usual, the attached patch adds the above functionality. It doesn't expose all the weapon fields for editing, sticking with the main ones people will want. In addition to using MVVM for the custom editor, it also saves a list of custom weapons to the AppData directory in a file named Weapon.xml. It saves the custom weapons when one is added and restores that list on loading weapons. This is a little sub-optimal because there's no removal mechanism. Probably not a huge deal, but something to be aware may be desired in future. It wouldn't be too hard to allow users to hit the delete key on the weapon list, check for custom weapons (or even highlight them somehow) and remove it if that's desired.
I've been starting at this for a while, going back and forth. I'm having real trouble saying yes to this because it feels like it's an extra level of complexity, particularly for the "Weapon" class, which is already set up for some Data Binding. I just don't like the idea of going down a new architectural route for this. There are plenty of those already :P
I'm concerned about this fragmenting more off the core and leaving functions that ought to be there out of there. For example, the "buildCritString" function is redundant with some (really ugly) code in the core.
Yeah, I didn't like buildCritString, either, but I couldn't find anything public that provided the functionality I needed (assigning a weapon's CritRange and CritMultiplier directly rather than through parsing a string). All the public-facing functionality of the Weapon class is built to go the other way since the weapon class uses assignment to the Critical property to assign the private members that feed CritRange and CritMultiplier.
This is actually the main reason I went with a ViewModel class as an intermediary (because the Weapon class doesn't allow assignment to CritRange and CritMultiplier). Changing that so you could assign those values on the Weapon class seemed more intrusive because it changes a very fundamental assumption about how that class will be used (i.e. that the critical information is set from the outside only through assignment to the Critical property).
Which brings up why I prefer using ViewModels to facilitate binding rather than making my data objects bind-aware. It's clear that the storage model for weapons (and attacks) is in native string formats. i.e. critical information is stored as a critical string and the range and multipliers are parsed from those strings. And because that is the case, it's actually a good thing that CritRange and CritMultiplier are get-only properties on the data object. Leaving them read-only ensures that the weapon object is never out of synch with different values for CritRange and CritMultiplier than are reflected in the Critical property. But that creates a challenge for binding to a UI where you might want to use a different strategy than you do for the data storage--i.e. it makes it impossible to do two-way binding for a weapon's crit range and crit multiplier (without resorting to, IMO, unnecessary converters).
That said, you have a valid point that leaving the UI binding to both the Weapon class and WeaponViewModel class is messy and a good way to leave us open for difficult bugs in the future. Would it help if I did a refactor to push the UI through the ViewModel and leave the data class responsible for the data storage and retrieval? I don't think it'd take much to do and it may make things easier down the line for all involved. Really, MVVM isn't that tough to use and maintain and the gains in removing complexity can be significant.