Jump to content

CrevsDaak

Modders
  • Posts

    231
  • Joined

  • Last visited

About CrevsDaak

  • Birthday 04/14/1999

Profile Information

  • Gender
    Male
  • Location
    Bs. As., Argentina
  • Mods Worked On
    www.urstuff2athkatla.com

Contact Methods

  • Discord
    crevsdaak
  • Website URL
    https://github.com/CrevsDaak

Recent Profile Visitors

5,430 profile views

CrevsDaak's Achievements

  1. Yeah I don't think its feasible at all then, unless you unlock several of them all at once. On the topic of issues with the mod: the Cleric HLA Divine Shell doesn't give the 80% slashing resistance it should (it does confer the proper resistances to everything else though, including the other physical damage types). This is on beta 7, but I don't think it had been reported before. Edit: the Paladin Holy Aura HLA has the wrong projectile set: it uses 1pp_sleep_cloud - 280 instead of something sane and reasonable like In Area Party Only - 158. Affected file is tg#hol1.spl.
  2. It's definitely technically possible, you'd just have to define tables that include any non-ordered combination of the poison skills and hope opcode 214 works when applied via opcode 326. So if there's 4 different types of Poison and one is the base type, you'd need 4! / 3 tables (so just 8 in this case). Then you check against a certain spell state and operate bitwise on it (so unlocking the different Poison types is just adding a certain value to it), and since you only care about 8 states so it's quite doable. 5! / 4 is 30 in any case so at that point just forget about it, though I don't know how many types of Poison there are.
  3. You can greatly reduce your input to achieve this by doing something like weinstall mymod --no-exit-pause --force-install-list X Y Z and also possible to call the game from the same command as well (or just press F5 on NI and then waste time navigating to what file you want to look at). So it hardly takes much effort at all once you have the right setup. I normally print the relevant parts of the files I'm modifying from WeiDU itself into the console and just look at that. For more complex stuff like effect ordering and such nonsense you're pretty much forced to look at it from NI and test it in-game (particularly for effect reapplication order and some other utter nonsense), but it's not worth doing after every little change. Once you're used to how this works it's not troublesome at all, and takes considerably less than for clang to compile my shit. You can, it's a full blown programming language, and I've done binary patching with it for stuff that was completely unrelated to IE modding more than once. The real issue is, it has too many features you don't need for anything else but IE modding, and dealing with things that are convenient for modding but incovenient for regular programming make it hard to justify using it. It indeed is a niche language and finding uses for it is hard, but it can do a multitude of things that are harder to perform in other languages (byte-editing regexp-matched strings comes to mind, though a good number of non-compiled languages are quite good at this as well, however off the top of my head I wouldn't know how to do it in them while I could put the WeiDU code for that down in less than ten seconds with REPLACE_EVALUATE. I would argue that it's also due to me not using those languages as much, so this isn't as important as I make it sound). That's just because someone went a wrote libraries for those languages. Imagine trying to use C without stdlib. I've done that plenty back when I was learning how to code in C (and WeiDU!) about a decade ago, and I can say, it's pretty a painful experience. WeiDU without using any libraries aside from what is shipped with it is comparable to C++ without any of its standard libraries aside from the C ones. Sadly the case for WeiDU is that you either put on the wizard hat and code out the library yourself or put on some apprentice robes and try to figure out how other people's code works, as there is no real standard library for it out there. The difference between how modders handle code ownership and how that works with GPL'd code in other programming languages also has a pretty big impact, though given that all the people that have written stuff worth using will let you use it if you just ask nicely it isn't much of a problem as long as you're willing to ask them (and learn how to use their code).
  4. You'll have to download the WeiDU binary from https://github.com/WeiDUorg/weidu/releases/latest and rename weidu.exe into setup-modname.exe, for 32-bit systems you'll need the Windows x86 one, might also want to use the legacy one (that one works everywhere and there's virtually no difference at all).
  5. In part the lack of dedicated tutorials to niche aspects of it and documentation aimed at doing complex things, while also explaining them in a detailed manner, is a bit of an issue, I've already thought of pairing it with rather unknown things the game engine has to offer and comitting myself to writing explanations of sorts about it. Your arguments are reasonable, and consider that I don't oppose to anybody writing IE libraries to deal with the game's files, if anything I'm more interested in what could one day be done with something like that, the issue is very much writing something like that myself, as WeiDU works well for what my needs are (not without making me lose some hair every now and then, but it's been a kinder experience after moving away from ADD_KIT). And as far as running utility tools during installation goes, it can go very far, a very powerful aspect is being able to call it with the file data itself during the patch operation, and then deleting the whole buffer and writing the whole new file. This lets you basically do it natively in WeiDU except you modify the file with an external tool.
  6. Does that language already exist though? You rely on a pre-defined library of the IE formats which is something that's not fun at all to write. Meanwhile, editing spells with WeiDU doesn't require me to write any code except what actually impacts the spells themselves. That's why I called a new language more convoluted, the amount of work it requires to match current WeiDU capabilities, rather than it not being easier to use (as it WILL be easier to use by means of further abstraction). I might sound too critical of the idea but I would have no reason not to use such a tool either, and if I thought it necessary I'd work on something like it, but dealing with WeiDU directly is just more efficient. As far as the more complex IE binary formats go, external tools would be much more useful than WeiDU, which is why I don't see it a worthwhile effort to make modification of spells and other simple formats easier when WED files or other aspects of area creation are still as much of a nightmare to deal with.
  7. It definitely does not cover every case, but you can easily write code to cover the odd cases (particularly on something as trivial as patching effects on a spell that's as neat and well formed as this one). Because there's C libraries with bugs it doesn't mean every C library out there is bugged, and the same applies to limited functionality on WeiDU functions, since the language does lack a null value and suffers from that. COPY_EXISTING spcl822.spl override GET_OFFSET_ARRAY ab_array SPL_V10_HEADERS PHP_EACH ab_array AS int => ab_off BEGIN GET_OFFSET_ARRAY2 fx_array ab_off SPL_V10_HEAD_EFFECTS PHP_EACH fx_array AS int => fx_off BEGIN PATCH_IF (LONG_AT fx_off) == 0 BEGIN READ_LONG (fx_off + 0x8) param1 WRITE_LONG (fx_off + 0x8) (param1 - value) END END END BUT_ONLY Doesn't take long at all to write, doing this from another language will always be more convoluted than learning how to do it in it. You could even check the levels on each header and apply the modification to the effect non-linearly.
  8. I don't think it's hard to code in WeiDU, even if it has its oddities and all, the language is pretty powerful too and there's a lot of existing code that can be read in order to learn. Also any language that would allow for modification of the game's files would evolve into a similar level of complexity, or else it would fail to replicate existing capabilities which would be unacceptable. Very few things warrant for external, non-WeiDU programs to be used (tileset conversions, audio decoding, creation of huge scripts), and even less mods require the biggest benefit of external programs which is how much faster they do things. WeiDU is also specifically designed to deal with binary files which many other systems do not do as well, WeiDU handles binary files better than every single other language I've ever attempted to put up to the task. The actual headache that it is to deal with such things from C and such, WeiDU is the pinnacle of imperative programming aimed at binary formats: it does exactly what you want it to do, exactly at the offset you want it to. No need to deal with buffers, endianess, seeking on a file, mismatched integer types, etc. Sure you can write a library in C, but that doesn't detach you from the compatibility problems inherent to it, nor different platforms make WRITE_BYTE behave any different. As for modifying binary files using text commands rather than editing the binary data as such, there's DavidW's SFO 2e which while it's rather hard to guess how to do some things with, offers insanely valuable functionality on most of the game's file formats and lets you perform very complex changes with relative ease. You can also just do this on WeiDU and create code that won't be present in the final version of your mod. I despise interacting with binary files and have been doing this for my mods for quite some time. Being able to use WeiDU's existing codebase and functions is a huge advantage as compared to having to reinvent the wheel to modify an item or two (or the existing alternative of clicking buttons around for several hours). Having code to create the binary files and then some other code to handle install-time tasks seems like the best idea to me, I should probably make it package the entire mod on its own as well, so it just creates new releases without me ever having to touch the release version files.
  9. Right, amalgamate_class_checks is what's causing the area script bugs, but the Druid issue is solely contained on dialogue, and only occurs in dialogue files because only those are being patched this way. Even if druid_multiclass.tpa calls amalgamate_class_checks again right before it rolls its own patches, an install mark for amalgamate_class_checks.tpa is set and checked, so the issue lies in the disjunctive_substitution call on dialogue files in druid_multiclass.tpa. Now, there's might be a bug somewhere in disjunctive_substitution, since the final scsain.00003.d (druids_multiclass.tpa acts upon scsain.00002.d, and then scsain.00000.d is the vanilla BG2EE file. scsain.00001.d isn't relevant for this issue, I've only included it for the sake of completeness) doesn't have the !Class(Player1,CLERIC_ALL) check, only the CheckSpellState(Player1,DW_DRUID) check. Meanwhile a toy version of version of it does not have this issue and both triggers are correctly present. I'll try fully reimplementing the disjunctive_substitution functionality tomorrow, since the code I selectively copy-pasted doesn't handle OR() yet, which leads us to the next issue which is that: If this was working correctly, it would present a logical error: we want either all non-clerics, or any fake Druids. Both at the same time present an impossible requirement. So it's necessary to put these triggers inside an OR() block. I'm going to test if that fixes it tomorrow, I don't want to mess with a new install right now (it's rather far past midnight which does not sit well for modding things this complex). Seems like my guess of !! evaluating to self-negating was correct, though rather than WeiDU doing so it is instead properly addressed in your code, both technically and in regards to its philosophical implications. Will look into the issue of the area scripts once this is solved, since that one looks to be considerably easier. SCSAIN.00000.d SCSAIN.00001.d SCSAIN.00002.d SCSAIN.00003.d
  10. I can figure it out if you want, I need to implement this on my ToB mod either way and I'm going to be working on it as it's one of the few things I have left to do. Though those two response states from scsain.dlg currently only check if the player is a Druid (via the spell state), on the unmodded script they just perform a !Class(Player1,CLERIC_ALL) check which needs to be placed along a CheckSpellState(Player1,DW_DRUID) inside an OR(), since otherwise *only* Druids can use those options to accept the quest, when it actually has to be offered to all classes. This is actually a very impressive bug, because it's caused by Class(Player1,CLERIC_ALL) being replaced by !CheckSpellState(\1,DW_DRUID) on a check patched in by druid_multiclass.tpa, which means WeiDU evaluates !! as self-negating when compiling dialogue.
  11. Okay, as a hotfix, you can download and the attached spell and place it on your override folder, it will permanently give you one extra spellslot for levels 1-9, and can be applied to any character (just once) with the following console command: C:Eval("ApplySpellRES(\"c7exspl\",Myself)") Will work as long as you have the character selected and the cursor over them (maybe both aren't necessary, I don't know what seals the deal). Don't use on single-Class specialists, those are already getting their appropiate bonus to spells. c7exspl.spl
  12. The delicate balance between playing too much and modding too much is hard to achieve, but it is definitely doable. Can't say I achieve True balance very often though. The Bigg's tweaks did something similar with letting you facestab, either always or when under Non-Detection, though your idea of making backstabs reliable by applying luck to force maximum damage is very good, definitely makes stabbing earlier on a lot more powerful, which is a fantastic change, since in most cases it's something that I don't even consider worth spending time on till much later on.
  13. As for the other minor bug, I don't know what causes it, but it is pretty simple: when kicked out of the party and recruited again, Aerie gets the MAGE_UNUSABLE specific assigned to her. Sadly Aerie knows way too many spells for Ctrl+M to reveal her SPECIFIC field in-game, but a quick look to my save on NI reveals that she gets it changed every time I kick her and make her rejoin. This is very easily hotfixed by setting back her Specific field to 0 on NI. Oddly enough, it only seems to block her from using Shields, she can still user her helmet just fine.
  14. So, this is a pretty hefty issue caused by amalgamate_class_checks.tpa I believe (I was looking at it to see what I would have to change to let the player go around as Druid/Mage on BG2:ToB, and it made me realise that it was the culprit for these issues), but since I also have Multiple Strongholds (but class specific, and I am playing a Paladin, however I still got the reward from the Sir Sarles quest as if I was a Cleric) from Tweaks Anthology installed, so there might be compatibility issues. So far, the actual issues are: Oisig does not teleport back to the Temple of Helm after he talks to you about the Unseeing Eye. This breaks the Sir Sarles quest completion. Console hotfix below. The other high-priests do not show up inside their own temples either, possibly breaking the turn in for that same quest as well. These two bugs are caused by the patches to their specific area scripts. The player class checks for accepting the Ring of Lathander quest on two dialogue options that are supposed to be the fallback ones, they currently check if the player is a Druid via spell states. I don't think amalgamate_class_checks.tpa causes this one, nor I know what causes it at all. Can be hotfixed by removing the Druid check from responses triggers 13 and 14 (those should not be there at all). This bug is caused by the multi-class Druids component, those checks should not be getting modified at all since they're fallback choices. Non-Cleric classes receive rewards and follow-up quests as if they were Clerics, even if not elegible for the Stronghold (might be intended). This is again, caused by amalgamate_class_checks.tpa, which seems to be run under the "Revised specialty priests" (40650) component, going off weidu --change-log on the area scripts and affected dialogue files. If you want to take a look at them I can upload any amount of the relevant dialogue files, however, these bugs can easily be fully reproduced by just installing the above mentioned component. Mods affecting SCSAIN.DLG: 00000: /* created or unbiffed */ ~DW_TALENTS/DW_TALENTS.TP2~ 0 40650 // Revised speciality priests of Lathander/Helm/Talos/Tempus/TyrBeta 7 00001: ~DW_TALENTS/DW_TALENTS.TP2~ 0 50400 // New choices of god / goddess for speciality priestsBeta 7 00002: ~DW_TALENTS/DW_TALENTS.TP2~ 0 55000 // Allow druids to multiclass as mages, rangers, and thievesBeta 7 Mods affecting AR0901.BCS: 00000: /* created or unbiffed */ ~DW_TALENTS/DW_TALENTS.TP2~ 0 40650 // Revised speciality priests of Lathander/Helm/Talos/Tempus/TyrBeta 7 00001: ~DW_TALENTS/DW_TALENTS.TP2~ 0 50500 // New class: Favored SoulBeta 7 00002: ~STRATAGEMS/SETUP-STRATAGEMS.TP2~ 0 4150 // Allow the Cowled Wizards to detect spellcasting in most indoor, above-ground areas in Athkatla35.10 As for the Sir Sarles quest turn in, the following console command can be used, from AR0900 (Temple District): C:Eval("ActionOverride(\"Oisig\",MoveBetweenAreas(\"AR0901\",[700.560],2))") And for Alvanna (places her in some basically random location, I don't know well where she's actually suppossed to be in, also needs to be used in AR0900): C:Eval("ActionOverride(\"acolyte2\",MoveBetweenAreas(\"AR0902\",[964.620],2))") Should be similar for the Talassan priest but I've not delved into that so I don't know his creature filename nor where they should stand. WeiDU.log
  15. Would the player be able to frame Kangaxx for property damage with this mod?
×
×
  • Create New...