Well ROFL! Okay then. Guess I misunderstood what the fuction was supposed to do... and thought it was going to incorporate the line of sight. Fixed is good.
@Avenger_teambg How hard would it be to change IVFPD into a bitfield type of function instead?
You mean, adding a bitfield parameter, then cutting it up from
a b c
into
if (p&1) a if (p&2) b if (p&4) c
That's about 15-30 minutes. But i guess, it should rather be a new trigger, because it would break compatibility with old scripts. And then all scripts where it is relevant, one must evaluate one by one, and use the appropriate field. So, changing the engine: 30 minutes. Fixing everything: a year
and several more can be used to set up exactly what the conditions for a talk to fire really are.
This particular call, the way I read it, could be called the "I don't care about conditions I just want the widest range of possible conditions to apply and get the damned NPC dialog to play". That could be because no one had the time originally to go all modder and write out things like
or it could be that diolog-progression in places using IVFPD() was required for plot advancement.
Either way, I'd suggest instead of messing around making IVFPD() actually logical, we leave it as the quick-and-dirty "if there is any remote chance of a suspension of disbelief and the game won't crash if the .dlg is called, play this", and simply help both the new professionals and current/new modders understand that a whole ton of tools are available for conditioning talks, and IVFPD() is really just there as a generic "yeah, play this line if the NPC is in the game and alive".
Most modders and existing mods have found that using @CamDawg's CD_STATE_NOTVALID in negation is the best way to balance the wanted behavior with players. So regardless of what gets done to IVFPD(), most folks are still going to rely on the tried-and-true combination of
@cmorgan i agree that using the individual triggers already provide a way to the scriptor (be it modder or original developer) to do exactly what they want. Yet, there is a need that a single line do the task of 3-5 lines, and on top of that, everyone has a different mental picture what this compact oneliner should do. That's where the programmer says, ok, i give you what you want, just tell me, what EXACTLY you want. Or better yet, i give you all the world in a single bitfield.
Comments
How hard would it be to change IVFPD into a bitfield type of function instead?
a
b
c
into
if (p&1) a
if (p&2) b
if (p&4) c
That's about 15-30 minutes.
But i guess, it should rather be a new trigger, because it would break compatibility with old scripts.
And then all scripts where it is relevant, one must evaluate one by one, and use the appropriate field.
So, changing the engine: 30 minutes.
Fixing everything: a year
See()
Detect()
InParty()
InMyArea()
StateCheck()
AreaCheck()
AreaType()
Range()
HPGT()
HPLT()
InPartyAllowDead()
and several more can be used to set up exactly what the conditions for a talk to fire really are.
This particular call, the way I read it, could be called the "I don't care about conditions I just want the widest range of possible conditions to apply and get the damned NPC dialog to play". That could be because no one had the time originally to go all modder and write out things like
InParty(Myself) InParty("Jaheira") !StateCheck("Jaheira",STATE_DEAF) !StateCheck("Jaheira",STATE_DUMB) !StateCheck("Jaheira",STATE_BLINDMAN) Global("sure_plays_a_mean_pinball","GLOBAL",1) See("Jaheira) Range("Jaheira",30)
or it could be that diolog-progression in places using IVFPD() was required for plot advancement.
Either way, I'd suggest instead of messing around making IVFPD() actually logical, we leave it as the quick-and-dirty "if there is any remote chance of a suspension of disbelief and the game won't crash if the .dlg is called, play this", and simply help both the new professionals and current/new modders understand that a whole ton of tools are available for conditioning talks, and IVFPD() is really just there as a generic "yeah, play this line if the NPC is in the game and alive".
Most modders and existing mods have found that using @CamDawg's CD_STATE_NOTVALID in negation is the best way to balance the wanted behavior with players. So regardless of what gets done to IVFPD(), most folks are still going to rely on the tried-and-true combination of
InParty("mynpcdv") InMyArea("mynpcdv") !StateCheck("mynpcdv",CD_STATE_NOTVALID)
or the related
InParty("mynpcdv") See("mynpcdv") !StateCheck("mynpcdv",CD_STATE_NOTVALID) if the modder feels invisible .cres should not talk.