Jump to content

CrevsDaak

Modders
  • Posts

    236
  • 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,448 profile views

CrevsDaak's Achievements

  1. I was thinking that they'd sort of escort you to the stronghold of sorts and then send you off into the Maze, but that could work too. I think the dead bodies in the Maze and maybe a few surviving, traumatized and injured soldiers (how we make them suffer, just for the tiniest bit of realism...) that could warn you about 25 years old traps and how their expedition failed could work pretty well, too. While I do prefer the idea of adding more areas, it's really tough, so this might be a better way to do it. Yeah, I know, I just wanted to make it so there's something more interesting to it than just skipping it, which I don't have anything against even, it's just the ever-burning desire of adding mooore and more content. Which obviously, of course, in practice I don't do (yet). AFAIK ActionOverride() is action number 1 (it starts from zero which I think is NoAction()), so it should be in every game. Though moving items between containers/changing area scripts and a few other actions aren't even on ToBEx. Yeah, if that was to be done in any way it'd have to be in the BGT WeiDU style of having SoD installed somewhere somewhat sane being a requirement and just unpacking and converting what you need from SoD at install time. Would most likely need to have the DLC merger installed and whatnot but I have no clue about that stuff. I hope if it's just one area its fair game though, extracting from SoD vs. BG1 doesn't sound nowhere as streamlined when it comes to the tileset conversions, and it'd be a bit too much for one or two areas (personally I would be OK with it, but I'm not sure if the majority of players would want to deal with it). Sure, BGT has its own subset of issues either way and developing a first version for multiple platforms is awful for progress.
  2. Sounds like a good idea to me, I've had an idea very similar to this, but had no clue where I would put the entrance where it concerns existing areas, and don't currently have the skills to produce new areas. My plan was to: Move the Maze entrance somewhere else, preferably forcing the player to look for it and allow for the Eltan et al quests to be completed. Remove the need to trace back trough the Maze in BGT by adding a small passage-way dungeon that becomes accessible after Sarevok dies (feels really anti-climatic to me, just to walk back through the Maze again). Add an area south of the Cloudpeaks so that you can travel back and forth to Amn through it (or a couple of areas, forcing you to actually cross them, and have going there trigger the Mae'Var ambush that's currently just a cutscene after you talk to Belt). While it's practically what EBG1 does, my idea was to bring similar behavior to BGT, and add a couple of areas and touches to the BG1 finale while at it. While your mod is aimed at the EEs and integrating SoD I think plenty of what can be done in BG1 is fully applicable to both games. Then the Undercity exit would be a short dungeon with some low level undead so it isn't just a walkaway out, and you'd exit outside of the City walls, which I was also planning on making an area for. As for where to place the Maze entrance, the best idea I came up with was to make an entirely new guarded compound composed of secret tunnels, which you would have to access through the Iron Throne after killing Cythandria (a door in the basement would get added, and something to hint at it being there), and then that would eventually lead you to the Maze itself, or you can enter said tunnels through the basement of a random house with very powerful guards. And just to keep a part of the vanilla feeling, the Thieves would get their own set of hidden tunnels, that aren't so secret and connect to the Sewers and a few other areas (I didn't think this one through). The idea of putting it on the Northern gate is pretty good though, I've only recently found out that zone is walkable even rofl. And you wouldn't have to walk too far from the Palace itself (my quest would send the player on a Marco Polo styled journey through the whole city basically, which is pretty similar to your idea about going in with the FF into Korlasz' dungeon. Storming the new underground complex with the help of the Flaming Fist, for which the area would have to be on the larger side then, and there aren't that many above-ground huge spaces in the city, though coming up with new below-ground ones is fairly trivial to justify—it must've taken them a LOT of digging to find the Undercity itself, at least that's how I think of this, so it'd make sense that in uncovering it they left a lot of tunnels/big empty spaces dug out. Also explains why they are on the Mining business). The issue? So far that's like five or six areas, and I have graphics for none. I plan on learning out Blender for real on my next break from uni but atm I'm absolutely swamped in homework (so progress on the tools for this + other projects is really slow and all non-pure-code mods are just on halt for a couple of months). Making areas out of existing graphics in Photoshop takes too much time sadly, but given the variety of areas to work with and that the aim is integrating the new areas into BG1's finale, it could work. And if you take them from SoD or just add new entrances it'd require no such work.
  3. I always thought of Balors' attacks as having a chance to decapitate due to their claws, however I might just not know how it's supposed to be. The Cornugons with clubs look very cool btw, I wish you luck on your overlay editing endeavour, I'm not sure if there's really anything you can do but brute force it through sheer time spent tinkering with it. I always wonder what Erephine did to realign some of the old BG1 shield animations or how the new ones were created but I honestly have no idea.
  4. No problem, glad I could help. It's quite interesting to look into such complex and specialized WeiDU code.
  5. Could most likely add other spells so that they're also patched in this way (though I can't think of any others that need this treatment), but I think the majority already act this way rather than making creatures hostile. Also, strangely enough this behaviour on Grease is only like this on my modded (though this is how the spell is in vanilla) BG2EE install, but non-hostile on every other similarly modded game. Either way I don't think this is relevant enough to warrant a component of its own and the code is simple enough that it really shows how trivial this is, but it already exists, here it is. BEGIN "Remove hostile effect from Grease" REQUIRE_PREDICATE FILE_EXISTS_IN_GAME spwi101.spl "Your game does not contain the Grease spell" COPY_EXISTING spwi101.spl override PATCH_IF (BYTE_AT (0x19) BAND BIT2) == BIT2 BEGIN WRITE_BYTE 0x19 (THIS BXOR BIT2) PATCH_IF enhanced_edition BEGIN WRITE_BYTE 0x19 (THIS BOR BIT1) END END BUT_ONLY
  6. 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.
  7. 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.
  8. 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).
  9. 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).
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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
  15. 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.
×
×
  • Create New...