tjayharvey

Yes. But the concept of "threat" in general is an artificial mechanism to represent something that's hard to do well in games of this style, that you have in fact highlighted: blocking or otherwise impeding their path. If you're talking about a one on one situation, there's no reason an enemy should ever get past the lead rank assuming relatively similar mobility. Having the enemy stick on the fighter is a convenience to avoid the ridiculous amount of micromanagement you'd have to do in order to keep your front line positioned exactly correctly in respect to the enemies. That's not tactical, that's babysitting. Ironically, it would actually work better to not have threat in an MMO style game where everyone is controlling only one character - only the issue of lag to the server and the resulting minor positional inaccuracies really stops it. If your front line is outnumbered, sure it makes sense for certain enemies to spread out so they can get past, but that should require some communication - at least some gestures, which could be reflected in game by having it take around 5 seconds for them to coordinate that plan. Furthermore, there are/were a lot of reasons why being surrounded was generally fatal to combatants. It may be great that the AI is now recognizing that charging off away from their unit and getting surrounded is actually fine because they won't pay any price for it - that is indeed a smart decision. But it's not great that the penalties for doing so are so minimal that it is a smart decision. This is partly an issue because of the conventions of RPGs (health points, and similar things). A child wielding a stiletto in a real-life situation would have to be respected - you couldn't just push past their "controlled space" because the are "weak" or "not very good at fighting me face to face". Tanking systems are ultimately necessary in order to make a defensive role make any kind of sense in the artificial combat of RPGs. Here, I think the easiest solution is just to seriously up the damage of Disengagement attacks except when the person leaving the "controlled area" is moving directly away. If the person wants to fall back into their own "back ranks", that should be significantly easier (because you can pick a time the person is off balance or recovering from a swing and jump back out of the way). But if I'm actually trying to move right on past someone with a weapon, there's a lot of danger there and that should be reflected. That way you can have both a combat system that actually reflects something realistic and an AI that makes intelligent decisions about how to operate within it.

It looks like Git integrates directly into Visual Studio. I was playing with it on my work machine between meetings and it seems fine. (Hey, I'm "evaluating" it for future use at our company, right?) I may grab another client for things the basic interface can't handle, but I imagine most of what I'm going to want to do are covered. Unfortunately I can't evaluate the actual code here, as I don't have the patch dlls and IEMod doesn't compile anyway since it uses C# 6.0 and I'm stuck on Visual Studio 2013 until we finish upgrading our Team Foundation Server. One of the major things I noticed is that the "UICustomization" mod is broken. There's a very large dependency chain on that as a lot of the generic stuff ("Helpers", "Quick Controls") shared between mods require classes from UICustomization. I'd suggest that be an early target for fixing since so much won't compile without it functional. For the Console mod, the old CommandLine class was refactored into two classes. Both classes were also made abstract with private constructors, so I had to change the mod classes not to inherit from them, and to pass the type being modded to Patchwork as an argument to the attribute (but you already had support for that, so this was easy). I still have somewhere between 5-10 commands commented out because they depend on the broken UICustomization stuff. Do you want me to go ahead and send a pull request for the intermediate changes or wait until UICustomization is fixed so these commands can be reinstated? Oh crap This is like literally a few days after I gave in and decided to use C# 6's awesome convenience features. Up till then I was doggedly sticking to C# 5 for compatibility I think you should go ahead and send the pull request. It's progress. Refactoring is also good What you say about UICustomization is a bit confusing. It depends on QuickControls etc, not the other way around. The only dependency that section has on the rest of the code, is when you set the Prefab objects are set (basically examples of Unity controls that we find from the game to clone and use for ourselves), and IIRC that's in the Options part. There is also dependency on StringTable. I also haven't found a using directive for that namespace anywhere in Helpers or Quick Controls. Maybe those parts depend on game components that no longer exist, such as UIDropdownMenu? It turned out I was mostly confused. I was excluding UICustomization and trying to resolve the resulting compile errors, and ended up commenting out/excluding more than I needed to. However, there are at least two mods that depend on UICustomization - the DropButtonMod and the Console. The former looks like a stray using (commenting it out lets it compile, and there are no problems when patching, but I haven't attempted to test it yet). The latter is only two commands. However, saving the preferences in Options is definitely malfunctioning. It prompts me to save options and won't respond to either choice, and appears in lots of situations that don't appear correct - it will block you from saving your game, for instance. It somehow seems to work fine if you select the "Autosave on changes" checkbox. Since this is used to save changes to the settings the other mods used, it also looks like a good early fix candidate. I've sent the pull request for the initial fix to Program. I had to restart from scratch (because of how I created the initial repo), and when I copied the changes back in it somehow decided I changed the entire file, so it looks a little weird. Hopefully the changes to the Console mod won't look so ugly and will be easier for you to parse. Here's a list of definitely broken mods: CombatLooting (signature change in source, compiles fine but fails patching) FastSneak (sneaking-related) NoEngagement (sneaking-related) OnLevelLoad (looks like AI change, also depends on UICustomization) SaveXML (change in PersistanceManager source) SelectionCircles (source object was generally refactored) Targeting (same) UICustomization (party bar stuff, looks like the source UIPartyPortrait and UIMapTooltip were changed) Of course, that doesn't mean everything else is working right, just that it doesn't immediately break. Will require some testing.

It looks like Git integrates directly into Visual Studio. I was playing with it on my work machine between meetings and it seems fine. (Hey, I'm "evaluating" it for future use at our company, right?) I may grab another client for things the basic interface can't handle, but I imagine most of what I'm going to want to do are covered. Unfortunately I can't evaluate the actual code here, as I don't have the patch dlls and IEMod doesn't compile anyway since it uses C# 6.0 and I'm stuck on Visual Studio 2013 until we finish upgrading our Team Foundation Server. One of the major things I noticed is that the "UICustomization" mod is broken. There's a very large dependency chain on that as a lot of the generic stuff ("Helpers", "Quick Controls") shared between mods require classes from UICustomization. I'd suggest that be an early target for fixing since so much won't compile without it functional. For the Console mod, the old CommandLine class was refactored into two classes. Both classes were also made abstract with private constructors, so I had to change the mod classes not to inherit from them, and to pass the type being modded to Patchwork as an argument to the attribute (but you already had support for that, so this was easy). I still have somewhere between 5-10 commands commented out because they depend on the broken UICustomization stuff. Do you want me to go ahead and send a pull request for the intermediate changes or wait until UICustomization is fixed so these commands can be reinstated?

I'm willing to help (lots of experience with C#, not a lot with Unity or GItHub as source control). I was able to get the patcher running on the source libraries that are part of GitHub (had a little trouble with the source files for Mono.Cecil not being present in the repo, but switched to just linking to the NuGet package for Mono.Cecil and it worked fine. It's possible my lack of knowledge with GitHub caused me to fail to get these files, but I can't seem to see them). I was able to get SetupEnvironment() to work, though it has a few bugs (opens the target file for reading instead of writing, opens what looks very much like the WRONG target file). Unfortunately a lot of stuff broke - looks like a good deal related to stealth not being party-only in 2.0, plus a bunch of general refactors. I concur that this is going to take some significant time to fix (and may be best served by doing a handful of mods at a time). I've successfully got it to work by excluding all mods except VersionNumber, but that's not very interesting. I'll see what I can do with Console, at least with the parts that don't depend on other pieces (there's some interaction with the UI and Settings that I'm just going to comment out for this pass). Any suggestions for collaboration mechanism(s)? Does GitHub have something built in for project management? Edit: I've successfully restored most of the Console/CommandLine functionality, though not the stuff that depends on the overall IE Mod framework (Helpers, UI, etc).