Detectable Spells

[Guest Guest]

And about the comments. I'm not inventing anything new. There's a description of the system from Horred. Is it necessary to have something else?

 

Sorry, that was me whining. I've been writing Work Instructions (read How to DO Something in 22 pages Which is Longer Than the Specification That the Work Instruction is Based On) for work lately. So I get nervous if every little detail isn't spelled out in a process. [/End Whine]

 

A wiki, community type effort is a marvelous idea. Exactly what I was looking for. That way the supercoders can code everything as intelligently and as efficiently as possible, modders can submit suggestions, and non-super coders can help out as needed. And everyone gets to enjoy the fruits of a consistent working version of DS.

 

Old DS: Avenger worked out names for some of the faulty States (states that were already doing something even though the documentation didn't explictly say they were doing anything). As in figured out what they actually did and gave them names. I've got a copy on my home computer if Avenger doesn't chime in.

 

Perhaps they would be worth including or at least commenting in the State.IDS file?

 

Anything else that I can do to help?

 

Thanks,

[cirerrek]

And about the comments. I'm not inventing anything new. There's a description of the system from Horred. Is it necessary to have something else?

 

Sorry, that was me whining. I've been writing Work Instructions (read How to DO Something in 22 pages Which is Longer Than the Specification That the Work Instruction is Based On) for work lately. So I get nervous if every little detail isn't spelled out in a process. [/End Whine]

 

A wiki, community type effort is a marvelous idea. Exactly what I was looking for. That way the supercoders can code everything as intelligently and as efficiently as possible, modders can submit suggestions, and non-super coders can help out as needed. And everyone gets to enjoy the fruits of a consistent working version of DS.

 

Old DS: Avenger worked out names for some of the faulty States (states that were already doing something even though the documentation didn't explictly say they were doing anything). As in figured out what they actually did and gave them names. I've got a copy on my home computer if Avenger doesn't chime in.

 

Perhaps they would be worth including or at least commenting in the State.IDS file?

 

Anything else that I can do to help?

 

Thanks,

<{POST_SNAPBACK}>

 

Sorry, last post was me. Apparently logging into the wiki site dosen't also log you into the forum.

[CamDawg]

I'm still working out kinks between the mutual forum/wiki logins. I hope to get it to the slickness of the portrait gallery-forum integration, but I'm not there yet.

 

The benefit of the lookup tables should be that anyone can add or change items/files/effs on the list with minimal fuss, and let the tp2 do the heavy lifting of actually adding the states. Two caveats about the DS on the wiki at the moment: the stats.ids changes are from a non-BP version, and I have not cross-checked them to see if they're correct--at a cursory glance, it looks like some have changed so no one should be running off and implementing the wiki version at the moment. The other caveat is that right now there is an all-item tp2 patch to deal with level draining items, which should be moved out of the tp2 and into the existing cddetect.2da table.

 

So, a to-do list off the top of my head:

• I'm with cirerrek: documentation is good. We should look at a couple of levels of documentation: a list of mods using DS, how mods including spells (and presumably items too) can make them DS-compatible (we need to DS-ize some of the new DR spells, for example), and, of course, the list of states and values for scripters.
  
• Items and effs that add states we want to detect. For example, the bigg has already indicated there are several potions for which we should account. This research can be done by anyone, and added to the lookup tables on the wiki.
  
• Discussion of future expansion--cirerrek has indicated in the past he'd like ways to detect (spell-added) elemental immunities, for example.
  
• Review of current spells and effects. This bit should probably be done by folks actively using DS instead of, say, me.
  

Anything else?

[cirerrek]

Here is the list of states that I mentioned.

 

166 MELEETHAC0

167 MELEEDAMAGE

168 MISSILEDAMAGE

169 NOCIRCLE

170 FISTTHAC0

171 FISTDAMAGE

172 TITLE1

173 TITLE2

174 DISABLEOVERLAY

175 DISABLEBACKSTAB

[the bigg]

The other caveat is that right now there is an all-item tp2 patch to deal with level draining items, which should be moved out of the tp2 and into the existing cddetect.2da table.

<{POST_SNAPBACK}>

Not necessarily - this way, you'll also catch mod-added items without listing them. Maybe we could patch also all SPL affecting this in the same C_E_R G loop, forgetting about listing them? (done also the tp2 code for this, somebody else should do this for the tables)

 

Another thing to implement is that you should block the zeroing of previous 282 effects only if you're modifying the same stat - for example, SPIN117 (Minsc Rage) has

SPIN117.SPL 282 1 3 142 A

SPIN117.SPL 101 0 45 142 A

And the second effect (immunity to stun) would prevent the first (setting the state) from happening.

 

Umm, I think I'll add this in myself... (done )

[LadeJarl]

The important thing here is that both KD's and Cam's/bigg's both use the same states for everything.

<{POST_SNAPBACK}>

 

May I suggest that the states list in KD's version is used as the foundation for future work, as it frees scripting states.

[CamDawg]

It is; one of the reasons why I had wanted to get the BP modders involved was that they had the most 'recent' version of DS.

[the bigg]

Also, now might be a good time to remind everybody of my proposal for Detectable Area Effects, where stuff like Cloudkill creates an invisible CRE which others can run away from.

<{POST_SNAPBACK}>

Since I'll do this soon, do you people think it better to do this via patching all instances of a header using a specific header, or by listing specific spells (EG catching more mod spells versus the risk having spells patched even if they use the same pro only for convenience, even if they have totally different effects)?

[CamDawg]

I'd say patch a specific list and then encourage mod authors to include the same functionality. If we do know of legacy spells where the author is unable to do this or is gone, we can add them to the list as well.

[Guest Razfallow]

I have installed Tougher Sendai from Oversight v7 on clean installation of BGII + ToB.

Why is effect "Modify script state" in strength raising spells (Draw Upon Holy Might, Strength of One, Holy Power etc.) set to WIZARD_SPELL_DEFLECTION?

 

Some spells have effect "Modify proficiencies" instead of "Modify script state", why?

[cirerrek]

I have installed Tougher Sendai from Oversight v7 on clean installation of BGII + ToB.

Why is effect "Modify script state" in strength raising spells (Draw Upon Holy Might, Strength of One, Holy Power etc.) set to WIZARD_SPELL_DEFLECTION?

 

That would seem like an error.

 

Some spells have effect "Modify proficiencies" instead of "Modify script state", why?

<{POST_SNAPBACK}>

 

Altough undocumented by Bioware, it turns out that some of the stats in use by Detectable Spells actually did do something.

 

To avoid the setting of unintended stats, it was proposed that the Extra Proficiency slots, which are not used in-game, be used instead.