Brainstorming: Ideas to improve mod quality by helping users to more easily identify and report issues

[Lurker]

(EDIT: note to myself - don't rename this topic, because it's been linked to)

Since I'm a pessimist at heart and what I propose will initially introduce more work for modders in general, I don't expect much from this, but at least I can say I've tried.

So, before derailing another thread with random rants caused by actual issues and the on and off experience of frustration and creeping burnout because escapism in a modded Baldur's Gate game is doomed to fail in more ways than even Xan might comprehend in his darkest hours, how about collecting ideas that in the long run could benefit all the people involved?

9 hours ago, Lurker said:

Otoh, if there are strong pointers that a mod tends to have game-breaking effects, I can only encourage again and again to provide a fair and explicit warning to possible users. Not doing so can negatively affect the opinion on the whole scene, because negative experiences tend to stronger emotional reactions.

Hmm, perhaps it might even be a good idea to establish a "best practices" thing, like having a guide within the readme, that explains what should be happening if the mod works as intended, so that users willing to report bugs have a bit more of an upfront guidance and don't need to ask the wrong questions at the wrong people. That's unfortunately more and often disliked work for the modder, but could smoothen  the process in the longer run.

And to avoid another reason to ending a run due to the player "burning out" - something I read more and more when reading about players talking about their BG experiences - on top of the "How-to-setup-a-modded-game"-guides, information of how to properly test a setup before committing to a "serious" playthrough could also help to improve the situation for everyone involved and willing to partake.

Regarding journal entries:

I'd find it *very* helpful if mod-added journal entries had a distinct marker to identify the responsible mod. "But that breaks immersion!" Fuck this, unresolvable quests, never closing journal entries and so on are worse. Also, if a mod matured long enough, those markers could again be removed.

Currently, I need to more or less wildly guess which readme could be the one I'm looking for (and to this day, not every mod even has one) when trying to identify the mod, and I think the willingness to provide a bug report goes downhill the more effort it takes to get even started, and this might also apply to other people.

Doing a recursive grep for random keywords on a whole installation takes too much time and generates too much noise (figuratively); so I'd have to collect all readmes from every mod in a distinct directory to make parsing them more practicable.

Hmm, alternatively, couldn't his be done as part of the installation process? Likewise to or even using the weidu_external directory, as a single place where a user can expect every readme from every mod installed?

Seriously, I cannot be the the first or only person that thinks about this stuff...?

Edited October 26, 2023 by Lurker

[mickabouille]

57 minutes ago, Lurker said:

Seriously, I cannot be the the first or only person that thinks about this stuff...?

I would guess (not being one...) that most modders get at work by "scratching their own itch" and not aiming at providing the best customer (?) support.

[Guest Graion@Work]

I don't know of a questmod without a readme suddenly, but that's irrelevant for your core issue... because you don't need a recursive grep.

If you know the journal entry you have an issue with, then look up it's TRA entry with NearInfinity using text search then run "weidu --log nul --change-log BGEE.LUA" and bisect the output files (basically pick one revision, Ctrl-F the TRA index, and go earlier if you find it within the journal entries, go later if you don't). Or grep the entire output outright for the TRA index directly with a wildcard. The relevant files are all autocollected to a series of BGEE.LUA.XXXXX files, so it's suitable for wildcards and LUA are plaintext enough for this.

weidu --change-log is a blessing for this. If you knwo what file you have the issue with, you can run it blindly and it'll tell the problem, so I don't see the issue with tracing back something.

[jastey]

@mickabouille ouch.

@Lurker Thanks for the feedback. Adding a mod identifyer to all journal entries is nothing I will do, not only because it's a lot of work for something that I would perceive as immersion breaking, but also, because to me it feels like aiming at sparrows with a canon. Your argument is that you need to go through many readmes etc to identify the mod in question. I reply: all you need is Near Infinity, a quote from the text in question, and a search program to scan the mod folders. Or a post in the forums to ask if anyone else knows the answer.

To your suggestion that game breaking issues should be pointed out: I agree wholeheartedly. The problem here is that we are all doing this as a hobby in our free time. Taking Transitions as an example - the mod has no real maintainer currently, that's the sad fact. If I had the time to make summary posts or even add such info to mod readmes themselves - I probably would have time to just fix the bug.

3 hours ago, Lurker said:

information of how to properly test a setup before committing to a "serious" playthrough could also help to improve the situation for everyone involved and willing to partake.

I have no idea how one would test an install for incompatibilities other than play it through.

Don't get me wrong, I appreciate the players' side to all this since I am surely trapped in my modder's perspective. But since I am on the other side, I also see where we touch the lands of wishful thinking.

[Lurker]

Am I interpreting this right? (in response to Graion@Work)

1. Bug: wrong StringRef for item BARING.ITM (need to add 200.000)

$ weidu --log /tmp/dontcare --change-log baring.itm
[weidu] WeiDU version 24900



Mods affecting BARING.ITM:
00000: /* created or unbiffed */ ~EET/EET.TP2~ 0 0 // EET core (resource importation)V13.4
00001:  ~JTWEAKS/SETUP-JTWEAKS.TP2~ 0 270 // Barrityl's Bigger and Better Burden3.1
00002:  ~STRATAGEMS/SETUP-STRATAGEMS.TP2~ 0 8130 // Rebalanced troll regeneration34.3
00003: /* acted upon in an undefined manner */ ~GENERALIZED_BIFFING/GENERALIZED_BIFFING.TP2~ 0 1 // Generalized BiffingBiff all files (recommended by the Big World Dudes)v2.6

So either JTWEAKS (main culprit considering the components name) or SCS are responsible?

I looked for backups of the original, which in this case is "weidu_external/backup/jtweaks/270/" (270 being the component). I open the original file, and see the correct StringRefs - so JTWEAKS deserves a bug report?

 

2. Bug: non-sensical title of a journal entry: "So be it! At least this mess is over with now."

• StringRef lookup in Near Infinity matches 31350
• weidu --log /tmp/dontcare --change-log bgee.lua
  • Spoiler

    00023:  ~BG1NPC/BG1NPC.TP2~ 0 10 // The BG1 NPC Project: Banters, Quests, and Interjectionsv32
    00024:  ~THEMED_TWEAKS/THEMED_TWEAKS.TP2~ 0 80 // SoD - Stat-based observations and quest optionsv0.4

• grep " 31350 " bgee*lua | head -n1

  • bgee.00024.lua: createQuest    ( 31350 )

 

Looking at bgee.00024.lua:

        createQuest    ( 31350 )^M
        createEntry    ( 31350, -1, 291768, {}, nil )^M
        createEntry    ( 31350, -1, 291780, {}, nil )^M
        createEntry    ( 31350, -1, 227193, {}, nil )^M

Out of curiosity, once again adding 200.000 and comparing StringRef:

Kagain's Quest

 

Why would THEMED_TWEAKS mess up a quest in BG1?

EDIT: That conclusion makes no  sense; I added the previous result to the spoiler above, because it's a much better fit context-wise. The output from the --change-log starts counting at zero, but the generated LUAs start counting at 1. Off-by-one issue? So it's really BG1NPC?
 

Edited October 26, 2023 by Lurker

[mickabouille]

28 minutes ago, jastey said:

ouch.

I guess you understood that as criticism. that was not the meaning I intended.

I just stated the most common reason people witll start hacking/modding/whatever. they have something that doesn't sit right with them and will try to do something to change it.

That's why I call that "scratching one's onw itch" and I thing that's perfectly fine. And a very nice thing for inquisitive minds.

But you can't really expect most of these people to make bug community-wide plans.

People like you who went above that and spent many years doing it will end-up organizing things : hosting sites and forums, creating tools like wiedu, recording modder prefixes, creating tutorials or easing compat (cmpvar?)...

Some rare people will think from the start about such things. Some even rarer will manage it (beginners tend not to be well prepared for it).

(Well, yes there was a quip about customer support . I hope nobody expects more from volunteer hobbyists than good will benevolence and best effort)

 

EDIT: or maybe there is a language issue there?

Edited October 26, 2023 by mickabouille

[Lurker]

34 minutes ago, jastey said:

Don't get me wrong, I appreciate the players' side to all this since I am surely trapped in my modder's perspective. But since I am on the other side, I also see where we touch the lands of wishful thinking.

I totally get that. But sometimes a new perspective might help to see the woods around all the trees again - that's why I used "brainstorming" in the title.

Unfortunately, I don't own a working time machine, because the idea for an orderly best practice where mods install their readme, ideally in the right language, in a default place should have come up years ago.

And I'm also fully aware that's not even the case with backup files, which currently are also here and there or in rare cases nowhere at all.

(Also, I'm on Linux and like the way FHS compliant file systems are, well, organized. )

Edited October 26, 2023 by Lurker

[subtledoctor]

40 minutes ago, Lurker said:

Why would THEMED_TWEAKS mess up a quest in BG1?

Because it is not a quest in BG1 - it is a quest in BG2, added by a mod (EET) along with all the other BG1 content. It is massively complicated. 

FWIW I just checked my game, which also has EET and JTweaks Bigger Better Burden, and my copy of baring.itm also has screwy strings. So my guess is either an EET import issue, or a compatibility bug in JTweaks. 

EDIT - it’s JTweaks. If you want a simple fix, to effectively “uninstall” the problematic change without messing with your big Weidu installation, you can grab the instance of baring.itm from /weidu_external/backup/jtweaks/270, and use it to overwrite the one in your override folder. Or alternatively, fix the strings in NI and keep the modded version. 

Edited October 26, 2023 by subtledoctor

[jmerry]

33 minutes ago, Lurker said:

1. Bug: wrong StringRef for item BARING.ITM (need to add 200.000)

So either JTWEAKS (main culprit considering the components name) or SCS are responsible?
 

Bug found; it's really simple. I don't change the strings, but I do a COPY on a new version of the item ... and that's copying a BGEE-valid version of the item. EET changes all the string references of BGEE strings, so I need to do an edit for EET compatibility.

Master version now corrected. When I put out the next version, the fix will be in.

[jastey]

@mickabouille I just jumped at the "most modders", but reading your elaboration, I guess it's quite true.

[Lurker]

@jmerry (also now feeling a tiny bit proud of myself)

@subtledoctor Nah, the quote and my first conclusion is incorrect. I've found matching text patterns in BG1NPC's TRA files, and also more hints in the setup log. There's an off-by-one discrepancy between the numbering of the output of weidu --change-log (counting from zero) and the generated files (counting from one).

New idea: If I'd created a topic for my current installation and collect bugs etc there, so that the basic information like game version, WeiDU.log etc is all available in the first entry, would that be considered helpful? That could avoid asking for redundant information, and repeating the more or less same questions over and over.

I'd then just reference individual entries in my topic in the affected mod's forum/topic, or if modders are so quick to respond like @jmerry, sometimes not even need to do that. This could help keeping the individual mod sections a bit more tidy, I'd say.

If this idea receives approval, a dedicated board section to aggregate such reports would also perhaps considered helpful? Otherwise, "General Mod Discussion" seems to be the fitting usual dumping ground for all kinds of stuff...
 

Edited October 26, 2023 by Lurker

[Graion Dilach]

2 hours ago, Lurker said:

EDIT: That conclusion makes no  sense; I added the previous result to the spoiler above, because it's a much better fit context-wise. The output from the --change-log starts counting at zero, but the generated LUAs start counting at 1. Off-by-one issue? So it's really BG1NPC?

The count difference comes from the fact that 0 isn't backed up, because it's the starting file in the base biffs. 1 is the snapshot between 0 and 1, 2 is the snapshot between 1 and 2 and so on.

So that's actually a BG1NPC bug. And it indeed is:

See https://github.com/Gibberlings3/BG1NPC/blob/b90822b39066c9d4261deb4aed215f141e50b3b7/bg1npc/phase2/tpa/bg1npc_kagqst.tpa#L135 - this isn't changed for EET, unlike say, Kivan's: https://github.com/Gibberlings3/BG1NPC/blob/b90822b39066c9d4261deb4aed215f141e50b3b7/bg1npc/phase2/tpa/bg1npc_kivan.tpa#L34-L42.

In fact, only that latter Kivan block is handled correctly, all the other BG1NPC ADD_JOURNAL EXISTINGs don't check against EET. Thanks! Will fix.

EDIT: https://github.com/Gibberlings3/BG1NPC/pull/127

Edited October 26, 2023 by Graion Dilach

[Lurker]

@Graion Dilach Quoting your GitHub link:

Quote

This fixes the "nonclosed journals" issue reported in https://www.gibberlings3.net/forums/topic/37293-brainstorming-ideas-to-improve-mod-quality-by-helping-users-to-more-easily-identify-and-report-issues/?do=findComment&comment=329294.

Just to be precise, I so far only reported an erroneous title of a journal entry. That this is also one of those that won't properly finish is something that I still need (well, not really ) to experience in game when I get there .

Anyway, great to know that I was able to help. And thanks for mentioning the --change-log feature. When I last tried to use that, I used a complete relative path to a file in override, which didn't really work...

[Graion Dilach]

Yeah, I mixed that up. I'm having a long week here. And yeah, if you really want to debug these, attempt rolling with --change-log. That does help. At worst, just don't trim the output.

[Lurker]

If a maintainer of WeiDU happens to read this, the output of "--change-log" lacks a space between "Component Name" and "Version".

EDIT: The same applies to "Component Name" and "Sub-Component Name".

Lazy Lurker

Edited October 28, 2023 by Lurker