The_Baffled_King Posted April 30, 2022 Share Posted April 30, 2022 (edited) On the basis of the discussion in DavidW's thread about the replacement of duplicate unique items with their generic counterparts, it seems that there is substantial divergence of opinion about the aims, standards, options, and terminology to consider in relation to the EEFP. That's surely gonna lead to endless rehashing of arguments and people talking past each other in the threads wherein specific changes are proposed. Sure, it's inevitable anyway, but perhaps the extent of it would be reduced with more discussion here? (1) Does a "Fix" Occur Only if Something is Broken? No. The term has a wider meaning than that. The following definition of a fix that jastey uses is from DavidW's thread that I mentioned above: 21 hours ago, jastey said: I see this more as a tweak, too. I do see the motivation of "devs intention was to assign a generic item and grabbed the wrong one" but the aim of a fix pack is to fix things that are broken. Having several instances of unique items doesn't break anything, not in the sense of "can't play on properly". As a matter of terminology, this definition artificially limits the meaning of the word "fix". Sure, "fix" is used most commonly in relation to things that are "broken". However, it is also not in the least bit uncommon to say that mistakes should be fixed, or that if something is wrong then it should be fixed. Applying jastey's definition as written would mean that errors that prevent banters from firing would not be fixed. It would also mean that errors in triggers that remove reply options would not be fixed, provided that the unavailable dialogue was for roleplaying purposes only (ie the missing options provide no alternative actions or journal entries). Is that your intent, jastey? To be clear, I think that jastey describes a perfectly sensible standard to adopt for a fixpack (although it is not the only sensible standard). It's just that the way in which "fix" was defined is, in my view, objectively wrong - and this contributes to people talking past each other. (2) A "Fix" Occurs When a Change Gives Effect to Developer Intent I don't see how any issue can be deemed a fix unless there is evidence that the status quo is contrary to developer intent. Equally, once an issue is judged to be contrary to developer intent, addressing that issue to match developer intent is by definition a fix. This, as Camdawg and DavidW have pointed out, was the standard used in BG2FP. (3) How Do You Determine Developer Intent? Some stuff is obvious. Otherwise, I think it's totally acceptable to apply logical thinking to draw inferences of fact about what the developers intended. Others might want to apply more strict standards before deciding that the status quo does not meet developer intent. (4) Are Beamdog's Actions Relevant In Determining Developer Intent? I think that Beamdog's actions are relevant. First, I think that Beamdog were privy to information that we are not privy to. Obviously some people who post on this forum are in a position to shed some light on that! Second, I think it's undoubtedly relevant that we're discussing an EE fixpack. Others will differ, and maybe that discussion should be had. (5) What Constitutes a "Tweak"? In the context of Infinity Engine mods, it seems to me (from the G3 Tweaks anthology, for example) that a change is considered a tweak if it is purely a matter of preference, in that there is either no evidence of designer intent, or the tweak changes what was clearly the unambiguous intent of the designer. I agree that nothing that constitutes a "tweak" should be in a fixpack. However, the fact that some players like the situation created by a developer error does not convert something that is by definition a fix into a tweak. (6) What About the Restoration of Content? I would consider the restoration of missing content capable in principle of being a fix, provided that unambiguous Word of Dev exists to clarify that an encounter was omitted only due to time pressures or unintentional error. In practice, given the existence of UB-style mods, it is probably better for such fixes to be omitted. There is one exception I can think of: naming NPCs who (a) are generically-named; (b) are unique characters; and (c) were named within vanilla game resources currently in use. (7) Should the Standards In Existing Fixpacks be Applied to EEFP? Not by default. I mean, Camdawg explicitly invited "re-examination of past decisions". Only, there wasn't much discussion of whether the principles and examples laid out were desirable for the EEFP. One month later, we have DavidW's thread on replacement of duplicate unique items with their generic counterparts, which begins on the basis that BG2FP offers a precedent and framework to follow. Some of the discussion is a respectable difference of opinion on DavidW's interpretation of developer intent. However, some of the discussion was less about the specific proposal, and more about the principles that should be applied to EEFP. (8) Should Mods Adapt to EEFP, or Vice-Versa? I don't know. However, as a matter of principle, I think one has to consider the downsides of allowing mods to dictate fixpacks, rather than vice-versa. I am particularly concerned if a fix is rejected because mod authors are no longer around to adapt their work to a fixpack - sooner or later, one-way compatibility with unchanging mods stifles progress. Obviously I'm not an experienced modder, so I am in no position to identify the point at which the balance tips one way or another. No doubt it depends to a large extent on the amount of work required of modders. (9) So What Am I Saying? Developer intent, and the framework of the BG2FP, provide a good starting point to identify potential fixes. If a different starting point is desirable, it seems productive to try to agree on a (rough) framework early on in the process. I've already posted about how, in my view, the length of time a designer error remains uncorrected is a point in favour of allowing (some) designer errors to remain uncorrected, and I won't repeat myself on that front. Most importantly, when people are making plausible suggestions consistent with a pre-existing framework that has not been subject to any challenge, can we please refrain from accusing them of trying to arbitrarily enforce their personal preferences on a specific issue (we reached that point on page 3 of DavidW's thread, in my view)? It's already been suggested that said pre-existing framework is up for debate - if that's what people want, how about we have that debate? At the end of the day, something that was considered a fix according to BG2FP is very likely to still technically be a fix here and now. What may change in the interim is not the terms by which a fix is to be defined, but the desire of the community to see fixes of a particular nature implemented. If we aren't going to suggest a different framework to the one laid down by the BG2FP then, when faced with fixes one might not like, can we just move straight to saying "I do not like this fix and I hope it will not be implemented"? (10) In Conclusion In my opinion, the BG2FP is a good starting point from which to propose and exclude specific changes. But the framework should work for the community, not the other way around, so we can on occasion depart from it, if we're honest about when that is what we're doing. If we're departing from it often, we arguably need a new framework. However, it tends to be human nature to keep quiet about the things we like, and pipe up only when we disagree with something - which means that a framework made on the basis of complaints about specific proposals is likely to be a little skewed. Edited April 30, 2022 by The_Baffled_King Quote Link to comment
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.