Jump to content


  • Content Count

  • Joined

Everything posted by Magus

  1. They are triggered by the engine, I believe. Just like BG1-style interactions. You can press the hotkey to advance game time (don't remember which one it is) and see them happen. I'm not sure how the system chooses between what to trigger, banter vs interaction. Maybe interactions start flowing after all banters are exhausted between the interacting characters. Maybe it's random.
  2. Imoen was originally intended to die in Spellhold. Interact.2da is not for banters, it's for BG1-style in-game interactions. Take a look here. They work in original BG1 and BGT too. Some mods extend them, though.
  3. It is mine, and it works on Classic (in fact, I only use Classic for testing). I didn't do anything about Otiluke + Fireball, because I didn't think of it. Not sure if something can be done, and doesn't worry me much, too. Although, if a way is found, and it's not too convoluted - everything is possible. Github issues are open for suggestions.
  4. In general, this is certainly a good idea. (Although I personally haven't encountered any issue with this just yet.)
  5. No stealing is in RR and TnT. Mislead and PI are also tackled in TnT. (Although not 100% bulletproof and not heavily tested.) No recharging is easy to do. Might be coming in UA. As for Protection for Undead, a better option would be to make it PnP.
  6. Point taken. However, learning is one thing, and production usage is another. The issue is that magic numbers are in some top 10 of bad programming practices, and generally should be avoided. The reasons why are explained numerous times by experienced programmers, easily googled with "why magic numbers are bad", or "code smell magic numbers". And yes, you can add comments to clarify the mumbo-jumbo. But they do not work as well as defined constants. For example, the code can be changed to OPCODE_hp_damage = 12 DAMAGETYPE_electricity = 262144 // (0 + (1 << 4)) (0 + (1
  7. For the love of god LPF ALTER_EFFECT INT_VAR match_opcode = OPCODE_hp_damage parameter2 = DAMAGETYPE_electricity END https://ielib.bgforge.net
  8. I'm actually suprised it even installs on it. I didn't test on classic ToSC. Submit an issue on github, with steps to reproduce. In the best traditions of IE modding: with horrible hacks. Code is on github, so...
  9. You can do this with NearInfinity, DLTCEP or Weidu. If you want a quick, one-off in-game change, NI/DLTCEP will do fine (edit the file, drop into override dir). Weidu is the heavy machinery for creating mods that you actually want to distribute to other people. (But you still use NI/DLTCEP a lot while creating a mod, even it's weidu-packaged). Scripting languages themselves are simple and shouldn't pose a problem for an exprienced developer to get the hang of. Mostly the challenge lies in learning how Infinity Engine works, how the things are connected, and various tricks and quirks.
  10. Cool, I did something similar with Otiluke, only handled it a bit differently. One tweak that I never find time to implement but still badly want is to be able to cut through Cromwell's chatter and just get straight to the point, selecting the item to be created directly or through some menu. His rummaging through inventory is mildly annoying in the original, but once you get some item upgrade mods, it's a never-ending click fest...
  11. So, this is since weidu 247, right? And the old way still works? And why does the function not handle the "temporary work directory" itself? Is there any reason why'd you want to not have it?
  12. Huh, I don't see what's even talk about then. The MVP is to just implement downloading the new iemod packages and that's it. It'll ensure that the update is atomic and all users receive the same files without any confusion. Then you could set up some topic with voting on desired features and see the users really do need the extra features, and which ones (deltas, pre-release, etc). Me personally, I don't care much about extra 200Mbs. And large mods aren't released that often, anyway.
  13. It would be delta if you only downloaded the diffs (not repo or tag or release source) and then apply the diff to the local. But I think it's too much to take on. What you describe is, I don't know, git update, or incremental update? Well, it doesn't matter much, just the question of terminolgy. The second part is quite simple - somewhere midgame I happily update some mods and suddenly hell breaks loose - some of them fail to install. Or install and cause crashes. Or screw up tkl refs. Or else. I want to be sure that at any point I can revert to the original state and continue playin
  14. "Delta" usually refers to bin files, I think the name is misleading. Anyway, I don't feel enthusiastic about this. I think that any bugs coming up in a existing installation are better handled by CLUAConsole. There's just too much that can go wrong with a mid-game update. But if you do actually implement this in one form or another, the first must have features are backup and rollback.
  15. Re: stuttering, I just use Pack Mule mod and don't take the holding bags anymore.
  16. @jastey OK, but do you think that most users will see your advice before installing? Because the usuall workflow as I see it: fire up PI, install whatever seems good, get bugs, come complaining. There is no bug in my mod or your mod per se. They are perfectly good. It only manifests in a combination. Therefore, for the time being, those users that did see your advice have to choose between our mods. If there's another reason mods can't be installed together, it's a conflict, and that's discussed in the other topic. This example is specifically about install order because that
  17. @jastey situation: Users complain about a bug in your mod. You spend time debugging, and track it down to my mod being installed after yours (because I've specified that in my ini file) For whatever techical reason, you can't resolve this on your side. You go to github, open an issue, let's say even dig into my code and see that actually I made a typo and meant to install my mod before yours. You even submit a pull request with correction. I'm unresponsive. Your actions? Day 1, day 7, 30, 365, etc.
  18. You're right, individual components conflicts with their numbers will certainly fail to be maintained in a centralized fashion. It's possible to have a centralized list for global conflicts, while keeping the local ones in metadata, but that's likely to get even more confusing. It could be possible to automate stuff with github actions, parsing and maybe even committing the updates into global list, but duplicating data is never a good idea and will also incure extra burden on the modders. So, I agree that the distributed way is more likely to succeed, even with the issues I li
  19. I'm saying that 1) The efforts that were before and the effort discussed here are not equivalent. 2) If you believe that a new centralized list will fail, then Dynamic Order (as it's implemented right now) will eventually fail even harder.
  20. I responded there. And irrespective of that, please consider using yml instead of ini, however this and that works out. Not at all. A centralized list doesn't mean scopes can't be used. If anything, it's even easier to introduce them.
  21. Following the mention in Mod Conflicts, I'd like to make some points. Might be too late, considering that Dynamic Order has already began rolling out, but anyway. 1) As it's been pointed out, in most cases component numbers are not necessary. 2) No one knows all the mods. You are not required to do more. The relationships to mods by other authors can be defined as they become known. 3) It can be automated. 3b) BWS took on much larger task - encompassing all exising mods. AFAIK PI only takes relatively small amount for now, which are relatively we
  22. I'm 99% sure it is, as it's already on the creature.
  23. There's 3 options: A pre-defined set of scopes. 1 + custom scopes. A set of rules for scope naming. I believe the only one that will possibly be useful is 1). The other two will likely lead to a number of scopes greater than the number of actual conflicts, and increase maintenance burden rather than reducing it. On the other hand, I'd like to retract my previous point to some degree. It not necessary to markup the whole mod in one go. In fact, probably not possible except for the simplest mods. Conflicts can be added as they are discovered. However, that requi
  24. Depeding on the flow, you don't necessarily need to rebase. Most of the time, just git pull upstream master will work (pull = fetch+merge).
  25. There will be no problems if you look up the offsets correctly.
  • Create New...