#116 (0x74) State: Cure Invisibility [116]

[Ascension64]

This is probably extremely situational, but it is the way that the Cure Invisibility effect works. Spells with this effect require the ability targetted on the Caster(5) with the Cure Invisibility effect targetting Preset target(2). In this case, Preset target(2) does not target Allegiance(NEUTRAL).

 

The specific scenario used was Krystin (KRYSTI.CRE) in BGT-WeiDU. Krystin starts with NEUTRAL allegiance. She has a permanently equipped MAGE01 (Ring of Invisibility that gives permanent STATE_INVISIBLE, unless she breaks the invisibility by casting an offensive spell or attacking the party). Casting any spell that dispels invisibility (True Sight, True Seeing, Oracle, Invisibility Purge) does not dispel Krystin's invisibility. However, if she is given the command Enemy(), then her invisibility will be dispelled by any of these spells before she has a chance to break her invisibility by an action on her behalf.

 

It is possible that any spell ability targetted on Caster(5) with effect targetting Preset target(2) does not target Allegiance(NEUTRAL), but I won't make this generalisation because there isn't enough evidence for it yet. Further testing would be warranted.

[igi]

An alternative explaination could be that True Sight, True Seeing, Oracle, Invisibility Purge all use the BIGNAREA projectile, which is set to only affect enemies.

[Avenger]

This sounds much more plausible

[Galactygon]

Try changing the projectile to some other one that affects everyone and see if your statement is still true. If the creatures still have their invisibility on, then you are probabbly right.

 

-Galactygon

[Ascension64]

A quick glance at BIGNAREA.PRO shows that it is set to 'not affecting self'. I'll check out Galactygon's suggestion later on and see if it should be refined to 'affect enemies only' or whether my original supposition is true.

[devSin]

And party-only projectiles set to "not affecting self," "not affecting allies," and "not affecting enemies."

 

If anybody truly knows the meaning of the various bits in PRO files, they're not sharing.

[Avenger]

I shared what i know

 

There is no 'target only self' bit.

There are 2 bits:

 

1. Target only enemies (this is bignarea)

2. Target only party (this bit should be set with the previous one)

 

[edit]

Oh well, this stuff is in DLTCEP for at least 2 years now. And i'm sure i posted a note about the projectile area bits.

So here they are:

 

1 projectile visible

2 target inanimates

4 explode on trigger

8 one explosion at a time (this was falsely marked as something else)

16 use secondary projectile

32 use fragments

64 target only enemies (alternatively you can name it use target selector)

128 target only party (alternatively you can name it target selector)

if it is 0 then target enemies

if it is 1 then target party (but only if the previous bit was set)

0x100 unknown

0x200 multiple set off (i forgot what this does)

0x400 use VVC

0x800 Cone shape

0x1000 unknown

0x2000 no explosion?

0x4000 delayed explosion?

0x8000 Affect only one target?

 

Most of these bits enable only other fields, so their usage cannot be tested without properly setting those other fields. (Like the VVC resref for bit 0x400).

[devSin]

Bits 6 and 7?

 

Sparkle party-only always has 4, 6, and 7; invisible AoE party-only has 6 and 7; sparkle not-party has 4 and 6; invisible AoE not-party has 6; invisible AoE not-target has only bit 1 set; sparkle all has bit 4; and invisible AoE all has none.

 

So, I guess bit 6 is hostiles, and bit 7 allies; bit 4 seems to be the big question?

[devSin]

16  use secondary projectile

I'm not sure about this? If you look at the InArea* PRO files, they don't have this bit set, but they definitely use the secondary projectile (79, slow-ass no-animation single-target travel).

[Avenger]

No, the *NP projectiles and HOLY/UNLYAREA projectiles which exclude party, all target only enemies. (bit 6).

See my previous note.

[Avenger]

16  use secondary projectile

I'm not sure about this? If you look at the InArea* PRO files, they don't have this bit set, but they definitely use the secondary projectile (79, slow-ass no-animation single-target travel).

<{POST_SNAPBACK}>

 

No, it is what i call the explosion projectile.

The secondary projectile is something you don't even know of

 

[edit]

It is on 0x214

[devSin]

No, it is what i call the explosion projectile.

The secondary projectile is something you don't even know of

No, I just mixed it with the explosion projectile.

 

It looks like a bit at 0xc controls the not-self behavior?

 

EDIT: and, look, it's in IESDP. :/

[Avenger]

Hehe, yes. And since it is in DLTCEP, i knew it at one point, and could very well given that info

I haven't cared with projectiles for ages.

 

[edit]

Btw, the 'face target' field is more like the number of orientations present.

5 - mirrored eastern directions (reduced orientation granularity)

9 - mirrored eastern (full granularity)

16 - not mirrored, not reduced

 

Probably even 8 would work (it is used in some avatar animations), but i wouldn't swear it.

 

At least this is how i imagine this

[igi]

1 projectile visible

2 target inanimates

4 explode on trigger

8 one explosion at a time (this was falsely marked as something else)

16 use secondary projectile

32 use fragments

64 target only enemies (alternatively you can name it use target selector)

128 target only party (alternatively you can name it target selector)

if it is 0 then target enemies

if it is 1 then target party (but only if the previous bit was set)

0x100 unknown

0x200 multiple set off (i forgot what this does)

0x400 use VVC

0x800 Cone shape

0x1000 unknown

0x2000 no explosion?

0x4000 delayed explosion?

0x8000 Affect only one target?

 

So your all agreed on these?

 

 

Btw, the 'face target' field is more like the number of orientations present.

5 - mirrored eastern directions (reduced orientation granularity)

9 - mirrored eastern (full granularity)

16 - not mirrored, not reduced

 

Probably even 8 would work (it is used in some avatar animations), but i wouldn't swear it.

 

And do people want this in, or not? It's obviously untested, I don't have time to test it. People will complain if it goes in and is wrong, or if it stays out and is right.

[Avenger]

Well, mark the stuff with something, like a yellow overlay, or yellow marker or whatever. And note that it is unconfirmed.

This way it is in IESDP and also it isn't there