I was brainstorming a bit. Is there any reason to externalize which familiar the engine chooses for find familiar, and the hardcoded link to the protagonist? Modders can already make "lite" familiars with the
AddFamiliar()
script action, so would externalizing Opcode #192 really help anything?
There is one issue I'm aware of. Adding a summoned creature as a familiar doesn't let them transition between areas correctly. I was wondering if there was any way to make it so regular summoned creatures can serve as familiars and transition between areas normally, without significantly changing the way the creature is summoned (this way, it could easily be patched onto existing summoning spells without causing problems). I suspect this will probably just involve flipping one number with a Lua function.
Apologies for going off topic for a quick question but this seems like a really good place to ask right now..
Would any of you know whether adding a large number of familiars to the game saves has a detrimental effect on game performance?
Alternatively, is there a way to remove familiars from gam files?
I'm thinking of a kit that gets to take permanent control of a creature until it dies and can then get a new creature, meaning I would end up with a really large number of familiars by the end of the game.
I'm thinking of a kit that gets to take permanent control of a creature until it dies and can then get a new creature, meaning I would end up with a really large number of familiars by the end of the game.
The Seducer kit already does something along those lines.
@OlvynChuru
I'm aware of the kit but I wasn't sure how much testing went into it (no offense).
I'm just a little concerned that adding 50+ familiars might impact game performance...
When a wild surge is averted due to the caster's wild surge bonus no string gets displayed (it just says "Wild Surge: <blank/notext>") is there a way to change that?
I'm not sure how the wild surge bonus works. If it is simply added to the wild surge roll and the game still looks at the wild surge table it might already be possible to set a string by extending the wild surge table up to 200, if it somehow just blocks rolls lower than the caster's wild surge bonus, then EEex might be needed to change that?
Edit: Nevermind, I just tested it and it looks like extending the table to 200 does indeed solve the issue.
@Ulb: Familiars shouldn't be too taxing, but it depends a little bit on implementation.
Normal familiars / creatures that are made into "global" familiars, (via a combo of AddFamiliar() and MakeGlobal()), are thrown into the save's GAM file instead of the compressed SAV. The GAM is always loaded into memory when a save is loaded, so the initial load-in of a save will take a bit longer with a ton of global familiars running around.
With 1,000 familiars added to the GAM it takes ~2 seconds longer to load the affected save on my computer. The familiars contribute about ~2MB of data on the hard disk, though quite a bit more in memory. Because they have to be loaded in and accounted for regardless of area, these 1,000 familiars take an extra 110MB in RAM once expanded into the structures the engine uses.
Note that the engine treats global familiars as a special case upon death. The engine, specifically and only in this instance, will turn the familiar back into a normal local creature as it dies. This means that once a global familiar dies it will be removed from the GAM and moved to the ARE, removing any impact it has on performance. So, you don't have to worry about dead familiars clogging up your game.
I've observed no change in active performance / fps with these familiars in the GAM, probably due to their AI being disabled and not actively polled.
If the familiars are added with a simple AddFamiliar(), without becoming global, they act pretty much like an ally - there should be no performance change.
If the familiars are added with a simple AddFamiliar(), without becoming global, they act pretty much like an ally - there should be no performance change.
Are there any other significant differences between a simple AddFamiliar() and the combo AddFamiliar() + MakeGlobal() ? Also, shouldn't the combo include a ChangeEnemyAlly(Myself,FAMILIAR) too? Or does AddFamiliar() take care of that?
// Sample code
IF
True()
THEN
RESPONSE #100
MakeGlobal()
ChangeEnemyAlly(Myself,FAMILIAR) // Useless...?
AddFamiliar()
END
@Luke93
Interesting, now that you mention it I seem to remember wondering why my familiars didn't show up with the proper class UI, back when I made my animal companions mod.
Now I know why.
As for, MakeGlobal()/AddFamiliar(), I always assumed you need MakeGlobal() to enable (master) area transition for familiars?
Here we go again with some more feature requests/suggestions...
1. Would it be possible to suppress the hard coded wild surge graphics for specific rolls?
Specifically, I'd like a way to suppress the graphics for rolls 100+. Not sure what the best way of implementation would be as the opcode is already pretty crowded. Maybe an extra entry in wildmag.2da?
2. Stoneskin (maybe I've ask for this before).. Would it be possible to allow us to suppress the hardcoded visual effect similar to how EEex handles it for wild surges already? It's an old ToBEX feature that Beamdog never implemented despite countless please (not all of them form me :P )
Also, if we could specify which types of damage should be absorbed, that would allow for so many neat things..
Here we go again with some more feature requests/suggestions...
1. Would it be possible to suppress the hard coded wild surge graphics for specific rolls?
Specifically, I'd like a way to suppress the graphics for rolls 100+. Not sure what the best way of implementation would be as the opcode is already pretty crowded. Maybe an extra entry in wildmag.2da?
2. Stoneskin (maybe I've ask for this before).. Would it be possible to allow us to suppress the hardcoded visual effect similar to how EEex handles it for wild surges already? It's an old ToBEX feature that Beamdog never implemented despite countless please (not all of them form me :P )
Also, if we could specify which types of damage should be absorbed, that would allow for so many neat things..
2. Stoneskin (maybe I've ask for this before).. Would it be possible to allow us to suppress the hardcoded visual effect similar to how EEex handles it for wild surges already? It's an old ToBEX feature that Beamdog never implemented despite countless please (not all of them form me :P )
Also, if we could specify which types of damage should be absorbed, that would allow for so many neat things..
This should be possible to do with opcode 403 (Screen Effects). I'll see if I can make a function that does this.
One new function: EXSTONES(originatingEffectData, effectData, creatureData)
Called with opcode 403, this function is a more versatile version of Stoneskin. You can choose which damage types the skins will block, and it doesn't have a hardcoded color change. You can also have it cast a spell whenever one of the skins is removed and/or when the last skin is removed.
I included a spell EXAMPL1.SPL which shows an example of how this function can be used.
I'd like to apologize for my lack of responses lately - I'm currently away. I'll be back and in full force in about a week.
Regarding the familiars, after looking at it closer, AddFamiliar() actually requires the creature to be global; if it isn't, the script action returns without doing anything.
AddFamiliar() also, for some reason, messes with a creature's object type quite destructively. Notes on this behavior:
First things first, there are three places in which the engine keeps track of a sprite's ai-type:
m_typeAI at offset 0x20
m_liveTypeAI at offset 0x349C
m_startTypeAI at offset 0x34B0
The engine, in a very confusing manner, accesses one of these three type objects based on some unknown logic. I have no idea why it chooses one over the others in certain scenarios, but I do know they can end up in different states simultaneously:
m_typeAI is the "normal" field which is accessed most of the time
m_liveTypeAI for lack of a better description, holds the current "temporary" state of the sprite's ai
m_startTypeAI is the "permanent" state of the creature - whatever is held here is written to the save
Now, AddFamiliar() causes the following to happen:
All m_typeAI and m_liveTypeAI fields are zeroed except for EA.
When an effect is applied to the creature / a reload is executed both m_typeAI and m_liveTypeAI are restored to m_startTypeAI, resetting the current ai-type to what it was before.
Due to an odd special case in the engine, m_liveTypeAI's GENERAL field is purposely not restored, leaving it zeroed out. Continuing this oddity, unlike all other ai-type fields, (which are saved from m_startTypeAI), m_liveTypeAI's GENERAL is what is written to disk. The creature's GENERAL is permanently lost after a reload because of this.
Under the above logic I can't find any way to create a familiar via AddFamiliar() without something breaking. Best I can do is this:
The "ADDFAM" spell contains an Opcode #72 (Change AI type) with
Param1 = 3
Timing mode = 1
to make the EA change permanent. It also has the side-effect of getting the engine to restore m_startTypeAI, correcting the creature's ai-type state. Note that everything is fine until reload, which causes the creature's GENERAL to be lost. If the GENERAL is known it can be restored manually, but of course this wouldn't be applicable in a spell's mechanism.
I'll go ahead and fix AddFamiliar() in EEex - all of this craziness is caused by a really small oversight in a script action that the dev's don't even use.
@OlvynChuru: Really awesome work! Great to see that more complex behaviors can be implemented in Lua without requiring additional engine hooks. Merged.
Been working for the past day or two on a wonderful suggestion made by @raizo in my spell menu mod's thread:
1. To be able to know what spells enemies are under, without combing through the dialog box. Something like a pop-up on mouse hover?
Just imagine, 5 cowled enforcers start their contingencies all at once. Then you have to comb through the dialog box to know which spell is whose.
And here's the result, (only made to be proof-of-concept, mind you):
When the player presses LShift Spell-Inspection mode is enabled, which then pops up on hover all the named spells which have put effects on the creature.
Any way to get this working in the current alpha release? Just found this (incredible work, by the way), and I'd love to use this to simplify mage duels.
Pausing the game at the same moment a spell is applied is and has always been broken - it can cause a single spell to use multiple save, magic resistance, and probability rolls, breaking the mechanics of effect application. At it's worst, it can cause every single effect in a spell to use a separate roll.
Is there any way for hijack 'pause game' command, check if spells are applied at this particular moment and if yes, delay actual execution of the 'pause game' command until spells will be applied/saving throws processed?
Is there any way for hijack 'pause game' command, check if spells are applied at this particular moment and if yes, delay actual execution of the 'pause game' command until spells will be applied/saving throws processed?
FWIW, this issue is known to the developers and will hopefully be fixed soon.......
Pausing the game at the same moment a spell is applied is and has always been broken - it can cause a single spell to use multiple save, magic resistance, and probability rolls, breaking the mechanics of effect application. At it's worst, it can cause every single effect in a spell to use a separate roll.
Is there any way for hijack 'pause game' command, check if spells are applied at this particular moment and if yes, delay actual execution of the 'pause game' command until spells will be applied/saving throws processed?
The underlying problem is that the engine, when the game is simultaneously paused + an effect is added, resolves all effects on the creature.
The resolving process rerolls all effect-specific probabilities before it does any resolving. So, if the game is paused while a spell is cast, every effect in that spell will roll its own probabilities, instead of using one unified set.
A simple fix is to stop the engine from resolving whole effects lists in the above scenario. I'm not sure why the engine is doing this in the first place, because it intentionally doesn't do it when time is flowing.
The act of "resolving" an effect is where the engine checks if it is ready to be run / should be terminated. Resolving an effect will either end up running it, transforming its timing mode, or terminating it.
Can anyone think of why the engine would resolve all effects whenever any one effect is added in the above? If a spell has 10+ effects that means the engine would go over the creature's whole effects list *10* times, which strikes me as a bit inefficient. @kjeron ?
I can make a very, very quick fix by disabling the "on add + paused" effects list resolve, but I want to make sure I don't break some very fundamental part of the engine.
Any way to get this working in the current alpha release? Just found this (incredible work, by the way), and I'd love to use this to simplify mage duels.
When I get back into things I'll make a module that has the "spell inspector" functionality.
Can anyone think of why the engine would resolve all effects whenever any one effect is added in the above? If a spell has 10+ effects that means the engine would go over the creature's whole effects list *10* times, which strikes me as a bit inefficient. @kjeron ?
It might be necessary for pausing dialog's, so they can update and check local variables on the creature. Otherwise I have no clue.
Can anyone think of why the engine would resolve all effects whenever any one effect is added in the above? If a spell has 10+ effects that means the engine would go over the creature's whole effects list *10* times, which strikes me as a bit inefficient. @kjeron ?
It might be necessary for pausing dialog's, so they can update and check local variables on the creature. Otherwise I have no clue.
That would be a major fix, actually. Auto-pause: spell cast borks any "immunity/protection from <RESOURCE>" effects if the spell doesn't have a projectile i.e. if you cast Vampiric Touch onto yourself. Local variables are mostly changed directly in the dialogue tree rather than directly via some other spell so I don't see this being an issue.
I've pushed to master a quick fix that should prevent pausing from breaking effect application. From the few tests I've done I don't believe there are any regressions, though it would still be good to get a few more eyes to test things out. If you want to help test the fix, download EEex from here.
I finally have an initial version of EEex_MatchObject up in master. It proved to be much more complicated than I first thought it would.
Notes:
The Action version is the only one currently implemented, though it won't take much time to make trigger / object variants once it's verified that everything works.
Due to a bug in EEex's WeiDU installer the full ACTION.IDS patch isn't executed - please add the following line to the end of your ACTION.IDS manually:
Lua globals: EEex_MatchObjectID -> Lua global that is set to the current actorID before the filter function is executed. EEex_MatchObject -> Lua global that is used as the return value of the filter function.
There are two versions of the action: EEex_MatchObject(S:Function*) => Calls the given Lua chunk to find the nearest creature that satisfies a set of conditions. EEex_MatchObjectEx(S:Function*,I:nNearest,I:range*,I:Flags*EEEX_MAT) => Same as above, with three extra parameters:
nNearest -> The nth nearest creature to return that satisfies the filter function. 0 returns the nearest valid creature, 1 returns the 2nd nearest valid creature, etc.
range -> The range that creatures have to be within to be considered. Multiply desired vanilla range by x32 to get correct parameter value.
Flags -> Bitwise flags that change how the lookup internally operates. Flags defined in EEEX_MAT.IDS:
0x1 IGNOREDEAD_FALSE -> Lookup won't ignore dead creatures.
DEFAULT BEHAVIOR: Lookup ignores dead creatures.
yay, I've been looking forward for the object selector alternative. Thank you very much for fulfilling this request. Say good bye to hardcoded BG class system! (once the object variant is in).
btw. does the non-Ex version of the action use the same filter criteria as object selector loops or maybe we should use Ex to mimic those?
@OlvynChuru: Agreed - the action version was just simpler to do as a proof of concept / main implementation. Thanks for the fix, merged.
@swit: The non-Ex version evaluates as EEex_MatchObjectEx with nNearest, range, and Flags all 0'd out.
I believe I matched how object selectors work with the default behaviors of the Flags param, so using a normal EEex_MatchObject is essentially like using a smart object selector. The internal function I'm calling / hooking is what the engine uses for object selectors, so it should work pretty much the same.
The one difference from object selectors is that my hook forces the engine to consider backlist creatures when searching. Sprites are in the backlist when they are either 1) sleeping or 2) dead, but those two eventualities are ignored by default, (you have to explicitly flag to match them with IGNOREDEAD_FALSE or IGNORESLEEPING_FALSE).
I'll finalize the concept and get trigger / object versions up today, (things might change a bit, so don't go wild with the current implementation yet), ^^
Here's a quick design decision: Should the EEex_MatchObject() trigger fail if it doesn't find an object? This functionality can easily be reproduced by adding an Exists(EEex_MatchObject) after said trigger.
I guess the real question is, would there be any reason for a script block to continue if an object match fails?
Comments
There is one issue I'm aware of. Adding a summoned creature as a familiar doesn't let them transition between areas correctly. I was wondering if there was any way to make it so regular summoned creatures can serve as familiars and transition between areas normally, without significantly changing the way the creature is summoned (this way, it could easily be patched onto existing summoning spells without causing problems). I suspect this will probably just involve flipping one number with a Lua function.
Would any of you know whether adding a large number of familiars to the game saves has a detrimental effect on game performance?
Alternatively, is there a way to remove familiars from gam files?
I'm thinking of a kit that gets to take permanent control of a creature until it dies and can then get a new creature, meaning I would end up with a really large number of familiars by the end of the game.
The Seducer kit already does something along those lines.
I'm aware of the kit but I wasn't sure how much testing went into it (no offense).
I'm just a little concerned that adding 50+ familiars might impact game performance...
@Bubb
Another question/possibly feature request:
When a wild surge is averted due to the caster's wild surge bonus no string gets displayed (it just says "Wild Surge: <blank/notext>") is there a way to change that?
I'm not sure how the wild surge bonus works. If it is simply added to the wild surge roll and the game still looks at the wild surge table it might already be possible to set a string by extending the wild surge table up to 200, if it somehow just blocks rolls lower than the caster's wild surge bonus, then EEex might be needed to change that?
Edit: Nevermind, I just tested it and it looks like extending the table to 200 does indeed solve the issue.
Normal familiars / creatures that are made into "global" familiars, (via a combo of AddFamiliar() and MakeGlobal()), are thrown into the save's GAM file instead of the compressed SAV. The GAM is always loaded into memory when a save is loaded, so the initial load-in of a save will take a bit longer with a ton of global familiars running around.
With 1,000 familiars added to the GAM it takes ~2 seconds longer to load the affected save on my computer. The familiars contribute about ~2MB of data on the hard disk, though quite a bit more in memory. Because they have to be loaded in and accounted for regardless of area, these 1,000 familiars take an extra 110MB in RAM once expanded into the structures the engine uses.
Note that the engine treats global familiars as a special case upon death. The engine, specifically and only in this instance, will turn the familiar back into a normal local creature as it dies. This means that once a global familiar dies it will be removed from the GAM and moved to the ARE, removing any impact it has on performance. So, you don't have to worry about dead familiars clogging up your game.
I've observed no change in active performance / fps with these familiars in the GAM, probably due to their AI being disabled and not actively polled.
If the familiars are added with a simple AddFamiliar(), without becoming global, they act pretty much like an ally - there should be no performance change.
Are there any other significant differences between a simple AddFamiliar() and the combo AddFamiliar() + MakeGlobal() ? Also, shouldn't the combo include a ChangeEnemyAlly(Myself,FAMILIAR) too? Or does AddFamiliar() take care of that?
@Ulb
Beware of this bug when playing with AddFamiliar()...
Interesting, now that you mention it I seem to remember wondering why my familiars didn't show up with the proper class UI, back when I made my animal companions mod.
Now I know why.
As for, MakeGlobal()/AddFamiliar(), I always assumed you need MakeGlobal() to enable (master) area transition for familiars?
Here we go again with some more feature requests/suggestions...
1. Would it be possible to suppress the hard coded wild surge graphics for specific rolls?
Specifically, I'd like a way to suppress the graphics for rolls 100+. Not sure what the best way of implementation would be as the opcode is already pretty crowded. Maybe an extra entry in wildmag.2da?
2. Stoneskin (maybe I've ask for this before).. Would it be possible to allow us to suppress the hardcoded visual effect similar to how EEex handles it for wild surges already? It's an old ToBEX feature that Beamdog never implemented despite countless please (not all of them form me :P )
Also, if we could specify which types of damage should be absorbed, that would allow for so many neat things..
Oh, I'm really liking #2 (especially that "also")
This should be possible to do with opcode 403 (Screen Effects). I'll see if I can make a function that does this.
One new function: EXSTONES(originatingEffectData, effectData, creatureData)
Called with opcode 403, this function is a more versatile version of Stoneskin. You can choose which damage types the skins will block, and it doesn't have a hardcoded color change. You can also have it cast a spell whenever one of the skins is removed and/or when the last skin is removed.
I included a spell EXAMPL1.SPL which shows an example of how this function can be used.
Regarding the familiars, after looking at it closer, AddFamiliar() actually requires the creature to be global; if it isn't, the script action returns without doing anything.
AddFamiliar() also, for some reason, messes with a creature's object type quite destructively. Notes on this behavior:
First things first, there are three places in which the engine keeps track of a sprite's ai-type:
The engine, in a very confusing manner, accesses one of these three type objects based on some unknown logic. I have no idea why it chooses one over the others in certain scenarios, but I do know they can end up in different states simultaneously:
Now, AddFamiliar() causes the following to happen:
Under the above logic I can't find any way to create a familiar via AddFamiliar() without something breaking. Best I can do is this:
MakeGlobal() ApplySpellRES("ADDFAM",Myself) AddFamiliar()The "ADDFAM" spell contains an Opcode #72 (Change AI type) with
to make the EA change permanent. It also has the side-effect of getting the engine to restore m_startTypeAI, correcting the creature's ai-type state. Note that everything is fine until reload, which causes the creature's GENERAL to be lost. If the GENERAL is known it can be restored manually, but of course this wouldn't be applicable in a spell's mechanism.
I'll go ahead and fix AddFamiliar() in EEex - all of this craziness is caused by a really small oversight in a script action that the dev's don't even use.
@OlvynChuru: Really awesome work! Great to see that more complex behaviors can be implemented in Lua without requiring additional engine hooks. Merged.
Thanks for your detailed explanation, I added it to my bug report.
Also, can you confirm this issue affects RemoveFamiliar() as well?
Thats awesome, thank you!
Any way to get this working in the current alpha release? Just found this (incredible work, by the way), and I'd love to use this to simplify mage duels.
Is there any way for hijack 'pause game' command, check if spells are applied at this particular moment and if yes, delay actual execution of the 'pause game' command until spells will be applied/saving throws processed?
FWIW, this issue is known to the developers and will hopefully be fixed soon.......
The underlying problem is that the engine, when the game is simultaneously paused + an effect is added, resolves all effects on the creature.
The resolving process rerolls all effect-specific probabilities before it does any resolving. So, if the game is paused while a spell is cast, every effect in that spell will roll its own probabilities, instead of using one unified set.
A simple fix is to stop the engine from resolving whole effects lists in the above scenario. I'm not sure why the engine is doing this in the first place, because it intentionally doesn't do it when time is flowing.
The act of "resolving" an effect is where the engine checks if it is ready to be run / should be terminated. Resolving an effect will either end up running it, transforming its timing mode, or terminating it.
Can anyone think of why the engine would resolve all effects whenever any one effect is added in the above? If a spell has 10+ effects that means the engine would go over the creature's whole effects list *10* times, which strikes me as a bit inefficient. @kjeron ?
I can make a very, very quick fix by disabling the "on add + paused" effects list resolve, but I want to make sure I don't break some very fundamental part of the engine.
When I get back into things I'll make a module that has the "spell inspector" functionality.
That would be a major fix, actually. Auto-pause: spell cast borks any "immunity/protection from <RESOURCE>" effects if the spell doesn't have a projectile i.e. if you cast Vampiric Touch onto yourself. Local variables are mostly changed directly in the dialogue tree rather than directly via some other spell so I don't see this being an issue.
Awesome, you're the best. Will be fun to play around with once I've got something to work off, too.
Notes:
Lua globals:
EEex_MatchObjectID -> Lua global that is set to the current actorID before the filter function is executed.
EEex_MatchObject -> Lua global that is used as the return value of the filter function.
There are two versions of the action:
EEex_MatchObject(S:Function*) => Calls the given Lua chunk to find the nearest creature that satisfies a set of conditions.
EEex_MatchObjectEx(S:Function*,I:nNearest,I:range*,I:Flags*EEEX_MAT) => Same as above, with three extra parameters:
nNearest -> The nth nearest creature to return that satisfies the filter function. 0 returns the nearest valid creature, 1 returns the 2nd nearest valid creature, etc.
range -> The range that creatures have to be within to be considered. Multiply desired vanilla range by x32 to get correct parameter value.
Flags -> Bitwise flags that change how the lookup internally operates. Flags defined in EEEX_MAT.IDS:
0x1 IGNOREDEAD_FALSE -> Lookup won't ignore dead creatures.
DEFAULT BEHAVIOR: Lookup ignores dead creatures.
0x2 IGNORESLEEPING_FALSE -> Lookup won't ignore sleeping creatures.
DEFAULT BEHAVIOR: Lookup ignores sleeping creatures.
0x4 SEEINVISIBLE_FALSE -> Lookup won't consider invisible creatures.
DEFAULT BEHAVIOR: Lookup checks if creature can see invisible targets naturally.
0x8 SEEINVISIBLE_TRUE -> Lookup will consider invisible creatures.
DEFAULT BEHAVIOR: Lookup checks if creature can see invisible targets naturally.
0x10 CHECKLOS_FALSE -> Lookup will consider creatures regardless of LOS.
DEFAULT BEHAVIOR: Lookup ensures target is within creature's LOS.
0x20 RANGE_MANUAL -> Range value is being manually supplied via range param.
DEFAULT BEHAVIOR: Lookup uses creature's visual range.
0x40 RANGE_MAX -> Range value is forced to the internal max, effectively disabling it.
DEFAULT BEHAVIOR: Lookup uses creature's visual range.
Example filter function that matches creatures that have a luck value greater than 0:
function B3Match() local luck = EEex_GetActorStat(EEex_MatchObjectID, 32) EEex_MatchObject = luck > 0 endExample script block that attacks the nearest creature with luck > 0:
EEex_MatchObject("B3Match()") Attack(EEex_MatchObject)Example action that finds the 2nd nearest creature within half the default visual range that has a luck value > 0, considering sleeping actors:
EEex_MatchObjectEx("B3Match()",1,224,IGNORESLEEPING_FALSE|RANGE_MANUAL)Any and all testing would be greatly appreciated. This action / hook is very complex, so there are most likely still bugs lurking in the shadows.
I sent you a pull request! I made it so EEex_MatchObjectEx is added to ACTION.IDS automatically.
Also, I think this would be better as a trigger or an object.
btw. does the non-Ex version of the action use the same filter criteria as object selector loops or maybe we should use Ex to mimic those?
@swit: The non-Ex version evaluates as EEex_MatchObjectEx with nNearest, range, and Flags all 0'd out.
I believe I matched how object selectors work with the default behaviors of the Flags param, so using a normal EEex_MatchObject is essentially like using a smart object selector. The internal function I'm calling / hooking is what the engine uses for object selectors, so it should work pretty much the same.
The one difference from object selectors is that my hook forces the engine to consider backlist creatures when searching. Sprites are in the backlist when they are either 1) sleeping or 2) dead, but those two eventualities are ignored by default, (you have to explicitly flag to match them with IGNOREDEAD_FALSE or IGNORESLEEPING_FALSE).
I'll finalize the concept and get trigger / object versions up today, (things might change a bit, so don't go wild with the current implementation yet), ^^
I guess the real question is, would there be any reason for a script block to continue if an object match fails?