88 replies to this topic

[Ascension64]

This hack will group all the new triggers together.

The first hack is that requested:

is it within ToBEX's ability to add a new scripting trigger? if so, it'd be amazing to be able to check a LOCAL on another creature.

Global(S:Name,O:Object,I:Value)

.. After actually thinking about this a bit more, TriggerOverride(O:Object*) would be better if feasible; it evaluates to True (taking up an extra slot in OR()) and makes the next trigger be evaluated on the given target:

My implementation is not quite the same.

-----1000 Expanded Triggers [M]
Enables the use of new triggers

Descriptions
0x4100 NextTriggerObject(O:Object*)
Defines the object that the next trigger will be evaluated in reference to
The trigger itself does not evaluate and does not count as a trigger in an OR() block
If the object cannot be found, the next trigger will evaluate to false

Options:
-0: disabled
-1: enabled

Triggers that do not get a separate switch statement typically evaluate to false, therefore it would not make sense to make the trigger evaluate to true as requested. So I thought it better to not evaluate the trigger at all. It is possible to make the trigger not count as one OR statement, but that will confuse the formatting in modder tools.

Let's have some examples:

IF
  NextTriggerObject("Imoen2")
  Global("IWasKickedOut","LOCALS",0)
  ActionListEmpty()
THEN
...

This trigger block will check the LOCALSIWasKickedOut for "Imoen2" and check whether the active creature containing this script has an empty action list.

IF
  NextTriggerObject(NearestEnemyOf(Myself))
  HasSpell(WIZARD_MAGIC_MISSILE)
THEN
...

This trigger block will check whether the nearest enemy to the active creature containing this script has the Magic Missile spell.

IF
  NextTriggerObject(Myself)
  Range(NearestEnemyOf(Myself),6)
THEN
...

This trigger block has redundancy. First, the active creature is already Myself so you don't need a NextTriggerObject(). Second, Range() already allows specification of an object, so NextTriggerObject() isn't required. However, you can use NextTriggerObject() and Range() to with a different reference object, e.g.

IF
  NextTriggerObject(NearestEnemyOf(Myself))
  Range(NearestMyGroupOfType,6)
THEN
...attack the enemy within 6 of the nearest enemy...

NextTriggerObject() does not cumulate.

IF
  NextTriggerObject(NearestEnemyOf(Myself)
  NextTriggerObject(NearestMyGroupOfType)
  HPLT(Myself,50)
THEN
...

The reference is my nearest friend of the active creature, NOT the enemy's nearest friend.

Finally,

IF
  NextTriggerObject(NearestEnemyOf(Myself)
THEN
...

The default empty trigger block evaluates to FALSE. This trigger block will evaluate to FALSE because NextTriggerObject() does not evaluate.

What needs to be tested is whether such trigger will cause stutter in the active creature beyond that which is normally expected for a normal script. Will upload a test soon.

Edited by Ascension64, 18 February 2011 - 08:03 PM.

[the bigg]

Having this not evaluate is better for readability than having it evaluate to true (and that's what I'd have proposed if I knew that triggers could not evaluate); other than that, is this different from my proposal (and, if so, how)?

After some further thinking, I'd like to propose that this does not take up an OR() slot; that way, I can program WeiDU to (de)compile NextTriggerObject("Imoen") HasSpell(WIZARD_MAGIC_MISSILE) into TriggerOverride("Imoen2",HasSpell(WMM)) (and work correctly with REFACTOR_*_TRIGGER). As for the other tools, they would still (de)compile formally correct scripts, and (if using the TriggerOverride format is too much work) correctly formatting the output is an one-liner.

[Ascension64]

Having this not evaluate is better for readability than having it evaluate to true (and that's what I'd have proposed if I knew that triggers could not evaluate); other than that, is this different from my proposal (and, if so, how)?

No, otherwise it really is the same (except that I've called it a different name just because NI reads all triggers vertically and the name is a little more intuitive than TriggerOverride). If anyone has a better name, shoot. I mean NextTriggerReferenceObject would be more intuitive, but is quite wordy.

After some further thinking, I'd like to propose that this does not take up an OR() slot; that way, I can program WeiDU to (de)compile NextTriggerObject("Imoen") HasSpell(WIZARD_MAGIC_MISSILE) into TriggerOverride("Imoen2",HasSpell(WMM)) (and work correctly with REFACTOR_*_TRIGGER). As for the other tools, they would still (de)compile formally correct scripts, and (if using the TriggerOverride format is too much work) correctly formatting the output is an one-liner.

I will leave this up to debate.
I personally prefer keeping it as an OR() because NI won't format correctly (since it reads vertically).

Edited by Ascension64, 18 February 2011 - 03:30 AM.

[the bigg]

No, otherwise it really is the same (except that I've called it a different name just because NI reads all triggers vertically and the name is a little more intuitive than TriggerOverride). If anyone has a better name, shoot. I mean NextTriggerReferenceObject would be more intuitive, but is quite wordy.

NextTriggerObject is OK for me (the important thing for me is that it should be distinct from TriggerOverride, which will be WeiDU's relevant syntactic sugar).

I will leave this up to debate.
I personally prefer keeping it as an OR() because NI won't format correctly (since it reads vertically).

I'll admit that I'm requesting the option that will result in less work for me; that said, adapting Near Infinity (and DLTCEP) for my scenario is trivial:

--- resource/bcs/Decompiler.java.old    2011-02-18 13:00:46.561786492 +0100
+++ resource/bcs/Decompiler.java        2011-02-18 13:02:30.902307798 +0100
@@ -188,7 +188,9 @@
       if (token.equalsIgnoreCase("TR")) {
         String trigger = decompileTR(st);
         if (orcount > 0) {
-          orcount--;
+          if (trigger.substring(0,19).equalsIgnoreCase("NextTriggerObject(")) {
+               orcount--;
+       }
           code.append(indent);
         }
         else if (trigger.substring(0, 3).equalsIgnoreCase("OR("))

On the flip side, handling properly TriggerOverride() and REFACTOR_*_TRIGGER for 'your' scenario is anything but easy: If I printed OR(3) and found a NextTriggerObject, I'd need to go back and amend that to OR(2) because NextTriggerObject + trigger would be condensed as a single (to the user) trigger.

Edited by the bigg, 18 February 2011 - 04:23 AM.

[Ascension64]

The test release has NextTriggerObject() not count as a trigger in OR().

[the bigg]

The git version of WeiDU can (de)compile TriggerOverride() to hide the NextTriggerObject() complexity. REFACTOR_*_TRIGGER pending.

Question: what happens if a script uses NextTriggerObject("foo") OR(3) (or, equivalently TriggerOverride("foo",OR(3)))? I'm currently having WeiDU refusing to (de)compile such a script, but can allow it if you prefer to enable that construct with a well-defined meaning.

[cmorgan]

Request and recheck for syntax in .d -

myMod.d

IF ~~ c-react_to_lovetalks
 SAY ~I want to mention something about <CHARNAME> and <PRO_HISHER> relationships.~
 + ~InParty("c#ajantis") GlobalGT("c#ajantisromancetalkvariable","GLOBAL",12)~ + ~Yes, I am getting pretty close to Ajantis.~ + c-nextstate
 + ~InParty("solaufein") NextTriggerObject("soulaufein") GlobalGT("soulaufeinlovetalk","LOCALS",12) InParty("yaserina") GlobalGT("yasloveltalks","GLOBAL",5)~ + ~Yes, i am dating two Drow, one male and one female... how is that any of your business?~ + c-nextstate
END

Edited by cmorgan, 18 February 2011 - 06:16 AM.

[the bigg]

Looks correct. That said, I have a question to ask for D files: is it possible to get BG2 to understand the TriggerOverride() syntax in DLG files? Otherwise, I have to make sure that the triggers in DLG files are compiled as NextTriggerObject() (while they currently would use TriggerOverride() like other decompiled BCS portions).
EDIT: WeiDU now correctly uses TriggerOverride() in player-facing and NextTriggerObject in game-facing files, so no need to add strange workarounds in ToBEx.

Moreover, REFACTOR_*_TRIGGER now also understands TriggerOverride (in Git).

Edited by the bigg, 18 February 2011 - 08:15 AM.

[the bigg]

EDIT: duplicate post.

Edited by the bigg, 18 February 2011 - 08:14 AM.

[Ascension64]

Question: what happens if a script uses NextTriggerObject("foo") OR(3) (or, equivalently TriggerOverride("foo",OR(3)))? I'm currently having WeiDU refusing to (de)compile such a script, but can allow it if you prefer to enable that construct with a well-defined meaning.

Well, OR() but not the constitutents of will be evaluated in reference to "foo", which is inconsequential, since OR() itself evaluates to false. So,

IF
  NextTriggerObject("foo")
  OR(2)
    HaveSpell(BAR)
    HaveSpell(ED)
THEN
...Myself has spells BAR and ED...

is NOT equivalent to

IF
  OR(2)
    NextTriggerObject("foo") HaveSpell(BAR)
    NextTriggerObject("foo") HaveSpell(ED)
THEN
..."foo" has spells BAR and ED...

NOR

IF
  OR(2)
    NextTriggerObject("foo") HaveSpell(BAR)
    HaveSpell(ED)
THEN
..."foo" has BAR and Myself has ED...

Request and recheck for syntax in .d -

myMod.d

Looks fine. I did briefly test whether it works in dialogue triggers and it appears to.

EDIT: WeiDU now correctly uses TriggerOverride() in player-facing and NextTriggerObject in game-facing files, so no need to add strange workarounds in ToBEx.

I don't quite get what this means, but anyway, as above my testing showed that the trigger does work as required in dialogue.

Edited by Ascension64, 18 February 2011 - 02:35 PM.

[the bigg]

Well, OR() but not the constitutents of will be evaluated in reference to "foo", which is inconsequential, since OR() itself evaluates to false. So,

IF
  NextTriggerObject("foo")
  OR(2)
    HaveSpell(BAR)
    HaveSpell(ED)
THEN
...Myself has spells BAR and ED...

... would be equivalent to

IF
  OR(2)
    HaveSpell(BAR)
    HaveSpell(ED)
THEN
...Myself has spells BAR and ED...

, correct? If so, I can safely prohibit such a construct in WeiDU (to safeguard against people trying to be smart).

I don't quite get what this means, but anyway, as above my testing showed that the trigger does work as required in dialogue.

By the original time of that post, WeiDU was going to write TriggerOverrde() instead of NextTriggerObject() in DLG files (hence making them not parse correctly). I've since forced DLG files to use NextTriggerObject, so this is a no-action for you.

[Ascension64]

, correct? If so, I can safely prohibit such a construct in WeiDU (to safeguard against people trying to be smart).

Correct.

[the bigg]

Great. The (currently being uploaded) beta version of WeiDU can handle TriggerOverride(), so modders should use that to prototype (rather than using NextObjectTrigger manually).

[Ascension64]

Can they still use NextTriggerObject() if they want to?

[the bigg]

Yes, they can. It's just that I suspect people would find TriggerOverride() easier to read; besides, decompiled (and REFACTOR_*_TRIGGER) files will use TriggerOverride.

[Galactygon]

Does NextTriggerObject() work if the .cre in question does not have it's script running (ie they are stunned, or they SetInterrupt(FALSE))? Just come to think how many uses it would have; it's going to make detectable spells through expanded stats obsolete if we're setting LOCAL variables through opcodes.

-Galactygon

[cmorgan]

And to reconfirm, then;

(checks in dialog against script object, switches object to "soulaufein", reads local, switches back to original object, reads global)
+ ~InParty("solaufein") NextTriggerObject("soulaufein") GlobalGT("soulaufeinlovetalk","LOCALS",12) InParty("yaserina") GlobalGT("yasloveltalks","GLOBAL",5)~ + ~Yes, I am dating two Drow, one male and one female... how is that any of your business?~ + c-nextstate

and
(checks in dialog against script object, switches object to "soulaufein", reads local, switches back to original object, reads global)
+ ~InParty("solaufein") TriggerOverride("soulaufein") GlobalGT("soulaufeinlovetalk","LOCALS",12) InParty("yaserina") GlobalGT("yasloveltalks","GLOBAL",5)~ + ~Yes, I am dating two Drow, one male and one female... how is that any of your business?~ + c-nextstate

and (yes, a stupid convoluted example that is much easier to achieve with GLOBAL usage, but just to check)

in c-aran.bcs

IF
 <<other conditions>>
 OR(2)
 InParty("solaufein")
 InParty("yaserina")
 TriggerOverride("soulaufein")
 GlobalGT("soulaufeinlovetalk","LOCALS",12)
 TriggerOverride("soulaufein")
 GlobalLT("soulaufeinlovetalk","LOCALS",24)
 NextTriggerObject("yaserina")
 GlobalGT("some_local_variable_on_yaserina","LOCALS",4)
THEN
 RESPONSE #100
 OR(2)
 TriggerOverride("soulaufein")
 TriggerOverride("yaserina")
 SetGlobal("c-aran_stores_var_on_sola_and_or_yas_for_a_one-off_talk","LOCALS",1)
 IncrementGlobal("c-aran_stores_var_on_self","LOCALS",1) // different drow insult each time stored on c-aran.cre
END
[code]
I am pretty sure you two just stopped stuff like the last three lines (I am not requesting a change, as this seems a very inefficient way to do it, just seeking to understand the parameters.)


Just to be really, really stupid - does this mean that under ToBEX, area variables are now checkable from other areas? For example, a .cre spawned in fictitious area "YS1002"
[code]
IF 
 See("c-aran")
 TriggerOverride("c-ar01")
 Global("c-aran_quest_variable","C-AR01",4)
 Global("message_from_teldra","YS1002",0)
THEN
RESPONSE #100 
 SetGlobal("message_from_teldra","YS1002",1)
 StarDialogNoSet("c-aran")
END

(what happens when TriggerOverride() or NextTriggerObject() encounters a resource that is not installed?)
(sheesh - too many questions. It would probably be better for me to wait and test.)

Edited by cmorgan, 19 February 2011 - 08:40 AM.

[the bigg]

Galc: dunno, should be tested.

Cmorgan: the syntax is

NextTriggerObject("Solaufein) GlobalGT("soulaufeinlovetalk","LOCALS",12)

or

TriggerOverride("Solaufein",GlobalGT("soulaufeinlovetalk","LOCALS",12))

The former is what is understood by the game, the latter the one I suggest modders to use. And no, I suspect this won't change the readability of area variables from other areas (and area names MUST be six letters long, not five like your example). If the NextTriggerObject() resource is not installed, the trigger evaluates to false .

[Ascension64]

Does NextTriggerObject() work if the .cre in question does not have it's script running (ie they are stunned, or they SetInterrupt(FALSE))? Just come to think how many uses it would have; it's going to make detectable spells through expanded stats obsolete if we're setting LOCAL variables through opcodes.

-Galactygon

Yes it does, because it is working off the active creature's script.

I think (not confirmed) stunned and uninterruptible creatures still check their triggers anyway, but certain actions are not processed.

Triggers simply check things. They don't really change things.

Check just to be sure.

IF
 <<other conditions>>
 OR(2)
 InParty("solaufein")
 InParty("yaserina")
 TriggerOverride("soulaufein")
 GlobalGT("soulaufeinlovetalk","LOCALS",12)
 TriggerOverride("soulaufein")
 GlobalLT("soulaufeinlovetalk","LOCALS",24)
 NextTriggerObject("yaserina")
 GlobalGT("some_local_variable_on_yaserina","LOCALS",4)
THEN
 RESPONSE #100
 OR(2)
 TriggerOverride("soulaufein")
 TriggerOverride("yaserina")
 SetGlobal("c-aran_stores_var_on_sola_and_or_yas_for_a_one-off_talk","LOCALS",1)
 IncrementGlobal("c-aran_stores_var_on_self","LOCALS",1) // different drow insult each time stored on c-aran.cre
END

You've mixed up a few things here. I think you mean:

IF
 <<other conditions>>
 OR(2)
   InParty("solaufein")
   InParty("yaserina")
 NextTriggerObject("soulaufein") GlobalGT("soulaufeinlovetalk","LOCALS",12) --> or TriggerOverride("solaufein", GlobalGT("solaufeinlovetalk","LOCALS",12)
 NextTriggerObject("soulaufein") GlobalLT("soulaufeinlovetalk","LOCALS",24) --> or TriggerOverride("solaufein", GlobalLT("solaufeinlovetalk","LOCALS",24)
 NextTriggerObject("yaserina") GlobalGT("some_local_variable_on_yaserina","LOCALS",4) --> or (TriggerOverride("yaserina", GlobalGT("some_local_variable_on_yaserina","LOCALS",4)
THEN
 RESPONSE #100
 ActionOverride("soulaufein", SetGlobal("c-aran_stores_var_on_sola_and_or_yas_for_a_one-off_talk","LOCALS",1))
 ActionOverride("yaserina", SetGlobal("c-aran_stores_var_on_sola_and_or_yas_for_a_one-off_talk","LOCALS",1))
END

Now you can't put triggers in a response, so it is probably better to keep these blocks separate for solau and yase if you want to set the appropriate local.
Also, if you script with NearInfinity, NI does not recognise TriggerOverride(<object>, YourTrigger()), so you have to use NextTriggerObject(<object>) YourTrigger() in two lines.
Only compiling BAF with WeiDU will recognise the former.

Areas variables from other areas...

False, you are just changing the reference object, so it won't affect how area variables are checked. That does pose an interesting thought, on how you might NextTriggerObject(<some area>) or NextTriggerObject(<baldur object>). I don't think this is possible.

Edited by Ascension64, 19 February 2011 - 03:24 PM.

[cmorgan]

Cool - I only work in WeiDU (or DLTCEP using WeiDU) to create/compile .baf and .d, but I troubleshoot/quickread the same resources in NI, so you just saved me poking with several more questions! (I will check my area names in examples too to make sure they are 6 letters).

I think I have it. For a more readable series of examples,

Reading LOCALS on another creature after ToBEX is in use (with incredibly long bogus never_use_extremely-long_variable_names) :

in c-aran25.baf

IF
 TriggerOverride("Anomen",Global("ExpLoveTalk","LOCALS",4)) // will fail if Anomen is not in the party or not valid, so no need for any other checks
 Global("c-aran_check_lovetalk_progression_on_cre","LOCALS",0)
THEN
 RESPONSE #100
 SetGlobal("c-aran_check_lovetalk_progression_on_cre","LOCALS",1)
 SetGlobalTimer("c-aran_comments","GLOBAL",TEN_MINUTES)
END
IF
 GlobalTimerExpired("c-aran_comments","GLOBAL") // 10 in-game minutes time
 Global("c-aran_check_lovetalk_progression_on_cre","LOCALS",1)
THEN
 RESPONSE #100
 StartDialogNoSet(Player1)
END

related c-arn25j.d

IF ~Global("c-aran_check_lovetalk_progression_on_cre","LOCALS",1)~ THEN BEGIN c-aran_whines
 SAY ~[ARAN] You fell for that wholething? 'your beauty and wisdom are ever shining, an eternal flame for those who would walk at your side'? Cyric's rump, wi' that load o' crap, it be a wonder you don't vomit.~
 ++ ~[PC] I liked it.~ DO ~ActionOverride("Anomen",IncrementGlobal("c-aran_irritates_anomen","LOCALS",1)) SetGlobal("c-aran_check_lovetalk_progression_on_cre","LOCALS",2)
~ + newstate

with the operating changes being that the currently failing ability to set LOCALS using AO
ActionOverride("Anomen",IncrementGlobal("c-aran_irritates_anomen","LOCALS",1))
and the new ability to read LOCALS
TriggerOverride("Anomen",Global("ExpLoveTalk","LOCALS",4))

would both be available.

Edited by cmorgan, 19 February 2011 - 04:21 PM.