Jump to content

suy

Members
  • Posts

    222
  • Joined

  • Last visited

About suy

Profile Information

  • Location
    Barcelona

Recent Profile Visitors

877 profile views

suy's Achievements

  1. Why would it be a lot of extra work? The external script can easily just add to the TLK file(s). Is is because of the backup? I have to admit that I don't see how weidu does backups of the dialog.tlk. I only have found copies of it in dlcmerger's installation. For the rest, I just see a bunch of "tlkpath" files which are one line long text files with just the path to the dialog.tlk file.
  2. Oh, great to know then! You mean that the looping over the files calls one Perl instance on every loop? Is that working fine for Windows as well? I'm asking because my understanding is that forking and calling external processes is extremely efficient on most Unix systems, given how prevalent shell scripting is (and how many process those spawn in complex pipelines), and also that POSIX sort of implies, but that Windows just favors other kind of techniques. I'll look at 10pp, thank you! I wasn't aware of that implementation detail.
  3. Thanks for your replies and comments, @DavidW. Some small comments: The examples of SFOv2 are more or less what I expected that could look like in terms of brevity and readability. I've seen SFOv2 before when I dug into the small issues that I've found in ToF, and which I reported on the forum. In some I even reported what my guess was of what the fix (or part of the fix) looked like. But as you said, time is scarce for everyone, so writing documentation for it has less priority than other stuff, so it's difficult to say if it will get some adoption. Until I started to search for weidu files in a ToF installation, I did not realize that such "special" syntax seems to be compiled into a file in weidu_external, which actually looks like the weidu code I'm used to. Then, the special syntax gets passed to functions, but still in string form. That's a bit worrying for someone who is not used to any of this, in that, it seems hard to realize how things really work inside the library, and figure out what's wrong when something doesn't work in the mod using the library. WRT the second point, yes, calling something via AT_NOW is what I have in mind. In that point you said: "The question I'd ask is: what is the advantage of implementing that high-level functionality in a new language that gets called from WEIDU, [...]". My answer is that I don't know if the alternative approach is a net benefit or not, but until it is attempted and it gets tested, we don't know for sure. For example, I surely can be more productive doing that in the alternative language, given the circumstances. Is it worth the cost of having to write support for a few file formats in a general purpose programming language, and the possible slowdown? Depends. The implementation of the file formats can be used for other purposes. For example, I use extensively a program that comes with GemRB's iesh called ieparse.py, to inspect files in the console. I can verify if patching code done with weidu does exactly what I wanted, because I can convert the before and after to text, and diff them. For the binary files that I (or anyone else) added to git, I see them as text instead in the git log, because that tool is automatically used as a filter. I already have to implement some of those file formats in C++ for Moebius Toolkit, as in the future I want it to be an alternative to EEKeeper, which is abandoned. Sadly I don't see a way to reuse that C++ implementation for anything else, but another language might have a chance. WRT the size of the existing mod ecosystem, and fully replacing weidu: I sincerely hope that we can keep running weidu for long. I think it won't be an issue on Linux, but I heard some concerning comments on weidu being still based on an old OCaml version, that might not be supported in newer Windows versions. I don't even remember who said it or where, so I can't double check if I'm misremembering, but it is very concerning, because some improvements here or there in weidu would be nice, but keeping it running is even more important. If maintaining or contributing to it gets even harder, then it can be a huge problem. I think that fully replacing weidu is indeed, just too much to ask. But (related to the previous point), if it can be ehnanced a little bit to allow for more compatibility with a theoretical 2nd tool (I don't know how, and I don't see much need, but mentioning it for the sake of the discussion, as I think it was AL|EN's point of the post), could be enough. I don't mind much having to write a TP2, and make a mod that it's weidu on the shell, but maybe more of another software on the core. But I don't know about modding other games, so I suppose AL|EN was having in mind some other additional features to make a GUI or any other kind of installer. Thanks!
  4. Exactly! That's the 2nd step that I mentioned in my first comment of the thread. It's something done already in some components of existing mod (using AT_NOW to call something external, but it would like tisunpack, iconv, perl for SSL, etc.), and I know that my mod doing for ITM or SPL files it is gonna be seen eccentric (because those other mods do it for much different purposes), but I want to try it, and see how it goes. Maybe the approach has to be thrown away, but I need to attempt it first. Indeed, the documentation that comes with weidu is a bit lacking some times. I of course read it, and give it a try, but it's the stuff posted in this forums that has saved me, because it is clearer what the intent is. Modding for having fun playing the game is great, but I have little patience this days, so if developing the mod is too frustrating, it feels like what I do for work, and give up easily. Stuff like CamDawg's post on item patching got me started with my first 55 lines of weidu, and after DavidW's course, it grew by 500 lines (literally, I see the growth just days after it was published, according to the git history). If you have the time to write anything documentation related I definitely would appreciate it, a lot. The stuff about GET_OFFSET_ARRAY that you posted was helpful already, and if you have any hint for doing what you mentioned in the last paragraph, it's also welcome. It's possible that running an external process for each file in a loop is prohibitively expensive, though, but again, I'll have to try and see it.
  5. I already said so in the previous comment, yes, I've seen a handful of libraries in a few different languages, none of them having gained any traction. And I have started one more that it's already working to some degree, and I will make it public in hopefully the next months (and I also said I don't expect to gain any traction, nor to be a replacement, just a complement of the current ecosystem). It's not fun to write such library for me, no, as the file formats are many and have lots of fields. But I'm having even less fun trying to do reasonable things in weidu, and not being able to. If you are happy with the status quo, better to you. I don't plan to subtract anything from it (nor I could, even if I wanted). I very much disagree. There would be no need to write such a function if weidu supported data structures. In fact, given that weidu is only capable of doing reads and writes via offsets, it's weidu's hammer which is constantly on the look for nails. I refer to my example again. The pseudocode snippet is based on real code. If you prefer the code using GET_OFFSET_ARRAY, more power to you. You can rely on tools that already exist. I don't, and that's I have to suffer making my own library, and be able to read and write files the way I think makes sense and which is scalable and maintainable. Becaue I very much would like to write this: for effect in item.effects if effect.code == 216 print("I drain", effect.parameter1, "levels") end end Rather than: GET_OFFSET_ARRAY ab_array 0x64 4 0x68 2 0 0 0x38 PHP_EACH ab_array AS int => ab_off BEGIN GET_OFFSET_ARRAY2 fx_array ab_off ITM_V10_HEAD_EFFECTS PHP_EACH fx_array AS int => fx_off BEGIN READ_SHORT fx_off fx_type PATCH_IF fx_type = 216 BEGIN READ_LONG fx_off + 0x4 amount PATCH_PRINT "I drain %amount% level(s)" END END END But if you prefer the latter, that's great. The latter exists and it works, available for every modder. The former needs work still, but I plan to publish it this year. And it's not coming to threaten anyone. It's just like SSL. Something written in another language, called from inside weidu. I know very well of weidu's origins, and I know what weidu's name means (everyone who moves the mouse over the word in this forum gets a tooltip saying so! ). Indeed, I mentioned dialogues for this very reason. I have not much interest in dialogue editing, and I don't plan to work on it. I'm not claiming that any language is or will be equipped with tools to patch dialogues out of the box. Quite the contrary. I'm just explaining that, for the kind of mods that I want to write (which involve ITM, SPL, 2DA... but not dialogues), weidu has shown to be very, very frustrating. I'm explaining what I'm doing to overcome that frustration. I'm trying to do so in the context of AL|EN's question, which is what would be needed to have a weidu alternative. As I explained in my first comment, I think if one would want to fully replace weidu (which, let me insist, I'm not saying it's likely or possible in practical terms), said person would have to start with something small (using it less and less for mods just dealing with a handful file formats, like the ones I do), then eventually grow, if people like the approach, there is time, etc. etc. etc. For a tweak mod, this is manageable, because it could come last (no backup? no big deal to do it manually), and the file types to support are few (and are the ones that weidu doesn't support well IMHO, but you might disagree on this). And again, I'm not saying that any well established mod should be be rewritten to drop weidu "just because". I'm not saying it's doable or advisable, and I'm definitely not saying that I volunteer to do any more work than what I mentioned. And I definitely don't want to lose all the wonderful mods that I don't want to code, but that I use for playing. That said, in the unlikely case that a project like mine gathers any interest (and others do exist! it doesn't have to be mine!), the fact that it originally comes with no support for dialogs, scripts, etc, does not mean that it can't be added, or that it would be hard to do so. It's way, way, way harder that weidu implements data structures or supports better functions, etc. PS: yesterday I wrote that first comment at 1 AM. Both yesterday and today I feel tired, so it's perfectly fine that I did not do my best at communicating what's my intent (to be fair, it's a difficult, nuanced topic that also involves a lot personal preference and social dynamics). I love this community and I'm just not happy of the technical limits of some tools. That's it. That's the gist of it. Cheers.
  6. In another language it would be very similar to the following pseudocode: spell = Spell::read(file) for effect in spell.effects effect.parameter1 -= 1 end spell.write(file)
  7. Very hard disagree, and I'll give you an example. The one that made me decide that I've wasted too much time with weidu, and that I'd attempt to use something else. Try to make a copy of SPCL822 (the spell that makes a Monk get a base AC going lower with levels), and patch it with ALTER_EFFECT/ALTER_SPELL_EFFECT so that every effect sets AC to a value lower than what it's there by default. You'll hit tons of limitations due to the values being negative for parameter1. I for one, could not know how to do it, and I only found a weidu bugreport, and an alternative version of the function that DavidW posted. Since David's version has the limitation of only allowing till -9, and I needed to go even lower, I gave up, and altered the item with NearInfinity, then added the generated file to the mod. CamDawg published another update/alternative to the function, but it was after I had to solve it "manually". That was posted 15 months ago, December 2022. I don't get the impression that the weidu ecosystem is so well established. In my experience, and for the mods that I want to make, weidu is not satisfactory, at all, and I keep seeing the wheel being reinvented constantly (as the links show). Maybe it's awesome for dialogs and scripts, I don't know, but I am very skeptical.
  8. I think this is something that pops up from time to time, and everyone has their own priorities or preferences. The last time I've read about a proposal, some of the answers were appalling, so no wonder that whoever wants to do this ends up burned. I have done enough weidu so far myself, that I know that I want to reduce it as much as possible for my own use cases, and I've started to do so. My plan is not to make an alternative from the start, but to work on phases. The first phase is to create a tool that can be invoked manually, ahead of mod install time, to create or alter game files. The files can be added to the mod, as "static" files, like if you created them in NearInfinity, but instead of pushing buttons, typing code. This exists in a few forms. I think iesh can do this, and dark0dave's library as well. There are few libraries/tools published online that have done similar things in other languages. The second is to call that tool from weidu, when the mod installs. This is also something that exists. Stuff like tisunpack, iconv, etc. Stratagems Scripting Language (SSL) uses Perl, if I remember correctly. This is just a helper to do heavy lifting of things in which weidu is not so well suited. It needs to delegate to weidu for copying the files, so the files end in the backup, if I'm not mistaken. Next would be the same as the previous, but more intensively. The whole mod component would be coded in the external tool. Then, to install this mod component using the new stack, it would not need weidu (but you won't get uninstallation support, unless this new system is last in the installation). This could be enough for a quick and dirty tweak at the end. Same as before, but the external tool could impersonate as weidu, for compatibility. I'm not sure how much would be useful or necessary, but I'm thinking at least writing in the weidu.log, and writing the backup files in the same format, so weidu could uninstall the "foreign" mod without noticing it's not written in weidu. I'm guessing this might be pretty hard, as the foreign tool it might need to generate a tp2 for compatibility, or maybe weidu should receive some feature to detect what to do. Now, this is a lot, and I don't see it happening realistically (and few more steps would have to come after, but that's even beyond what I'm gonna bother writing). However, despite it, I've started to work on something, and I'm only at stage 1, but I'll soon reach the 2nd, and I expect to reach close to the 3rd at some point. It's unlikely that I'll go myself beyond that (which, as I said, I think it's not too different than the status quo, just in a different angle). But my use case is very niche. I only have immediate plans to support ITM, SPL, EFF (most of it it's done), and later on maybe CRE and STO. And I'm only worrying about a mod that comes probably the last in the install order to ease development, so that's why I'm in a position of attempting to do any of that madness. Not being able to be compatible with the existing ecosystem is super painful, and not a realistic proposition to the community, but if it's self inflicted pain, could be Ok. I don't know how much this answers the original question, but to summarize, I think the main deal is the general compatibility with (un)installation procedures. I've only glanced at what weidu does for backups, and it seemed reasonable to replicate in another software. But the whole workflow of weidu reinstalling B and C when A gets updated since too much work to fix, that I don't expect this happening, unless someone wants to contribute to weidu to make it aware of other tool.
  9. Not everyone uses PI. If I'm wishing for better LABEL support inside weidu, it's because it would be universal to everyone. If one wants to prioritize the experience of installing with PI only, then that's fine. But this is where my remark about caring less about (some) users comes from. You know why I said that. Moments after I wrote it, you submitted a PR to remove that bit from the text that weidu outputs to the console as help. Also, the option is not documented in the readme (which would not harm), and it's output mixes weidu's usual informational messages ("[weidu] WeiDU version 24900", etc), with the JSON output. It would help to be only the JSON, as it requires less parsing, and could be more efficient. If Fredrik considers it enough tested to remove the "experimental" note, so be it. I can't tell much more about the JSON output, as I've not used it enough. I just can say that sometimes I see a wrong tree of the mod components in Zeitgeist, but if no one has seen such thing in WIT or PI, then it's of course not a weidu issue, but a bug in Zeitgeist's display.
  10. This sounds good as well! I like a bit that you have to invest in items, buffs or points in hiding to pull this off, but an special ability to invoke from time to time is something that I've considered as well. Something that would resemble the "sneak attack" of the 3E mode (which I've not tried much beyond a test, not at all in a playthrough). I tried to set the APR to a lower value, to compensate if you are super hasted, and with speed weapons, etc. I think I've been able to make 2 backstabs in some corner cases out of stealth, so I gave up on setting APR, as it wasn't reliable, or I was failing at setting the right values for the effect. I've not considered balancing traps, as I rarely end up using them. But it's worth considering, indeed.
  11. Well, the idea is definitely not mine, but from semiticgoddess. Funnily enough, I delved into reverse engineering the game, and starting to learn Ghidra, and tons of other complex stuff, mostly spurred by Bubb's awesome work, but having the facestab as a goal, given that I thought it would be easy to do. Well, heck, no. But this little "cheat" with scripting is something I can understand and implement. I think a fancier mechanism would be necessary to allow 7th party members to have the same feature, or maybe some other corner case. I'll leave that to someone who knows more than me! But surely, what I can say is that facestabbing is quite liberating. It takes away a lot of the tedium, and it feels like a good trick to teach to an old dog.
  12. Yes, of course. I've asked to make it part of G3, so eventually it will be in a more "conventional" location, but for now, here is attached. I've not tried it much on Windows, so let me know if I broke something on the packaging. all-the-things-revised-0.1.1.zip
  13. Sorry for the wall of text, but I just feel like writing and sharing something today. I'll try to focus, though. A few years ago, my time spent playing the game plummeted: I started to make a mod called Glass Cannon to redesign some classes that fit (or should fit) this theme of being glass cannons, like the Monk, Swashbuckler, Kensai, etc. I discovered that the running joke about modders never playing the game because making the mod takes too much time turned out to be true after all, and you did not tell me! I want to publish this mod eventually, but it's not close enough to be in a releasable state. But some months ago I started a second mod called All Things Revised which should be just very small components to tweak this and that. I finished the first 4 components some weeks ago, and I started to play again to test them in BG1. After fixing a couple of bugs, I've been super happy with how well this 4 very small things synergize together. Two of them are directly related to backstabs, and the other two just happen to help. And yesterday this happened: This is such a good outcome that I did not even expect I would see in BG1. I wanted backstabs to be reliable, and this is as reliable as it can get. Maximum damage, and no failure despite rolling a 1 for the attack roll! But let me elaborate. This is what the components are and what they do: A party AI script. This is very humble, and it's just something suited to my needs by blending the existing AI scripts that come from the game and some patterns I've seen in other mods. The script is configured to make Alora and Kivan attempt to hide in shadows constantly. Doing this manually would be tedium, so without an AI script, one would attempt it only when planning ahead, so a few times only. Automating it multiplies your chances of having a random chance during the playthrough to give it a shot. Try this with some of the built-in scripts that come with the game. I micromanage a lot, but this is something I can delegate to automation as it has very low chance of downsides. Backstab from any angle, a.k.a. "facestab". The title says it all: forget about positioning, just hit while hidden, and it'll be an attempt to backstab. IIRC, you can't backstab unconscious enemies, but with this, you can, which makes even more sense. The implementation is a bit simple (as suggested by semiticgoddess, I just give the assassination effect via an script), but works well enough. Rogue's luck: improve attacks after invisibility. If you are familiar with the "luck" stat you'll know that it increases the chances of higher rolls, while negating the lower ones. It's not like a flat bonus, so the maximums are still the same. Both a bonus and an increase in luck make the average higher, but only luck reduces the variance. There is an effect that increases just "damage luck", and abilities like Kai or Offensive Spin work by giving +20 to it to ensure you deal the maximum with any weapon. This component on my mod just gives +2 luck at level 1, and increases by 1 every 3 levels. It also reduces the chance of a critical miss from 5% to 0%. That's why in the screenshot Alora made the hit, even with a roll of 1. So this means early game Imoen with a Short Sword and 2x multiplier will do 6 and 12 as minimum and maximum damage respectively (assuming no buffs), instead of 2 to 12. That's an awesome improvement to me, because rolling such a low number always feels such a waste of your time, effort (and risk of putting a squishy Thief on the front lines). So far this only affects pure Thieves, as I did not want hyper-broken multi/dual combinations doing even crazier backstabs. I wanted Thieves to at least feel useful and "special" in their own way. Note that this "damage luck" applies also if your Thief comes out of stealth to do a ranged attack, or if the backstab fails due to weapon or enemy immunity. It won't be a backstab, but it'll make sure your first attack of an encounter (if it hits), won't be a 1. This also increases (very, very moderately) the power of crossbows with respect to bows, given that they do 1d8 instead of 1d6, so they get more benefit of this lucky roll. That's a nice side effect. Worthwhile proficiency points. This makes that the 1st and 4th proficiency point feel a bit more valuable. The first point will give +1 to hit instead of nothing. That's it. This helps a bit in making early combat a bit less tedious, as there will be less failures. It also reduces the gap between classes that can get the 2nd point, and the ones that don't. And, for the title of the topic, backstabbing, makes it less likely to fail, of course. Every bonus counts. So that's basically it. For Alora's backstab in the image, she's using a non-magical ninjato, so just 1d8 damage. She's hitting an enemy using a bow, that gives +4 to hit and damage, which is multiplied by the 3x backstab. Her luck is huge, though. She has her amulet giving her +2. A bard is giving her +1, and the 3rd component mentioned above gives her +4 more. So basically the 36 damage is guaranteed, given the circumstances. A "less lucky" thief with 3x multiplier and the same weapon, but without the Bard and Alora's ring, would do 27 minimum damage (33.75 on average, though). I think that's fair for my goal of buffing a pure Thief, but surely more play testing is needed. Let me wrap up by saying thanks to all the modders, as in this playthrough I could not be enjoying this so much if it weren't because I've recruited Eldoth and Alora ahead of time (thanks to Tweaks Anthology), I've made Kivan a Stalker to try backstabbing with him (thanks to SCS's customization component), and I'm trying new Bard songs that increase luck *and* stealth stats thanks to IWDification. I'm enjoying other things as well, but that would be a longer detour. Cheers.
  14. You are also sending a clear message to users: you care less about them. Don't get me wrong. Your previous message made me consider making a small program that wraps weidu and can accept installing something by label name (I'd make it cross platform, open source, and hopefully easy to use, etc., so it can spread usage of LABEL for more people, not just me). But given that weidu.log only stores component numbers, not using designated component numbers at all, and given David's findings on the bad performance of LABEL, this all points to a promising future for the labels, maybe, but a pretty limited present. This needs work on weidu's side. Note also that the JSON output is marked as experimental, so it's another problem to spread its usage.
  15. I would go even further. I wish the labels could replace the component numbers entirely (e.g. by writing in the weidu.log file #{label-name} instead of #XYZ, or some other extension to the file format that would not break too much), but in the current situation, I'm just not interested in adding labels. If I could install components by name instead of number (by calling weidu --force install label-name instead of a number), that's something that I can easily test, and which is easy to me. As is right now, I can't test labels, and serve no use to me, so I'm sticking to DESIGNATED without labels for now.
×
×
  • Create New...