Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
and no problem, glad people enjoy it.
Will look at the __state features in a bit.
for (int a = 0; a < num; a++)
{
esimateBuilder.Append(ave[a]);
if (where_order < 5)
{
avBuilder.Append("{{c|").Append(min + a * add).Append("}}");
}
if (ave[a] == 0) break;
if (a != num - 1) esimateBuilder.Append(daml);
if (where_order < 5)
{
if (a != num - 1) avBuilder.Append(avl);
}
}
The `break` should be in between the two so that there isn't a trailing |
public static bool AddMissileWeaponDamageTagPrefix(GetDisplayNameEvent __instance, out DescriptionBuilder __state)
{
char do_r = Options.GetOption("BCL_Damage_Option_What")[0];
if (do_r == 'N' || do_r == 'M')
{
__state = null;
return true;
}
__state = __instance.DB;
__instance.DB = new DescriptionBuilder();
return true;
}
[HarmonyPostfix]
[HarmonyPatch(nameof(GetDisplayNameEvent.AddMissileWeaponDamageTag))]
public static void AddMissileWeaponDamageTagPostfix(GetDisplayNameEvent __instance, GetMissileWeaponPerformanceEvent E, DescriptionBuilder __state)
{
if (__state != null)
{
__instance.DB = __state;
}
[/code]
fyi, I used harmony's __state feature to handle your AddTag() issue. I'll post example code in next comment because of steam's character limit in comments.
https://harmony.pardeike.net/articles/patching-prefix.html#passing-state-between-prefix-and-postfix
Hmm.. Not sure what to tell you. I had no other mods and this mod set to defaults (or mostly defaults), and was easily able to reproduce those errors. Possible my base game option settings were to blame somehow, maybe debug options that I had enabled.
> PV increases with 'Str' or strength, up to a cap (shown in description or with base game option 'display detailed weapon penetration' on). This option is mostly because some popular mods have weapons with PV that increase with Agility instead, but I don't think base game has any, so can be turned off if so.
Could possibly have an option that works like:
1. Do not show attribute that increases PV
2. Show attribute that increases PV
3. Show attribute that increases PV when it isn't Strength
Can't reproduce, maybe missing something.
Some of the others probably aren't strictly necessary per se, but if I already have to use prefixes to skip, and the new code is more replacement than addition, then may as well skip the originals too if they're not being used. And since they're all the same,
Started a few Artifex, got some missile weapon disks, then crashed, although that log isn't saying anything. Will have to test more.
The prefix patches don't do anything other than prevent the original function from running under certain conditions. Unless I'm missing something, the prefixes appear to be redundant because, in the postfix patches, the same check is performed a second time. I didn't look at the original function decompilation, but it must be caching/inserting something into a dictionary that results in the various errors with key lookup exceptions and null pointer exceptions.
In general, it is best practice to allow the original function to run when writing prefix patches, unless there is good reason to disallow that.
Having data disks on the character seems to be the most reliable way to reproduce the issues, so True Kin -> Artifex has been the most reliable. I posted another error stack trace in the discussion forum for this mod.
I'm still trying to figure out what exactly is causing the issues.
> Hm, in that case I might just throw a 'if actor == null, quit or just use original function' in there then. Shouldn't be a problem if game wasn't trying to show item names anyway?
It should be fine to just return if actor == null since these are in a harmony postfix (the original already ran and produced '__result').
It happens numerous times during world creation before taking a turn. Perhaps it is generating legendary/hero monsters and somehow the methods decorated by this mod are invoked?
if both __instance.ParentObject.Equipped and IComponent<GameObject>.ThePlayer are null, then `actor` will be assigned null.
I'm sure actor being assigned null is the issue here. I added the following after those 2 places in the code assign a value to actor to address the issue, and I see in the debug logs in player.log:
if (actor == null)
{
XRLCore.Log("MODWARN [Show Weapon Stats (Range; Damage vs AV)] - MeleeWeaponPostfix: actor is null");
return;
}
I'm pretty sure it shouldn't be 'actor' because those use "GameObject actor = __instance.ParentObject.Equipped ?? IComponent<GameObject>.ThePlayer;" which is code with null check from the base game. Although not sure what else it could be either, since the only other object is "__instance.ParentObject", which is just the item.
I'll add "?? IPlayerPart.ThePlayer;" to the actor initialization, but not sure if that'll do anything.
Can you recall what was happening, like were you walking into/loading a new zone, or had just come into sight of a Boulderer, or had the Boulderer already thrown a few rocks, or anything else?
at XRL.World.GetThrowProfileEvent.Process (System.Int32& Range, System.Int32& Strength, System.Int32& AimVariance, System.Boolean& Telekinetic, XRL.World.GameObject Actor, XRL.World.GameObject Object, XRL.World.GameObject ApparentTarget, XRL.World.Cell TargetCell, System.Int32 Distance) [0x0013e] in <92095d38a1a94620890943b3fa8613ab>:0
at BCL.Display_Weapon_Stats_HarmonyPatch.Thrown_Patch.GetPerformanceTagPostfix (XRL.World.Parts.ThrownWeapon __instance, System.String& __result) [0x0024e] in C:\Program Files (x86)\Steam\steamapps\workshop\content\333640\3371639487\Thrown_Patch.cs:79
The default settings of this mod instead shows "Str→7 ♥4.5 ■13|5→♦0|5", which in order means:
PV increases with 'Str' or strength, up to a cap (shown in description or with base game option 'display detailed weapon penetration' on). This option is mostly because some popular mods have weapons with PV that increase with Agility instead, but I don't think base game has any, so can be turned off if so.
■13|5→♦0|5 means that the weapon will do 13 damage on average against a target with 0 Armor Value ('average' meaning anywhere from 0 to like 30 is possible), and 5 average damage against 5 AV, taking into account the average damage and average expected penetrations, but not critical hits. It also doesn't take into account flaming/freezing, but those are easy to add on. This value can also be used to estimate how much damage a weapon will do to you, with your AV.
The options for this mod should mostly show what they do as well, so it's recommended to check those out. Once you're familiar with Qud's stats, you can reduce those to just display the first letter (S for strength), or adjust set AV values to enemies you have trouble with, etc.
So any more of that kind of bug should be unlikely.
Added Issues and Troubleshooting section to description.
In your case, since the Inv wasn't opening, then it was a combination of an item in there and specific options (although I didn't test every item in the game, so it could be default options).
It's probably not a mod conflict, though a mod could have an unusual item? But a new game with the same item (base or mod) would have the same problem.
See the above Issues section.
Also, will update to make mod more stable soon-ish (initializing all stringBuilders with "" instead of null, so don't fail if used while null), it may fix the issue.