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

[Baronius]

The bug was known for v15 already. Wouldn't it be easier to fix it in UB itself?

[This topic was split from this]

[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

[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.