Jump to content

Magus

Modders
  • Posts

    312
  • Joined

Posts posted by Magus

  1. On 2/17/2020 at 2:49 AM, subtledoctor said:

    You said wrapping code in functions “breaks encapsulation.”

    No I didn't. You made that up, again. I won't bother to go over the whole of your post, as you didn't answer questions and didn't provide examples supporting your points.

    I think you argue in bad faith. You are welcome to prove me wrong with actual code examples, actual quotes and supporting evidence. I'm not afraid to admit being wrong if I am. Are you?

  2. 1 hour ago, subtledoctor said:

    Sigh.  Not really looking for a debate.

    Then you've come to a wrong place. This is an internet forum. People have been debating on these since before we were born and will continue after we're gone.

    1 hour ago, subtledoctor said:

    If CLEAR_EVERYTHING works for you, that's great.  Suggesting that there is only one way to skin this cat, or that your lazy simplistic simple way ( :p ) is somehow objectively better than another given way, seems ridiculous to me.

    I didn't suggest that there's only one way. However, if there are multiple ways, it's either they are all objectively equal, or some are better. In particular, in software engineering, it is general consensus, with which I agree, that simpler is better. If function way works for you, great.

    1 hour ago, subtledoctor said:

     And there were two fine answers which I guess bear repeating because you either didn't read them or didn't understand them or you found some other reason to ignore them:

    1) "At a more conceptual level, I'd like my encapsulation to be built in to the way the code is structured, not forced explicitly. One of the main points of FUNCTIONs is to deliver this; why not use it?"

    2) A disadvantage with CLEAR_EVERYTHING is that "you can't read in data in your ALWAYS that's to be used in any component."

    These answers had responses in the following posts, which I guess you didn't read or didn't understand or found some other reason to ignore. However, I'll detail:

    1) I literally explained in the post you've replied to.

    2) Is not true.

    1 hour ago, subtledoctor said:

    But, you're wrong.  Functions don't break the idea of encapsulation.  They were specifically proposed as a way to achieve it.  Moreover, the point of encapsulation is that things can't get out of your component sandboxes; it's mot mean to keep anything from getting in.

    I didn't say they did. You made that up.

    And no, you are wrong about the point of encapsulation. It is to make sure stuff works the way it's supposed to, even when used in whatever funny way. Applicably to weidu components, however, it's really just semantics. Things that get in have to get out of another component first.

    2 hours ago, subtledoctor said:

    So at the very outset, the first time you install anything in the mod, it generates an array of arcane spells and their associated scrolls (and also their schools).  Later, various components read from this array in order to correctly patch the spells and scrolls.  We feed that data into each component for use by the component; if we did CLEAR_EVERYTHING every time, we would have to dynamically generate that data every time.

    ...

    If you tell them "thou shalt put CLEAR_EVERYTHING in your ALWAYS block" and later they decide to implement something like what Tome & Blood does, it won't work for them and they might not understand why.  Dropping things into functions (again, adding a single line of text at the beginning of each component) precludes the possibility of that difficulty, for exceedingly low effort.

    I, too, don't understand why. If it's generated by any component launched first, I assume it's in the ALWAYS block. If it's there, it'll work. Please explain.

    2 hours ago, subtledoctor said:

    as I say, I haven't seen any valid arguments for why clearing the data and re-generating the array multiple times would be any better.

    Have you heard the phrase "the best code is no code at all"? Do you agree with it or not?

  3. 6 hours ago, subtledoctor said:

    Flexibility vs. what benefits? I haven’t seen any mentioned. Apart from not wanting to copy and paste “DEFINE_ACTION_FUNCTION” a handful of times?

    Simplicity and just working. Effortlessly.

    1. Look at this thread. 4 pages of discusion (also, I looked back and actually CLEAR_EVERYTHING was already proposed). Even people who are not novices getting confused and disagreeing. How do you want beginners to undestand this? Or would you prefer them to copy the code without understanding what it does and even why?
    2. You keep your flexibility. No one forces you to put it in the ALWAYS block. However, if you're worried about encapsulation at all, breaking it should be explicit, not the other way around.
      Like, if you configure a firewall, a good practice is to block everything by default, then open each needed port explicitly. If you open everything and then try to block each unneeded port one by one (yes, just copying a config line a handful of times), you will slip up at some point, because you're human.
      And the very reason to employ encapsulation is remove human error element (well, from that particular angle).

    Following the best practice policy should be effortless, and breaking it should take effort. That's the best practice for following best practices.

    So if I was asked for an advice, I would say "Just always CLEAR_EVERYTHING. But if for some reason you really need to pass variables between components, be aware that it breaks encapsulation. And if you're ok with that, then go LAF route."

  4. 10 hours ago, Gwendolyne said:

    In the past I had too many bad experiences with this code that I strongly don't recommend it. I remember wrong coded old mods that introduced space characters in string fields which screwed up any further STR_EQ or STR_CMP commands.

    A little off topic, but since the original issue is resolved, it's probably ok...

    In my opinion it's an absolutely wrong approach that is harmful in the long term. Bugs are to be fixed.

  5. I got a spell which holds the caster (project image style), and it's incompatible with PnP free action, because it adds immunities to hold, stun, etc. PI works normally, though, I presume because it's image project effect does that automatically.

    Any ideas what to do? It's got to be true hold/stun just setting speed to 0 isn't enough.

  6. On 7/10/2016 at 9:37 AM, qwerty1234567 said:

    Cool. I guess with hooks it can be embedded into commit messages themselves.

    Following up:

    $ cat .git/hooks/prepare-commit-msg
    #!/bin/sh
    
    base_msg="
    
    Binary changes listed below with iesh:
    "
    iesh_diff="$base_msg"
    
    for f in $(git diff --name-only --cached); do
      fname=$(basename -- "$f")
      ext="${fname##*.}"
      case $ext in
        bcs|chu|cre|itm|gam|pro|sav|spl|wmp|vvc)
          file_diff="$(git diff --cached "$f")"
          iesh_diff="$iesh_diff
    $file_diff"
        ;;
        *) true ;;
      esac
    done
    
    if [ "$iesh_diff" != "$base_msg" ]; then
      echo $(cat "$1") "$iesh_diff" > "$1"
    fi

    Example result.

  7. Sorry for chiming in so late, I don't know if it's still relevant, but anyway:

    1. I think that .iemod thing is good in general.
    2. I don't care about the extension specifically, it could've been zip as far as I'm concerned. I guess it's more convenient for Windows users to have a specialized extension, though.
    3. I agree that there's no reason to pack copies of weidu and other tools within .iemod. It's specifically desigined to be consumed by mod managers, and mod managers can take care of the tools themselves.

    4. I do not understand the fuss about including or not including weidu executable inside, as well as other files (tisunpack.exe, thumbs.db and whatever). I would rather think of this in terms of IFTT (if this than that). What are you going to do if "setup-mymod.exe is included", and why?
      - Not including it is not a problem, as far as I can see.
      - Including it is not also not a problem, as far as I can see. A mod manager doesn't have to use files that exist on filesystem.
      OR do you actually plan to abort mod installation because there are files you don't like inside? (Aren't you causing the problem you wanted to avoid in the first place??)
      @AL|EN has pointed out to me that some antiviruses throw a false positive on weidu. I say: this is a problem with these antiviruses. Not with weidu. If a user purchased an antivirus, and it throws a false positive, it's the antivirus' fault. It must be communicated clearly to the user, the company producing the antivirus, and all other involved parties. I shall not budge a single inch on this.

    5. All the talking and agreeing is nice, but I do not see the actual file format definition. Not as an editable forum post, but as something versionable, like an .md doc on github, at least? The reason I'm asking is that I might want/need to add automatic packaging to Golem.

  8. I've got a suggestion though it's not a new feature but an update to an existing one:

     

    Allow users to specify which stronghold is made available to which classes.

     

    The current version of this tweak (either all strongholds are free for all or only multi class characters get any love at all) is far too rudimentary for my taste.

    I want the bard, fighter and thief strongholds to be available to all classes, allow bards to keep the mage stronghold and fighter/clerics to do the paladin one. Someone else might want a totally different selection.

     

    I get that it might get a bit complex coding wise and would take a bit of time for users to go through (though it could be offered as a sub-component next to the two existing options) but I think it would a real improvement.

    You can just refuse the strongholds.

×
×
  • Create New...