Scriptable Spells v3

[Salk]

How are things going ?

 

Unfortunately Horred The Plague has disappeared soon after the release of BPv177 and it was him coordinating this project. So Cirerrek correct me if I am wrong but Scriptable Spells is at halt untill Horred comes back and works on it...

[cirerrek]

How are things going ?

 

Unfortunately Horred The Plague has disappeared soon after the release of BPv177 and it was him coordinating this project. So Cirerrek correct me if I am wrong but Scriptable Spells is at halt untill Horred comes back and works on it...

 

Salk,

 

Yeah, that is the current state of affairs for Detectable Spells.

 

Cam and I have discussed it a bit recently.

 

The framework is here in the forums. The problem lies in getting the mods using the old version updated.

 

If we are going to get it done despite Horred's abscene, we really need to have everyone's agreement that there will only be this one version from now on.

 

Basically, we probably just need to get the dialog started back up and go from there.

 

Thanks,

[Salk]

How are things going ?

 

Unfortunately Horred The Plague has disappeared soon after the release of BPv177 and it was him coordinating this project. So Cirerrek correct me if I am wrong but Scriptable Spells is at halt untill Horred comes back and works on it...

 

Salk,

 

Yeah, that is the current state of affairs for Detectable Spells.

 

Cam and I have discussed it a bit recently.

 

The framework is here in the forums. The problem lies in getting the mods using the old version updated.

 

If we are going to get it done despite Horred's abscene, we really need to have everyone's agreement that there will only be this one version from now on.

 

Basically, we probably just need to get the dialog started back up and go from there.

 

Thanks,

 

I would really like to involve Aigleborgne in this because his mod (Enhanced Creatures) makes use of custom detectable spell but he has no time to even speak to me on MSN in this period and I have no competence to try and join this myself.

 

I would really want to share the same package if it is possible.

 

I could only work as link before and now can't do that either.

 

Is there anything you think I can do ?

 

Thanks!

[Galactygon]

Something struck me just now on making spells detectable without having to resort to additional slots.

 

There would be certain limitations to this (it wouldn't work with party members correctly since they usually have full inventories).

 

Here is my idea: The spell creates a non-removable item in the inventory of the target (non-party member). That item is a blank item, but could be "detected" via script. After the expiration of the spell, the item would simply be removed.

 

There are some spells (Khelben's Warding Whip might be such an example) the AI doesn't care if it were casted on the PC, but cares if it is casted on itself/own group, so it would act differently if the item is in its inventory. This is very similar to using local variables, with the difference they can be detected by other creatures.

 

-Galactygon

[Nythrun]

Then you'd need yet another version for party members, double the scripting blocks to select from which detectable effects version is applicable, extra checks to account for hostile joinables, and worries about junked inventories in spell heavy battles.

 

Thanks, but no.

[pro5]

Not to mention that checking for items is one of the slowest/laggiest things you can script.

[Galactygon]

Then you'd need yet another version for party members, double the scripting blocks to select from which detectable effects version is applicable, extra checks to account for hostile joinables, and worries about junked inventories in spell heavy battles.

 

Using .eff files are really simple, so it isn't that difficult to prevent party members' inventories from filling up with invisible junk.

 

Not to mention that checking for items is one of the slowest/laggiest things you can script.

 

Is it really that much slower?

 

-Galactygon

[Nythrun]

Using .eff files are really simple, so it isn't that difficult to prevent party members' inventories from filling up with invisible junk.

 

Sure is That just doesn't change that

it wouldn't work with party members

.

 

Stats values being stored as a byte on the cre is frustrating, I agree. But any system that's going to replace it needs to

1. Work on everyone
   
2. Work all of the time
   
3. Work without overloading the script engine
   

Because using stats.ids already does, and not fulfulling these three criteria is a step backwards.

[Galactygon]

That just doesn't change that

 

I just tried that method, and it worked quite fine, without noticable slowdowns. You might be right, in that it might be slightly slower, since items themselves take up slightly more space than the integers of stats do. But the difference isn't noticable, as I have experienced.

 

Because using stats.ids already does, and not fulfulling these three criteria is a step backwards.

 

Not when there is a shortage of IDS slots. The AI makes certain blunders when the effects of many spells are lumped into a single stat. I think I told Horred about this once, and he disagreed.

 

-Galactygon

[devSin]

OMG HasItem() is teh SLOW!!! seems to me a myth propagated in the prehistoric eras. I haven't found any actual basis for the belief.

 

No, you don't want to check for 50 items all in a row where it can be avoided, but no, nobody should ever discern any performance hit using HasItem() over CheckStat() or StateCheck() or Global() or whatever.

 

If you do, detail it, and then I might believe all this fear of inventory checks.

[Nythrun]

Obviously I'm missing something here.

 

Please explain to me how Galactygon's initial assement "it wouldn't work on party members" is in fact incorrect and you can add as many detectable items as you like without affecting inventory. Because I don't know how that works

 

If it doesn't work on party members and it works in limited fashion on NPCs you still need two packages.

[devSin]

I spoke only of speed. The feasibility or practical implications of the proposed method don't concern me (it was meant only as a reply to pro5's "slowest/laggiest" and Galactygon's "really?").

 

It's not something the engine was designed to handle; there will never be an elegant approach to ability- and effect-based detection.

[Galactygon]

...as many detectable items as you like without affecting inventory.

 

I am not aware of any slots that allow this.

 

No, you don't want to check for 50 items all in a row where it can be avoided, but no, nobody should ever discern any performance hit using HasItem() over CheckStat() or StateCheck() or Global() or whatever.

 

I have only verified my statement with a few items (6 or 7), so 50+ items are a different story. 50+ items, however, was never my intention from the start.

 

I am basing my theory on existing scripting blocks that use HasItem() checks to prevent the AI from casting Melf's Minute Meteors over Mordenkainen's Sword, so it has to work.

 

-Galactygon

[pro5]

If you do, detail it, and then I might believe all this fear of inventory checks.

There's a drastic performance hit, if the creature you're checking is carrying any containers (which PC with high degree of certainty do, most of the time). If you need proof of that, I can provide it.

[devSin]

Nobody in this context would be carrying containers. PC AI isn't really being covered here (at least, not as far as I can tell from Galactygon's comments).

 

I can imagine that walking through the STO files for containers incurs a penalty, but proof is always welcome (especially since it's something that I've never bothered to play with).