UB bug still present in v16, [split by Baronius] Options

[Sikret]

At its current status, the Bg2 fixpack is best be called a "bugpack" rather than a "fixpack".

Yes, if it's installed with certain other mods.

No, even if you install it alone, it will add lots of bugs to your game.

The so called BG2 fixpack has two types of bugs:

1- Plain bugs, which will affect your game even if you install it alone.
2- Hidden bugs, which will come to surface and show themselves only in presence of some other mods (and no, they are not simple compatibility issues; they are bugs in FP).

Also, what you quoted was only the last part of a paragraph. The missing part is this:

Moreover, since their mod is supposed to be a fixpack, they should give even a more serious attention to testing it than other mods. A fixpack should not add so many new bugs to the game.

Which says the same thing Baronius wrote in his reply to your post.

[DavidW]

2- Hidden bugs, which will come to surface and show themselves only in presence of some other mods (and no, they are not simple compatibility issues; they are bugs in FP).

So I'm wondering what would make something a "hidden bug" and not an incompatibility issue. The kind of example that comes to mind is a .CRE file whose Effect index has been set to zero but which doesn't itself have any effects, so that anything which tries to add effects will corrupt the file (Baldurdash does this to TOMEGOL4, as I've recently discovered in debugging SCSII). I can see the case for calling that a bug even though it has no in-game effect (play with just Baldurdash installed and you'll notice nothing).

Is that what you mean by a "hidden bug" (in which case I'm surprised that there are many such in Fixpack, but I'm happy to be corrected), or do you mean something else?

[Sikret]

So I'm wondering what would make something a "hidden bug" and not an incompatibility issue. The kind of example that comes to mind is a .CRE file whose Effect index has been set to zero but which doesn't itself have any effects, so that anything which tries to add effects will corrupt the file (Baldurdash does this to TOMEGOL4, as I've recently discovered in debugging SCSII). I can see the case for calling that a bug even though it has no in-game effect (play with just Baldurdash installed and you'll notice nothing).

Yes, this is a good example of a hidden bug (as an important note, it's the WeiDu version of Baldurdash which touches Tomegol4 -- not the original Baldurdash -- and I don't know what exactly it does with that file; Vlad should know the answer).

There are other sorts of such hidden bugs as well.

Bg2 fixpack has such bugs, but I hope you don't expect me to point them out here, because I'm not going to play the role of yet another free tester for those who don't test their own mods.

EDIT: Using the term "Free" in 'free tester', I was not talking about money (as it should be already clear for those who don't want to intentionally misinterpret my words). Some people release mods by putting a bunch of codes into it without giving the least attention to testing and without giving any value to the players' time. Then they sit back waiting for the players' bug reports (expecting players to do what the mod's developers and their testing team should have done before releasing it). My point was that I was not going to fall in that trap by giving them the exact information they needed to fix the bugs in their mods. If they want to release a bugfree mod, they should work hard to acheive the goal (that's exactly what we do in developing IA. I don't say "what I do", I say "what we do". I have my own testing team for IA and I give them the biggest credit for IA's quality at every opportunity). Releasing high quality mods requires investing time and effort on it.

This post has been edited by Sikret: Aug 30 2008, 11:45 PM

[DavidW]

So I'm wondering what would make something a "hidden bug" and not an incompatibility issue. The kind of example that comes to mind is a .CRE file whose Effect index has been set to zero but which doesn't itself have any effects, so that anything which tries to add effects will corrupt the file (Baldurdash does this to TOMEGOL4, as I've recently discovered in debugging SCSII). I can see the case for calling that a bug even though it has no in-game effect (play with just Baldurdash installed and you'll notice nothing).

Yes, this is a good example of a hidden bug (as an important note, it's the WeiDu version of Baldurdash which touches Tomegol4 -- not the original Baldurdash -- and I don't know what exactly it does with that file; Vlad should know the answer).

There are other sorts of such hidden bugs as well.

Bg2 fixpack has such bugs, but I hope you don't expect me to point them out here, because I'm not going to play the role of yet another free tester for those who don't test their own mods.

Well, it's not my problem how the mod is or isn't tested, but you (and Baronius) have been admirably strong on the importance, when criticising others' mods, of providing concrete evidence rather than just making comments, so yes, I guess I would like to see some examples. I don't think I've seen any mentioned in previous discussions of this kind (the reason I got involved in the previous discussion of hidden bugs on SP was that I thought that for those examples, "incompatibilities" was a better name than "hidden bugs"; those examples aren't bugs in the sense you and I are using it in these posts.)

PS Are there "non-free" testers - can we pay people to test our mods? I'd seriously consider it:)

This post has been edited by DavidW: Aug 30 2008, 11:02 PM

[Baronius]

As I've emphasized earlier, it's a matter of definition. If a fixpack breaks another mod (and all mods that have the same common dependency) with a change that doesn't correct a serious problem or "unambigiously undesired effect" in the game, then such a change shouldn't be applied by a fixpack. No matter how we call it.

I feel a double standard here.

As we've discussed, DavidW, the developers of G3FP seem to use a different definition for bug than myself (and others at BWL).

Their definition allows the neutral alignment of a smuggler leader to be a bug, because they have some sort of subjective reasoning why it should be evil.
Their definition allows the phenomenon that certain keys remain in the inventory of the party members (instead of disappearing) to be a bug.

For some interesting reason, when the G3FP's change breaks mods, it's called "plain incompatibility" or "incompatibility".

So here we are: something which breaks or corrupts new content added by mods isn't a bug, but a smuggler's alignment who can be neutral for a million reasons is a game bug. This is where their silent propaganda led: they now managed to make (almost) everyone believe and use their incredibly ridiculous definitions and descriptions -- definitions which classify simple game settings as BUGS but don't classify fixpack's mod-breaking and dangerous changes as BUGS.
Wonderful!

[DavidW]

Well, to be fair, it's my terminology to call it "incompatibility", not theirs.

I think it's consistent with their definition, though. Their definition says (as I've phrased it elsewhere; I'm not quoting): something is a bug if, on balance of probabilities, it contradicts developer intent.

By that same definition, something is a bug in Fixpack if it contradicts the intent of the Fixpack team. And the Fixpack team probably didn't have any intentions one way or the other towards other mods.

(In fact, on your theory of their motivations, their intentions are probably to break other mods, so it would be a deliberate albeit nasty feature - not that I really buy that theory!)

But actually my point to Sikret was rather narrower: I'm interested if there are bugs in Fixpack under a much narrower definition. Call it the TOMEGOL definition - the BD-weidu bug in TOMEGOL is (I think, correct me if I'm wrong) a bug even under your quite narrow definition, as it violates the filestructure conventions. I took Sikret to be saying that there are such bugs in BG2-fixpack. I haven't come across any (and I write mods with a fixpack base and which fairly widely mess with file structure, so I'd expect to have), so I was after evidence (or clarification that I'd misinterpreted).

Incidentally (and off-topic), thanks for the civil tone in which this conversation is happening (to me at any rate!). I'm not especially interested in conflict; I'm interested in clarity and civilized debate, and I'm getting them.

EDIT: correct me if I'm wrong, but under your definition of a bug, something in fixpack wouldn't be a bug just because it broke another mod: something more would be needed.

This post has been edited by DavidW: Aug 30 2008, 11:24 PM

[Ardanis]

BTW, this indeed might have something to do with how one defines what is a bug.
For me it's (mostly) incorrect variable setting which would prevent action from triggering and thus destroying some quest. For Sikret (as I percieve it) it includes an enemy spawning too early (that's what there are checks for items in inventory and respective variable settings, right?), while for me it's nothing but minor inconsistency. And so on.

This post has been edited by Ardanis: Aug 30 2008, 11:46 PM

[Baronius]

Incidentally (and off-topic), thanks for the civil tone in which this conversation is happening (to me at any rate!).

You don't need to thank anything, but I'm glad to see you feel it in that way. If someone (from those who seem to disagree with us) should be considered as a more credible discussion partner, then it's definitely you. For obvious reasons. Of course, everyone deserves civil tone, except trolls (who don't get any tone, they get Crom Faeyr at BWL).

By that same definition, something is a bug in Fixpack if it contradicts the intent of the Fixpack team.

Their intent is to spread the BG2 Fixpack, and collect as many happy players for it as possible; and meanwhile, to teach as much WeiDU skills as possible, which also brings traffic for their site, and spreads the use of WeiDU.

This is all nice, but meanwhile they forget the real goal of a fixpack (= to fix real bugs and offer a compatibility-friendly ground for mods that are based on it), instead they add lots of things they call "fixes" so they can advertise it to be big, continously-improving etc., necessary mod. Same with WeiDU: they forget the fact modding is about ideas (and learning as much knowledge as required to realize one's ideas), and not learning as much knowledge as required to support their G3 Fixpack (and possibly to negate the changes of the G3 FP which break one's mod).

EDIT: correct me if I'm wrong, but under your definition of a bug, something in fixpack wouldn't be a bug just because it broke another mod: something more would be needed.

I haven't defined bug, I only defined a fix (= real fix). I will try to give a simplified description. Obviously, let's disregard the "obvious" bugs (= corrupt file, faulty implementation of a fix). On the other hand, a change ("fix", but not fix) which affects a potential dependency (e.g. monopolizes a supposedly "popular" game interface of mods) without a valid justification is basically a bug (see my definition of fix for what a valid justification is: e.g. a broken or "unambigiously undesired" element can be enough justification). This has been one of my major points all the time: if a change of a fixpack corrects an actually faulty or broken element, interface monopolizing is acceptable; otherwise it isn't. This is because there aren't many real game bugs to be fixed, and this means there won't be many monopolized interfaces => this means there will be very few broken mods. But I've devoted a complete post to explain this, as you also surely remember, so I won't repeat it.

I know I've quoted it already, but I like it so much:

something is a bug in Fixpack if it contradicts the intent of the Fixpack team

This probably hits the nail on the head, and is in perfect harmony with what I've been saying all the time: they believe their methods are superior and thus they have right to decide what is considered to a bug in their work and what isn't. TheBigg pointed out a few posts earlier, that it's never good if a developer is a tester as well for the same project (More accurately, the tester team is "external" in the reality, they are obviously not those who develop the project -- but this is off-topic). Well, the case is the same here: they develop the fixpack and they are also those who define what is the bug in it. We all know that it's never good if the same person criticizes (or proofreads, examines, etc.) a certain work as the one who has created it. Unfortunately, the G3FP developers believe their methods to be superior and perfect, and do not allow others to make suggestions. They even don't consider others suggestions.

Let me create another definition then, based on your latest one:
Something is a bug in the game if the Fixpack team thinks that the Fixpack should change it.

[DavidW]

I know I've quoted it already, but I like it so much:

something is a bug in Fixpack if it contradicts the intent of the Fixpack team

This probably hits the nail on the head, and is in perfect harmony with what I've been saying all the time: they believe their methods are superior and thus they have right to decide what is considered to a bug in their work and what isn't. TheBigg pointed out a few posts earlier, that it's never good if a developer is a tester as well for the same project (More accurately, the tester team is "external" in the reality, they are obviously not those who develop the project -- but this is off-topic). Well, the case is the same here: they develop the fixpack and they are also those who define what is the bug in it. We all know that it's never good if the same person criticizes (or proofreads, examines, etc.) a certain work as the one who has created it. Unfortunately, the G3FP developers believe their methods to be superior and perfect, and do not allow others to make suggestions. They even don't consider others suggestions.

Let me create another definition then, based on your latest one:
Something is a bug in the game if the Fixpack team thinks that the Fixpack should change it.

I think you're misunderstanding what I meant, which could perfectly well be my fault.

My point is that the FP is operating with this definition of bug:

Something is a bug ("thing needing fixing", if you like) in software X if it contradicts the intent of the designer(s) of software X.

And actually I think that's fairly defensible. If someone asks me whether such-and-such thing they've encountered in SCS is a bug, the reply is normally either "oops, yes, I'll fix it", or "no, it's intended to work that way". I'd have thought the same is true for most people's mods. It might be, of course, that once they know that (say) my giving Mulahey a Summon Fallen Deva spell is intentional, they decide that that's a really stupid feature (rightly so in this case!), but that doesn't make it a bug.

Now of course, the problem for the FP developers is that they want to know what the bugs are in vanilla BG2, which requires them to make inferences about what the developers want. Occasionally they've been able to do that by actually asking them (I think they corresponded with David Gaider a couple of times), but mostly they're having to resort to various deductions and evidence-gathering (my "balance of probabilities" from earlier in the debate).

(Incidentally, I'm using "designer/developer intent" in a relatively narrow way. In a sense, the "intent" of the BG2 designers was to create a bestselling game and make lots of money; the intent of Sword Coast Stratagems is to entertain me by seeing what can be done within the confines of the engine; on your theory, the intent of the BG2 fixpack designers is to spread the fixpack, collect happy players, and advertise WEIDU (I'm not necessarily buying that theory, of course ).

But in a narrower sense, my intent in writing such-and-such bit of code for SCS is that mages should cast these spells in these circumstances; the intent of the designers of the fixpack in writing code to change someone's alignment is to change it, etc. )

[Baronius]

I think you're misunderstanding what I meant, which could perfectly well be my fault.

I forgot to emphasize that I was interpreting your words in my own way, and found it quite possible that you meant them in a different way. I just pointed out that I think this definition is very narrow-minded and doesn't help to improve or assure the quality of a fixpack:

something is a bug in Fixpack if it contradicts the intent of the Fixpack team

And from that, I derived a definition on my own:

Something is a bug in the game if the Fixpack team thinks that the Fixpack should change it.

Nonetheless, I'm a bit tired of discussing definitions, because it's strongly indifferent.

A fixpack that requires all the mods that are based on it to be specifically designed and optimized for it (and if it's not done, it breaks the mods) is not a fixpack. .

A fixpack which brings a lot of questionable, ambigious and possibly mod-breaking changes to the game is not a fixpack.

A fixpack which brings changes (with subjective, one-sided justifications) that don't correct real problems while they may break third-party mods is not a fixpack.

A fixpack which isn't thoroughly verified & tested before its release (and this is also publicly admitted by one of its developers) is not a fixpack. "Trial and error" is not an acceptable method of quality assurance.

A fixpack which may break several mods that worked with its earlier versions is not a fixpack.

And so on.

These are not related with definitions, these are pure facts.

[DavidW]

I agree that discussing definitions can get tiresome (even for an academic ). The reason I keep being pedantic is just that: whether something is or is not a fixpack depends on the definition of "fix" (I take it that this is not controversial).

It seems to me that this mod we're discussing is a mod which attempts to modify those bits of the game which the authors think, on the balance of probabilities, contradict developer intent, and make them not contradict developer intent. It also seems to me that "fixpack" is a reasonable name for such a mod - although, sure, a mod written on a very different set of principles might also be a candidate for that same name. That's language for you.

Here's a way of seeing the point I'm (however badly) trying to make: Suppose I released "DavidW's developer-intent mod", and I didn't even use the name "fixpack", and my mod did indeed try to change BG2 to be as in accord with developer intent (on the balance of probabilities) as I could manage. And suppose that I advertised this mod reasonably and tested it reasonably (without prejudice as to whether either of those things is true of the actual Fixpack - I'm rather carefully trying to avoid that topic).

It seems to me that according to your philosophy of modding, with which I have a lot of sympathy, if I did release such a mod then:

1) it's entirely up to me whether, if at all, I break it up into components (you've defended the position that it's a mod author's own business whether or not he breaks up his mod).
2) it's entirely up to me to what extent I worry about third-party compatibility (you've defended the position that this is a nice feature but not a requirement).
3) something in my mod which broke another mod wouldn't be a bug just because it broke that other mod. (SCS breaks Improved Anvil and probably vice versa; that doesn't make either of them bugged).
4) You might or might not think it was a sensible mod (you might think that developer intent boiled down to guesswork, for instance), but even if you didn't think it was sensible, you'd defend my right to make it and promote it.


If you agree with me, then your criticism of the fixpack is clarified. It comes down to three issues:

1) is this mod properly tested?
2) is it being legitimately advertised?
3) does it have a sensible name?

I'm trying to avoid discussing 1-2; I'm happy to discuss 3 but obviously it's unavoidably a discussion about semantics and definitions.

[Baronius]

It seems to me that this mod we're discussing is a mod which attempts to modify those bits of the game which the authors think, on the balance of probabilities, contradict developer intent, and make them not contradict developer intent. It also seems to me that "fixpack" is a reasonable name for such a mod [..]

For Sikret and me, it doesn't. There is no need for definitions, just common sense. For us, a fixpack is what solves problems, and not creates them. Note that I didn't use the words 'fix' and 'bug'. I used the word 'problem'. In this case, a problem for a player is -- for example -- what has a negative impact on gaming experience. For a mod developer, it's a nuisance to be deal with, something which requires plus effort and time; effort and time that isn't devoted for his or her own mod's internal improvement, but rather for something that is triggered externally, by the silliness of someone else.

(SMALLER PROBLEM) The G3 BG2 Fixpack changes things that are liked by certain players while disliked by others. It has a negative impact on the experience of those who dislike it.

(BIGGER PROBLEM)
The G3 BG2 Fixpack changes things that can break third-party mods.
(1) It has a negative impact on the experience the players who encounter the problems and broken content in the third-party mods.
(2) It causes a nuisance and burden for third-party mod developers, because they are forced to touch their (possibly well-made) mod and modify their own work to fix the problems of an external mod (the G3 Fixpack).

'Developer intent' or not, 'balance of probabilities' or not, definitions or not -- common sense is the best advisor, and it says: a fixpack should not introduce PROBLEMS for players and mod developers. No matter how we define fix, bug, developer intent or whatever. Problems are problems. Nuisances are nuisances. Negative effects are negative effects.

Generally, in my dictionary, something which causes negative effects for players and modders can't be a fixpack.

As someone wrote in a Gibberlings3 forum topic:

What is a fixpack fixpack? It's a fixpack written to fix things that a fixpack breaks, of course.

It hits the nail on the head.

Your below statement is a nice but rather theoretical, formal definition:

whether something is or is not a fixpack depends on the definition of "fix"

Yes, but it disregards the external conditions, expectation of the "world" that surrounds this statement.

An army can also have a definition (I don't want to define it, let's imagine something reasonable for it, e.g. "an armed organization which ...., controlled by the ... " etc. ).

Your statement quoted above is almost like this:
"whether something is or is not an army depends on the definition of "army""

If we want, we can define an army as a "group of mounted warriors with bows". It's another question that such an army won't really protect a country nowadays from anything. Is it an army? By definition, yes. Practically, it isn't!

So there are qualitative measures as well, not just static definitions which think in absolute things.

It's senseless to keep focusing on definitions so much, because definitions themselves don't help at all. We could use completely different definitions to build up Physics -- everything would be consistent and OK, but completely different. It's another matter that things would be hard to handle etc., because of the impractical definitions.

I can define 'hero' as "Any person with nickname Baronius". It won't make me a hero.

So I think saying that the creators of fixpack have a consistent definition with their work does NOT justify it that their work causes problems and nuisances. It's a poor justification, just like the earlier one (i.e. that "how Baronius defines 'subjective' then", asked by certain G3FP developers), which was easily solved by my post where I presented that it's not that hard to categorize fixes (the fuzzy membership functions example, etc.).

To cut a long story short, common sense says that a fixpack -- regardless of its definitions -- shouldn't cause PROBLEMS. We say that a fix should never cause problems -- a fix should SOLVE problems, instead.

[plainab]

To cut a long story, common sense says that a fixpack -- regardless of its definitions -- shouldn't cause PROBLEMS. We say that a fix should never cause problems -- a fix should SOLVE problems, instead.

This is true. However, may I bring up something that has been noticed within the vanilla and expansion games of BG? I am sure we are all familiar with Oublek in Nashkell and the bounty rewards he can give, specifically the bounty for the emeralds gained from Prism. Now in this case there is a problem that needs solved. A problem that can cause more problems. To be exact there is an action which works but is broken in that it does not do exactly as intended. TakePartyItem(S:resref) takes all items of the specified item from the party's inventory not just one. This is a problem in that Oublek needs to take two, but will take one or more of the given item. This is what has led to the Oublek Bounty Reward Exploit Fix of Baldurdash. However, that fix only works for ToTSC and even that in a limited fashion.
Where does actually solving it cause more problems? Due to the lack of specific actions to take only two items and that the triggers are lacking in the vanilla game to find only two of an item, to truly correct it the items would need to be replaced with a known unique item (i.e. a mod added item). This in turn could cause issues with a mod added later that for some reason has another bounty hunter come and steal them from the party. You can see that a fix that works and solves the problem in a way that works around and with the limits of the game engine based on an unmodded game, can indeed cause problems with an added mod.
Should we forgo the fix because of the possibility of a future conflict? No, I don't think we should. I do think that since such a situation could cause a foreseeable problem, that it be well described in what is wrong, why it is believed to be wrong, and the steps taken to correct such action.

To make it shorter because my explanations can be mud:
1) It's a fix to place a variable to keep the state from repeating.
2) It's still a problem that since it uses a fairly common gem item that the player might have more than two and lose the extras because of the hardcoded limitations of the game engine or an exploit in that the player could leave one behind, get the reward and sell the other for more gold.
3) #2 can be fixed but it requires using at least one unique item (a copy of the original but with a new resref) so that there will be no question, within the confines of the game, how many of the given item there are.
4) #3 then creates the potential for a 'bug' with another mod (I would say incompatibility here) that for some reason has someone interact with the party based on them having the game original items.

This sorta ties into that one example you, Baronius, gave earlier about giving the two swords to a creature. However, unlike that one where it was merely a subjective reason based on D&D or what have you. This issue is entirely based on the game engine and our current understanding of how it works. So this may very well be an example of an issue where changing the items a creature has can not correct a problem but work around a game engine limitation. This would then as I understand it be totally doable as a fix to solve a situation that can not be solved short of porting the game to a newer engine ala BGT/TUTU. Any mods out there that may already do something with these existing items, should be communicated with and determine if they have a better solution to the issue. If not, then it would be their choice to modify to become compatible or they can change the files back so that the remainder of the fixes could be used in games containing their mod.

As an aside, I started out with the bad habit of making the code, making sure it would install with no errors, but never did much real testing with it. Some of the partners want to get all the code together and then test (sort of like the BG2Fixpack I suppose) but I'm glad that's not happening. I've got someone who has not just volunteered but is actually installing each bit of code and testing it in game. Boy has he found problems, the theories to fix may be sound but sometimes as in the above situation game mechanics don't allow it. I'm also finding that it is much better to keep each specific issue as it's own component. 1) It's easier to locate within a tp2 file 2) It's easier to see exactly what files you adjust. 3) If you're there doing one issue and you're testing it properly, you can usually find if there are other problems besides the "reported" one. At this point in time, when the BG1Fixpack does come out, be prepared for individual components that will 1) work on the unmodded game without too much deviation from the expected 2) have been at least tested with as many existing mods as possible 3) any known conflicts would be listed along with the steps being taken to correct. I don't foresee making too many changes that aren't specifically a fix of broken code or the addition of variables to make sure certain things don't take place.
Isn't it a issue that when you were going to be struck by a lightening bolt from that mad wizard Ramazith you ran all the way up the stairs only to find Ramazith there attacking you? Maybe not so much, but after you kill him and go back downstairs, he's standing right there where he was when you dodged his attack. Now that just ruins the immersion and the belief of the game. It's one thing if a person shows up a little early, but if the guy is dead that's just ridiculous.

I would be more than willing to discuss issues with the bg1 fixpack in a more public place other than the 'private by invitation only' workroom at G3. When we started back in 2006/2007, Cam just gave us access to the 'old' workroom from the previous fixpack attempt that more or less fell onto Unfinished Business to include any non-baldurdash fixes as they saw fit. We've just been there making our slow, silent and steady progress. Seems though that there are a few people who are interested, there are new modders/players who want to help, Cam usually gives them access after a one of us 'moderators' requests. Most share problems they run across with the unmodded game, a few actually help with thoughts on fixing certain issues, and a couple actually test things out (some of it I can't, don't have access to ToTSC). I just wander how many more people would be interested in seeing a fixpack for BG1. A fixpack that does what Baldurdash and Dudleyville do together in one location plus maybe a few more things (I wouldn't say hundreds more, unless you count all the little errors DLTCEP throws at you because the LastTalkedToBy didn't have the '()' at the end. Didn't break the game, doesn't break the game to change, and can't break any future mods by changing, but if left unchanged makes DLTCEP spout a bunch of unnecessary errors.

Earlier you said something along the lines that you knew how to build a better program than weidu to create and distribute mods, but that no one has asked you. This was the first that I've ever heard that you have such knowledge (not saying you don't I've just not read or heard it anywhere until now). If you could make a better program than weidu to create mods that wouldn't overwrite the entire file for just a simple change like increasing/decreasing weight to match the description, why haven't you? If there were something better available, I'm sure many would use it, especially if it didn't require a good grasp of programming to understand. I'm self taught when it comes to weidu (self taught as in, ask questions and look at other code). I think it's pretty poor of a program's developer to say 'the best way to learn how to use it is to look at how others have used it'. True, seeing the work of others can be enlightening. But if you can't understand what is being described in the help documents that come with the program, how are you going to understand what others do with it? If I hadn't even had the slightest understanding of computer programming (self taught basic back in the late 80's when I was in junior high), I would never have attempted doing any kind of mods. This is because weidu assumes a certain level of programming knowledge within it's documentation a level that can be hard to obtain for someone just starting out with nothing but the basic know how to turn on the computer and start their favorite RPG.

Okay, I'm done.
ab

[DavidW]

To avoid getting enmeshed in a philosophy-of-language debate (which I recognise I started ), can I just ask if you agree with my points 1-4 about my hypothetical "DavidW's developer-intent mod"?

EDIT:

We could use completely different definitions to build up Physics -- everything would be consistent and OK, but completely different. It's another matter that things would be hard to handle etc., because of the impractical definitions.

Off-topic: we probably couldn't, actually, unless you mean relatively minor shifts of definition. There's a certain literature on this in philosophy of science if you're interested. (My PhD was in physics, before I moved to philosophy; most of my research interests are in philosophy of physics.)

This post has been edited by DavidW: Sep 1 2008, 09:28 AM

[The Bigg]

I think it's pretty poor of a program's developer to say 'the best way to learn how to use it is to look at how others have used it'. True, seeing the work of others can be enlightening. But if you can't understand what is being described in the help documents that come with the program, how are you going to understand what others do with it?

The docs can be improved, and the tutorials can be written or amended - one of the things I'd like to do if I had the required skills is to largely rewrite them. Unfortunately, people that are good at programming, I.E. talking clearly with computers, aren't necessarily good at talking clearly with human beings. Additionally, a program developer is ill-suited to write detailed documentations about it, since he might be 'innately' aware of quirks within the program that newbies will have troubles figuring out on their own (and no, not only WeiDU has harmful quirks).
However, it isn't just me and Weimer being lazy and not wanting to write detailed documentations. The best way to learn a program is to read beginner tutorials, read other people's code, experiment with their code, and write your own similar code (repeating the cycle in this order two or three times). This is what programming books (or courses) do: explain a concept, give examples, make you do simple exercises on given code, make you write your own code.
The docs are meant as a reference for already skilled people, not as a beginner's read.

[Jarno Mikkola]

No, even if you install it alone, it will add lots of bugs to your game.

The so called BG2 fixpack has two types of bugs:

1- Plain bugs, which will affect your game even if you install it alone.
2- Hidden bugs, which will come to surface and show themselves only in presence of some other mods (and no, they are not simple compatibility issues; they are bugs in FP).

1) Like what? If we are talking about the key items that disappear when they are used in locked doors etc, it's a fix, as it was meant to be that way...
If we are talking about the alignment fixes, they effect the game balance(cause of spells) and there has been much discussion on the difference of alignments. But at least, they should be some what consistent on 'party of thieves', so...
2) ----

[coaster]

Unfortunately there are a few bugs outstanding in the current Fixpack (and which are apparent to the player, not just to modders whose mods have been affected by a particular fix). Assassin poison was buggered in the last version (although I think one of Nythrun's hotfixes might have solved this) and the Improved Mace of Disruption now results in undead saving vs. polymorph (with no modifier IIRC). Neither are game breaking, but they are there - the latter was particularly annoying as the IMoD became all but useless as a weapon in my last game.

TBH I wonder whether the "suck it and see" approach to Fixpack works better when it is updated more often (which doesn't seem to be the case currently).

[The Bigg]

TBH I wonder whether the "suck it and see" approach to Fixpack works better when it is updated more often (which doesn't seem to be the case currently).

Very likely: look at Linux ("release early, and release often").

[Sikret]

Like what? If we are talking about the key items that disappear when they are used in locked doors etc, it's a fix, as it was meant to be that way...
If we are talking about the alignment fixes, they effect the game balance(cause of spells) and there has been much discussion on the difference of alignments. But at least, they should be some what consistent on 'party of thieves', so...

Neither! We are talking about serious and critical bugs in a mod which claims to be a fixpack. I can't imagine how one can be playing the game with the BG2 fixpack without noticing any of those plain bugs in practice. If some day they want to gather a testing team, you can't be a member of it for sure.

See my edit to this post for the reason I'm not going to give exact information about those bugs.

[Lorph Halys]

See my edit to this post for the reason I'm not going to give exact information about those bugs.

You know, regardless of what your reasons are, it's pretty damaging to your credibility to complain about "serious and critical" bugs and then refuse to point out what they are when pressed on the matter.

If nothing else, all it takes is for someone to do the exact opposite to counter you. Watch.

There are no critical bugs in the fixpack. No, I'm not going to take the time to prove my statement. There just aren't any. Trust me.

Now what gives your claim more weight than mine at this point?