Messages

Thanks for the detailed feedback.

Yeah, i'd seriously consider you getting the first step for rebalancing to normalize percentages, or at the very least apply some curve behaviour (min/max percentages with hardcaps). I see a huge potential on your changes so far, though, good job.

Luckily it's done already by default on the game itself. I only had to add a hardcap on parry chances (90%). Still can be improved, because I want highly skilled fighters that are able to deal with penalties derived from health conditions (Normalized internally by Vanilla) also to cancel some of the Parry Counter penalties... For doing that, sadly, I need to dig deeper into vanilla normalization process, which will invariably mean higher chance of collisions with another mod that may do the same. So I hope that for now, this will suffice.

If you want a suggestion for further improvement, make parry weights for weapons. A shiv, for instance would have a parry weight of 1, and larger weapons, such as the spear, of 8. Larger difference in parry weights reduce your parry chances by a factor of N, where N is the difference between the parry weight.

Nice suggestion... What in some RPGs is modeled as "wielding difficulty" or pairs of Weapon Size vs Parry Size.

The issue with adding new "per weapon" mechanics is the vast array of mods that add new types of items to the game... I would actually have to classify a potential unkown ammount of new items.

As I want ppl to add this mod into their prefered playstyle immediatly... I would like to avoid triggering "unexpected" gameplay interactions because a given "new weapon" is not classified properly.

That's why I forced myself to relay strictly on Vanilla stats/concepts. In the current system, the smaller weapon should have less HP than the bigger one meaning it would be able to whistand less parries. It's a weak relation, I know, because it full of anomalous cases... But after inspecting most popular Mod additions they more or less follow the logic:

- Heavier/Bigger weapons = More HP.
- Faster weapons = Less damage per hit.

As you can guess I can't forsee in detail how each player will combine what this mod provides with the repertory of items his current mod suite offers.

On a related topic... I have a Draft to provide an independent Parry Chance Stat, not just for the looks, but to allow weapon creators to add Parry Chance offsets derived from gear. I think this could address what you look for indirectly, by making some weapons increase/decrease the Parry Chance of their wielders. This feature, sadly, is one of those requiring leaving potential items ingame with a stat definition that WILL NOT be recognized in the event a savegame is loaded without the MOD responsible of creating them active , so for now it's a feature on Hold.

So, let me get this straight. If I get a very fast-attacking weapon, the chances of proc'ing the special effect will increase? Because let's say you apply a 10% chance of proc'ing. Obviously, a 2s cooldown weapon will proc less than a 1s cooldown one.

Yes... Not only that, but remember that if your weapon is faster than your opponent's... You will be able to saturate his defenses occasionally, meaning you will get higher chances to connect and posibly be able to trigger special effects from the Hard Modes (Check the tooltips).

On the receiving end... With this changes on, if your pawn is been attacked at the same time by multiple enemies, he will not only parry less... But may allow less skilled enemies to trigger special effects on your pawn they wouldn't be able on 1v1 duels.

= NEW VERSION 1.3.0 =

Changes:

- Added Attack Mode command.

- Added Basic Localization: English.


Current Attack modes are the following:

	Kill Mode In this mode your pawn fight regularly and occasionally will do double damage.
	Capture Mode In this mode your pawn will do half damage and when a special effect happens will inoculate a powerful anesthezise effect on the target. This means you will not be able to affect mechanicals with this effect... So watchit.
	Stun Mode In this mode your pawn will do half damage and occasionally Stun his/her opponent for around 10 seconds. Ideal to suppress powerfull enemies or to be able to move away without been staggered.
	Disarm Mode In this mode your pawn will NOT DO ANY DAMAGE (He is aiming at enemy's weapon) on a regular hit, but when a special effect happens, the opponent will drop his/her weapon to the ground. Remember that plenty of Mods and Vanilla opponents' weapons are instantly destroyed when touching the ground... So don't expect to go around wielding too many Inferno Cannons .

Each Mode has a Threshold and a Chance (You can check them on the tooltip). Threshold controls the effective melee hit chance a Pawn has to have to be able to trigger the special effect of the Mode. The chance that a regular hit triggers the Special Effect of the Mode, surprinsigly , is the Chance. A numeric Example should make all this clear (I hope ):

Gronan (90% melee chance) and Wally (30% chance) are fighting each other... Gronan is trying to Capture (T: 40%, C: 25%) and Wally is simply on Kill (T: 20%, C: 33%). Leaving other factors aside, Gronan effective chance to land a hit against Wally are 63% = 90% * ( 1 - 30%). As Gronan's effective chances are higher than his current mode threshold he has roughly 16% chance per attack to incapacitate Wally (Effective chance 63% times chance of special effect of the current mode 25% = 16%). Meanwhile Wally has a tough challenge as his reduced effective melee chances 3% = 30% * ( 1 - 90%), aren't enough to activate Kill Mode special effects... He has to find a way to reduce Gronan's parry chances to be able to do double damage.

Probably this feature will require a lot of feedback to fine-tune it properly, so I hope you all find this fun enough to test and report back.


Some Comments on the Release:

- I think I'm approaching the limit of what I can achieve without leaving savegame traces. Parry counter reset, Attack Mode reset and having to relay on Anesthesize mechanics (Instead of using a new type of wound) may detract from your experience while using this mod. I would love to hear specific feedback on how anoying this issues are versus how much you like the addon.

- Sadly I have met the 1st mod incompatibility with Defensive Possitions (Not a surprise because was one of the mods I have been inspecting to learn "how to do things"). I'm sure there will be more, because the entry point BOTH mods use to inject new command buttons is very attractive because it has an inherent additive nature on Vanilla. My current priority is to be able to solve the collision so users of BOTH mods can enjoy all features provided FULLY.

- The current localization support is just "Barebones" (I will add a Spanish Language translation at some point). I have seen some users like to provide Localization data for their prefered Mods. Before I consider this Mod stable, there are a lot of things that may be added that may require translation, so if you like to see Mods in your prefered language and like to provide a translation I recommend that you wait for the Mod to grow a bit more before making the effort of creating a Language File. It would rock to have such translations, but it's not nice to include something that may become obsolete the next version and then those kind contributors may feel "obliged" to keep adding updated versions of their Language files.

- Finnally I was able to move the entire project to a GITHUB repo, for automatic source management and for you to be able to access old versions if you don't like what the newer ones bring. The sources are still the product of how I approched this whole project as a learning excercise... I think there are far better examples on this forums for you to learn/start a project from, I hope they become better over time.


The mod is STILL savegame friendly. When/If I do something that leaves a trace on the savegame I will clearly announce it.

K, back with another strange issue. This time moving from autopatching approach as wiki explained to manual patching as wiki also explains (My little mod now Detours another method that's also detoured by another mod (Not using Harmony)... So I'm at the 1st step to see if I can make conditional patching based on the pressence of the Other Mod, to avoid the collision).

Still haven't even touched anything related to the final goal... I was just, in theory, converting my code to "manual patching" mode as wiki explains.

From this:

Code Select Expand


            //Initializing Harmony detours
            var harmony = HarmonyInstance.Create("net.oreganor.rimworld.mod.meleerebalance");
            harmony.PatchAll(Assembly.GetExecutingAssembly());


To this:

Code Select Expand

   
            //Initializing Harmony detours
            var harmony = HarmonyInstance.Create("net.oreganor.rimworld.mod.meleerebalance");

            var original = typeof(Verb_MeleeAttack).GetMethod("TryCastShot");
            var detour = typeof(VerbMeleeTryCastShotPatch).GetMethod("Prefix");
            harmony.Patch(original, new HarmonyMethod(detour), new HarmonyMethod(null));

            original = typeof(Pawn_DraftController).GetMethod("GetGizmos");
            detour = typeof(Pawn_DraftControllerGetGizmosPatch).GetMethod("Postfix");
            harmony.Patch(original, new HarmonyMethod(null), new HarmonyMethod(detour));


Which is just what wiki describes with the added null definitions according to what HarmonyInstance.Patch expects internally because I only need a fix in each Detour (one Prefix for the 1st, and a Postfix for the 2nd).

This is the error-stack I get from Rimworld when it loads:

Code Select Expand


Could not execute post-long-event action. Exception: System.TypeInitializationException: An exception was thrown by the type initializer for MeleeRebalance.MainController ---> System.ArgumentNullException: Argument cannot be null.
Parameter name: key
  at System.Collections.Generic.Dictionary`2[System.Reflection.MethodBase,System.Byte[]].TryGetValue (System.Reflection.MethodBase key, System.Byte[]& value) [0x00000] in <filename unknown>:0
  at Harmony.GeneralExtensions.GetValueSafe[MethodBase,Byte[]] (System.Collections.Generic.Dictionary`2 dictionary, System.Reflection.MethodBase key) [0x00000] in <filename unknown>:0
  at Harmony.HarmonySharedState.GetPatchInfo (System.Reflection.MethodBase method) [0x00000] in <filename unknown>:0
  at Harmony.PatchProcessor.Patch () [0x00000] in <filename unknown>:0
  at Harmony.HarmonyInstance.Patch (System.Reflection.MethodBase original, Harmony.HarmonyMethod prefix, Harmony.HarmonyMethod postfix, Harmony.HarmonyMethod transpiler) [0x00000] in <filename unknown>:0
  at MeleeRebalance.MainController..cctor () [0x00000] in <filename unknown>:0
  --- End of inner exception stack trace ---
  at (wrapper managed-to-native) System.Runtime.CompilerServices.RuntimeHelpers:RunClassConstructor (intptr)
  at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor (RuntimeTypeHandle type) [0x00000] in <filename unknown>:0
  at Verse.StaticConstructorOnStartupUtility.CallAll () [0x00000] in <filename unknown>:0
  at Verse.PlayDataLoader.<DoPlayLoad>m__6F8 () [0x00000] in <filename unknown>:0
  at Verse.LongEventHandler.ExecuteToExecuteWhenFinished () [0x00000] in <filename unknown>:0
Verse.Log:Error(String)
Verse.LongEventHandler:ExecuteToExecuteWhenFinished()
Verse.LongEventHandler:UpdateCurrentAsynchronousEvent()
Verse.LongEventHandler:LongEventsUpdate(Boolean&)
Verse.Root:Update()
Verse.Root_Entry:Update()



The stack is so deep, so many tests passed... That I ran out of ideas (Tested even with dummy REAL postfix & prefix methods that did some bogus actions and then return instead of the null declarations... The error was the same).

What I'm missing?

EDIT: The other Mod has been completely disabled over the course of ALL this tests. In fact I already did collision tests when patching automatically and nothing happens (My Detour is just ignored, as it should be).

EDIT2: I added the 2 manual patches as reference... Just in case. I tested each of them individually and the error was the same. The only thing I'm missing is to add specifially a dummy Transpiler... The Method prototype marks it as optional, so that would be a really exotic bug.

= HOTFIX VERSION 1.2.1 =

Changes:

- Fixed Critical Null error while attacking buildings.


I said that 1.2.0 was the last version to release as attachment, but due to the extremely disruptive nature of the bug and how simple it was to fix (I commented the wrong line by accident ), I prefer to release this fix now while I'm still cleaning and preparing the github repo. Sorry for the inconvenience.


The mod is STILL savegame friendly. When/If I do something that leaves a trace on the savegame I will clearly announce it.

Have you considered increasing the changes of hitting vital areas with highly skilled warriors? It would make sense that the level 20 person is aiming for the throat, eyes and head areas compared to the wildly swinging level 0. Also, perhaps you would consider even hitting internal organs as well? Like some sort of martial art.

Thanks for the feedback. Yes, I have considered it at draft time... Then I checked how incredibly detailed Bodies are modeled into Rimworld's code and...

...Decide to model extra lethality in a simpler way as I described in the TODO list.

My next target, after code cleanup -> GITHUB migration, will be to add "extra lethality" options in the shape of toggle buttons in the UI.

It's not the kind of detailed effects you seek... But it's how far I can go for now regarding increasing lethality of Expert Fighters while keeping a decent chance of providing to you what I promised.

= NEW VERSION 1.2.0 =

Changes:

- Full Harmony Library integration. Thanks to pardeike work and advices, not only detours, but access to private data/methods goes through Harmony Library.

- Parry chances of a pawn are reduced the more parries it has to do between his/her melee attacks.

Some remarks about Parry Counters mechanic:

- Parry Counters only accumulate in the case of successful parries or hits that go through one.

- The current penalty for parries beyond the 1st one is a flat -25% chance per extra parry (-50% for 2, etc, etc). I'm not happy with the way it's evaluated AFTER skill normalization happens ingame. I want that pawns with effective skill chance above 100% can also "negate" this penalty as they do with other factors like wounds, fatigue, etc. ATM trying to alter this would require "touching" deeper methods used by Vanilla that would increase the chance of a "mod collision". Once I get more practice with modding, I will revise this to see if I can make Elite fighters to be able to parry more times before seeing their chances reduced.

- Weapon Speed gives a net advantage in 1 v 1 duels. The faster pawn will sometimes manage to connect 2 or more attacks between swings of his target, meaning the 2nd and following hits will have less chances to be parried. Obviously this is amplified if the same pawn is been attacked by multiple enemies. Take this into consideration when having to deal with a Veteran Figher as enemy.

- If a Pawn is retreating from melee, will not have his/her parry counters refreshed, meaning that hitting a fleeing target will become easier over time.

- ATM Parry Counters AREN'T SAVED. This means that if you save in the middle of a melee combat, when you reload, ALL pawns will have their parry chances back to full. It's a small discrepancy that I hope you don't mind for the sake of been able to keep this MOD savegame friendly for now.



This will be the last version I deploy as an attachment. The next one will come as a download from a GITHUB repository and will contatin also the source code of the mod. It may take a bit longer than the previous updates as I have to refactor/clean my chaotic code full of test/debug/trash lines .


The mod is STILL savegame friendly. When/If I do something that leaves a trace on the savegame I will clearly announce it.

Woah! All Traverse calls working flawlessly.

Thanks a lot, specially for helping at the correct syntax for those calls to private methods. Glad I could help you at squashing some bugs.

Time for a cleanup on my mod code to publish also some decent sources.

This is at least hopefully going to be fixed in Alpha 17 though

Ah k, so it's a known issue then? (I was about to fill a bug report)

Also was a Brawler in question if that matters.

Mmm... Apparently if ILSpy info is corrent and my understanding of Ludeon code is correct, I have an idea on why Brawler doesn't have an impact on reported melee chances (My debug code is telling the same... Not a surprise, because I use what vanilla games calculates as Melee Chance, which is what Vanilla game uses to determine if a melee attack lands or not).

The code responsible of calculating ALL stats of pawns is ignoring StatFactor tags defined on Traits (Honors StatOffsets, although)...

...I may miss something here because I swear that young animals got their stats changed when changing Lifestages and those are defined precissely as StatFactors... But on another entity.

Also was a Brawler in question if that matters. Did a lot better against a horde of manhunting hares with a steel gladius .

So you found that turning to a faster and sturdier weapon felt better?

I chose the "balance" point regarding pawn skill versus unskilled entities (ie ALL animals) at exactly 10, so going higher will make your pawn harder and harder to be hit.

On the current test version I finnaly found a way to implement "Parry Counters" so it will become increasingly difficult to defend against multiple concurrent targets in the near future , although.

On the subject of Brawler Trait, I have pending an investigation on why on the tooltip of melee chances it doesn't seem to have an effect... Because I considered it overpowered combined with this Mod for the advertised x 1.75 bonus to Melee Chance. I need to go back to it... Because Brawler + skill above 10 should make your pawn a deadly foe with this Mod against animals.

Sorry for delaying the answer to your very usefull comment, PetWolverine:

I think ideally manipulation would affect armed but not unarmed combat, so losing fingers would reduce a pawn's effectiveness at wielding a sword, but scyther blades, as a hand replacement with 20% manipulation, would retain their tradeoff of producing highly specialized melee super-soldiers who can't really do anything else.

I documented the different efects on manipulation as requested by user TAA6 on Vanilla and on some very popular mods, to find 3 issues:

- Most hediffs affecting manipulation ALSO affect conciousness. Meaning that to simmulate Melee Skill degradation due to temporal hediffs is enough with the current weight of modifers.

- Some Unarmed Melee Enchancing Bionics reduce the efficiency of the Body Part chain they are attached to. In turn, Body Part chain efficiency degrades any Capacity they are linked to. Sadly, Manipulation is a component on most upper limb definitions.

- Loosing completely a Body Part chain, triggers a loss on efficiency also. Which should affect BOTH Armed & Unarmed melee Capacities.


So I see now why Ludeon left manipulation out of melee modifiers ... It's more important to simmulate the Productivity degradation ATM, while leaving the option to specialize pawns as melee fighters.

I need to think carefully on how to do this WITHOUT forcing other content creators to redefine the way their Parts/Bionics/Hediff behave... Vanilla gives me tools to do it such as creating new Capacities, spliting Melee Chance stat between Armed and Unarmed... This is a hard nut to crack, so it will be very enlightening to solve it gracefully, but I will add it to the pipeline. I need to do a decent Draft even before adding this to the TODO list.

= NEW VERSION 1.1.0 =

Changes:

- Melee Weapons that would be destroyed on a parry are droped to the ground instead. If there is not enough room nearby for the weapon, it will be destroyed instead.

Warning!!!: Your melee pawns will be droping items on the ground with low HP... They will not last much exposed, so if you value a melee weapon and want to repair it... Do not let it linger around in the open too much .


For as long as I don't move the project to a GITHUB repository, I will keep the current version and the previous as attachments on the Original Post. Just in case you find something you don't like on the current version and prefer to keep using the old one.


The mod is STILL savegame friendly. When/If I do something that leaves a trace on the savegame I will clearly announce it.

Thanks CHjess and Canute for the detailed feedback:

Initial feedback: Melee weapons break pretty darn fast.

Had a colonist fight off a wild hog with a club. The club broke pretty fast from all the parrying. Some way to mitigate weapon from taking damage could be nice i guess.

ATM balance is focused on High Tech melee warriors, wielding Steel Weapons and using personal shields, so they don't become Godly Killing machines. So it's a bit of a small scenario for such a rich game as Rimworld.

Was the colonist skilled in melee? ATM a parrying weapon receives (1 - Melee Skill) * Original Damage / 2. With a minimum of 1 point of damage. So the better a pawn is in melee the less damage his/her weapon receives on a parry. Notice that material of an item has a HIGH impact on its resulting HP.

As with everything related to fine tuning, the scenario & mods you play with have a saying in all of this. Can you ellaborate a bit more on the kind of game you are playing? I'm interested in adjusting the mod so ppl playing in different ways find it useful.

- a parry should 100% interrupt the current attack of the parry one entity.

That would backfire, because high skilled fighters parry a lot... If they wield a slow weapon, they will be effectively denied of any chance to attack by a less skilled warrior wielding a faster weapon.

- maybe introduce riposte too. When the entity who parry got enough skill (10+) he got a chance for a extra mellee attack if he wield a mellee weapon.

Ripostes are typical of most RPGs with some focus on melee mechanics, so I thought on them, the problem is the ammount of blows that is currently exchanged between fighters on the typical melee duel in Rimworld (Even without this mod on). If I had to make Ripostes common enough to matter, a skilled pawn subject to attack from multiple sources will become a killing machine because his applied DPS will be amplified by the number of attackers. I prefer to keep giving players a way to deal with a powerfull melee enemy by sending multiple fighters against it.

There is also the technical problem of triggering actions ON ANOTHER PAWN in the "tick" of the pawn that can potentially receive them. Sequences like that can be sabotaged easily as "first" and "last" can't be clear nor assumed. In time, when I get more familiar with modding, I will be able to do "stunts" like that.

- Range weapons should be damaged too an a parry.

The initial tests of this mod damaged any weapon hold... Until I saw what did happen when an AI shooter lost its weapon. It was very easy to exploit for a Human Player.

- Mellee attack should general have a chance to interrupt the others attack. Do you can still shoot at someone who poke you with a knife ?

I see that you are concerned about that painful scenario on vanilla when your melee pawn has managed to dodge all ranged fire, able to reach it target... Just to be shot miserably to death at point blank . It's one of the original issues that drove me to make this mod for "personal use" in the 1st place.

I plan on including "interrupting" mechanics as a result of good attacks in the form of Disarms & Stuns. It's the "Attack Mode" button that's in the TODO list.

Thanks for the detailed feedback.

Could you consider a critical attack working a bit like the stun attack bears have also adding more dmg to the equipment and body parts maybe start with 150% at under 10 melee and 250 % dmg above 10 melee?

I think these changes would balance the whole issue of not making close quarters fighters?

The idea I have for special effects is a toggle button were players can select the intention their pawns go with into a melee and when a "critical" happens the selected special effect is triggered (This is what I meant on the TODO section as "Attack Mode" buttons). The current draft I have is like this:

- Killer. Double Damage.

- Capper. Double Pain.

- Defensive. Disarm/Stun. Depends on what I find easier to implement. Disarm is the more attractive because there is a lot of tactical depth into it... But it has a lot of potential fallout to check regarding how AI reacts to it. Stun, on the other side, is very easy to do as there is a current mechanic for it... "Surprise Attacks", which is what Animals trigger when they "hunt" unsuspecting prey.

Add cooldowns to parry. Higher melee skill, lesser cooldown. So that when engaged with many opponents, pawns wont be able to parry every attack. Well except for that Godlike 20melee pawn who can parry attacks every 0.2 seconds. 😂

The draft I have for Parry Saturation is based on the concept of Parry counters. The more a Pawn accumulates the less His/Her melee chance can reduce attackers'. The Parry counters reset to 0 each time the Pawn attacks. The reasson is mainly technical, because allows me to evaluate EVERYTHING into the same Method (Thus controlling the Impact my mod has on the overall code). As a secondary goal, I want that weapon speed matters more than now... To balance the fact that slow hard hitter weapons can still easily one shot Pawns on a lucky hit. So players can find tactical use for a variety of scenarios:

- Slow Big Weapons. Better for 1 v 1 duels. Better chance at disabling in one hit versus higher max ammount of parry counters between swings.

- Fast Small weapons. Less chances to disable in one hit versus lesser max ammount of parry counters between swings.


In BOTH cases, the current showstopper is the same... Implementing them REQUIRES leaving something "saved" (Either because I need to store states that evolve over time... Or because I have to create a new entity ingame that will leave a trace on the savegame itself). ATM, I'm not confident enough in my modding skills to allow this to happen, because 1st I want ppl to get a feeling on how it looks... And for that they should be able to jump in, install the mod and be able to remove it without consquences if they do not like what they see.

Once my learning process allows me to create safe and clean ways to disable this mod with "savegame" entities... I will proceed to add "fancy features" like the 2 commented.

Also put on Steam ?

Partially linked to my "still-to-learn" moding savegames... Steam is a nightmare for the average user that just subscribe to mods if they do not leave savegames intact. I know I'm missing a lot of audience, but I prefer to be honest about my current knowledge limits and expose this mod on a channel were users are more aware of the implication this important step has. In time, I will add it to the workshop when I feel it's rich, fun, diverse and robust enough to justify a potential lost savegame in the worst case scenario after an autoupdate.

I know that in the permissions I stated I don't mind what you do with this mod now or in the future... So can't really blame anyone that uploads it to the workshop directly. Please, if you do, at least warn the subscribers about what I comment here, that at some point this MOD will leave savegame traces and then they will be exposed to all the autoupdate madness Workshop may trigger.