Endurium Posted July 26, 2017 Posted July 26, 2017 I've seen scripts using Deactivate("") with actors and wondered where that was being done. Seems the change is made to the Actor's attached CRE file by setting the Status/State at 0x0020 bit 19 which is STATE_DISEASED in the default STATE.IDS (NI pulls IDS data for this field in CRE files). I tested by editing the area script for AR2600 so it did a Deactivate("Gorion") on startup, walked to the steps to verify he was missing (he was) then saved and examined AR2600 in the save file to find this info. When not Deactivated he is STATE_NORMAL.
lynx Posted July 26, 2017 Posted July 26, 2017 What type of scripts are the calls being made from (area, actor, cutscene, trap ...)?
CamDawg Posted July 26, 2017 Posted July 26, 2017 Yeah, STATE_DISEASED is actually inactive; I'm pretty sure we fixed this for the EEs. A simple way to check this in game is summoning a good deva. They have a block to cast Cure Disease on party members that are diseased via a STATE_DISEASED check. You can get diseased all you want (via contagion, mummy attacks, whatever) and the deva will never do anything (in vanilla, at least).
lynx Posted July 26, 2017 Posted July 26, 2017 Yeah, the state overlap has been known for a long while. I'm interested more in the empty parameter, which I'd guess just falls back to the caller as the object.
CamDawg Posted July 26, 2017 Posted July 26, 2017 Oh, gotcha. I'm not sure I've ever seen it used without an object--and friggin' IWD uses Deactivate/Activate *everywhere*--but Myself is probably a good guess for the default.
Ardanis Posted July 26, 2017 Posted July 26, 2017 Never ever use Deactivate() for whatever purpose you might think you should. During the development of SoD the number of bugs of various nature associated with this feature has been beating any other bit of code by a landslide. It's been fixed once, and twice, and thrice, and still new kinds of bugs kept popping up. Just don't use it, unless completely out of any other ways to solve whatever problem you have on hands.
Endurium Posted July 26, 2017 Author Posted July 26, 2017 What type of scripts are the calls being made from (area, actor, cutscene, trap ...)? Area scripts, from what I've seen so far. For example in BGEE AR0300.BCS has blocks that Activate and Deactivate Narlen Darkwalk depending on the time of day, after he is initially created on the map. The state overlap isn't noted in the IESDP (under the CRE formats), thus my curiosity. Interesting both blocks refer to variable CDNarlenExists (CamDawg?) I'm not using it just noting it in stock game code. Oh, and the empty parameter was just me using shorthand. Haven't seen either action used without an object.
CamDawg Posted July 26, 2017 Posted July 26, 2017 Yeah, Narlen's activate/deactivate blocks are unbounded and block anything after them in the script. That's my fix from Tweaks or Tutu (or somewhere) that made its way into BGEE. You'll find some CD resources and variables scattered throughout the EEs from my various fixes, and perhaps an Easter egg or two. And I was wrong about IWD and Deactivate--the original uses a ton of HideCreature, not Deactivate. I was thinking of IWD-in-BG2 and IWDEE where these got converted into Deactivates, before just being scrapped for outright spawns. As Ardanis mentions, dealing with Activate/Deactivate is a PITA and generally not worth it.
Miloch Posted July 27, 2017 Posted July 27, 2017 I'm pretty sure we fixed this for the EEs. Just out of curiosity, "pretty sure" equals what, a 90, 95, 98% chance? Never ever use Deactivate() for whatever purpose you might think you should. During the development of SoD the number of bugs of various nature associated with this feature has been beating any other bit of code by a landslide. It's been fixed once, and twice, and thrice, and still new kinds of bugs kept popping up. Just don't use it, unless completely out of any other ways to solve whatever problem you have on hands. Again, out of curiosity, why has this been so elusive a bug? Call me simple (orcish heritage if you want to bring race into the issue), but it seems straightforward: activate a sprite/CRE or not. We (you and I) have used it all over the place, long before there was EE and after. Is there some sort of glitch in the code?
CamDawg Posted July 27, 2017 Posted July 27, 2017 EEs fixed it, but it was by implementing spell states and not by making STATE_DISEASED work. I think we left the legacy behavior of the state simply because we didn't have to change it. For IWD-in-BG2/IWDEE, I believe it was primarily the combination of hostile deactivated creatures. The combat counter constantly misbehaved, preventing saves and other stupidity... any time entering the town maps like Lonelywood and Kuldahar you'd get auto-paused for deactivated enemies. I can't speak to the code side of it.
Ardanis Posted July 27, 2017 Posted July 27, 2017 Never ever use Deactivate() for whatever purpose you might think you should. During the development of SoD the number of bugs of various nature associated with this feature has been beating any other bit of code by a landslide. It's been fixed once, and twice, and thrice, and still new kinds of bugs kept popping up. Just don't use it, unless completely out of any other ways to solve whatever problem you have on hands.Again, out of curiosity, why has this been so elusive a bug? Call me simple (orcish heritage if you want to bring race into the issue), but it seems straightforward: activate a sprite/CRE or not. We (you and I) have used it all over the place, long before there was EE and after. Is there some sort of glitch in the code? Not "a bug" as in singular, but a slew of different bugs/issues/regressions/what have you. They all seem to have been resolved eventually, but I'm naturally skeptical about a thing that managed to cause that much trouble. As for the use of it, I've seen Lava having issues with it (judging by comments in the .baf), so just because it worked in one place, doesn't necessarily imply it will elsewhere.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.