Jump to content

Magus

Members
  • Content Count

    274
  • Joined

Posts 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.

    On 4/3/2021 at 2:05 AM, jastey said:

    I think it enabled those compliment/insult comments for BG1?


    They work in original BG1 and BGT too. Some mods extend them, though.

  3. 19 hours ago, Bartimaeus said:

    TnT...seems to be your mod? I see we've had a number of similar ideas, including Slayer form, True Sight, and Otiluke's. Does that Project Image tweak work for non-EE games? I would imagine not, but just making sure. I also feel like your statement about it accurately captures how I feel about many exploits: "To clarify, the purpose of this component is to give a normally working spell to the players who don't want to cheese in the first place. The purpose is not to close every possible PI exploit." Especially because I was about to ask you about your Otiluke's tweak and how you would prevent the Otiluked character from, say, casting Fireball at themselves over and over in the middle of a battle...but presumably you haven't done anything to prevent it and are simply trusting that the player won't do so since it's clearly a lame exploit.

    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. 9 hours ago, subtledoctor said:

    There’s something to be said for learning what’s going on under the hood...

    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 << 16))
    LPF ALTER_EFFECT
      INT_VAR
        match_opcode = OPCODE_hp_damage
        parameter2 = DAMAGETYPE_electricity

    This is what "for the love of God" refers to. It is not hyperbolic at all.

     

    Unrelated to the main issue:

    1. Of course, with time you tire of defining and looking at the constants over and over again. The exact numbers are not useful for the context. So you tuck them away into an include. And then you want to use the same include in another mod. So a library is born.
      I do not mean at all that you should use IElib specifically. By all means, build your own or use another one. Just remember, every time when a programmer uses a magic number, God kills a kitten. (Although I do think that combining efforts is more efficient.)
    2. 10 hours ago, subtledoctor said:

      I won't even get into the fact that, as a VSCode extension, I assume this is OS-dependent and thus useless to people with a Mac or Linux.

      - I'm not sure why do you assume that. As far as I can tell, on the contrary, VSCode is the cross-platform code editor.
      - The extension and the library are two separate things. They are integrated, but can be used independently.

    3. 10 hours ago, subtledoctor said:

      I don't know that it's that much easier to remember "DAMAGE_TYPE_lightning" versus "(4 << 16)." And what if you want a %-change in damage, instead of a set number? That variable does not address that.

      Whoops, I mean "DAMAGETYPE_lightning."

      Is it easier to remember 0x248 versus SCRIPT_OVERRIDE?
      Well, to each his own, of course. However, the goal is not having to remember, and focus on logic instead of offsets and bit fields:449426095_Capturadepantallade2021-02-0708-50-43.thumb.png.bfc5aaba79dca80bfa2313135d0ab880.png
       

  5. On 1/24/2021 at 8:29 PM, Greenhorn said:

    Component "Potion of Really Mirrored Eyes: v8.4"  from TNT mod cause CTD in my BG:TotSC vanilla game when used. From my humble experience CTD on one version of the game is usually indicative of problem encountered on all of them so maybe it wouldn't be bad idea to check and fix this ( for all versions ). 

    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.

    On 2/2/2021 at 4:04 AM, subtledoctor said:

    I really want to know how you managed to get Project Image to use the caster's memorized spells...

    In the best traditions of IE modding: with horrible hacks. Code is on github, so...

  6. 48 minutes ago, Taylan said:

    Say, creating a new item called "Hello World" (could be a copy of another item, like a gem or something) and dropping it in the inventory of the character upon starting a new game. Or creating a creature which appears aside you when you start the game, and says "Hello World" when you talk to it... You get the idea.

    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.

    And the most often given advice it to look at other mods to learn.

    48 minutes ago, Taylan said:

    I think it would be great if there was a little guide/tutorial like "making your first mod" which lists you the tools you'll need and walks you through the steps to create some basic "Hello World" kind of mod.

    Well, it's in your hands. Once you figured out a thing or two, feel free to create one.

  7. 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...

  8. 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.

  9. 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 playing the savegames I have. Preferably, with one button click.

    (Well, theoretically, since PI is windows-only and I don't have windows).

  10. "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.

  11. @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.

    1. There is no bug in my mod or your mod per se. They are perfectly good. It only manifests in a combination.
    2. Therefore, for the time being, those users that did see your advice have to choose between our mods.
    3. 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's the topic here.
    4. As for community - well, how come a global list doesn't get fixed by community, but mods do?

    @AL|EN and then we of course get the opposite situation when I finally update my mod (changing the order some more) and jastey disappears. The history repeats.

    Not that I have any intention of disappearing, or expect other people to. But I would like to have a better plan than just hope for the best.

    Anyway, if a global override feature I suggested in the conflict topic is confirmed as an eventual possibility, then I wholeheartedly agree that Dynamic is better.

  12. @jastey situation:

    1. Users complain about a bug in your mod.
    2. You spend time debugging, and track it down to my mod being installed after yours (because I've specified that in my ini file)
    3. For whatever techical reason, you can't resolve this on your side.
    4. 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.
    5. I'm unresponsive.

    Your actions? Day 1, day 7, 30, 365, etc.

     

  13. 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 listed.

     

    And it's not that I like the centralized way too much. Quite contrary, in fact. It's just that I didn't see an alternative way to deal with code rot.

    But coming to think of it, I do have one more idea: a central override list. Which would be used as a last resort option, when there are documented problems caused by prolonged lack of updates by missing modders. A manager could compare the timestamps of the last release vs update time of the override file, and use whichever is newer. Normally, the override repo would be completely empty (and hopefully it stays so). And even if an old override file gets forgotten, it wouldn't matter. This could be the best of both worlds. Finally, there's even no need to implement this until such an issue arises. If it ever does, then you could add this functionality - I think wouldn't be too hard? (This applies to both conflicts and Dynamic Order).

     

    2 hours ago, AL|EN said:

    I'm a fan of modern file format. I've consider using JSON/yaml, even offered support for it for metadata. There was no single question regarding those. This is reality which I have to accept.

    Well, you have one now. All those who think that ini is better than yml in this use case - raise hands!

    Is it still supported now? I'd convert to yml.

  14. I responded there. And irrespective of that, please consider using yml instead of ini, however this and that works out.

     

    3 hours ago, AL|EN said:

    Plus, the conflict definitions would have to be done via old, flawed BWS-DESIGNATED-way where one mod update would cause domino of errors and incorrect conflicts. I don't want to repeat this.

    Not at all. A centralized list doesn't mean scopes can't be used. If anything, it's even easier to introduce them.

  15. 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.

     

    On 8/19/2019 at 12:52 AM, jastey said:

    What I do not like (but I don't have a better solution, either): it looks like the component numbers need to be inserted by hand with the numbers they have internally upon installation. For some of my mods, I do not know the exact numbers (e.g. bg1re with a lot of optional components) of each component (without spening time to count them etc.)

    1) As it's been pointed out, in most cases component numbers are not necessary.

    2)

    On 1/15/2020 at 4:32 AM, jastey said:

    I can only talk for myself: as much as I am interested in help players to have correct install orders, I can only correctly list my own mods - and not in relation to all others since I do not know all other mods. I would like to pass on any install order requirements or restrictions for my mods that I know of, though.

    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)

    On 1/15/2020 at 2:27 PM, jastey said:

    Whether this information could be automated completely I am not sure, especially since what you described @Leeux sounded very much like what BWS was providing which was the reason people burnt out while maintaining it, at least if such mod install order informations would need to be updated when new mods come out - or maybe I'm missing something.

    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 well-maintained: the ones in GH organizations. More importantly, BWS list was mostly maintained by the people who were not the authors. In a centralized list of mods supported by PI, you would only be responsible for you own mods.

      4)

    On 1/16/2020 at 10:53 AM, jastey said:

    Yes and no. Putting it into the mod's ini is done on the by while updating the mod. Having to edit the list is two/three extra steps - and such needed modder collaborations never worked in the past... I am thinking long scale here: doing it once is no problem. Doing it every update because something changed, for example will eventually cease, and info in that list will become outdated. Plus: i know it sounds silly, but sometimes this happens because people forget about it after making changes to their mods. For example I wasn't aware of the BWPFixpack every time I made updates to my own mods, although I was very interested in incorporating its fixes.

    ...

    Definitely true, and that is why one list makes much sense, not only for players. But info might be outdated at some point, that is my fear, so we should check whether e.g. creation of such list from mod.ini info might be possible or even feasible thing. Probably not, as not every mod can list all others it should be installed after / before...

    What happens when your mods become outdated? Say, you're away for half a year, or busy, or wating for external updates (translations, etc). With order information available only in your mod, it's up to you to make the update (well, and maybe a few other people if you gave them access to the repo). With a centralized list, it's up to you and everyone else. The order in your personal ini in mod folder has more chance to become outdated.

     

    5) I think that having absolute order and/or a single list of files is hard to maintain and is indeed off-putting for modders to work on. A better option would be to allow each mod to have its own file, in which dynamic rules are defined.

    6) INI format itself is not great for structured data. I would rather prefer something like yml.

     7)

    2 hours ago, AL|EN said:

    Regarding 'online list for collaboration', I'm sure that you understand why the last thing that I think of. There was attempt to do it for install order and it didn't fly.

    I fully understand the reluctance. Still, I think that centralized option has a better chance of working.

    I don't fully understand what do you mean by "didn't fly", though. Was it ever live? Was the list actually used? I was not aware of it, nor did I have commit access.

     

    My suggestion (which, again, I know, a little late):

    Say, taking UA as an example

    # rules/ua.yml
    
    policy: bottom # optional, means that generally it should be installed as late as possible
    before:
      - stratagems
      - ir # item randomiser
    after:
      - bg2fixpack
      - rr
      - tactics
    conflict:
      - item_rev # just because

    In the whole list repo, I would be responsible for this one file. The manager would then evaluate the files and construct the correct order. Specific before/after rules would obviously override the policy, and mods sharing the same policy and having no specific rules regarding each other, can be sorted however, say, alphabetically.

    Now, if there was such a repo, and it was actually in use by a manager, and I had access to it, then I would commit such a file. Otherwise, why'd I bother? Even the new dynamic rules for install order that are in BGforge mods were submitted via pulls, I didn't write them myself. It would've been exactly the same in case of a central list.

     

    Lastly, I think the reason centralized dbs have somewhat bad rep is because it seems like a gargantuan task, and that's because people want to have the ultimate list from get-go. There's no need for that. Let the list build itself naturally. If it gets stale it would be because literally no one cares. Which means there's no problem to begin with.

    So, while late, I propose to reconsider this one more time, for both install order and conflicts.

  16. There's 3 options:

    1. A pre-defined set of scopes.
    2. 1 + custom scopes.
    3. 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 requires collaboration from both authors.

    And that brings us to the next issue, where the system fails hard: it takes two to tango. Until both mods are updated, the manager doesn't know about the conflict, and is displaying wrong data to the users. And one of the mods may never be updated. What are you going to do? Exclude the mod from the manager altogether? That's a bit heavy handed. Allow one-sided conflict rules based on LABELs or DESIGNATED or whatever? But what if such a rule was added, and then the author went AWOL, but the conflict was resolved by the other mod's update?

    You can easily reverse this, too: A/B/C all conflict and marked as such, B and C resolve their conflict, A is stale, now you're displaying a non-existent conflict.

    Some more puzzles:

    1. Take the 3-mod edge case and make it 4. Now instead of 3 relationships you got 6.
    2. Mod A is compatible with both B and C. But it's not compatible with their combination.

     

    To summarize:

    1. I agree that the scope system could be useful some cases.
    2. However, there's no way it'll cover every possible confict without becoming unmanageable.
    3. For a complex enough mod, it's cost prohibitive to mark it up in its entirety from the beginning. So the updates will be incremental.
    4. Still, warning about some conflicts is better than nothing.
    5. But over the years, discrepancies will pile up. Unfortunately, the only possible solution I see for the stale code is a centralized database.

    And I know, of course, that centralized dbs didn't do great so far. However, consider this:

    • Scope system: it takes two certain people to mark a conflict: authors of mods A and B.
    • Centralized system: it takes literally anyone to submit a pull, and anyone else with access to the list (which should include the said authors) to accept it.

    The second has a better chance of happening, simply because there's many more people who can make it happen.

     

    Well, I don't know the answer to all this madness. But it seems to me that a combination of scoping with a central db for finer control could possibly work.

×
×
  • Create New...