this is an example for a script to track if the player has talked to an NPC. The idea is that after 72 hours the normal dialog checks all reset. this would require MWSE (or MGE since it has internal MWSE). I didn't want to hijack the MCP posts so I put it here and linked to it from the MCP post.



I also put in my 2 cents that this is not necessary for a MCP fix. Seems like it could be remedied with MWSE scripting without too much of a problem. I mean, if you want to run a script on a target without necessarily knowing the object ID of the target it would have to be MWSE, cuz regular vanilla scripting doesn't allow targeted scripts on a variable ID. BUT I don't think you would have to do much and I don't think it would result in a huge FPS hit, either. I'm sure someone can correct this for optimizations, but Something like this running on player:

Begin conversation_keeprlong lookreflong checkrefshort ST_cntl ; control variable for this scriptSetx lookref to xGetPCTargetSetx checkref to lookref->xRefTypeif ( menumode == 1 )	returnendif; check various situations to see if this script should continue processif ( lookref == 0 )        if ( ST_cntl = 2 ) ; this part indicates that you looked away, so reset the ability to run NPC keepr script                       set ST_cntl to 1                       return        endif	set ST_cntl to 0 ;looking at nothing/no target	returnendifset ST_cntl to 1if ( checkref != 1598246990) ; 1598246990 -> is NPC        set ST_cntl to 0        returnendif; verified you are looking at NPC if you got this far in scriptIf ( OnActivate == 0 ) ; to check to make sure you actually TALK to the NPC         return ; this way if you don't it doesn't go on to the remainder of the scriptelse        Activate ; must include to be able to talk to NPCendififx ( ST_cntl )		xSetRef lookref		StartScript, "NPC_keepr"endifend conversation_keepr

and then this should run ONCE and ONCE ONLY on any NPC when you talk to them

Begin NPC_keeprshort has_talkedset has_talked to 1set conversation_keepr.ST_cntl to 2stopscript NPC_keepr; changes control code in other script to 2, so this runs once ; sets the varialbe has_talked on the NPC to 1; then ends and doesn't run again until you look at an NPCEnd NPC_Keepr

ST
ps, since I'm still new at this, I obviously HEAVILY comment my code. Anything this the semicolon in front can be cut out. Also since I'm new at this, there are bound to be ways to change this for even more optimization. go ahead and correct me, cuz I want to learn how to make the code actually run smoother.

How does this fix the Talked to PC dialogue filter condition for existing mods? That's kind of the point of making it an (optional) patch.

Er, I guess it doesn't. What this does is give any NPC a variable that you can test for in dialog testing

ST

It could work. Do variables in variable-targeted scripts get stored properly? It would seem there would be a conflict somewhere if the NPC already had a script.

I haven't read anywhere that there could be only one targetted script on an object or NPC - if you run them from another script. This script is a cut of the one I'm trying to finish for my trap project. It basically does the same thing: run a one time script check on certain objects the player looks at. I thought that a simple short variable wouldn't take much memory; and targeted script variables are local to the object the script is run on, so each NPC would have its own. The only thought I have towards making this better is that you wouldn't get to know everyone in the world by just talking to them ONCE; so you could even put in checks to see how many times you talked to a given NPC but this was supposed to be a simple example of an idea I thought would work - but haven't tried out (again, its a chopped up copy of the trap script which is almost at first release status, but there might be a hidden syntax error I didn't see in writing it up)

ST
edit for clarity

Thing is, do dialogue conditions see all the variables in targetted scripts?

Edit: You should read the http://lovkullen.net/Emma/What_is%20the_72_hours_bug.htm on the bug. It's more than that dialogue condition.

Well I took a look in MWSFD v. 9 and it states this:



I bolded the local variable for that is what is set thru this script: a local variable (local to the NPC). And, in theory; you could define greetings and responses based upon the variable. But, since I'm going off about a script that is theory and I haven't tested I'm going to test this out and get back with you here about it.

ST

keep in mind, targeted scripts (scripts not attached to the actor and started with startscript) CAN NOT have local variables used as dialog conditionals. you will be allowed to make dialog with those locals as conditionals, but they will never return true.

Yeah, I just found this as well:



Oh, well. It was a nice thought.
ST

because so much of my own work is targeted scripts, the way you get around it is transferring the information as a global. for dialog, this is impractical, unless it is for a smallish number of NPCs. you can kind of "cheat it" by using a getdistance to player, but it's a hassle.

If you want to store state on an NPC, you need to use objects.