Jump to content


  • Content Count

  • Joined

About devSin

Profile Information

  • Gender

Contact Methods

  • Website URL
  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. 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. 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. Ah, so that's what it was. I knew I did something, but I couldn't remember what it was. Thanks for checking. :-)
  5. 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. They're there (school and secondaryType). Taimon was the first to reverse these fields IIRC.
  7. 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. 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. 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. 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. 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).
  • Create New...