Jump to content

a strange question (is there a trigger which could consistently crash?)


Avenger

Recommended Posts

Anyone can tell me a script trigger which is crashing the game consistently?

Maybe tell me more than one. (Those that would crash with a bling - and possibly a popup - are the ones i look for). These are 'planned' crashes, and could be used for debugging very nicely.

 

I've mostly finished the effect opcodes and started looking into actions and triggers.

Link to comment

Can you look at the mirror image opcode in BG2? The max # images parameter isn't actually the max # images (it looks like the number of images may be hardcoded).

 

I can't think of triggers that always crash. AreaCheckObject() can easily be made to crash, but this is specific to either the Mac version or the 26499 ToB update. Using HaveSpell() with the bad spells will always crash, of course, but I'm guessing you're looking for a trigger that's completely broken by default?

 

A group in BG2 is defined as 2 characters with the same specifics value. This is how InMyGroup() and NearestMyGroupOfType work. I don't know if GemRB supports this yet.

 

I had some other script observations, but I don't know when (or even if) I'm going to get around to detailing them on the IESDP board.

Link to comment

Thanks for the HaveSpell tip, i'll see if it works for me.

I need these to see the call stack to get an idea where the code branches out to the different triggers.

Previously this method let me find the jump table for the effect opcodes/script actions.

Link to comment

Does it look like the parameters are used at all?

 

You can get the HaveSpell() crash by setting an innate to some level greater than 1 and then running the trigger from a character who has the spell (you could probably get away with using Minsc and his berserk).

 

NearestDoor(Myself) will also always crash if you want to start looking for object handling.

 

You may be able to get the game to freeze if you have a dead actor run ReallyForceSpellPoint() (which, despited the name, is really handled as a ForceSpell() action).

 

It may be tougher than effects if any of it is handled by the Lua engine, I guess (I know a lot of the scripting routines are exported to the Lua interpreter, at least).

 

I can't remember if I've asked before, but for GemRB, it might be useful to have a SetSelected(I:State*BOOLEAN) action that will toggle the selection state of the calling PC to either unselected (FALSE) or selected (TRUE).

Link to comment

I've implemented SetSelection(whom , type)

 

if whom = -1 then it selects all

otherwise whom is the party id

and type = 0: deselects the actor

type = 1: selects actor (others are not changed)

type = 2: selects actor (deselects others) and centers on it

 

Yeah, i know you did not ask exactly for this, but this is a single call for me, and i'm lazy :p

Selection alters stuff in multiple objects, and this part was the best to call into.

 

Well, the benefits are that you can do other than single select, and that you can do this from anywhere without actionoverriding.

The bad thing is your script must know which party slot the actor has.

Link to comment

GRR.

This stupid game just don't want to crash!!!

I tried everything, changed spwi101 to be innate and level2, then use

havespell(WIZARD_GREASE)

 

Tried to remove the actor's innate slot. It didn't cause a crash!!!

Doh.

 

[edit]

 

Ok, randomnum(0,0) did the trick. :)

Link to comment
Ok, randomnum(0,0) did the trick. :D
I couldn't even get that to crash. Damn you, Mac OS X PPC! ;)

 

Did you find anything out yet? Dish. You know I'm a slut for engine details... :D

 

Yes, i got a pretty list of triggers useful on actor or globally. (Only triggers with 0x4000 have been tested so far).

There are 18 0x4xxx triggers that wouldn't work from an actor, the rest would.

(I'm writing this from memory, i'll post any barely significant findings later).

 

The randomnum crashes because it does the primitive random()%x kind of random numbers without boundary checking ;)

Link to comment

Well, the most significant find (for me) was that i finally was able to take a peek at CheckStat trigger.

It is clear that stats are in the 1-201 range (in ToB) and I could tell the type (size and signedness) of each stat. All stats are accounted for in CheckStat, so some stats that are not found yet, or known to be used by invalid effects, could be used for something else. (like stat #198 would be the 'immunetosequester' stat). To set this stat, you would need a special scriptingstate opcode i previously found.

 

Interestingly enough, the engine keeps several copies of the stats in the actor structure, so i couldn't use these memory locations directly. I still have to find the code where it copies the output from the effects to this memory area.

Link to comment

Oh, this is exciting stuff and I'm missing it for stupid overtime ;)

 

Stats 182, 184, 185, and 198 are definately being used by something.

 

188 (whats with the .bam display?) and 193 are used by something broken - I bet you'll be able to figure out which is IMMUNITYSEQUESTER, I didn't ;)

 

Oddly enough, I got LEVELDRAIN (200) working by using zero duration effects with the weapon proficiency opcode rather than the scripting state opcode :D

Link to comment

My current understanding is this:

Note that there is a little confusion around #185

I don't know #182, #188 and#193

 

#define IE_ENABLEOFFSCREENAI 183 // bg2 has this on this spot

#define IE_EXISTANCEDELAY 184 // (sound2mn)

#define IE_DISABLECHUNKING 186 //

#define IE_NOTURNABLE 187 // immune to turn

#define IE_CHAOSSHIELD 189 // defense against wild surge

#define IE_NPCBUMP 190 // not entirely sure what is this

#define IE_CANUSEANYITEM 191

#define IE_ALWAYSBACKSTAB 192

#define IE_SPELLFAILUREINNATE 194

#define IE_NOTRACKING 195 // tracking doesn't detect this

#define IE_DEADMAGIC 196

#define IE_DISABLETIMESTOP 197

#define IE_NOSEQUESTER 198 // this doesn't work in IE, but intended

#define IE_STONESKINSGOLEM 199

#define IE_LEVELDRAIN 200

#define IE_AVATARREMOVAL 201

 

 

I found out the immunity to sequester by finding an inactive code piece which was wedged between disable timestop and stoneskinsgolem. It simply would set stat #198.

I got the name of the crashing effect from DevSin. (It crashers with an assertion in the constructor of the effect, ie, it was deactivated on purpose).

 

 

 

Please clarify (or share your ideas) about any stats over #175, i still need to find them ;)

Link to comment

All that I've had time for so for (sigh) is to run through all stats < 176 (once with the weapon proficiency opcode, and once with the modify scripting state opcode), set them to zero with an effect, and do a CheckStatGT(0) script test.

 

Everything in the 202-255 range returns true (greater than zero) after being set to zero, so those really are inaccessible.

 

Stats 182, 184, 185, and 198 also return true after being set to zero, I see you've got two of them already :D

 

188 detects correctly via script, while set to a value of one it displays the disc-of-window-cleaner-under-your-feet animation that the bounce projectile opcode uses, I don't know what this means yet, if anything.

 

193 can be set to what values you like, and didn't have any immediately noticable side-effects, so it might be a holdover from something abandoned very early on in development.

 

I'll go wandering through the opcode list later this week and see if I can find 182 and 185 at all (provided you've not already discovered everything)

 

Sorry I can't be of more help ;)

 

/edit

 

I'm pretty sure that NPCBUMP was originally going to be the "Stop blocking off that doorway with your Wizard Eye!" opcode, that Bioware neglected in favor of just making the .cre fragile ;)

Link to comment
188 detects correctly via script, while set to a value of one it displays the disc-of-window-cleaner-under-your-feet animation that the bounce projectile opcode uses, I don't know what this means yet, if anything.
Check all the opcodes with the hardcoded visuals. Maybe spell shield?

 

I'm pretty sure that NPCBUMP was originally going to be the "Stop blocking off that doorway with your Wizard Eye!" opcode, that Bioware neglected in favor of just making the .cre fragile :)
I'm not sure, but it works fine. I just can't figure out the proper usage (why CRE x should have it and why CRE y doesn't need it). I just ignore it.

 

I think LEVELDRAIN (200) has always worked for me (or there's some super-secret method for using it that only I know and have since forgotten).

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...