Jump to content

Taylan

Members
  • Posts

    30
  • Joined

  • Last visited

Everything posted by Taylan

  1. Gentle bump on this thread, since BG3 is about to be launched. We've made really great progress with the wiki, both in terms of the server's ability to handle load, and the wiki's design and content. I think we're ready for the potential onslaught of new visitors and anonymous editors at launch, LOL. Google unfortunately still hates us for inexplicable reasons (even SEO professionals are baffled) so I thought I'd make sure to mention it here again for those who care about BG3.
  2. Hahaha to each their own my friend! But I think your criticism is partly... misplaced? The barrelmancy is just a meme, there aren't really that many places where you can use it. And it's not like there weren't silly ways to cheese fights in the older games. I think they intentionally overdid the environmental damage stuff in the earliest parts of early access (the prologue, and then the first group fight you're likely to encounter in chapter one) because they wanted to show it off. The max level is probably gonna be like 12, which makes sense for a "fresh start." Think BG1. Maybe you should give it a go once it's released.
  3. Hey all, I don't know how many people here are interested in BG3 but I've been having lots of fun with it and a while ago decided to set up a wiki for it: https://bg3.wiki/ It's a completely non-profit project, unlike the Fextralife one that's filled with ads, auto-playing videos, and claims exclusive copyright ownership over anything you contribute. We already have some amazing contributors who wrote a number of pages that are a lot more comprehensive, detailed, and well-written than anything you'll find on the other wiki, so I have high hopes about this becoming the go-to resource for fans. So yeah, just a heads up that this exists.
  4. I'm trying to debug the issue I've described in the following post: Since I'm still very unfamiliar with BCS files, it's difficult to figure out which of the dozens (hundreds?) of possible IF blocks might be erroneously triggering (or not triggering) to cause the observed behavior. Well, even if I was familiar with all the actions and triggers, I think it would be difficult to find out where I have to look without having some preexisting knowledge about where the actual combat logic is likely to reside. Hence the question: is there a way in the Infinity Engine to enable some sort of debugging mode where it traces ALL script execution and writes a massive log of every single decision it takes? Of course, this would generate heaps of data, but I figure it shouldn't be too hard to search such a log for certain actions (like the Beholder's piercing melee attack maybe) to quickly find the whereabouts of the problematic decisions taken by the script. For those familiar with Unix/Linux kind of programming, I'm talking about a trace log of the sort you would get from debugging tools like strace/ltrace/truss. Alternatively, let me explain what I'm looking for with an example. Consider the following script snippet written in BAF: IF Allegiance(Myself,NEUTRAL) OR(7) AttackedBy([GOODCUTOFF.0.0.0.0.SUMMONED],DEFAULT) AttackedBy([PC],DEFAULT) AttackedBy([FAMILIAR],DEFAULT) AttackedBy([ALLY],DEFAULT) AttackedBy([CONTROLLED],DEFAULT) AttackedBy([CHARMED],DEFAULT) SpellCastOnMe([GOODCUTOFF.0.0.0.0.SUMMONED],0) THEN RESPONSE #100 Enemy() Shout(89) Continue() END Now let's say that "Allegiance(Myself,NEUTRAL)" evaluates to false, therefore it skips this whole block. The trace log would then contain a snippet which somehow encodes the steps that were taken during execution. For example, using an imaginary BAF-like syntax: BEGIN CONDITIONS Allegiance(Myself,NEUTRAL): FALSE END Or for a more complicated example, let's say that "Allegiance(Myself,NEUTRAL)" matches, and from the OR(7) the third one i.e. "AttackedBy([FAMILIAR],DEFAULT)" matches, and therefore the actions are executed. The trace log would then contain something encoding the following execution, again using our imaginary BAF-like syntax: BEGIN CONDITIONS Allegiance(Myself,NEUTRAL): TRUE OR(7) AttackedBy([GOODCUTOFF.0.0.0.0.SUMMONED],DEFAULT): FALSE AttackedBy([PC],DEFAULT): FALSE AttackedBy([FAMILIAR],DEFAULT): TRUE BEGIN RESPONSES HIT RESPONSE #100 Enemy() Shout(89) Continue() END I know that BAF scripts are not executed directly but rather compiled to BCS, and that probably means that unless our tracing mechanism is highly sophisticated, it will NOT contain such nice snippets in a BAF-like format but rather something ugly that contains the kind of codes and references you see in raw BCS. Still, it would be an immense debugging help, and one can imagine writing a tool that parses it to turn it into a BAF-like syntax just like we can decompile BCS into BAF. So yeah, is something like this possible? Some native debug functionality of the engine? Some DLL hack? The next step would be to develop a whole modding IDE where you can set breakpoints in your scripts and trace the execution live while the game is running. xD
  5. I had completely missed this thread until now. Just want to say: neat! When I wrote that WeiDU is "probably" Turing-complete I was still very very unfamiliar with it. I'm still not particularly familiar with it, but I've since realized that it does offer all the basics (and then some) for general-purpose programming. Perhaps my main issue is the rather unique syntax and naming of builtin operations.
  6. I'm in the Beholder Cave in the Underdark right now and noticed a strange behavior from the Beholders in there. I reinstalled the game clean then installed the mods/components indicated by the WeiDU.log below, to make sure it wasn't due to my outdated SCS installation. Basically, if I charge into a big group of Beholders with Valygar, then as expected, they vaporize him pretty quickly. Death Ray, Disintegrate, Cause Serious Wounds, the whole shebang. But if I charge in with any of my other characters, they barely do anything. For some of them, literally all they do is try to bite them (melee piercing damage), with some others they cast only a few spells like Anti-Magic Ray but not much more. Perhaps they're trying to be smart by saving up their abilities for party members who are particularly vulnerable, though I can't figure out a sensible pattern. (It doesn't seem to be saving throws or magic resistance, for example.) They were acting more normal (i.e. properly aggressive against all my characters) after I had done the clean install of the game / before reinstalling SCS, so it must be an issue with SCS. WeiDU.log:
  7. @subtledoctor Thanks for the tips! I have SCS installed of course, hence posting this thread in the SCS section of the forum. Next time I encounter an enemy like Deirex I'll make sure to note whether repeated Pierce Shield / Pierce Magic / RRoR really do what they're supposed to. Your mod sounds very interesting. Currently I have all the SCS enemy/tactics improvements for mages and priests installed so I guess it would be incompatible, but I'll check it out in the future.
  8. Unfortunately I've already beat him by cheesing now. (Well, if you consider Protection from Undead to be cheesing.) But it's surely not going to be the last SCS enemy who poses this issue. I think the main issue tends to be that spells to eliminate protection from magical attacks like the ones I listed above don't work on them, probably due to innate immunity to spells up to a certain level, and that in turn means you can't Breach them so they're also immune to physical attacks (innate immunity to non-magical weapons + Protection from Magical Weapons or Mantle).
  9. Maybe I'm stupid but this seems kind of broken... All of the following spell protection removals result in a "Spell Ineffective" on Deirex: Pierce Shield Pierce Magic Secret Word This means I also can't cast Breach on him, so he's effectively completely immune to my attacks for enough time to cast a Comet and Dragon's Breath, obliterating my weaker characters. Is there a way to properly fight against him? Currently I'm thinking of cheesing the fight like I had to do with some other ridiculously powerful spell-casters, especially Liches who seem to love staying in one place and never chasing you. Just move in and out of their sight to bait out the protection spells and wait for them to wear away... Makes it easy but feels really wrong.
  10. Sorry for triple-posting / bumping, but I feel like I should provide an update since it's the end of August now: I had to take care of my grandmother for a big chunk of my vacation, since she has dementia and can barely move. From 3-4 different projects I had lined up for my vacation and was enthusiastic about, I was able to complete just one. T_T Please don't expect any quick progress, though I really don't want to let this project idea die. I'll probably work on it on and off as time goes.
  11. In case anyone's wondering what happened to this, I've just had all my energy taken by work and personal things in the last couple weeks. Will continue working on it soon, at least when I'm in vacation in August.
  12. @kjeron If that really is the case, that's a problem indeed. Quoting my previous post: A third option might be to expect the sound set mod to contain one SoundID->WAV mapping table per supported game. So the contents of the definitions file could look like: [sounds/bgee] battle_cry1 = bc1.wav battle_cry2 = bc2.wav ... select_action4 = select4.wav select_action5 = select5.wav ... [sounds/bg2ee] battle_cry1 = bc1.wav battle_cry2 = bc2.wav ... select_action4 = action4.wav select_action5 = action5.wav ... (I'm using the names from SNDSLOT.IDS, just lowercase.) There would be lots of duplication because those sections will be 90% the same, but at least there's no chance of confusion. Although I think I like solution nr. 1 in my quoted post better. There would be a small number of "special" names which the sound set installer automatically translates to a different name, based on the game. Consider: [sounds] battle_cry1 = bc1.wav battle_cry2 = bc2.wav ... select4 = select4.wav # Translated to select_action4 for BGEE, select_common4 for BG2EE select5 = select5.wav # Likewise ... action4 = action4.wav # Translated to (???) for BGEE, (???) for BG2EE action5 = action5.wav # Likewise ... (I'm not sure what the "(???)" should be in the last example. Is this what those game-prefixed IDs are for? E.g. within BGEE, there are IDs like BG2EE_SELECT_RARE1.) So this half-half solution might be best. It allows using mostly the IDs defined in SNDSLOT, and only requires the sound set installer to assume special knowledge over a small number of incompatibilities between the games. Doesn't require defining a whole table of our own IDs per game.
  13. I still don't see why it would be an issue to use the names from SNDSLOT.IDS. That the game engine doesn't actually read that file isn't important, so long as the mapping in it is accurate. I'm not proposing to write to the file, only to use it as a reference. And if for instance IWDEE uses BATTLECRY1 but BG2EE uses BATTLE_CRY_1 then all your sound set mod has to do to support both games is to list both of those entries (pointing to the same WAV file), like: BATTLECRY1 = my_fancy_battle_cry.wav BATTLE_CRY_1 = my_fancy_battle_cry.wav. Tell me if I'm still missing something. Neat! I still think a language like Python would be beneficial in the long term, but to each their own. We'll have to see if my project goes anywhere; it depends mostly on whether I actually find enough time and energy to put into it.
  14. @kjeron Why not use SNDSLOT.IDS when it tells me which symbolic name corresponds to which integer index? No need to create one's own mappings. A sound set can define a WAV file for BATTLE_CRY1, SELECT_COMMON1, etc., and it will be automatically translated to the correct integer index based on the SNDSLOT.IDS of the game for which you're installing the sound set.
  15. A sound not existing in all games or having a different numeric ID is no problem. 1. If a sound set provides a sound, but it doesn't exist in all games, it will simply not be installed for that game. 2. The numeric ID will always be looked up from the current game's SNDSLOT.IDS, the mod utility never assuming any knowledge of numeric IDs. What would pose a very minor problem: - Games use different symbolic names for what's obviously the same sound. E.g. if one game calls it BATTLE_CRY_1 and another calls it BATTLECRY1. Easy solution: sound set definition must define both, pointing to the same WAV. What would pose a significant annoyance: - The same symbolic name is used for completely different purposes in two games. E.g. if the name "DAMAGE" is used by one game for the generic sound whenever a character is hit, but another game uses it for the "critical damage reached" sound where the character asks for help. (This particular example is surely not the case, it's just an example of what could be.) Solutions might be: 1. use a symbolic name that exists in none of the games, the installer translates it to the correct real name; 2. sound set definition must specify which game is meant with the symbolic name, by specifying it as e.g. "DAMAGE/BG2EE" and "DAMAGE/IWDEE" and the installer interprets it the right way. That last issue *might* be the case for some symbolic names that are used for NPCs only, but I think it never applies to a regular character sound, so I think we're safe. This means the installer doesn't have to include tables mapping symbolic names to integers; it can use the mapping from SNDSLOT.IDS and expect the sound set definition to use names from there. The only "special knowledge" a sound set installer needs is a mapping from sound to WAV filename suffix, for pre-2.6 compatibility, because that mapping isn't defined in any game file, correct me if I'm wrong?
  16. So as I've recently realized and is mentioned by @DavidW above, symbolic names for character sounds can be found in the SNDSLOT.IDS file. That's pretty neat. However, are the symbolic names compatible between all games? I just compared BGEE, BG2EE, PSTEE, and IWDEE. They seem to be mostly identical, with exceptions. At the end of all but PSTEE there's some strange entries with the name of some game prefixed. Not necessarily the game the file is for, e.g. in BG2EE there's entries prefixed with BGEE_ and IWDEE_. The IWDEE_ entries found in BG2EE seem to correspond to EE_ entries in IWDEE. I guess if a sound set really contains sounds for those ids, then at worst one would have to write some duplicate entries, e.g. the sound set definition would link both EE_LEADER2 and IWDEE_LEADER2 to the same WAV and all should be fine. Insight from others welcome.
  17. @AL|EN I thought you were inviting me to discuss things over Discord. Is there some kind of document there that I can read? I just joined but just see chat. As a Discord noob I might be overlooking/misunderstanding something. I'd love to read some elaboration on what you mean with those points, e.g. how could/should an auto-update system look, what is meant with "application model" and so on. About installation / uninstallation / backups: I wonder if it would be best to just take a "start from scratch every time" model, meaning: before any file is touched, a pristine backup of all files is stored in a safe place. Then, whenever the user wants to uninstall something, change the order of installation, etc., the process looks like: 1. restore the original untouched game, 2. reinstall everything in the new order. What would such a method entail? As far as I understand, most game files (the BIF files in the data directory being like 75% of the game by size, I think) are never actually modified, and instead modified versions of individual files (like CHARSND.2da) are dropped into the override folder. However there are exceptions, like the TLK files which are modified in-place. Is there a guide somewhere explaining what files a mod *needs* to modify in-place vs. what can be done via the override folder? If the number of actually modified files is small, then creating a complete backup and starting from scratch every time should be easy and not waste too many disk space or computing time. (Although installing a behemoth like SCS takes ages even on my top of the line PC, so I guess I'd need to see if I can port it to PieDU and make it more efficient. I suspect that there's a ton of optimization possibilities / that WeiDU wastes way too many resources for the sake of simplicity. I dunno.) And then there's new files a mod drops in place, like sound files, which I guess could either be just left there to rot when not needed anymore, or would have to be registered by name and later cleared up... And some questions about iesh, or more precisely the "infinity" Python module package it provides: how actively is it maintained, how battle-tested is it, and how suitable would it actually be for a modding framework? Are there any known design flaws that inhibit performance or force the programmer to write cumbersome code for things that should be easy? I'm sure there's a ton of good code in it, but I wonder if it wouldn't be better to write a library with modding in mind from the start, just copying bits and pieces from iesh where needed (or using its code as a reference point).
  18. @AL|EN maybe you could shortly summarize the fundamental flaws you have in mind? I don't use Discord unfortunately but I'd be very interested to hear your thoughts. Regarding sound set installer only vs. the whole of PieDU, I'm currently planning to implement just enough of PieDU at first to allow creating mods of type "sound set" and nothing more, so I have something working and useful to be happy about, without immediately getting lost in complexities. At the same time I thought it would be best to start considering right away where else one might take the project, and start writing the code with that bigger vision, so there won't be many roadblocks in the future when it's extended to support more and more things. As a counter-example, think about how WeiDU started as "dialogue utilities" and can now do everything. That organic growth from a tool focused on one task towards a tool that can do anything is probably the main reason why it became so messy, which is exactly what I'd like to avoid. As for focusing on the players, modders, and ecosystem, I guess you people will have to help me on that since I'm new around here.(*) For instance I didn't even know about Project Infinity until this very moment! That's certainly a very cool project and I wonder how I could shape my project for least duplication of effort and most compatibility between tools. I'll keep in mind @subtledoctor's suggestion and make sure that there's a mode of operation in PieDU where its interactive UI can be skipped (allowing you to call it with command-line arguments instead), so that Project Infinity could theoretically be used as a master GUI for WeiDU / PieDU / (insert other tool here). One thing I believe I already understand about the players & modders, and you have to correct me if I'm wrong, is that the community contains both people who are very creative but don't have any programming knowledge, and people who are advanced/professional programmers. So that's something I'm keeping in mind. With the "mod types" I mentioned before, I intend to make it as easy as possible to create certain types of mods (ideally with zero code, just some definitions in a simple format), while also offering a rich Python API for programmatically editing any files you want. (*) Since I said I'm new around here, here's a funny story about that actually: I think when I was somewhere around 14 years old, which means around 13 years ago, I very briefly toyed with a class kit mod for BG2, and that was one of my first interactions with something close to software development. I might have created an account here to ask a question or two, or maybe it was a different forum, I don't remember. Sadly I got bored with it soon and didn't touch BG modding again for all those years. Now thanks to the attention brought to BG by Beamdog and then the BG3 announcement, finally I am here again after becoming a proper software developer.
  19. Happy to see more people in this thread who agree to my point of view. Yes, I suppose WeiDU compatibility would be crucial if such a project is to become something serious, and a sound set installer alone wouldn't get too much attention, especially since the WeiDU-based one seems to do the job just fine even if it isn't as squeaky clean. I frankly haven't written much code yet after all, but found myself thinking a lot about how exactly the project could look if it is to become serious. The current idea looks like this: PieDU A Python library & modding framework for IE games that aims to be dirt easy to install, clean in design, and easy to create mods for. The name is of course a homage to WeiDU, and the "Pie" part sounds like "Py" which is what a lot of Python tools/libs/etc. like to put in their name. It could have been called "PeiDU" to be closer to WeiDU, but I've come up with the neat backronym "Python Infinity Engine Doctoring Utility" which I like. Also, pie is yummy. So PieDU it is. PieDU is installed by unpacking it into a stand-alone sub-directory within an IE game installation folder. This means you have to install it once for each IE game you want to use it for, but that's not a problem because it mainly consists of a bunch of Python source files which are small in size. (I expect that it would still be under 1MB after it can do most things you'd want it to do.) It doesn't matter what you call the sub-directory for PieDU, but as a convention let's go with "PieDU" (duh). The following graph shows a sample IE game installation folder together with a PieDU installation: e.g. C:\Program Files\Steam\steamapps\common\Baldur's Gate II Enhanced Edition |- data |- lang |- Baldur.exe |- ... etc ... |- PieDU |- start.py (launcher script to start the PieDU UI) |- README.txt (always good to have documentation!) |- piedu (the actual PieDU Python library, don't touch) |- mods (drop your mods into here; the following are examples) |- SoundSet-NWNF5 |- SoundSet-Blah |- SwordCoastStratagems |- TweaksAnthology It seems that Python is trivial to install on Windows. There's official installers on the homepage (the kind where you just click Next a few times) as well as a free "app" in the Microsoft Store if you wanna go that route. Either way, once Python is installed, you can simply double-click on any blah.py file to run it, so all you need to do to start PieDU is to double-click on start.py. You can of course also start it from the command-line like "python start.py" on any OS. The user-interface could simply be console-based (don't have to do anything special for this; double-clicking on a blah.py automatically starts the Python program in a console), or it could use a GUI at some point in the future, since Python also has a built-in cross-platform GUI library. Whenever you start PieDU, it would ask you what you want to do, like install/uninstall any of the mods registered with PieDU. To register mods with PieDU you just drop them into the mods directory. They should be self-contained sub-directories like shown above. They would contain all the mod files plus a definitions.txt file that declares a bit of meta-data about the mod, like a pretty name, some documentation, and maybe a "mod type." A mod type could for instance be "sound set" which tells PieDU to invoke a predefined sound set installer procedure (like the one I've written previously in this thread) to handle the installation of the mod, so the mod author doesn't need to write any Python code. Other mod types could be "class kit" or "npc" for instance. And of course there would be a fall-back mod type called "custom" where you can add any Python code you want. Some trivial WeiDU "compatibility" would at first be offered by taking the easiest possible way: just allow people to drop a WeiDU mod into the mods directory, write a trivial definitions.txt that says it's a mod of type "weidu" and says where the main .exe is (or even just auto-detect all this). Then when the user starts PieDU and selects that mod for installation, PieDU just starts the mod's WeiDU installer. Thoughts/criticism/feedback? To be honest I fear that I'll end up being all talk and little action because my actual job is keeping my quite busy and I have some other hobby projects too, but let's see where it goes.
  20. I know it's probably possible. It seems the language can read arbitrary files and process their contents in a (probably) Turing complete way. However, in programming language lingo we have this term called a "Turing tarpit." Just because something is possible in a language, doesn't mean that language is as good as any other language. The most extreme examples would be languages like Brainfuck and Unlambda which are designed specifically to be so minimal that writing any useful software in them is practically impossible, even if technically possible. TP2 is obviously not that extreme, but I do honestly find the idea of using it as a general-purpose language pretty horrible. Keeping track of spaces and tabs in Python should really not be an issue for anyone who uses a halfway decent editor. Even Notepad++ should do. In fact that's what I'm planning to use for this pet project... so I'll be off to creating a proof-of-concept Python library and sound set package installer then, wish me luck.
  21. You're missing a crucial aspect of the code I've written: it allows you to define *everything* about the sound sets in INI files. The Python code doesn't ever need to be touched. I.e. a person creating a sound set package wouldn't need to know either Python nor TP2, just put WAV files in a directory and write a definitions.ini file, then put the installer.py script in the same directory and zip it up. And while you may be used to TP2 and not Python, I have to disagree that finding one cleaner over the other is purely a matter of taste and/or prior experience. I've been programming professionally for about 10 years (+2 before that) and worked with a variety of languages including some weird ones: sh, C, Objective-C, C#, Java, Scheme, PHP, JavaScript, Python, and XSLT. Usually learning new languages is quite easy at that point. But I have difficulty figuring out what TP2 code does, even with the documentation at my side, because it's really idiosyncratic. On the other hand I've only ever written about 2 serious Python scripts in my life and was able to produce straightforward code that mostly does the right thing (not completely but only because I don't know IE modding details), is probably easy to understand for anyone with a bit of programming experience, and allows the person creating a sound set package to not touch a single line of code. Apparently WeiDU is written in OCaml, so I wonder whether that might have affected the way the TP2 language works. But I doubt it, because from what I know OCaml is a very clean language that supports "functional programming" style. (A bit like Scheme which I'm a near-expert in, but with different syntax, static typing, and built-in pattern matching... I could probably learn enough of it in 1-2 hours to be able to make changes to WeiDU's code. ) I think anyone who's seriously worked with a proper programming language would agree that TP2 makes some things, that should be simple, unnecessarily difficult. Indeed I forgot the fallback to -1, gotta fix that. I guess I could try adding the UI thing too. About extracting CHARSND from the game: my idea was that the imaginary "weidu" library I used in the Python code would take care of that. I.e. the .parse2DA function would search for it in the game directory including overrides. I definitely wouldn't propose to use INI for anything more complicated. I just thought, "how could we make the creation of sound set packages as easy as can be," and using INI for the definitions was the first thing to pop to mind. You could just as easily use Python for the definition file. I just did a little Googling and it seems it would be just as simple, e.g. a "definitions.py" file could look like this, allowing the sound set package author to add some special code there if needed for some reason:
  22. Hmm, help me understand if I got this right: for <=2.5 compatibility, the WAV files need to have a suffix of one character (letter/digit/symbol) in their name, is that right? And the character is equivalent to one of the integer sound IDs, as per the mapping in your code? If I understood correctly, then I think that's very easy to resolve in my code. First of all I'd make sure that my imaginary installSoundFile() function supports an optional named argument withName=... which tells the function to rename the file when installing it in the game directory. (That would be a very simple addition to its implementation, like 2-3 lines.) Then at the start, I'd define the mapping from integer ID to character, just like in your code, just with Python syntax: soundIdChars = { 9: 'A', 6: 'B', 7: 'C', ... } Then, drop the for-loop with the glob, and instead move the installation of the WAV files into the for-loop over charsnd.rows, like this: Honestly I'm liking this idea so much that I might try to implement those few imaginary "weidu" Python functions over the weekend and see if I can get a super simple sound set package installer like this working. Edit: Full updated code:
  23. Wow, this thread got more attention than I expected. Indeed iesh sounds like what I had in mind. Funny that it's indeed in Python! Guess I'll look into it in the future, but if it requires a lot of extra development to be WeiDU compatible then I'm not sure if/when I could deliver. Too many hobby projects I'm working on already... That code is... monstrous. I could try it out, but honestly I'd feel terrible about using it. In any decent programming language this task wouldn't be nearly so complicated. Note that my criticism isn't necessarily aimed at the author of the code. I'm no TP2 expert, so for all I know, that might be the cleanest possible way to write that code in TP2. But let's think about how else that code could look, and how sound set "packages" for our theoretical code could look, if we had a full general-purpose programming language at our disposal. Let's start from the end goal of how we want our sound set packages to look. In essence, a sound set consists of: Name of the sound set. A set of WAV files. A mapping from WAV files to subtitle strings. A mapping from sound IDs (greeting1, battle_cry3, etc.) to WAV files. Ideally, that's ALL our package would contain. As you said: we want to hide all complexity from the person creating sound set packages. (Digression: We could "encode" the information mentioned in point 4 directly into the names of the WAV files --i.e., the name of each WAV file would be the sound ID it's for-- but that would force us to duplicate WAV files when we want to use the same WAV for multiple sound IDs. For instance, if we only have 2 battle cry WAV files but the game supports 3 battle cry sounds, then we might use one of the two battlecry WAV files for 2 of the 3 battlecry sound IDs to fill the gap. Therefore, let's scrap the idea of sound IDs as filenames and say that our WAV files can be named however we want; the package will contain an explicit mapping from sound ID to file name.) Our sound set packages could be zipped directories like: my_sound_pack |- greeting1.wav |- greeting2.wav |- battlecry1.wav |- battlecry2.wav |- ... |- definitions.txt (file containing the mappings) |- installer.py (theoretical Python installer) Where the file definitions.txt contains text like the following: [config] name = MyCustomSoundSet language = en_us [sounds] greeting1 = greeting1.wav greeting2 = greeting2.wav greeting3 = greeting2.wav battlecry1 = battlecry1.wav battlecry2 = battlecry1.wav battlecry3 = battlecry2.wav ... [subs] greeting1.wav = Yes? greeting2.wav = What is it? battlecry1.wav = You will fall by my hand! battlecry2.wav = No mercy for enemies! ... And that's... literally all "code" the sound set packager would have to write! (The installer.py in this example is the readily provided sound set installer, like your TPH. The sound set packager doesn't have to touch it.) Sounds unrealistic? It isn't. I wrote the definitions.txt in an INI format, which Python can parse with its configparser library. The following is an example of how the code could look, if we had a Python library called "weidu" which provides some of the WeiDU functionality in the form of Python classes. Did I miss any steps? I think I just spent about 2-3 hours writing that, but when I began I didn't even know how string references work so that time includes learning about TLK. Also had to Google some Python stuff as I'm no regular Python programmer. Note that I've written the code in a super friendly way with lots of comments. A more condensed form might look like: This assumes one sound set package = one sound set. But it would be fairly easy to allow many sound sets per package. And that still without requiring the packager to modify the Python code. For example every sound set could reside in its own sub-directory, with the WAV files plus the definitions.txt file, and the Python code would be modified to wrap all the code above into a function (like in your TPH) and that function would be called once per sub-directory in the sound set package. Tell me that's not a lot nicer! All the pseudo-functions I've used above from the made-up "weidu" Python library should be easy to implement, either by using code from iesh, or with a bit of manual coding.
  24. WeiDU is a monster, both in a good and a bad way... The good thing about it, I suppose, is that you don't need to be a programmer to be able to understand and modify TP2 files. While TP2 is technically a programming language (I'm 99% sure it's Turing complete), it's not really a programming language in the conventional sense and includes a massive amount of convenience commands that are fine-tuned to the task of patching IE game files. The bad thing is, since it's not a proper programming language, you will easily hit very annoying limitations where a little bit of custom code in a proper language would have solved the issue. Currently I'm trying to write a sound set installer that will work for all game types: since the first column in CHARSND.2da specifies which sound the row is for, it should be possible for the script to fully automate the patching of CHARSND.2da based on the files you put in the SND directory of your sound set mod. For instance, if I put the files MySound6.wav, MySound9.wav, and MySound20.wav into the SND directory, and I supply a TRA file that defines @6, @9, and @20, then the installer script should automatically patch CHARSND.2da the right way, inserting the values from the TRA into the rows identified by 6, 9, and 20. I've been reading the WeiDU documentation to figure out whether this is possible, but it seems very difficult. The documentation is also not very well organized I'm afraid. (A single massive table of alphabetically sorted commands is not very nice for navigation, or searching for commands that are useful for a particular purpose, like 2da patching.) So I wonder: is there an alternative to WeiDU that's more for programmers? I've been thinking something like a Python library for instance, that contains a bunch of classes and functions that more or less correspond to all those useful WeiDU commands, but it would allow me to read a 2da file into a Dictionary object, so I can modify it with regular Python code, then tell the library to turn it back into a 2da. (I'm not actually a Python programmer, but I think Python would be a good fit for this.) Sometimes I wish I was rich and unemployed. I would love to create something like that myself, or fork WeiDU to create a more powerful variant that supports a proper programming language. If you don't know of any tool/library like that, maybe you can help me brainstorm how a smart sound set installer can be written in the TP2 format. EDIT: Looks like someone beat me to it when it comes to writing a smart sound set installer: https://forums.beamdog.com/discussion/82008/ https://github.com/GraionDilach/Planescape-Torment-Voice-Pack-for-EE-2.6 But that kinda proves my point when you look at the code. It's so over-complicated, defining huge tables and all. (Maybe there's still a better way to do it, dunno. Code clarity might not have been the top priority of the author.) And with that much complexity, you may as well use a regular programming language anyway.
  25. I could go through the whole source code of GemRB to figure out how all the game files fit together, and it would still not teach me how to distribute mods with WeiDU. Documentation is crucial in any software project and more broadly in "software communities" that create content together with hand-crafted tools like NI/WeiDU/etc. The French guide looks exactly like what I had in mind... at least from a glance, since I can't read French LOL. I guess I could run it through Google Translate and clean it up to create an English translation. The link to the BGForge MSL extension for VSCode is also much appreciated. Nobody likes writing code in Notepad. Thanks for all the pointers!
×
×
  • Create New...