This topic is locked
I think an extremely large number of people are waiting for my response to this ?crisis?, if you like. I do apologise dearly for not taking the time earlier to do this, and as you shall see, an extreme amount of effort has gone into this single post. I must make an excuse and use real life as my sojourn, as similar to this dilemma, my job is not traveling too well. As such, and as I do, I have read through every single post in the Baldur?s Gate Trilogy-WeiDU forum (yes, absolutely 17 pages from the Wishlist thread at http://www.shsforums...showtopic=18795 and the discussion thread at http://www.shsforums...showtopic=18742) as if each and every post was scientific articles talking about the same facet of an organism, and have proceeded to ?review? the comments made by all parties concerned. And if you are wondering?yes, scientific research is what my current job involves.
Before I start into the particulars, I will expect excuse from personally naming names, as I think this may help clear the rubble of posts. Do not forget that every contributor has posted publicly and willingly, and I do not see any violation in naming names here. I will, of course, refrain from personal abuse, flaming, or targeting of any sort as a spawn of my biased opinions. However, I may get someone?s opinion incorrect, since this is my interpretation of all the current ?findings?, and if such an error is indeed discovered, please PM me. Do not post in this topic regarding the error, as this will waste space. This will not be repeated. If something like this happens though, I will likely correct the oversight, then delete what the user said regarding the error, effectively ?removing the error?. Finally on this matter, the names for and against certain components/arguments may well be incomplete, and will likely become outdated quickly, seeing as a ?Big Bang? of posts occurs quite frequently at this time of hot discussion. Thus, I will note that this list is correct as of my interpretation on Saturday 21th January 2006 3:21AM AEST.
OK, without further ado, I go to the meat of my post, of which there are two major points to discuss.
Major point 1: Should BGT/TuTu merge?
I have read a wide variety of arguments for and against this topic. There is also a poll available here that seems to be progressing healthily at this moment. The poll can be accessed at http://www.shsforums...showtopic=18824. Here is a rundown of the arguments on both sides. I have not named names generally, so not everyone in one camp will agree with all the arguments I present in one camp.
Yes (amazinggameguru, Andyr, Borsook, Bursk, CamDawg, cirerrek, Chevalier, Drew, grogerson, Grunker, J Beau, kharan5876, MajorTomSawyer, Salk, SimDing0, Thauron, Urghhh)
- working on two parallel projects wastes time that could be spent on improving and developing other modifications that do not share convergent aims
- saves effort on working with compatibility of other modifications
- combines the best aspects of BGT and TuTu
- remaining compatibility problems after the merger should be easy to solve
Indifferent (Sir BillyBob)
- generally similar reasons to the ?No? camp
No (Ashara/Domi, King Diamond, horred the plague, ronin69hof, sadun, ScuD, Vlad)
- the prospect of ?killing? one project and thus working with almost all of the content from the other project only is biased
- the perceived ?uniqueness? factor between BGT and TuTu, which has existed ever since conception of the two mods
- will likely take too long and be too difficult as a hobby-like pursuit
- no benefits perceived from a merger
- is likely to produce difficult incompatibilities to solve
- the project will likely fail because of continuing BGT vs. TuTu animosity
- BGT and TuTu supposedly have a different ?developing spirit?
- it is highly likely that a project that allows the user to ?Play BG1 using the BG2 engine? will split into three, rather than merge into one, i.e. this would be BGT, TuTu, and the merged project
- the commencement of developing the merger will strain the modding community as relevant modifications may be forced to halt development due to pending release of the merger
- allowing two parallel projects maintains variety in the community
- there exists no such thing as a ?best? merger that conglomerates the most optimal components of the two platforms. Rather, it will likely take most from only one project, which again introduces bias
In summary, the general argument sees many isolated concerns, as in from different people, about the validity, the practicality, the time frame for completion, the ?camaraderie? so to speak, the usability, and the downfalls of beginning such a project. On the other hand, the argument for a merger stresses ?ease-of-use? (excuse the pun) and minimal fuss associated with the merger.
Major point 2: If a BGT/TuTu merge goes ahead, what components of which will be used, if at all? How will that affect the wider community? Where should the components go?
This is the major topic of concern, especially to some of those people who disagree with the merger taking place. It is obvious, as Andyr had stated, that this is not a clear-cut thing to consider, and the Wishlist thread has promoted a variegated set of ideas from all sides of the camp. Here, I attempt to place all components discussed into discrete sections, and detail the issues that have arisen regarding them. I also give my evaluation of the current data, and present my verdict at the bottom of each component section. Before each of those takes place, I state the particulars of my understanding of how each component works in BGT and TuTu, since I seem to be the only one who is getting experienced at both systems of implementation.
1. Resource Naming (or naming conventions)
This component can be divided into two areas of concern: area renaming and other resource renaming. The former includes .ARE files, and to an extent can include the area script .BCS files. The latter includes filetypes as .ITM, .CRE, .BCS. I will treat these together for sake of some brevity.
BGT has a radical system of renaming the BG1 areas. It is irrelevant to the discussion how this came about, but it can be noted that SimDing0 attributed this to mediocre tools at the time of BGT?s conception. The area prefix is still ?AR?, but the numbers have no bearing on the original BG1 area numbers. This is because BG1 area numbers conflict with those in BG2, and maintaining ?compatibility?, if it can be referred to as that, the numbers need to changed. As an example, Candlekeep is AR2600 in BG1 but AR0015 in BGT. For another, AR4400 in BG1 is AR3300 in BGT. For a full conversion of area numbers from BG1 to BGT, and vice versa, please see the developer?s documentation that is bundled with the current version of BGT-WeiDU. Currently, door names and entrance/exit names are also renamed according to the area numbers. Finally, .MOS, .TIS, and .WED files follow the same naming convention as the .ARE files.
For other resources, BGT] keeps the original BG1 resource name as strictly as possible. However, the progressive nature of BGT takes into account incompatibilities with modifications founded and completed before the BGT-WeiDU revolution. For example, the modification ?Never Ending Journey? uses IMOEN6.CRE, and so BGT compensates in this specific case by renaming IMOEN6.CRE to IMOEN61.CRE. This is an unusual case, and only a few others are present. Typically, BGT will prefix with ?BG?. For example, other ?Never Ending Journey? incompatibility, is WOLF.CRE, which BGT renames to BGWOLF.CRE.
TuTu has a straightforward system of renaming the BG1 areas. The numbers are untouched, but the prefix ?AR? is changed to ?FW?. This maintains the consistency and validity of BG1 area references from a number of public documents, including walkthroughs, travel maps, and the like. Therefore, these documents can be referred to for an area number guide to TuTu, except that the prefix change from ?AR? to ?FW? must be considered when, for example, using the CLUAConsole, or when developing modifications. Finally, .MOS and .WED files, but not .TIS files, use the same naming guidelines as the .ARE files.
For .BAM, .BCS, .CRE, .DLG, .ITM, .STO, and .WAV resources, TuTu prefixes all such resources with the underscore (_). This ensures all BG1 resources used are strictly BG1 resources, and thus does not touch BG2 resources in these filetypes only. Since the BG2 engine only supports 8.3 filenames similar to that of old version of Microsoft Disk Operating System (MS-DOS), 8-character resources from BG1 have their first character replaced by the underscore character. For example, DYNAHEIR.BCS becomes _YNAHEIR.BCS. One major exception to this rule is with files like FTOWBE_A.CRE and MTOWBE_A.CRE. Replacing the first character of these two files will result in overlapping resource names. Therefore, a convoluted is used in the naming of such files. Ten such examples are given below, presented in the form <TuTu name> -> <BG1 name>:
"_0_FTOWB" -> "FTOWBE_A"
"_10_FTWB" -> "FTWBAX_B"
"_11_MTOW" -> "MTOWBA_A"
"_12_FTOW" -> "FTOWBASC"
"_14_FTWB" -> "FTWBAX_D"
"_15_FTOW" -> "FTOWBA_D"
"_16_MTOW" -> "MTOWBA_C"
"_17_FTWB" -> "FTWBAX_A"
"_18_FTWB" -> "FTWBAX_C"
Scattered ?fragmented? resource names also exist, such as _8_GBASI.BCS and _28_ELDC.BCS.
Ruleset filetypes such as .2DA and .IDS, have minimal modifications, but for those who are modified are actually replaced entirely. For example, NPCLEVEL.2DA, PDIALOG.2DA, SONGLIST.2DA. Other BG1 resources like .SPL use mostly BG2-resident resources. It is interesting to note as well that in reference to the area renaming conventions of TuTu, the .TIS and the area script .BCS files of TuTu use the ?_? prefix instead of the renaming of the ?AR? prefix to ?FW?. Hence, FW1000.ARE will use FW1000.MOS, FW1000.WED, but _AR1000.BCS, and _AR1000.TIS.
Argument
Some people prefer to keep the TuTu naming conventions (Ashara/Domi, Borsook) CamDawg, Grim Squeaker, SimDing0, NiGHTMARE). The reason appears simple. Giving a ?_? prefix to the other resources and simply renaming ?AR? to ?FW? in .ARE files is the easiest and simplest way to distinguish and mark BG1 resources from BG2 resources. For example, all BG1 ITM resources can be patched in one go by a simple COPY_EXISTING_REGEXP ~^_.*\.ITM$~ ~override~. CamDawg especially reminds of the consistency and validity with current naming of BG1 areas. On a more extreme note, Ashara/Domi apparently will not support the merger if the austerity is not achieved with the TuTu naming conventions in the merger.
Some people are not so sure that the entire TuTu naming conventions should be used in the merger. For example, Hety was reserved about conflicts with the ?_? prefix, although that has been recently solved. However, other reservations about adopting strict TuTu naming conventions have circulated. Drew suggested scrapping the bad side of the TuTu naming conventions, if any. In further elaboration of this case, Thauron and horred the plague has expressed some concern about using ?_? as a prefix, suggesting that it should rather be used as a suffix. SimDing0 and some others countered about the problem with files like BOYBA_01, BOYBA_02, BOYBA_03, which will become indistinguishable in resource name if the final character is replaced with an underscore. Finally, seanas suggests keeping the TuTu area renaming conventions but using BGT naming conventions for all other resources.
The third camp prefers to use BGT naming conventions in the merger. King Diamond did warn of his ?love of BGT? and his possibly biased view, but in no way can this side of the argument be deemed insubstantial. Argument directly against this camp refers to the difficulties or making any renaming of current modifications. CamDawg and Shed, however, referred to the use of ConTEXT and UltraEdit with highlighters, respectively, in tackling the problem. However, people ostensibly remain skeptical about this. I point out an error make in the Wishlist thread pertaining to this particular issue. ConTEXT and UltraEdit will to an extent convert all names of matching source to a target name by the use of wildcards, but is limited externally to the performance of hex filetype changes to files of extension like .ARE files. For example, removing the underscore prefix generically from an .ARE file opened as ASCII text will pollute any hex characters equivalent to the underscore that are not part of a resource reference.
In summary, there is massive division as to the plan of action for resource naming conventions for the merger, should a merger take place.
Finally, in this section somewhat as an aside, I also point out major misconceptions regarding the TuTu2BGT converter utility. Here, I understand the lack of knowledge of the tool as I have abstained from its release due to possible abuse of the program. In fact, whoever said that it took ?machine-time? to convert the resource names from TuTu to BGT is absolutely correct. For everyone?s information, this utility converts every single occurrence of a TuTu match in all known BG filetypes containing resource references to the target BGT name. First, tricky TuTu resource names such as _1_FTOWB and _YNAHEIR, the program can utilize a dictionary conversion method where variables are defined stating the source TuTu name and the target BGT name. If no such a match is found in the dictionary, then an underscore character is removed at the beginning of the resource reference name. TP2 code has also been implemented successfully. Despite how good this program may seem, I make no guarantee that this program works perfectly, but am still striving to remove bugs and adapt it for unconventional use. For example, those people who have read information about trap output from .ARE files will know about trigger points and their vertices stored in a .nfp/.vtx pair. If scripts need to be converted, I can adapt the program to recognize .nfp/.vtx pairs with ease. As Sir BillyBob had pointed out, it took him eons to convert just the resource references for the BG1 NPC Project to be consistent with BGT. I have, as a test run, used this program to convert this modification to be BGT-compatible, and although issues remain, such as the Dynaheir Romance cutscene after Sarevok?s death, what is converted is sound and saves very much daunting manual labour.
Evaluation
I believe that the major issue of concern to people adopting a particular stance on this issue is how difficult mod incompatibilities will be solved for the use of any naming convention, existing or novel. Forcing BGT naming conventions will cause a rethink of all modifications released and currently in development for, or for compatibility with, the TuTu naming conventions. For example, I reference the BG1 Quest Pack, updates for the BG1 NPC Project, and Enhanced Creatures for BG1TuTu. On the other hand, forcibly adopting TuTu naming conventions will throw modifications released and currently in development for, or for compatibility with, the BGT naming conventions out of whack. For example, I reference The Darkest Day, Never Ending Journey, and Check the Bodies. If a middle point is chosen where bits and pieces of BGT and/or TuTu and/or novel naming is used, then both ends of the modification spectrum are disturbed. Therefore, there is no doubt that whatever naming convention is considered desirable and agreed upon, existing modifications, whether currently in development, released, or are being refined, will suffer. Unfortunately, if anyone is unwilling to accept this for their particular modification, and I make reference to Ashara/Domi in particular on this point, I am afraid that the entire merger will be debunked. This is especially the case when the author of the modification in question is one that is technically considered a ?standard? in playing BG1, as is the case for the BG1 NPC Project. One can attempt to avoid such extremism by echoing the person?s views, but there is no surety that all anxiety will be absconded by making this kind of compromise.
On my preference for the naming conventions, I concede that TuTu has by far better naming conventions than BGT-WeiDU, but I also recognize flaws in the current naming conventions. Therefore, I support Drew?s view of taking what is best out of TuTu and changing the more dubious aspects so that it is clearer. For example, I noted in the Wishlist thread several days ago that I was unhappy about the naming of files like MTOWBA_A, FTOWBA_A, etc. It is clear from the description previously that replacing the first character results in overlapping filenames. It is also evident that replacing the final character as per Thauron and horred the plague?s suggestion will still result in overlapping filenames. Still, naming such a file _1_FTOWB.CRE does very little to distinguish it from _3_FTOWB.CRE or _22_FTOW.CRE. Furthermore, the numbering system used has no bearing on alphanumeric order of files. See the examples I gave in the description for such an event. I also believe it to be more confusing to replace some of the middle characters with novel characters. Therefore, I suggest keeping these filenames as they are, as they do not conflict with BG2 resources. I am very reluctant and definitely have reservations about my decision, but I fathom no other way to tackle this problem effectively. We have been thrown as an end-user the mess of BioWare and must work around it, for the end-users of end-users. Still on this convolution issue, I do not understand such files as _8_GBASI.BCS, so with my current knowledge I would simply restore the typical ?_? prefix if possible. I would also make all area-related files use the existing ?FW? prefix, so that we have a complete set of FW###.ARE/BCS/MOS/TIS/WED. This circumvents problems trying to identify each resource of the area set.
On the ?_? prefix itself, I understand the concerns regarding finding resource names quickly, but it is not difficult thinking that DYNAHEIR.BCS is _YNAHEIR.BCS, for example. I strongly support the notion of having a unique prefix to patch BG1 resources only, without resorting to a very large COPY_EXISTING list block. This is crucial to reduction in modification size and allows less repairing work for every modification that deals with BG1 resources in BGT and TuTu. The prefix will only peeve modders, if at all, cheaters, do-it-yourself fixers, and testers who need to use CLUAConsole or modding tools like NearInfinity or DLTCEP.
On repercussions of my proposed area naming convention system, it is inevitable that modifications will be affected. I has discussed this in detail above. Every effort should and will be made to update modification compatibility with the merger. The authors might simply give permission for alteration of their modification if they are concerned about the extra work that may entail from the merger. Also, simply stepping away and working on other modifications, or attending to real life, should not cause discredit to the author should the modification end up marginally ?broken? because of third-party ?tampering? with the modification. In other words, if modders are at all frustrated with the prospect of more chore brought about by such a merger, leave it to the team performing the merger. It is one more responsibility the team must take to ensure success of the merger project. I do forewarn a possible failure of the project if this requirement is not fulfilled, and make reference specifically to the facts that BG1 was released in 1998 and BG2 in 2001. The game is getting old, and Ashara/Domi correctly points out the ?dying? nature of the community. Even if it does not seem so at this point in time, it is more the sudden, unexpected decline in fans that will deal the greatest blow.
2. The BG1->SoA transition
This issue has been partially retracted as one of the most major topics as of late. It details whether such a transition, whether it is minimal or extended or BGT style, should be included into the core package of the merger, and whether it should be optional if it is indeed included in the merger.
The BGT transition is a compulsory core component, and the nature of it can be considered the minimal-extended type. After killing Sarevok, the final movie displays but the credits do not show and force the player back to the main menu. Instead, the game continues and a string is displayed suggesting the player should go to the Duchal Palace. There, they will meet Belt. Interestingly, if Belt was killed during Sarevok?s foibled coronation, Belt still appears for the transition. Belt conjures up a cover story, revised by seanas, about continuing tensions between Baldur?s Gate and Amn and asks the player to deliver a message to the Council of Six. The details are sketchy, but Belt teleports the players to an undisclosed location near Amn. There, a cutscene is only shown, where Shadow Thieves led by Mae?Var ambush the players and take them to Irenicus? dungeon. This cutscene also serves as the vehicle through which many journal entries are removed, items are checked for importation, and NPC transitions are made, if applicable. When in Irenicus? dungeon, the Shadows of Amn introduction movie is played, then Shadows of Amn proper commences. The NPC importation will not be discussed here, as that is not considered the fundamental part of the transition at this stage of the discussion.
The TuTu installation does not allow the player to play Shadows of Amn without installing a separate copy of Baldur?s Gate II, and thus does not contain a transition.
Argument
Many active posters agree this component should be optional (Andyr, Borsook, CamDawg, Grim Squeaker, kharan5876, Kulyok, Salk, SimDing0, Thauron), but there is some disparity between whether it should be included in the core package for the merger (CamDawg, kharan5876, SimDing0, Thauron) or not (Grim Squeaker), as well as how many choices the player gets if it is included in the merger. For example, SimDing0 mentioned three choices: none, minimal, and extended, and kharan5876 suggested that he agreed with this idea. Grim Squeaker believed in a minimal transition only, whether or not it was in the core package.
On the other side of the argument is a mandatory inclusion of the component, Chevalier and seanas argued that the inclusion of a transition of negligible size relative to the entire installation package for the merger is of no consequence, considering further that a player can simply export their character if they don?t like such a transition.
Evaluation
I made the argument previously that including new content like the transition is no different from including any other custom content into the core package. I made the analogy to collecting ?junk? in the garage until it was useful, if ever it became useful. Please peruse the Wishlist thread for an exact record of what I wrote. Therefore, I believe that a transition should be not be in the core package, and this by default infers that the transition be optional.
3. Transition Addendum: reputation reset at the beginning of Shadows of Amn in the core package
This component would set the player?s reputation back to the traditional Shadows of Amn value, when they transition from Baldur?s Gate to Shadows of Amn in the event of a transition being included in the core package. Note that exporting a character and importing into Shadows of Amn resets the reputation to the traditional Shadows of Amn value, so if the transition was not included in the core package, then this argument need not belong here.
Neither BGT nor TuTu undergo reputation adjustments in such a manner.
Argument
CamDawg is affirmative on the issue, arguing that the player is unknown in Amn. seanas also says yes. On the other hand, Hety, King Diamond, and Salk believe that it should not be reset because ?being a scum? (having a low reputation) should rollover to Shadows of Amn. Otherwise, high reputations should reset as to not give an advantage at shops.
Evaluation
I do not believe this is an issue for the core package, since I do not support the presence of a transition component in the core package (see above). However, if this would not be the case, then I agree with CamDawg about the player being a stranger in Amn. Also, it would preserve the Shadows of Amn portion of the game to reset the reputation to the traditional value. If people were to like this component, then it should be an optional component that is not part of the core package.
4. Map notes
This argument is similar to the transition in terms of determining whether such a component should be core and/or compulsory. However, the nature of this component is different, because it forms part of the BG2 engine, whereas the transition was entirely new content.
BGT uses compulsory core component minimal map notes for the major areas in cities only.
TuTu has an optional map notes component that adds map notes to every place that contains an info point, as well as obvious landmarks, such as ?Cave Entrance?.
Argument
All active posters agree that this component should be in the core package (kharan5876). Borsook and CamDawg originally stated that this component be optional in the core package. It is unsure whether that stance is now retained. On the other hand, Grim Squeaker, Salk, and SimDing0 believe that it should also be compulsory. Kulyok was reluctant to accept this, due to the possibility of ?bad writing? bad conceded that if it was simply taking from existing trigger points and obvious landmarks, then making the component mandatory could suffice. Still, a warning about forcing onto players the component, particularly purists, could have some detrimental effect.
Evaluation
The BGT map notes are lackluster. For example, Baldur?s Gate sections on the mini-map look bereft of prominent locations in terms of the map notes. Therefore, the TuTu map notes should be used, and should undergo review by Kulyok to ensure that those map notes suffice. I would advocate the realization of the phrase ?Play BG1 using the BG2 engine? by making map notes compulsory and in the core package, contrary to my view in the Wishlist thread. However, the map notes should not be hard-coded into the area files, so that any mistakes can be changed by simply changing the ADD_MAP_NOTE command. Also, if purists are just too worried, I do not have qualms about making the component optional.
5. One installation or two installations?
This argument deals with whether one installation should be used to play all of BG1, Shadows of Amn, and Throne of Bhaal, or whether two installations should exist: one to play BG1, and the other to play Shadows of Amn, and Throne of Bhaal.
BGT allows the former type, while TuTu only works with the latter type. One reason for this difference is that BGT appends ruleset files while TuTu overwrites them. What also may be of note is the fact that TuTu requires BG1 still installed to play, since it pulls resources directly from BG1 (such as .WAV and .BAM files). BGT duplicates .WAV files, and uses BG2 .BAM files, and imports .BAM files where they do not inherently exist in BG2 (such as the basilisk animations).
Argument
Drew and kharan5876 support one installation to play all, while SimDing0 suggested keeping the two-installation structure of TuTu because of an ?unbalanced? menu screen. Divergence resulted in the use of LadeJarl?s TutuGUI, with Hety, NiGHTMARE, Salk, and SimDing0 all agreeing that the size of this modification and for other reasons should keep it separate from the core package, and thus would be optional. Hety and seanas did not mind the current menu screens used for BGT-WeiDU, where only the Tutorial button is changed to New BG2 Game, and the information box under the Shadows of Amn option in the main menu changed to reflect the ability to play Baldur?s Gate. With this particular system, Kulyok expressed concern about not being able to access the Shadows of Amn tutorial, and it was then suggested that the start of Shadows of Amn could ask whether a tutorial take place. This idea was discarded and further discussion ostensibly halted.
Evaluation
I believe that there was truly digression in this topic, but there can be considered some overlap with the menu screens. I argue that the menu screens are purely cosmetic, and whether they are balanced or not should not affect the decision to have one or two installations. I do note Kulyok?s point about a lost tutorial, and if people really desire it, the only option for a one-installation system is to ask the user whether they want the tutorial at the start of Shadows of Amn. To the main argument, I stated in the discussion thread that an extra 2.95GB (the size of patched Shadows of Amn and Throne of Bhaal), or possibly less if a minimal install is made, goes to waste and does not compare with an apparently unbalanced set of menu screens, while the installation of an optional transition will render the extra disk space used redundant, since a tradition must ensure Shadows of Amn is playable. I add now that merger resources should not be dependent on BG1 being installed at game-time, saving more disk space. As I appreciate that most users have middle-to-high-end systems nowadays, there will still be the possibility of fans with low-end systems that could aim to play the merger, and we should cater for such an audience.
6. Tweak-like components
Such components include ?BG1-style summons?, ?BG2 items in BG1?, ?Hooded avatars?, ?NPC kits?, ?Summons rebalancing?, ?Walking speed reduction?, and ?World map update?. The issue is again with whether the components should be included in the core package, and if so, whether they should be considered optional. This section covers six components, so please read carefully to avoid being confused. One clarification is necessary here, and that is that the ?World map update? refers to a merging of at least the BG1 world map with the Shadows of Amn map. Due to engine limitations, there is absolutely no way to cause the BG1 world map to change to the Shadows of Amn map during the game, nor is there any way to use a ?third? map, since any Shadows of Amn or equivalent game menu-wise uses WORLDMAP.WMP, while any Throne of Bhaal or equivalent game menu-wise uses WORLDM25.WMP.
All the components mentioned, with the exception of ?BG2 items in BG1? are present in either the core TuTu installation or TuTu Fixpack.
None of these components exist in BGT except for ?World map update?, which is a core and compulsory component of BGT to allow access to Shadows of Amn, although it is possible that some of these components are compatible with the current version of BGT-WeiDU. Yacomo?s Revised BP-BGT Worldmap also serves as a kind of ?World map update? that works with BGT-WeiDU, and is supposedly compatible with TuTu, but this has not been tested.
Argument
?BG2 items in BG1? and ?NPC kits? are listed in CamDawg?s first post in the Wishlist thread, although his stance may have differed since. Grim Squeaker and SimDing0 believe that these two components should not be in the core package.
Andyr believes ?BG1-style summons?, ?Hooded avatars?, and ?Walking speed reduction?, should not be in the core package and thus should not be compulsory. The problem is of Shadows of Amn rollover, if a transition is installed, or if Shadows of Amn will be playable on the same installation as the merger (see previous). Grim Squeaker concurs with this view. SimDing0 believes that ?BG1-style summons? and ?Walking speed reduction? components should be optional in the core package because they represent facets of BG1, but ?Hooded avatars? can be considered in an external package.
SimDing0 also believes that ?Summons rebalancing? and ?World map update? should be an optional component in the core release. seanas suggested the use of Yacomo?s Revised BP-BGT Worldmap as a base for the ?World map update?. Grim Squeaker believes that such a ?World map update? should only occur in the presence of a transition, i.e. that the BG1 map should merge with the Shadows of Amn map only if Shadows of Amn is accessible. Unfortunately, this is not possible.
All these views may possibly have changed since, but not publicly stated.
Evaluation
I believe that all of these should not be included in the core component, and thus should not be compulsory. Again, I draw references to the phrase ?Play BG1 using the BG2 engine?. Thus, ?BG1-style summons?, ?Hooded avatar?s, ?Summons rebalancing?, and ?Walking speed reduction?, which seem to re-create the BG1 atmosphere, actually tweak the BG2 engine and thus does not satisfy the phrase. ?BG2 items in BG1? and ?NPC kits? are definitely tweaks. Finally, due to engine limitations, there is no choice but to merge the BG1 map with the Shadows of Amn map provided that Shadows of Amn is accessible in the same installation as the merger project. In other words, if Shadows of Amn can be played in the merger installation, then a world map merger must also talk place. Since I do not believe in more than one installation to play any Baldur?s Gate game, with the exception of total conversions, I would prefer the ?World map update? to take place as a compulsory component in the core package of the merger project.
7. Journal entry sorting and titles
BG1 does not have separate sections of the journal, so all entries are entered into an INFO-like area relative to Shadows of Amn. When such journals are directly imported into Shadows of Amn, they thus all appear in the INFO area, making it difficult to distinguish the important entries from the redundant ones, especially with quest entries. Therefore, the sorting system utilizes the BG2 engine by moving journal entries as appropriate into the QUEST and DONE_QUEST areas. One problem with this is that QUEST and DONE_QUEST journal entries appear spatially incorrect if they do not have details, and BG1 journal entries do not have titles. For a hypothetical example, a journal entry ?Angelo has sentenced me to death.? would look like ?Day 4, Hour 7 (5 Mirtul, 1369)Angelo has sentenced me to death.?. With a title, this would look something like:
?Our sentence.
Day 4, Hour 7 (5 Mirtul, 1369)
Angelo has sentenced me to death.?
Both BGT and TuTu have sorted journal entries and titles for them, but the implementation is different.
BGT has sorted journal entries directly embedded into the BG1 .DLG files in decompiled form (.D files). This allows easy specification of SOLVED_JOURNAL, UNSOLVED_JOURNAL, and JOURNAL, in the dialogue file. Solved journal inclusion will also have actions EraseJournalEntry() to remove all relevant unsolved journal entries as required. Since the transition is embedded into BGT, all BG1 journal entries are removed upon transition into Irenicus? dungeon. Journal text as of ZETA is contained entirely in the translation file journal.tra, although v1.00 will pull journal text directly from the BG1 dialog.tlk and simply add titles to them by regexp WeiDU patching, thus simplifying massively the translation process.
TuTu sorts journal entries by direct hex offset patching of compiled .DLG files. The component is contained in the TuTu Fixpack. A second component (written by Andyr) adds titles to the journal entries using a STRING_SET old_text new_text function. However, this only supports English and exact matches of old_text. Journal entries are not removed when quests are completed.
Argument
There is little active discussion over this topic, but it is generally agreed that this component should be compulsory in the core component due to the use of the BG2 engine as well as the bugged nature of the solved and unsolved journal entries. Kulyok did express concern about writing titles properly, but it was suggested that Kulyok reads through the titles when they are done to ensure that they are written properly.
Evaluation
There seems to be little, if not no, argument here, and I strongly agree with journal entry sorting and titles being a compulsory core component of the mequel project.
8. Spawns
Spawns are the random appearances of monsters within an area. This is different from a random encounter, where a transition from one area to another results in the player entering a median error in which they are ?waylaid by enemies and must defend themselves?. The argument revolves around whether BGT or TuTu spawns should be used. An important fact to note in this argument is that BG1 and BG2 spawns are leveled. See below for a description of leveled vs. static.
BGT spawns are static in level, controlled by the file SPAWNGRP.2DA. Areas with spawns use spawn point data blocks. Therefore, no matter what level the player is, static types of spawns will always appear in certain locations. For example, a level 1 player may encounter two ogres and one gnoll in a spawn, and at other times encounter one gibberling and one xvart, and if the player was level 10 instead, the same creatures appear. There is limited randomization in the types of creatures that get spawned.
TuTu spawns were erroneous in v4 but were fixed in v6 beta. The spawns are leveled, not static as in BGT, where the encounter levels are scaled according to the player?s level. For example, a level 1 player may encounter one wolf, but in the same place at level 10 may encounter six wolves. This works similar to BG1. Areas in TuTu have spawn point data blocks deleted, and have trigger points implemented, as if they were traps, to act as the spawn points.
Argument
All posters agree that the better spawn system should be used, which appears to be the TuTu style (Borsook, CamDawg, Grim Squeaker, Hety, King Diamond, Salk, Thauron). However, King Diamond did warn of the possible complexity of implementing the spawns.
Evaluation
I agree, knowing full well about both spawn systems, that the TuTu spawns are better and more closely reflect BG1. In terms of implementation, I imagine this to be quite a simple task. Recently, I have successfully pulled spawn information directly from the TuTu areas into .nfp/.vtx pairs for easy importation into any target set of area files.
9. Throne of Bhaal and Tales of the Sword Coast expansions requirement
A major issue is whether players will require ToB and/or TotSC to install the merger. Arguments include implementation difficulty, target audience that could be barred from using the modification, use of new scripting techniques provided by ToB, if applicable.
BGT currently requires both Tales of the Sword Coast and Throne of Bhaal expansions. However, it is possible that BGT be installed without Throne of Bhaal installed, although the consequences of a non-version 24698 game are unknown, and thus such a combination has not been tested.
TuTu does not require either Throne of Bhaal or Tales of the Sword Coast.
Argument
Those who believe both expansions should not be required for the merger include Borsook, CamDawg, Grim Squeaker, NiGHTMARE, and Thauron. Borsook suggests the merger attempt to coax players into obtaining the expansions for an improved experience. However, Thauron suggest it could be too inefficient and impractical to code.
Hety, on the other hand, things that the extra coding would be a waste of time, so he believes both expansions should be required. NiGHTMARE countered by referring to those players who have none, or only one of the two expansions that would miss out on the merger and are active players in the community.
In the midst of it all, seanas and Sir BillyBob do not mind about Tales of the Sword Coast requirements, but Throne of Bhaal should be required for ruleset reasons. The ruleset argument carried on a little with questions of exactly the types of features of Throne of Bhaal that would be used.
Evaluation
I believe both expansions should not be required for the merger, despite the extra coding, to increase the scope of the target audience. I think NiGHTMARE has a good point that generalizations cannot be made about who downloads and uses, or attempts to use, either BGT or TuTu, and then find out that an expansion was required that the player did not own. Telling those players to stop being sooks and buy the expansions extremely cheaply would not do anything to help the situation. The coding, I admit, can be a pain, but would benefit in the execution. The ends justify the means here.
10. Chapter globals
This was another minor issue regarding whether the prologue was equivalent to a chapter global of 1, or whether it should be the traditional chapter global of 0. In the former, the chapter globals are incremented by one relative to the actual chapter number, so that Chapter 5 would have a chapter global of Chapter 6, for example.
BGT has always used the incremented system, but uses ?modding-correct? chapter names instead. Therefore, a chapter global of 1 refers to prologue and chapter 1 simultaneously, so that a chapter global of 2 refers to chapter 2, and so on.
TuTu v4 uses the traditional system of chapter globals. With TuTu v6 beta, however, it uses the incremented system in order to enable journal function during the prologue portion of BG1.
Argument
Kulyok was worried that using the incremented system of chapter globals threw modification into disarray, expressing concern about the problems changing the chapter globals for existing modifications. Andyr, CamDawg, and SimDing0 supported the incremented system, and noted that changing the chapter globals is actually a simple matter of using ConTEXT and doing a mass textual replace of chapter numbers. They also noted that using the traditional numbering system would compromise prologue journal entry function. Finally, Borsook was indifferent, stating that using the incremented system is not really that bad.
Evaluation
A compromise must be made here. In both cases, a faithful conversion to the BG1 style is not possible and I cannot support Kulyok?s concerns simply due to engine limitations. It is either: journal entries work in the prologue, or chapter numbers are incremented. Therefore, I propose for modding convenience that the current BGT chapter system is used. I concur that chapter globals can quite simply be incremented using a mass textual replace with a program such as ConTEXT.
11. Bug-fixes in the core package and compulsory
This seems to be universally accepted throughout the active community following the discussion.
12. Compressing merger-installed files
This was a passing comment introduced by seanas that the merger should compress its files in BIFF format so that the override directory is not clogged, and the game performs faster, but was not discussed further.
Evaluation
I believe the merger should BIFF all files it introduces into the BG2 override directory, but not files existing in BG2 that are affected, such as the ruleset. This ensures ?clean? installation of the merge without affecting other modifications that by change were installed prior to the merger.
13+. Other issues
The following issues are not treated here, but are discussed in other threads. I may update this post later to include my opinion on these issues:
- extracting BG1 resources from CDs; suggested in the BGT-WeiDU forums by Grim Squeaker (topic at http://forums.pocket...ic,21327.0.html)
- one program for the entire conversion; initial first-post suggestion by CamDawg (somewhat of a discussion at http://forums.pocket...ic,21305.0.html)
- TuTu saves working with the merger project; mentioned in-passing by Ashara/Domi
- overwriting vs. patching (treated at http://forums.pocket...ic,21253.0.html)
Final words
This is a long review of all the points discussed in BGT/TuTu merger topics. Those topics are now closed as they are getting cumbersome to work with: the Wishlist thread with 12 pages and the discussion thread at 5 pages. I think I have expressed the active argument and my opinion on all the issues major and minor addressed in both threads apart from those raised in the other issues. I may present my thoughts at a later date. Believe me when I say that at least 8 hours went into preparing and writing this post. I stress again that the evaluations are my views, and people are free to discuss further.
I shall now deal with the team and time-frame of the merger. The Wishlist thread stated Andyr, SimDing0, CamDawg, and myself are willing to initiate and/or complete the merger project. Fair enough, and to be honest, my intentions are not in starting this project this very moment. It was suggested both privately and publicly that BGT and TuTu should stop development, but I do not see this as ideal. One can say that the future will come faster if you drop the present and work for it, but during that period of time (and the time-frame I do not believe will result in a release in a couple of weeks, as SimDing0 suggested) where is the present? I believe one must continue to serve the present while willing the future to arrive, and thus I do not plan to halt work on BGT at all. There will be a v1.00, there will be 10 written pages of bug-fixes accumulated from myself writing down all the bugs reported with ZETA in the BGT-WeiDU forum, and they will be fixed if required. Currently, translations are also being worked on. This type of meandering has been branded a waste of time, but those who look a little too far into the future forget the present. The present is why the Tutu2BGT converter utility was conceived, for example, and the presence is why BGT-WeiDU will continue. I understand that the merger project may slow because I am dividing my resources, but again I reminisce to my old claim of WeiDU-ising BGT in the first place, in that it has been a month since the release of ZETA, and a huge lot has changed since then. I am not one who throws it away, and this will be no exception. Regardless, unexpected factors will whisk me, and possibly others away, and one should always keep in mind that real life is of priority. We shall see.
To end this rabble, I ask everyone to take King Diamond?s argument seriously, that the community may well be divided into three at the end of this project. This is my risk assessment for Ashara/Domi. It is likely that this unfortunate event will take place, but the risk can essentially be minimized provided that mod authors allow adaptation of their modifications to be compatible with the merger project. If not, then I can almost say that all our discussion, intention, and even compulsion, will be close to nought.
Have a great day. Cheers,
Ascension64
P.S. For those interested in numbers this post uses only 48590 of the total 1024000 characters allowed in a single post.
Edited by Ascension64, 20 January 2006 - 07:29 PM.
