19 réponses à ce sujet

[Tchos]

I can't seem to find a way to make an activated item's unique power (targeted) show a targeting circle on the ground where you move your cursor before clicking to cast it.  Is this something that only works for items that use standard "cast spell" calls, like the Bowl of Commanding Water Elementals? 

 

The script works, but I'd like for the player to be able to see the targeting circle so that it's clear that you can click on the ground, and don't need to click on an object.

 

I tried making the item out of several base types, including misc small object, magic wand, and grenadelike, but I saw no difference between them.

[AGhost_7]

The only way that I can think of pulling that off would be to create a spell which has the targeting that you want. The spell would then point to your script. As usual, you'll need to edit the spells 2da, but this time you'll also need to make some changes to the iprp_spells 2da.

[Dann-J]

I tend to use Cast Spell: Activate Item (long range) for such items (like my Horn of the Skymage script).

[Tchos]

I tried out Cast Spell: Activate Item (long range), and it seemed to work just as well as Cast Spell: Unique Power.  Both of them fired the script, but neither showed a targeting circle on the ground.

 

I can try the 2DA editing method next.  I haven't touched either of those 2DAs before.

[AGhost_7]

You might be able to make yourself a "stock" item spellcast item property with the targeting circle. If you do the same as I sugested and instead place use this as the script which is triggered in the spell 2a:

 

void main()
{
    object oItem = GetSpellCastItem();
    string sScript = GetLocalString(oItem, "sSpellCastScript");
    if(sScript != "")
    {
        ExecuteScript(sScript, OBJECT_SELF);
    } else 
    {
        SendMessageToPC(OBJECT_SELF, "Oh noes! There was no script.");
    }
}

 

You might be able to save yourself from having to edit the 2da files for every time that you want to make an item that has a targeting circle. After doing those changes, you'll just need to create the item with your custom item property and set the variable which points to your script on your item.

 

Now, this relies on GetSpellCastItem to work, and there's a good chance that the function won't return the source item which was used to cast the spell.

[Tchos]

I'm going to keep this post on hand until I've had either a nap or some good caffeine, as I'm a bit too groggy at the moment to fully explore it, but the script does need to make use of the information returned, such as the activator, the item activated, and the activator's target or target location, which if I understand correctly you're saying may not be available with that latter method.

[Dann-J]

There might be a way of doing this without having to modify any 2DAs.

 

If you find a summoning spell that has a generically named item property (Summoning Pool comes to mind), you could modify the spell script to look for a local variable on the spell casting item that overrides the default behaviour. If that local variable happens to be the creature blueprint template, then you could use that one item property to summon anything you liked.

[Tchos]

If I understand you correctly, you're talking about using an item property whose name could be taken more broadly to apply to the behaviours I want my item to give, so that when a player looks at it in the examine window, the On Use description will still make sense, right?

 

Unfortunately, the name would have to be more generic than "Summoning pool", because I'm not actually using this for summoning most of the time (though I would have done that for the Bosun's Pipe item, which is a summoning item but has no targeting circle).  What I'm doing now is building another of my questing system helpers, so the name of the property can't be any more specific than "activate item" or "unique power".  I think in this case, the editing of the 2DA may be necessary.

[Dann-J]

Yes - my suggested method hinges on finding an existing item property with a display name generic enough to be applicable to another circumstance, AND one that also happens to point to a particular entry in spells.2DA that has the required targetting circle effect. If you don't get lucky in that respect, then you're pretty much forced to edit some 2DAs (spells and iprp_spells).

 

Although I suppose you could split the difference; edit iprp_spells.2DA so that the new property has the required display name, point it to an existing spell entry that has the required targetting circle, then edit that spell script to look for an override variable on the spell casting item. The modified spell script might also need to bypass the function that broadcasts the OnSpellCastAt ID (EventSpellCastAt I think), otherwise the console might tell you that you're casting the original spell you've hijacked.

[Tchos]

Editing spells.2da didn't work, at least not in the way I approached it.  I tried editing the two entries directly (Activate Item: Long Range and Unique Power) to simply add the targeting circles to the TargetingUI column, where several spells like Fireball or Isaac's Missile Storm show entries taken from spelltarget.2da.  I tried several shapes and sizes for the circles, including ones that were used by the spells above.  Nothing appeared on the ground, and I know the edits were in effect because I also changed the casting animation.

 

Next I tried copying all of the settings from the Fireball entry except for the fireball scripts onto the Activate Item entry.  That didn't make a circle appear, either, but it did produce some special effects in addition to activating the item as normal (no damage of course, since the only script was the normal Activate Item script).

 

Looking at other spells like Summon Creature, I see that they don't have anything in their TargetingUI column as the offensive spells do, so there may be something somewhere else that controls whether it appears, and the TargetingUI column may be simply a way to change the circle's style to something other than the default, if there is a default.

 

Next I tried editing iprp_spells.2da so that the Activate Item entry pointed to the Fireball spell index.  The description in the examine window showed "Activate Item" for its Use, but right-clicking on the item showed the icon and name of the Fireball spell.  The console, however, did not report that I was casting Fireball, but only that I activated an item, so that's good.

 

The target did appear on the ground with this method.  So, since I can't get the other method to work, I could go through looking for something that sounds generic enough and has a target, and edit the spell script to override its behaviour.

 

I'm starting to think that having a targeting circle might not be worth it for the incompatibilities it may introduce, such as with Kaedrin's pack.  I know he overrides spells.2da and spelltarget.2da in the older version I have, and have no idea what he may override in the latest version.

[Dann-J]

Perhaps it's TargetType in spells.2DA that determines the targetting circle?

[Tchos]

I tried with that option set to ground-targetable.  As it comes, Activate Item is set to all-targetable, using bitwise operators.  At any rate even the TargetType that was copied straight from the Fireball entry didn't make it appear.

[Lance Botelle]

Hi Tchos,

I was surprised to hear that setting targetingui to "2" in line 697 (Activate Long Range) did not work. I messed around with it myself and could not get it to work in this simple manner myself.

Anyway, why not simply add a new spell (generic cast at type) and see if editing the column works there?

i.e. Copy Fireball line to spells.2da and alter all columns/scripts to suit your own needs. I would have thought you could even point to the same Activate scripts for simplicity ... or at the very least copy/rename/add them to you own.
 
TESTED & WORKS ... Just be sure to update your iprp_spells.2da with a new line for your spell as well. 

 

I imagine the other spell lines are hard-coded somehow ... but we are able to add our own new ACTIVATE CAST AT lines with your own name/descriptions. And if you are calling the same script as the OC line, then it will behave in exactly the same way, but with the targeting GUI as you require.

 

IMPORTANT ... Showing the GUI on the ground does NOT limit the spell to its image. You have to script that part within the spell itself. Therefore, having a generic script to fire the item used must also fire the script that determines where and how the damage is applied.

 

I hope that makes sense.

Cheers,
Lance.

[Tchos]

Yes, so my mistake was trying to alter something that couldn't be altered, when a new line would have worked with the alterations in place, according to your report.  Thank you for the information.

 

I was hoping not to have to alter spells.2da for compatibility reasons, since it's such a commonly-edited 2DA, and a part of packages like Kaedrin's that I'd have to include if I want to be compatible with that.

 

The circle on the ground is only an arbitrary visual indicator, I know.  I won't generally be using this for damage, but for environmental interaction in quests, so I would have been happy enough if I only had one size to work with, but if I go ahead with editing the 2DA, I'll make several sizes for different uses.

[Lance Botelle]

Yes, so my mistake was trying to alter something that couldn't be altered, when a new line would have worked with the alterations in place, according to your report.  Thank you for the information.

No problem ... I may need to do something like it myself one day.
 

I was hoping not to have to alter spells.2da for compatibility reasons, since it's such a commonly-edited 2DA, and a part of packages like Kaedrin's that I'd have to include if I want to be compatible with that.

If you saw the number of 2da and XML I have edited, any remote possibility of any kind of "compatibility" with other packages went out the window a long time ago. I reckon creating your own module the way you want it to play is the priority. i.e. I would not worry too much about trying to be compatible with others, just make your module plays the way you want it to ... of course, that may mean you want it to be compatible.
 

The circle on the ground is only an arbitrary visual indicator, I know.  I won't generally be using this for damage, but for environmental interaction in quests, so I would have been happy enough if I only had one size to work with, but if I go ahead with editing the 2DA, I'll make several sizes for different uses.

Good to know that you knew this ...

Cheers,
Lance.

[Psionic-Entity]

Seems you've found the solution in adding a line to the cast spell item property 2da.

 

A word of warning, though. It's best to cannibalize a cast spell line that you will never use because adding extra lines to this 2da has been known to cause client crashes in some cases. I've personally fixed client crashes by moving extended lines of this 2da up to some spell I knew I wouldn't use.

[Tchos]

Noted.  Perhaps an epic spell would be a good candidate, since there will be no epic levels in my campaign.

[Dann-J]

I took my own advice, and hacked the main summon script that is used for quite a few summoning spells (nw_s0_summon). A couple of extra lines now allows it to check for an override string on the spell cast item, using that template value instead. That gives me a whole lot of summoning item properties with various names and icons to choose from, so I don't have to alter any 2DAs.

 

As an example, I now have a wand that can summon halfling war dogs that uses the Summon Monster I spell, which has an appropriately doggy icon (a wolf). The target circle on the ground and the summoning effect are all courtesy of the original script.

 

I can see myself creating all sorts of new summoning items now. A razor boar instead of a dire boar. A worg instead of a dire wolf. Basically anything that the existing spell cast icons slightly resemble, that have nice generic item property names.

[Lance Botelle]

I took my own advice, and hacked the main summon script that is used for quite a few summoning spells (nw_s0_summon). A couple of extra lines now allows it to check for an override string on the spell cast item, using that template value instead. That gives me a whole lot of summoning item properties with various names and icons to choose from, so I don't have to alter any 2DAs.
 
As an example, I now have a wand that can summon halfling war dogs that uses the Summon Monster I spell, which has an appropriately doggy icon (a wolf). The target circle on the ground and the summoning effect are all courtesy of the original script.
 
I can see myself creating all sorts of new summoning items now. A razor boar instead of a dire boar. A worg instead of a dire wolf. Basically anything that the existing spell cast icons slightly resemble, that have nice generic item property names.

Hi Dann-J,

I did something similar using line 12 (Summon_Clockroach) from the spells.2da. I altered the script that was there (or rather added my own), which reads a string variable from the item to determine the creature summoned, etc.

With respect to not having to edit 2da's, I have found that it is just as prudent to consider editing 2da's as OC scripts, which you will have needed to do for your summon options. i.e. I believe the risks/issues are the same whether you edit 2da or OC scripts.

I think once you've edited one 2da, then it becomes no more or less or an issue than editing OC scripts. It then becomes a matter of preference. I suppose the only situation that may occur with respect to 2da's is if you are trying to avoid editing them for the purpose of somebody else's work ... That boat sailed long ago for me.

Cheers,
Lance.

[Dann-J]

Indeed. I try to avoid editing a 2DA for just one purpose, but once I've busted a particular 2DAs cherry there's no reason not to make a dozen edits to it.

 

I'm always conscious of whether or not a custom item will continue to work in another module via an exported character. At least piggy-backing on a standard script using a standard item property ensures that the item will still do *something* in another module - even if it reverts to summoning the usual creatures.

 

Not that Storm of Zehir was very good in that respect - the clockroach and ivory shieldmaiden summoning scripts seem to have been in the SoZ campaign folder, so those items don't work in other modules even though their item properties are in the main 2DAs (unless you copy the scripts to the override folder yourself).