Jump to content

devSin

Modders
  • Content Count

    2,951
  • Joined

  • Last visited

Everything posted by devSin

  1. IIRC, the description is awkward because the poison effect is bugged (none of the persistent effects were working quite right in vanilla). DLTCEP may be the way it was supposed to work, and IESDP the way it actually worked. But it's been a long time, so I could be mistaken.
  2. devSin

    custom region/trigger issue

    IsOverMe() isn't an event trigger like Entered() and some of the others (Opened(), etc.). Those only respond when the appropriate event fires, and for ground triggers, that means springing the trap (so it has to be marked as trapped if you use Entered()). IsOverMe() just polls the area every frame (or whatever the evaluation period is) and checks for the specified object being in the right spot. It will work from any trigger region, marked as a trap or not.
  3. devSin

    Items with bonuses vs. X bugs

    Target should be irrelevant (it's inherited from the "Use EFF file" effect rather than read from the EFF resource). That's why the EFF files sometimes look wonky (they're just unused values, so they come from whatever other resource the designer copied it from and didn't bother to change).
  4. devSin

    More stuff for v10

    Ah, so that's what it was. I knew I did something, but I couldn't remember what it was. Thanks for checking. :-)
  5. devSin

    More stuff for v10

    Two things I've been meaning to say about this: BioWare actually fixed these icons in TotSC, so there are "official" versions of them in the TotSC override (they just never made their way back upstream, so BG2 still has the fugly ones). Additionally, the engine does something with scroll icons (does it composite them with the generic scroll background? I can't remember). If you look at my TP2, you should see a way to fix this just by editing the icon reference in those items (I think; I don't remember what I did), giving you get a perfect scroll icon. This would cut down on the number of files we need to ship.
  6. devSin

    ITM/EFF file format

    They're there (school and secondaryType). Taimon was the first to reverse these fields IIRC.
  7. devSin

    [IWD1:TotLM] - Alignment() trigger issues

    Yeah, known. BIS went their own route with the *Ex() triggers (you'd almost always just use ClassEx() in an IWD game), and they never bothered using the symbols for alignment (it should work if you use the numeric values, like they often did).
  8. We make changes according to the usage in BG2. BGT can modify the resource if there's a difference in how something works in BG content and in BG2. We're also not going to change the resources used by a ton of scripts and spells in the game just to set the XP awards. We have to worry about mods that then make changes to those scripts and spells and expect that they work the way they always have. That said, I wouldn't be opposed to simply dropping the enemy-only summons from the list. I'm not worried if somebody wants to farm a few extra thousand XP from these encounters.
  9. I'm not a huge fan of that. Then we have to explain "For ToBEx only" and then have people going to figure out what ToBEx is, and then we're on the hook for it if they decide to install it. A standalone pack for ToBEx users seems to be more appropriate. Let's keep the fixpack for working with the engine as BioWare provided. (And who knows what's going to happen with EE.) That would be my inclination, at least.
  10. I don't have a problem if you want to change these. I never paid much attention to the details when it came to implementation. Unless you can find a similar block in the current TP2, I'd say to just make sure that whatever you add does what it's supposed to and doesn't break a normal install. Truthfully, my solution would be to revert the shell spells. Because anybody who was here years and years ago knows that I hate the shell spell fixes. I hate them! :-)
  11. IIRC, reevaluate allows a change in target that typically would not be possible without stopping the action and restarting it. If you have Attack(NearestEnemyOf()), the script runner will attack that object until it dies or until the action times out (or until it's given something else to do). If you have AttackReevaluate(NearestEnemyOf(),90), the script runner will attack that object, every 6 seconds determining if the object has changed (if a different enemy comes closer during that time, you switch to it and attack it). This is done so that it's not constantly switching blocks (otherwise you'd have to stop attacking and check your targets all the time). Neither Attack() nor AttackReevaluate() return until the target becomes invalid, meaning ActionListEmpty() not returning true in the example above is the expected behavior. All of the attack actions are interruptible (if the engine finds something else for the object to do, then it will do it). At least, that's what I seem to remember of it.
  12. devSin

    Help for Mac-users

    I never got around to even investigating mosunpack, in response to your message last year. Sorry. :-( I did mean to, at one point, but it kept dropping off the radar. Hopefully somebody else will be able to look at it for you.
  13. devSin

    Persistent MoveToObjectFollow()

    You'll have to post the script. Obviously, something is still true (they'll stop moving/following if they break out of that action, but your script is apparently dropping them back into it).
  14. devSin

    Help for Mac-users

    Assuming it's all installed (you needed to a manual full install IIRC), BG/TotSC with whatever that last patch was didn't actually have a disc check.
  15. devSin

    Immunity to Kill() action?

    I don't think so. You could try immunity to effect: death, since death code often goes through there IIRC, but Kill() may ignore it too (it actually used to not work through minimum HP effects, but they changed it in ToB to kill you anyway).
  16. devSin

    Help with wing buffet

    Doesn't staff of the ram use it? Copy that.
  17. devSin

    Illasera avatar bug

    Unless you can get David Gaider to say that she's an elf, we're not going to change her avatar. It's a high-visibility change with little justification (just go look at our list of race fixes; it's not always a reliable field). It would be fair to suggest her race be changed, but I don't think it's really necessary at this point. Maybe she's meant to be a stocky elf, or an alien-looking elf because she's half-god.
  18. Yes, it needs to be removed. Somebody will have to review the component to see if there's anything salvageable, and there may be things in there that deserve some sort of community release (maybe a tutorial or something), but it doesn't belong in the fixpack. There was a reason for it in the beginning, but the lack of maintenance and the reality of mod development simply make it more harmful than beneficial.
  19. devSin

    LeaveAreaLUA() and possible side effects?

    The game will decide on its own what it runs. Like Miloch says, try not calling it from Baldur.bcs, and make sure you run a ClearAllActions() before StartCutscene(). My only other suggestion would be to try making your new area a master area.
  20. devSin

    Azuredge

    The read me encourages all sorts of responsible behavior, I'm sure. But there's a difference between advocating responsible behavior and expecting responsible behavior, and Cam clearly favored one over the other when he decided to do a resource copy (and we hated resource copies, even back then). Knowing Cam, it was all about us doing the right thing and not simply looking the other way unless the player does the right thing. ;-) Maybe I'm old and stupid now, but isn't that SET (variable named the value of "var") += 1? If abil_fx_num is 4, then the code is SET "4" += 1.
  21. devSin

    Azuredge

    As long as it works with an already fixed (e.g., Baldurdash) copy of the item. IIRC, that was the reason for copying the resource instead of patching, way back when. Really? :-)
  22. I'm surprised it isn't affecting the roll, but I don't remember all the nuances. Oh, well. Luck is already overpowered, so a few extra buffs can't hurt. :-)
  23. If it rolls, I'd suppose so. I don't remember any special checks, but there probably are. Now that you mention it, it sounds familiar, but I don't remember if it was an exception or if it just works because of the way it changes the results. The 5% in the description is probably just because it gives a +1 d20 roll bonus, and then they listed stuff that rolls (but if it doesn't do a dice roll, then it doesn't do anything). What are we doing for saving throws BTW? Wouldn't luck already influence them, and how the hell do you add 5% to values so small anyway? It sounds suspiciously like we may just be making stuff up here.
  24. Seriously? When did we do that? I guess since we already do it, it makes sense to extend it out the the thief skills (we're making it noncumulative, right?), although I'm inclined to believe that the description is just being overly-generous on the types of rolls the game makes (luck is somewhere way down in the roll calculation IIRC; does open lock even initiate a roll? isn't it just a >= b?). Perhaps it's just a motivational bonus. The little 5% that could. :-)
  25. devSin

    Minor 2da corrections

    But you didn't post the tables, or at least the relevant parts. So I'm left trying to decipher what the actual values are, without access to the tables, the desire to look for them on IESDP, nor the memory to actually recall correctly what it is (even I have forgotten most of what I once knew). And as is typical for me, I read through your post and reached an incorrect conclusion. :-) So after your followup, I checked the 2DA on IESDP, and I saw instantly what you're saying. You can, and often you should. We're guided either to something that's so inherently silly it couldn't possibly have been intended, or something that is flat-out broken. Guessing which values BioWare intended among two possible, fully functional choices, is the place where you really have to stop and examine the situation. If it doesn't match the manual, then we get to change it (we've used it as justification before, and it's also the justification for the other table fixes here). But that the table itself is simply an extension of the original doesn't immediately signal an issue (if the PnP rules didn't exist, what would be the expectation for those values?). In this case, the important argument you make is that the Hide in Shadows row has compliant values. It's hard to argue that half of what the game uses as a single value is supposed to be compliant and the other half was really intended not to be. Since it involves thief skills, this one is aVENGER's call. It doesn't bother me, but it will change slightly these scores, now in the second decade of the game's life (since these are calculated at runtime IIRC, if anybody is depending on the old scores, they will have changed after installing the fixpack).
×