Jump to content

Magus

Members
  • Content Count

    265
  • Joined

About Magus

  • Rank
    Magus_BGforge

Recent Profile Visitors

4,078 profile views
  1. 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.
  2. 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...
  3. 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?
  4. 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.
  5. 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
  6. "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.
  7. Re: stuttering, I just use Pack Mule mod and don't take the holding bags anymore.
  8. @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
  9. @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.
  10. 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
  11. 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.
  12. 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.
  13. 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
  14. I'm 99% sure it is, as it's already on the creature.
  15. 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
×
×
  • Create New...