50 réponses à ce sujet

[Lance Botelle]

BartjeD wrote...

Perhaps you can turn someone temporarily hostile to the spellcaster in the spellhook? Thereby you avoid the code and factions I think.

Hi BartjeD,

This is exactly what I am trying to do. I do/did have something sort of working, but it now longer does.However, it used the actioncastspellat function, which I think changes a number f the parameters sent and so I am not happy with that path anyway.

BartjeD wrote...

You can turn them permanently hostile by seeing if it's a hostile spell (from the 2da column) and then making then faction hostile.

So you'd have if(NonHostileSpell) ---> {Make temporarily caster's enemy}
else if(HostileSpell) ---> {Make permanent hostile...}

The problem you have here is that the targeting cursor does not allow you to target non-hostiles in the first place. Therefore, you have to change the cursor type (using the methods desribed above) and then allow the new code to temporarily change the faction.  As I say, I did have a type of this working, but it was messy and I would prefer to work out how to collect and send all the variables from the second GUI target method back into the spell process .. in one (relatively) smooth process.

I still reckon there might be a way and am still looking. (For a little while longer at least.)

Lance.

Modifié par Lance Botelle, 27 décembre 2010 - 05:09 .

[Lance Botelle]

Chaos Wielder wrote...

So, I was looking into checking via the examine UI to see if someone has examined a particular item/creature. Is there a way to do this? I know rudimentary xml, but not enough to make heads or tails of it in a raw state.

And sorry if this is a digression, but this is UI based so I figured people could come here for their general UI needs.

Hi CW,

Is what you describe exactly what you need, or will forcing the player an examination of an object for the first time be OK instead? If the latter is acceptable, then you can force an examination using the "ActionExamine" function after checking a variable state. The "GetPlayerCurrentTarget" is also useful.

However, you *can* also add some code to the examine.xml to allow a script to fire when the examine is opened, which you can alter as required. I have altered the examine.xml to allow a gui_examine script to fire when used. (By the way, this bit of script simply adds a "0" variable because I use the same script for the creature examine XML as well. You do not have to pass the "0" if the scipt is doing only one thing.) This is how I have changed the top section of the examine.xml code (and placed copy into my campaign directory). I use the "GetPlayerCurrentTarget" function in the gui_examine script to help do what I need next. You will most likely need the same.

Lance.

[nwscript]
<UIScene name="SCREEN_EXAMINE" x=ALIGN_CENTER y=ALIGN_CENTER modal=false width=409 height=600 fadeout="0.3" fadein="0.3" draggable=true backoutkey=true scriptloadable=true
 OnAdd0=UIScene_OnAdd_AddExamineScreen("EXAMINE_NAME_TEXT","EXAMINE_DESCRIPTION_TEXT","IDENTIFY_BUTTON")
 OnAdd1=UIObject_Misc_ExecuteServerScript("gui_examine","0")
 OnRemove=UIScene_OnRemove_RemoveExamineScreen() priority="SCENE_INGAME"/> [/nwscript]

Modifié par Lance Botelle, 27 décembre 2010 - 05:04 .

[Lance Botelle]

Hi All,

After a little trial and error, I am able to make the new targetting system work with existing spell code with one exception: If I cast a spell, the spell will cast (using the ActionCastSpellAtObject after a loop has turned the target hostile), but the spell uses two applications of itself to do so .. once for the targetting and another for the actual spell.

Is there any way to either (a) increment the spell after use? - I do not think this is possible, ( refire the spell casting script with the new parameters acquired with the targetting GUI? (I tried setting the ActionCastSpellAtObject to "cheat" but this stopped other aspects from working.)

Furthermore, does using ActionCastSpellAtObject cause other problems (by using other variables) that original spell casting would not have used?

Thanks.

Lance.

EDIT: Here is the current process:

1) Cast spell ... Spell hook code checks for self target and then brings up new target GUI for new targetting method.

2) When targetting, the "gui_targetscript" stores the target as a variable on caster and then is checked again in the spell hook code, which is executed from this "gui_spelltarget" script. (I added my spell hook script at the end to refire.)

3) Spell hook code now fires again (with new target from 2 above) and still uses spell ID correctly to fire in ActionCastSpellAtObject function within the spell hook code after the target has been turned hostile to the party (only).

PROBLEM: If a PC has 3 magic missiles memorised, they end up losing 2 to make this work, instead of just 1.

Modifié par Lance Botelle, 27 décembre 2010 - 05:40 .

[M. Rieder]

MasterChanger wrote...



I also think it's interesting that you moved the effect on a neutral creature to the on_spell_cast event rather than the spell script itself. Not that there's anything wrong with this, but it might be best to see all the effects of the spell in one spot IMO.

I did this to save time because I wanted to make sure that the script was  actually being applied to the neutral NPC.  That was a quick way to do it.  If I were to use it in a campaign, I would have to monkey with the script to make it work. 

[M. Rieder]

Lance Botelle wrote...

Hi Matt,

Thanks for keeping me in the loop with respect to this. I have read your tutorial and can now understand the approach you are using. The main problem I see, is that this is still a *lot* of work if you want to change all spells to work in this way. It's probably best for the odd spell ... or for somebody who has a lot of patience.

Yes, this system is very scripting intensive and would not be very practical to change all the spells to target friendly or neutral.  Each spell script would have to be modified and that would be alot of work.  If I use this system, I will apply it to only a few spells which seem to need the modification. 

In the back of my mind, I still wonder if there is another way to make this simpler (via spell hooking as well). (Probably just wishful thinking.) As an alternative (and my favourite course of action to date unless I find a better way), I am also considering writing a simple targeting GUI to allow a player to tell the game if they want to consider/turn an NPC hostile from afar. Once hostile, the targeting issue disappears. One could even add an option to change all associated with the targeted NPC hostile, or keep if singular if possible (as others may automatically become hostile anyway).

Spellhooking probably won't work because by the time the script for the spellhook gets called, the targeting cursor has already been created by the game engine.  Spell scripts don't fire until after the player left clicks on the spell icon in the quickspell bar or hotbar.

I really like the idea of the GUI to change an NPC's faction.  Another solution is to add a new spell.  Call it "infuriate" or "provoke" or something like that.  It could be a cantrip or 1st level spell and it could have the effect of irritating someone into becoming hostile toward you, then you could use hostile spells on them.

As others have done, making radial spells out of a few spells is another very good solution.  Doesn't look that hard either. 

[M. Rieder]

I did notice that if a placeable's faction is set to hostile, it does not affect what spells can be cast on it. I wonder if this could be exploited to help solve this problem.

[M. Rieder]

Lance Botelle wrote...

Hi All,

After a little trial and error, I am able to make the new targetting system work with existing spell code with one exception: If I cast a spell, the spell will cast (using the ActionCastSpellAtObject after a loop has turned the target hostile), but the spell uses two applications of itself to do so .. once for the targetting and another for the actual spell.

Is there any way to either (a) increment the spell after use? - I do not think this is possible, ( refire the spell casting script with the new parameters acquired with the targetting GUI? (I tried setting the ActionCastSpellAtObject to "cheat" but this stopped other aspects from working.)

Furthermore, does using ActionCastSpellAtObject cause other problems (by using other variables) that original spell casting would not have used?

Thanks.

Lance.

EDIT: Here is the current process:

1) Cast spell ... Spell hook code checks for self target and then brings up new target GUI for new targetting method.

2) When targetting, the "gui_targetscript" stores the target as a variable on caster and then is checked again in the spell hook code, which is executed from this "gui_spelltarget" script. (I added my spell hook script at the end to refire.)

3) Spell hook code now fires again (with new target from 2 above) and still uses spell ID correctly to fire in ActionCastSpellAtObject function within the spell hook code after the target has been turned hostile to the party (only).

PROBLEM: If a PC has 3 magic missiles memorised, they end up losing 2 to make this work, instead of just 1.

Hi Lance,

I'm not in front of my modding computer right now so I can't test this but have you tried commenting out the code that decrements the spell that the player casts?  I know there is a function whichs is something like "DecrementSpell()" or something like that.  If the spell script uses this and fires twice, that is probably why you are getting the problem.  Just comment out the function in one of the scripts and you should be fine.

So when you say you have it working with existing spell code, does that include all the visual effects and projectiles and everything?  I'm not completely following the process you are using part of the problem is that I have not played around with the spell hook code very much. 

Modifié par M. Rieder, 27 décembre 2010 - 07:59 .

[MasterChanger]

Lance, the problem with using the standard spell-scripts, either by re-firing or puting your code in the spellhook, is that the spell-script will still use GetSpellTargetObject / GetSpellTargetLocation, which are hard-coded functions.

The only way I could see not overriding the original spell script is to use a spellhook to bring up the GUI, and then if you aren't going to use the original script, send FALSE back from the Spellhook to the spell-script*. So, then you could have the regular nw_s0_scare and s0_myscare or whatever.

*Because all spell-scripts have this section at the start:

    if (!X2PreSpellCastCode())
    {
    // If code within the PreSpellCastHook (i.e. UMD) reports FALSE, do not run this spell
        return;
    }

Then you'd make your Spellhook somewhat generic, and look at GetSpellId and the relationship between the caster and the target to determine whether there's an alternate version you'd like to cast.

Modifié par MasterChanger, 27 décembre 2010 - 10:27 .

[Lance Botelle]

Hi All,

I managed to get the spell to use the correct variables by capturing them from the original spell (via spell hooking) and then recalling them after firing the same spell hook code (for a second time) after the gui_spelltarget script fired (after targetting again with the new cursor), which simply fired my spell hook code again recalling the captured variables. I then used these variables (principally the target and the spell ID) in the ActionCastSpellAtObject function which was called from the spell hook code in the second loop.

1) Spell fires and calls my spell hook script. (alb_spellcast)
2) Spell hook script recognises the self target spell (which has been altered in spells.2da) and immediately creates a new GUI target cursor - and finishes the original spell casting. (Invisible to player after altering spells.2da a bit more.)
3) Targeting with the new cursor then fires the gui_spelltarget script that captures the target, saves as a local variable on PC and uses ExecuteScript function at the end of this script to refire the spell hook script. (alb_spellcast)
4) The spell hook script then picks up new target (from local variable recovered from PC) and still recognises the spell id from before. I then use these bits of info to allow caster PC to use ActionCastSpellAtObject function to fire the actual spell at the new target (hostile or friendly) from within the alb_spellcast spell hook code again.
5) The spell now continues as normal because the target is no longer "self" and so bypasses the normal "self" check that would have brought up the new cursor.

The advantages of this method is that it means:

a) No spell scripts would need to be rewritten.
 Only spells that need to be rerouted to start the new targeting GUI need be changed in the spells.2da file.

As only single target hostile spells need rerouting, then this should be sufficient. AoE spells can easily be made to work through spell hooking already as they do not need to target a neutral but a location.

POSSIBLE ALTERNATIVE SOLUTION
=======================

This brought me to another possible solution: Change single target spells into location spells that simply find the nearest creature object to the location target.

However, because I was unable to find a solution to the decrement/increment spell issue (and maybe there isn't any code to fix this), and because this method would still require some more spells.2da editing to ensure VFX and spell animations matched correctly, I decided to work on my GUI to change a creature hostile to allow targeting in the first place.

MY PREFERRED SOLUTION
=================

This turned out to be a lot easier to implement, and I believe, *does* sort the problem rather well (in my opinion). In the end, I edited the examine.xml code a little more (I have already edited it once) and allowed myself a small button that toggles a creature examined into either a "anti-party" or "neutral" faction state. Once done, the NPC continues as normal (no combat with anyone at this time as the faction arrangement ensures they are not enemies of anything at the moment), until the spell is cast at them. Then (as I have it) nearby friends can come to the aid of the victim (if coded) or not. This same button can toggle the faction back to neutral if you change your mind before spell casting them. NB: You cannot toggle permanant hostile creatures back to neutral.

I have also put in some code that prevents the player from making the NPC targetable if the DM wishes to ensure the NPC canot be harmed due to plot reasons.

This method also overcomes any issues with targeting distance, etc. Furthermore, the other feature I have added to the examine window is that it gives a "live update" of NPC distance in the examine window so the player knows if they are within spell range or not. (Updates evey 0.25 seconds.)

Comments welcome. I will also cover this again in my next blog update. (See link below.)

Cheers!

Lance.

M. Rieder wrote...

Hi Lance,

I'm not in front of my modding computer right now so I can't test this but have you tried commenting out the code that decrements the spell that the player casts?  I know there is a function whichs is something like "DecrementSpell()" or something like that. 

Hi Matt,

I have not seen this. Are you sure it is there?

Lance.

Modifié par Lance Botelle, 28 décembre 2010 - 01:36 .

[Lance Botelle]

For those interested,

Can we place script inside boxes anymore?

Here is the approach I was trying originally ....

1) The spellhook script (spell hooking must be enabled) Assumed name: "alb_spellhook_script":

#include "x2_inc_switches"   
void ExecuteTargetingScript(object oPC, string sTargetingScreenName, string sTargetingXml, string sValidTargets, int bHostile, string sScriptName)
{
 DisplayGuiScreen(oPC, sTargetingScreenName, FALSE, sTargetingXml); 
 SetLocalGUIVariable(oPC, sTargetingScreenName, 0, sScriptName); 
 SetLocalGUIVariable(oPC, sTargetingScreenName, 1, sValidTargets);
 string sHostile = (bHostile ? "true" : "false");
 SetLocalGUIVariable(oPC, sTargetingScreenName, 2, sHostile); 
}
void main()  
{  
// MAGIC MISSILE IN 2DA CHANGED TO 0x01 FOR TARGET TYPE & HOSTILE SET TO 0
object oPC = OBJECT_SELF; //CASTER
location lLocation = GetSpellTargetLocation();     
int SpellID = GetSpellId();
// TESTING // TESTING // TESTING // TESTING
int BYPASS = 1;                     // TESTING   
object oTarget = GetLocalObject(oPC, "SPELLTARGET"); DeleteLocalObject(oPC, "SPELLTARGET");  // TESTING
if(oTarget == OBJECT_INVALID){BYPASS = 0; oTarget = GetSpellTargetObject();}     // TESTING
 
   // OPEN NEW TARGET GUI // TESTING // TESTING // TESTING // TESTING // TESTING // TESTING
   if(oTarget == OBJECT_SELF)
   {
   ExecuteTargetingScript(oPC, "SCREEN_TARGETSCRIPT", "targetscript.xml", "self", FALSE, "gui_targetscript"); 
   SetModuleOverrideSpellScriptFinished();
   return; 
   }
    
   SendMessageToPC(OBJECT_SELF, "SPELLID # > " + IntToString(SpellID)); //DEBUG
   SendMessageToPC(OBJECT_SELF, "TARGET > " + GetName(oTarget));   //DEBUG
   
   if(BYPASS == 1)
   {
   object oAnti = GetObjectByTag("SETFACTION_ANTIPARTY"); ChangeFaction(oTarget, oAnti);  
   ActionCastSpellAtObject(SpellID, oTarget); 
   }
   
   // TESTING // TESTING // TESTING // TESTING // TESTING // TESTING // TESTING // TESTING
   
}

2) The gui_targetscript (slightly altered from original):

void main(int objectID, float locationX, float locationY, float locationZ)
{       //alter as needed
 object oPC = GetFirstPC(FALSE);
 object o = IntToObject(objectID);
 SendMessageToPC(oPC, "fired targetscript: " + GetName(o) + " " + FloatToString(locationX) + "," + FloatToString(locationY)+ "," + FloatToString(locationZ));
 
 SetLocalObject(oPC, "SPELLTARGET", o);
 
 ExecuteScript("alb_spellhook_script", oPC);
 
}

3) The targetscript.xml unaltered from the original:

<?xml version="1.0" encoding="utf-8">
<UIScene name="SCREEN_TARGETSCRIPT" x=0 y=0 width=0 height=0 draggable=false fadeout="0.0" fadein="0.0" scriptloadable=true backoutkey=false
OnAdd0=UIObject_Input_ActionTargetScript(local:1,37,39,-1,local:2,local:0,"target:object","target:x","target:y","target:z")
OnAdd1=UIButton_Input_ScreenClose() />

Lance.

Modifié par Lance Botelle, 28 décembre 2010 - 12:46 .

[MasterChanger]

If the Spellhook version works, then that's great; I originall thought the Spellhook would be a better spot to put your modifications than each spell-script.

If you're using ActionCastSpellAtObject to enqueue a second cast, though, you'd probably end up with a spell taking two total rounds (two actions) to cast. You'd probably want to use TRUE for the bInstantSpell parameter to fix that.

As far as decrementing/incrementing the spells, that might be an issue. Spells cast from the spell-book don't use DecrementRemainingSpellUses. Feats that use other feats as maps for their number of uses (Turn Undead/Divine Might, Wildshape/Elephant's Hide) do use DecrementRemainingFeatUses, and there is an Increment version for feats, but not for spells. If there is a way to add daily uses for a spell, I don't know it.

[M. Rieder]

I defer to MasterChanger's reply on the DecrementRemainingSpellUses.



When I ran my test module, I didn't have any problem with losing the spell twice. If the spell is taken out of the spellbook at the engine level, then nothing you do to the spell script should change the number of spells that get used, right? Either the changes you made are somehow telling the engine to fire the spell twice, which I think is unlikely, or there is some other bit of code that gets repeated twice which decrements the spell twice.

lance botelle wrote...





2) Spell hook script recognises the self target spell (which has been altered in spells.2da) and immediately creates a new GUI target cursor - and finishes the original spell casting. (Invisible to player after altering spells.2da a bit more.)

This bit makes it seem that you have fired the spell script twice. Have I understood properly? This could possibly account for the double decrement of the spells memorized. Perhaps if you modified the code to not finish the script if the spellhook script finds that the target is oSelf.



One potential bug is if the caster wants to cast mirror image or some other buff on himself, this may make the spellhook bring up the additional targeting cursor.





One other question: I saw this code in your spellhook:



object oTarget = GetLocalObject(oPC, "SPELLTARGET");



Does this mean that every time a PC casts a spell, the engine stores the target as a local object on the PC with the designation "SPELLTARGET"?



I really like your solution with the button on the examine window. Have you tested it? How do you change the faction to something that the compute will recognize as hostile without causing combat? Is it a custom faction that is only hostile to the PC and no-one else? That would work. I guess the only challenge is that if you had companions, thier AI would attack it. Maybe you would have to change their AI code a bit. Sounds really neat and I'd like to hear more about it. I think that this is the easiest solution I have heard and it comes with the benefit of not having to edit spells.2da!

[Lance Botelle]

M. Rieder wrote...

This bit makes it seem that you have fired the spell script twice. Have I understood properly? This could possibly account for the double decrement of the spells memorized. Perhaps if you modified the code to not finish the script if the spellhook script finds that the target is oSelf.

One potential bug is if the caster wants to cast mirror image or some other buff on himself, this may make the spellhook bring up the additional targeting cursor.

Hi Matt,

This is exactly the problem of the spell firing twice. Unfortunately, I can see no way of returning the lost spell to the PC and is why I abandoned the idea. If this problem could have been solved, then it would have solved a lot of recoding issues.

Spells that naturally cast on the "self" (like Mirror Image) need not have the code altered in the spells.2da and therefore will not change the targeting GUI and would fire as normal. However, there would be an issue if a player was trying to cast a hostile spell on themselves (which I guess would not happen).

M. Rieder wrote...

One other question: I saw this code in your spellhook:

object oTarget = GetLocalObject(oPC, "SPELLTARGET");

Does this mean that every time a PC casts a spell, the engine stores the target as a local object on the PC with the designation "SPELLTARGET"?

Only in circumstances where the 2da has been altered to allow the new GUI targeting cursor to fire. The SPELLTARGET is only filled when the player uses the new targeting GUI cursor. It is immediately emptied after it is used to allow "normal" spells (unmodified in the spells.2da) to work OK.

M. Rieder wrote...

I really like your solution with the button on the examine window. Have you tested it? How do you change the faction to something that the compute will recognize as hostile without causing combat? Is it a custom faction that is only hostile to the PC and no-one else? That would work. I guess the only challenge is that if you had companions, thier AI would attack it. Maybe you would have to change their AI code a bit. Sounds really neat and I'd like to hear more about it. I think that this is the easiest solution I have heard and it comes with the benefit of not having to edit spells.2da!

The examine window system works 100% fine in all testing to date. As it is a fairly "basic" system (not altering too much), then there is not much (nothing?) to go wrong. Yes ... it is a custom faction that is hostile to the PC and nobody else. As for the companions attacking the new hostile, I simply turned off the party AI (and informed the player) when they turn the NPC hostile. This then prevents them from doing anything hasty until the player wants them to.

The system works really well (in my opinion) as it is very easy for the player to both use and understand. The target is not hostile until they deem it to be, and then only after an examine of the NPC, which may be a good idea for the DM anyway. As I say above, the system also allows for the builder to prevent the NPC from being turned hostile if it is a plot critical NPC that must be spoken to first.

I hope to blog about this system in my next blog.

EDIT: BLOG UPDATED: http://worldofalthea.blogspot.com/2010/12/casting-hostile-spells-on-neutrals.html

Lance.

MasterChanger wrote...



If you're using ActionCastSpellAtObject to enqueue a second cast, though, you'd probably end up with a spell taking two total rounds (two actions) to cast. You'd probably want to use TRUE for the bInstantSpell parameter to fix that.

As far as decrementing/incrementing the spells, that might be an issue. Spells cast from the spell-book don't use DecrementRemainingSpellUses. Feats that use other feats as maps for their number of uses (Turn Undead/Divine Might, Wildshape/Elephant's Hide) do use DecrementRemainingFeatUses, and there is an Increment version for feats, but not for spells. If there is a way to add daily uses for a spell, I don't know it.

Hi MasterChanger,

Taking two rounds should be easy enough to fix I imagine (using instant casting), but the spell decrement issue *is* a problem that I cannot see being resolved (probably hard coded).

I prefer the examine approach (see above).

Lance.

Modifié par Lance Botelle, 28 décembre 2010 - 03:56 .

[M. Rieder]

Hi Lance,

The examine window system sounds fantastic and it sounds much easier to implement.  Great work!

Modifié par M. Rieder, 28 décembre 2010 - 04:04 .

[Lance Botelle]

M. Rieder wrote...

Hi Lance,

The examine window system sounds fantastic and it sounds much easier to implement.  Great work!

Hi Matt,

You are welcome to use anything I design .... all I ask is to be given credit for the idea.

Please contact me via email. Do you have it still? I lost yours when I transferred data to a new hard drive and had the wrong email contact backup. Doh! Contacting me that way will allow me to have your email address again, and allow us to send information to each other regarding the system. Send me a PM if you do not have it and I will give it to you there.

Lance.

Modifié par Lance Botelle, 28 décembre 2010 - 04:09 .

[M. Rieder]

Great! Super! Thanks! I'll definitely give you credit.

[MasterChanger]

I've been building a custom quickspell GUI that uses ActionTargetScript. It seems to work ok, except that once I've clicked on a button that choose a certain spelltarget.2da value, all the next clicks seem to choose the same one. I've verified that the proper .XML is being called in each case. Here's the targeting UI:

<?xml version="1.0" encoding="NWN2UI">
<UIScene name="SCREEN_TARGETSCRIPT" x=0 y=0 width=0 height=0 draggable=false fadeout="0.0" fadein="0.0" scriptloadable=true backoutkey=false
    OnAdd0=UIObject_Input_ActionTargetScript(local:1,29,31,1,local:2,local:0,"target:object","target:x","target:y","target:z")
    OnAdd1=UIButton_Input_ScreenClose() />

I have targetscript[1-19].xml called depending on the value retrieved from the spell's TargetingUI column; the filenames match up to the 4th parameter in ActionTargetScript, which determines which UI to call.

So if the first button I click on has row 2: circle_huge, the rest of the buttons will pull up that same UI. Weird!

[M. Rieder]

Have you figured out how to populate the GUI dynamically yet, the way the current quickspell is populated from the spellbook?

[dethia]

Since 2da's are just text files (can be edited with a text editor or excel, it's very easy to change target types in mass, simply do a Replace, replace > xxxx with xxxx

[MasterChanger]

M. Rieder wrote...

Have you figured out how to populate the GUI dynamically yet, the way the current quickspell is populated from the spellbook?

If you take a look this thread on Add/ModifyListBoxRow, that's where I've been talking about populating it. Basically, I'm creating a bunch of listboxes that make up the columns, and adding rows to them as I add spells. I use an OnAdd script for the UIScene.

As to where I get the applicable spells from, it has to do with a custom database for this project. For a default spellcasting system, it might have to be ugly GetSpellKnown loops through the .2da.

dethia wrote...

Since 2da's are just text files (can be
edited with a text editor or excel, it's very easy to change target
types in mass, simply do a Replace, replace > xxxx with xxxx

Thanks for the info, but this isn't relevant to what I'm doing. The TargetingUI values in the .2da are fine. They are retrieved fine by my script, and the script calls the appropriate targeting XML (I put in feedback). It's almost like the GUI isn't being refresh--

Oh, wait a minute. Let me try adding in an idleexpiretime value to the UIScene. That should probably do it.

So, the idleexpiretime definitely was key. Otherwise it doesn't refreshed the UI, I think. Also, I think it helped when I added the number of the UIType onto the name I gave the screen from the DisplayGUIScreen function (now it's "SCREEN_TARGETSCRIPT" + sUIType).

Alas, though, I seem to have run into a potential show-stopper. Though rectangular (wall), point, or circular UI shapes worked fine, any time I've tried cone or bolt shapes (like lightning bolt) NWN2 immediately crashes. Lance B does mention in his UI tutorial that some values for spelltarget rows don't work. If I can't use cone or bolt target shapes, I may have to scrap this effort, which would be kinda ridiculous.

Modifié par MasterChanger, 18 janvier 2011 - 01:11 .

[The Fred]

It seems I've come a little late to this thread so forgive me if I take a little time to catch up. I did read the previous thread about using the GUI to hack into spellcasting, though, and it sounds very powerful.

@Lance,
The spellhook method you outlined above looks to be about right - does it work OK? If the player is casting the spell with all the animation and things first, and then instant-casting it again on a target afterwards, does this mean that a second spell can be queued up whilst the first is being cast, leading to action queue issues?

Also, a quick question about examining in general...

Chaos Wielder wrote...
So, I was looking into checking via the examine UI to see if someone has examined a particular item/creature. Is there a way to do this? I know rudimentary xml, but not enough to make heads or tails of it in a raw state.

I'd thought about doing this myself with much the same method you supplied, but also had the issue of finding the examined object. Does the player's target always match the thing they are examining? I seem to recall that happens for creatures and I think items, but is there an examine button you can use on people and does this set the target too? And does that same GUI fire when things like spells etc are examined?

M. Rieder wrote...
Either the changes you made are somehow telling the engine to fire the spell twice, which I think is unlikely, or there is some other bit of code that gets repeated twice which decrements the spell twice.

It seems to me that since you are casting the spell twice, once normally and then again through ActionCastSpell, you will lose the spell twice. However, that function has a cheat parameter which allows you to ignore that.

I also had the problem with cone-shaped targeting areas, but might it be possible to make custom ones of the same shapes?

[MasterChanger]

Skywing looked over error logs I gave him and said that it doesn't look like cones and bolts/lines are supported from ActionTargetScript. So, don't pass values of 3,4,5,12, or 16 if you don't want crashes! It seems to have something to do with those UI's needing to be associated with a spell.

For my purposes, it may work to approximate the targeting for cones through circles of similar size. For bolts, perhaps a small circle targeted at the end of where the bolt would be. Far from ideal, but perhaps better than nothing.

[MasterChanger]

My next task is to identify what different shapes consider their target location to be and to figure out the implications for substituting targeting UIs for each other. I hypothesize that a wall (rectangle) uses the center of the rectangle, a cone uses the center of its wide arc, and a bolt uses the endpoint of its beam; I know that a circle uses its center.

So, I'm thinking that it might be best to use a very small circular UI for the endpoint of a bolt, and perhaps a rectangle for a cone. The challenge with both of these, since they search for targets in a shape that takes the caster as its origin, is how to correctly apply range. Bolts usually take medium range, so that should be fine, but cones have range from touch to medium. Usually it's the UI that gives them the outer bound of the affected area.