Fallout New Vegas GECK & Scripting Help 101

[prideslayer]

I'm basically lost, having trouble understanding really what the problem is.

 

If as AJ said it is really this simple

so if I understood well, you are spamming a dialogue package every 0.05 seconds, so you are sure that the ref will talk, then inside the dialogue itself you set a variable so that the quest script will stop spamming the addscriptpackage?

To which you said

 

Exactly! That's what I should have said from the very beginning.

I don't see the problem? You said you're worried about something crashing, and maybe the dialog result script not running? Why not use the script in the package end instead then?

 

Regardless the answer is not to just keep reducing the script delay, that isn't reliable.. it'll make slow/struggling computers slower, and won't fix the issues on fast ones.

[Guest tomm434]

The problem is I don't want to use any dialogue script. Not that I want to use Package result script because it failed me many time in Quest Overhaul and in this mod too. But "OnPackageEnd" block might work(at least it never failed me). It's the fact that it is a still one time script that troubles my mind. And also that I have to make about 30(more in the future) blocks in NPC's object script.

[prideslayer]

Ok first, to be honest, I've never had the problems you're describing. Unless there are errors in the script itself, I've never had a "one time" script fail to run, no matter how complex, and no matter how many of them I have. I think if you've experienced that, you probably have bugs in your scripts also.

 

That said, your problem then is moving this out of the dialog result script means now you don't have anywhere good to put it, because you don't know if the dialog took place or not? Welcome to hell! I suggest you just set ONE var there, it can be a quest var, an NX var, whatever, and do nothing else.

 

There is no way that is going to be unreliable. If anything screws you up but the dialog has happened successfully, it's going to be because either:

 

1. You made a typo or something in the result script.

2. Some other script RESET your variable back to its default value, so it only looks like it didn't run.

 

You can watch for either of these by putting a DebugPrint inside the dialog script in question, before and after setting the variable.

 

DebugPrint "Setting..."
set somequest.somevar to 1
DebugPrint "Set."

Keep in mind that if you change the order of the variables in your quest, you need to recompile every script referencing those variables, including dialog result scripts.

 

So "don't do that." Once you've put a variable in a quest and started using it elsewhere, you must never add or remove any variables that come before it.

[Guest tomm434]

I believe you . But any thoughts on how to evade double "addscriptpackage MyDialoguePackage" ? Now I use the exact method you described(setting stage to 0 in dialogue script(start)) and yet I had one issue when Dialogue was added twice.  I'm sure it wasn't a script error because all of them use the same system.

 

1) Stage is set to 1 - add dialogue every 0.05 sec

2) In dialogue script (start) set stage to 0

3) Quest ends.

 

My theory is that script just stopped checking line after "if stage ==1" and after dialogue resumed there -  and added package again

 

So, increasing quest delay to 0.1-0.3 might minimize the chance of this repeating Less checks - less chance of mistake. (or not - I didn't understand that post).

 

Regardless the answer is not to just keep reducing the script delay, that isn't reliable.. it'll make slow/struggling computers slower, and won't fix the issues on fast ones.

 

[Guest]

what I don't get is... now, you have a conditional statement which contains an addscriptpackage. The conditional statement will be executed only if the variable is true, but the variable will go false when you addscriptpackage. So, why the game should add two script packages in a row?

 

my theory is it's not AddScriptPackage which is triggered twice, but it's the dialogue itself that happens twice, like if it doesn't drop it after the Goodbye topic. Just because I often had this issue with dialogue packages

[Guest tomm434]

my  theory is it's not AddScriptPackage which is triggered twice, but it's the dialogue itself that happens twice, like if it doesn't drop it after the Goodbye topic. Just because I often had this issue with dialogue packages

 

That's interesting - I've never ever ever had this bug and I've added a lot of dialogue packages during my modding days All of them were added once of course. You sure that was the issue?

 

 

what I don't get is... now, you have a conditional statement which contains an addscriptpackage. The conditional statement will be executed only if the variable is true, but the variable will go false when you addscriptpackage. So, why the game should add two script packages in a row?

So script runs from up to down. Usually when I do a script like this and dialogue starts next frame (range of 900)

NPCRef.Addscriptpackage MyDialogue
PrintC "Executed"

 the line "executed" only appears after dialogue is exited. So script stops at the exact line it was before game went into menumode and continues where it left off after menumode ends. But if somehow dialogue is not executed next frame - player is far from NPC or she had a package earlier so I had to remove it first etc. and script might get past "if stage ==1" line and then menumode happens! So after menumode ends - package is added twice. Now if I can make quest script "return" itself from Dialogue - that might solve the issue. But I can't.

 

 

[Guest]

I get what you mean. So the question would be "how you set that variable during the dialogue". If you use a Begin Package Script, I think it first sets the variable and then it executes the dialogue package. If you use a end script, prolly it jumps some frame after the Goodbye and you have this issue from time to time.

 

And about my issue, no it wasn't "exactly" that issue. The real issue was that EVP wasn't re-evaluating before the dialogue was triggered a second time, while ResetAI was instantly. We could say that EVP was slower than the package itself, in some ways. So you could question yourself if the package really drops when you have a Goodbye topic, that's an answer I really don't have. I can only say "ok, some things are faster than others"

 

Oh, by the way, about the fact you never had that bug. It happens on vanilla too. It's rare fortunally, but it happens.

 

EDIT:

sorry but... I would like to point you this:

" the line "executed" only appears after dialogue is exited. So script stops at the exact line it was before game went into menumode and continues where it left off after menumode ends. But if somehow dialogue is not executed next frame - player is far from NPC or she had a package earlier so I had to remove it first etc. and script might get past "if stage ==1" line and then menumode happens! So after menumode ends - package is added twice. Now if I can make quest script "return" itself from Dialogue - that might solve the issue. But I can't."

 

So, let's say you spam addscript package, the npc is far so it starts approaching you, ok? in the meantime, the script continues spamming addscriptpackage, which drops the previous one exactly when it finds a second addscriptpackage. So, the only way to trigger it twice, would mean your npc takes a certain amount of time EXACTLY equals to the script to loop x times and STOP EXACTLY BETWEEN THE IF STAGE STATEMENT AND THE NEXT LINE ADDSCRIPTPACKAGE?!?!?!?! now that would be really like throwing a ball on a roulette with some millions of numbers... are you sure THIS could really happen in your tests, or there could be something else?

[prideslayer]

Woah...

 

This...

the line "executed" only appears after dialogue is exited. So script stops at the exact line it was before game went into menumode and continues where it left off after menumode ends.

Is not at all reliable in my experience.

 

There is no guarantee that the dialog/menumode is going to start immediately upon executing that line. Any number of things could delay it, from distance to the NPC, to general lag on the players computer at just the wrong moment. There is also no guarantee that the script will pick up on the line where it left off -- this almost never happens in fact. Usually it starts over from the top.

 

Since these things aren't guaranteed, what I do when writing scripts like this, is not just assume the "bad thing" is going to happen -- but force it to happen every time.

 

I am almost 100% certain that is what is to blame here -- assuming that it picks up where it left off, when that is not always the case. Add that super-hyper-fast repeat rate and it's a recipe for disaster.

 

Try something like this (gamemode).

if (0 < fDelay)
  ; delay and return
  set fDelay to fDelay - GetSecondsPassed
  return
endif

if (0 == stage)
  ; placeholder, not doing anything, you may not need.
elseif (1 == stage)
  ; Adding package, waiting on dialog to clear the flag
  set fDelay to 0.5
  NPCRef.Addscriptpackage MyDialogue
elseif (2 == stage)
  ; The dialog could have set it to this, or to 0, or whatever.
endif

That is just a basic structure but I hope you get the idea.

[t3589]

Forgive me if I misunderstand.  But why not just lock the addscriptpackage with getiscurrentpackage after it executes?

[ArgusSCCT]

I need a little help figuring out base effects. Ok, so like I mentioned before, this mod I work with used to equip objects to cause a player effect, it created its own base effects, such as a speed reduction effect, tagged as script in its archetype but it had no script assigned to it. While it did work before, the base effect doesn't work anymore when being applied within an actor effect. I changed its archetype from script to ValueModifier, but that really didn't do anything. I checked the wiki but I'm not sure I'm understanding how it all works. What determines what the base effect does? All I see are some check boxes to decide how it behaves.

 

To be frank, effects have been the most confusing of things that I've had to deal with in GECK. Maybe I missed something when going from an Object Effect to an Actor Effect. 

[Guest tomm434]

So, let's say you spam addscript package, the npc is far so it starts approaching you, ok? in the meantime, the script continues spamming addscriptpackage, which drops the previous one exactly when it finds a second addscriptpackage. So, the only way to trigger it twice, would mean your npc takes a certain amount of time EXACTLY equals to the script to loop x times and STOP EXACTLY BETWEEN THE IF STAGE STATEMENT AND THE NEXT LINE ADDSCRIPTPACKAGE?!?!?!?! now that would be really like throwing a ball on a roulette with some millions of numbers... are you sure THIS could really happen in your tests, or there could be something else?

I'll tell you more - my script was like this when that happened.

If LunetteRef.GetCurrentAIProcedure !=43 ; to evade cases when she has package but standing in place
PrintC "Remove Conversational Package"
LunetteRef.removescriptpackage ConversationPackage
endif


if GetType ConversationPackage ==73 && LunetteRef.isFollowing ==1
LunetteRef.addscriptpackage ConversationPackage
return
endif

So engine somehow passed GetType condition. Pridelslayer didn't comment on that(is it possible for gamemengine checking something wrong because something just changed the frame earlier?). I remember you complainging about spell script which run every frame and could spawn a lot of player clones for n times because in next frame game "if MyRef.isActor" still returns 0. Now,  I set this packahe to Cell in dialogue start script to evade some issues .It is just a package, not a clone but  I don't know why that happened. That's why I created another nest of gettype - to minimize the chance of it repeating. ANd script has delay of 0.05. So chances can be high(it didn't happened with 5 sec quest delay, right? Now that would be a miracle)

 

Considering what you said about bug when dialogue starts twice- my stage here now is "Rejection". I just can't accept it. I mean  - what's the point in doing any mods then when something like this can happen? What if this happens for some very important story dialogue which an only happen once? I admit that most of the time I played Vegas I did it on Xbox 360 but even when playing on PC I didn't experience something like that.

 

Anyway, what's more likely - this bug to happen or gameengine checking type of package wrong? I have no idea.

 

t3589, I use that trick temporarily in cutscenes where NPCs are staing close to player and there is no chance for dialogue no happening next frame(I ResetAI on actors just before giving them dialogue.)

is stage ==4
   if timer >=10
    IbsenRef.addscriptpackage Dialoguepackage
    let timer :=0
    let stage :=5
   endif

elseif stage ==5

if IbsenRef.GetISCurrentAIPackage Dialoguepackage !=1 && timer >=1
let stage 6
etc
endif

So there package is added only once and then I check of it executed. Still unreliable but if package is not added somehow, scene will progress... Yeah. this will be bad if some actor doesn't say some line but it's better that having scene && game && companion stuck. Now I can't do this in my script because I don't know the distance Lunette will be from player + I don't know if player is going to travel between cells and package will be deletd(even dialogue packages with "Must Complete" are cleared when NPC enters differenc cell)

 

In case that we are talking about GetIisCurrentPackage won't help because it would still require dialogue script to set next stage which doesn't guarantee that  script from earlier stage doesn't executes twice. Also this can be called unreliable because sometime dialogue package is not removed after dialogue is done - NPC just stands there as usual and doesn't talk but if I giver her ther same package (to say another response in the same topic), it won't be added because she already have the same package. But her currentAI procedure will still be 0 or 17(Done state). That's why I check for that in my script above and the one I uploaded in the previous page.

 

Also that happens when NPC was added a script package and then another NPC starts conversation with Player first. I got that issue when NCR soldier who giver player the radio entered Red Lucy room and broke the whole scene. Also if you want to see something scripted bad in vanilla NW look for RedLucy sex trigger - whole scene is mantained by the duct tape and good wish. . On the other hand all scripts I met made by Jorge Sawyer are good-written.

 

 

 

Prideslayer, I understand. After I add first package in 90% cases Lunette will be standing close to player and dialogue will be executed next frame.

For another 10% when she far away(behind the corner) or if player uses "sprint" button from project Nevada - I may still run into that issue with a small chance(much smaller than now of course). I'll increase quest delay to 0.2 then. Overall time between entering trigger and dialogue package added will be half a second. Then check time will be 0.2 + quest delay(1.8).  

 

Thanks everyone.

 

 

[t3589]

Not for nothin', but I've found dialog packages to be fairly wonky as well.  Now I just use packages for location, and trigger startconvo on X package end.  I've also noticed that much of the time startconvo follows you through cell transitions.  ie. NPC gets startconvo in one cell, Player leaves cell, NPC follows Player and initiates dialog in the new cell.  Granted this was never intentional on my part, so I'm not sure how reliable it is at continuing after the cell transition.

 

Another idea that I've used successfully in the past (but hated it the whole time), was use one package to get them to the desired location, and then on THAT package end trigger a dialog package.  It seems redundant, but for the instance I was using it, the dialog package ran without hesitation (a chase scene), while startconvo hesitated in such a way as to prolong the chase.

 

ie. Travel package to chase player, get within range, trigger startconvo on end, the NPC would stop to engage dialog which allowed the PC to keep running and escape before the dialog ran.  Changing startconvo in this sequence to trigger a dialog package instead seemed to remedy the situation (almost instant), and the player was caught.

 

EDIT: You know, now that I think about it.  I could be remembering that in reverse.

Edited August 7, 2014 by t3589

[Guest tomm434]

That's interesting. Very. I'll think about it. Thanks you too.

[Guest]

The case of my spell with placeatme, was somewhat different. My placeatme was allowing more instances of itself, it was creating new instances of the ref at every execution. Your AddScriptPackage shouldn't, because every AddScriptPackage should drop the previous one.

 

I feel your pain, Tomm, that doesn't seem a nice situation to handle and I can get you want full reliability or it wouldn't make sense. All I can suggest is to think the script in a different way to workaround the whole situation.

 

For example, while you can have something slow (=needs more frames to work properly), setting a variable to control a stage is instantaneous (IF you set it on top, you know). So I really feel confortable in locking/executing scripts with stages and conditions based on variables values.

 

An example of workaround, maybe... if that package has a condition IsBusy = 0 (inside the AI Package window), and the package itself sets IsBusy to 1 when it will be executed, if the main script will run another AddScriptPackage again I think it will drop automatically since the condition is not true.

 

Can't say I tried it, I never use package conditions on AddScriptPackages because they run only in specific "special events", so I know exactly when they must be triggered and they don't need extra conditions. Anyway maybe this is something you could try, to see if it helps you to avoid a double execution.

[Guest tomm434]

Thanks for the sympathy.

 

NPC will pick up any package you give him via "addscriptpackage" no matter what conditions are. Moreover package will not be dropped if conditions become false(never tried it without unticking "must complete" of course, maybe then it will be dropped ). Also I didn't understand what you meant about setting variable just after condition. I remember our talk loing time ago in this thread where you advised to use this system

if stage ==3
let stage :=4
{ remaining code}
endif

But how can I use this here? All I know is that I need to constantly check if package is executing before it has.

 

 

Meanwhile I'm thinking about moving "is stage ==1" in top of the script so game checks "if stage==1" first and only then "if stage ==0". with quest delay of 0.2 I can be sure that when "if stage" line is checked, there is no other check coming from the top of the script(only if computer is too slow or game lags at the exact moment). Even if there is, it will be stopped by our artificial quest delay which is 2 secs. Also I can quicken stage check by removing "==1" from conditions since there is only 2 stages.

[Guest]

yes I was exactly meaning that, putting that let stage just after the condition.

 

In your case, since you said your package sets the IsBusy variable, I asked you how you set it inside the package, if in the End script or in the Start script, I think this could make difference (like when you put that let stage := 4 at top or at bottom of a script)

 

you're right addscriptpackage ignores conditions, I never tried it so I wanted to give a shot. I didn't flag must complete, even because I use that only for travel packages, so I guess it doesn't influence it. It was ignoring my false condition, so that's not a solution.

 

now I'm thinking, Lunette is supposed to follow you when she's triggering this dialogue, right? because I guess you already used conditions like IsInCombat, to avoid that extra events happen in combat.

 

If it's the case, what about this:

 

if LunetteRef.GetCurrentAIPackage == 1 >>> if lunette is executing a follow package

    ; spam the addscriptpackage Dialogue

 

I used that sometimes and it seemed working well, never had weird results

 

----

Note: while 5 minutes ago I was testing the addscriptpackage, I was doing it in game, by console. The npc was sandboxing. In 3 cases (of...6? I mean it was a good percentage) I had to trigger it TWICE, because the first one was skipped. The problem was in the activation range of the package itself, it was too high, lowering it solved and the next 6-7 attempts never failed.

I still think packages are reliable, they only need to be used correctly, and for "correctly" I don't mean in a rational way, I more mean they all have their own tricks to know. I had very bad times with the packages in the past, everytime I was spending a week to bang my head against the monitor because they weren't acting correctly. Then, usually, when I was completely lost, Astymma simply was answering me "flag this / do that" and it was magically working, perfectly. It's like T said, they act strange sometimes, but I still think there are tricks that experienced modders can share to make them work well.

[prideslayer]

I'll tell you more - my script was like this when that happened.

01: If LunetteRef.GetCurrentAIProcedure !=43 ; to evade cases when she has package but standing in place
02:   PrintC "Remove Conversational Package"
03:   LunetteRef.removescriptpackage ConversationPackage
04: endif
05: 
06: if GetType ConversationPackage ==73 && LunetteRef.isFollowing ==1
07:   LunetteRef.addscriptpackage ConversationPackage
08:   return
09: endif

So engine somehow passed GetType condition. Pridelslayer didn't comment on that(is it possible for gamemengine checking something wrong because something just changed the frame earlier?).

 

I didn't understand what you meant before, and what you've mentioned so far seems overly complicated; I was under the impression that you have removed all of this and "started over" testing with a simplified approach.

 

If you want me to take a look anyway..

 

If this is just working from memory but not an actual copy/paste then some of this may be incorrect if you remembered incorrectly, that definitely makes things more difficult. I added line #s for reference and indented for easier reading.

 

1. Line 6 should have a "LunetteRef.GetType" shouldn't it? Is this just you remembering wrong, or is this script running on a different reference? nevermind.

 

2. The check on line 1 does not make much sense to me, what's the purpose? You're removing the entire package if the current procedure (a package can have more than one procedure) is not a dialog activation. That means you're removing the package if it's running a travel procedure (to get close enough to the target) to start the conversation. There also will probably be a wait procedure between the travel and dialog, if the target is busy. Overall this chunk (lines 1 - 4) seems like a bad idea.

 

3. The first half of line 6 makes no sense. If "ConversationPackage" is a package, then that first check is always going to be true. This means that whole line is really just:

 

06: if LunetteRef.isFollowing ==1
07:   LunetteRef.addscriptpackage ConversationPackage
08:   return
09: endif

Is that really what you want to do? Keep adding the package over and over if the actor is following? Then you remove it again in the next run (0.05s later or whatever?) if the procedure isn't dialog (e.g. travel, wait, etc) within that package?

[prideslayer]

Just stabbing in the dark but about that first check again, running a dialogue package the procedure could be any of:

 

0 - Travel

3 - Wait

4 - Dialogue

11 - Follow

19 - Travel to target

27 - Accompany

43 - Dialog activate

49 - Movement blocked

 

And probably some others as well.

 

Again this whole system just seems vastly overcomplicated for what you're trying to do. Personally, I would abandon this approach and rethink it, simplify.

[prideslayer]

If you really want to use the packages like this, I would do as already suggested, basicaly:

 

1. Create a travelpackage. In the package done script, set stage to 2.

2. Create a dialogepackage. In the package done script, set stage to 3.

 

The main script (with a much less aggressive script delay! Call it 0.5s or even 1.0s):

1. If stage 0, do nothing.

2. If stage 1, check the current package. If it's not the travel package, remove it, add travel.

3. If stage 2, check the current package. If not dialog package, remove it, add dialog.

4. If stage 3, do your post-dialog whatever, set stage back to zero.

 

To start everything in motion, all you need to do is set the stage to 1. The script will then handle adding the travel package and everything from then on is automatic. You need to ensure that you only set the stage to 1 when it's 0.

 

No "fast" script, no looking at the AI procedure or any of that. Test it this way and make sure it works most of the time, if not all the time, and if it fails.. report back in.

[Guest tomm434]

no, that was the exact script I had.

 

Her AI procedure is 43 all the way. She just ran across whole goodsrpings after player(with speed mult of 30) with AI procedure of 43. And I do it because if she got her package and someone spoke to the player frame after(like ranger in Lucy's room ) - she is still having the package and just stands in place. Even ResetAI doesn't help - only deletion of the package.

 

I check Conversation package to be Conv package just in case somehow stage 1 will be set by mistake and to additionally check if dialogue happened.

Newer version of the script is here

  If LunetteRef.GetCurrentAIProcedure !=43 ; to evade cases when she has package but standing in place
    PrintC "Remove Conversational Package"
    LunetteRef.removescriptpackage ConversationPackage
  endif

 If GetType ConversationPackage !=73 ; Package is set to cell when quest is reset.
  let stage :=0
  return
 endif
   

  if GetType ConversationPackage ==73 && LunetteRef.isFollowing ==1
    if GetType ConversationPackage ==73 ; failsafe!!! ; Only think I could thinkg of is to doublecheck the package
      LunetteRef.addscriptpackage ConversationPackage
      return
    endif
  endif

So when dialogue starts the package is set to a cell. That's why even if script is stopped after "stage==1" it should not execute anyway. But it did .

 

 

About script you proposed - I need constantly check her for having packages. I had one case when she was looking to start conversation with player and then I entered another cell and she lost the package(though it was "MustbeDone" type of dialogue package) so I can tell you now  - that would fail someone sometimes. I can't make player "care" about when travelling with her - move slowly in case she has package active. That would be stupid to play with a companion like that

 

So now I'll stick with lowering set delay and optimizing they way game engine has to "stage ==1" condition like moving it to the top and making it a boolean(so I can check for "if stage") which is slightly faster - and making artificial quest delay just like you said.

[prideslayer]

Well, I still think this sounds very overcomplicated for what you're trying to do. Other companions and lots of other mods do similar things without so many problems or such "crazy" ways if fighting back against those problems. I think there is a mistake (or incorrect assumption) somewhere in here that is screwing everything else up, but the only way I can think to find it is to "start over" with the packages and take it slow and simple.

 

This may sound harsh, but that "double check the package" is gibberish. There's no way it's going to have any effect, it's impossible for that value to change right there between those lines unless you've done something really foolish like install one of those script engine multi-threading mods/tweaks. By default, NV only uses one thread for all script processing, and it's that way for a reason.

[Guest tomm434]

I'm only learning you know so no offence taken. Thanks for your help!

 

A.J. I'll check it.

[DoctaSax]

So apparently ListClear works now? Or does it?

Just had me a quick test & it seems to do as it's told.

 

[Guest]

 

I had one case when she was looking to start conversation with player and then I entered another cell and she lost the package(though it was "MustbeDone" type of dialogue package) so I can tell you now  - that would fail someone sometimes. I can't make player "care" about when travelling with her - move slowly in case she has package active.

 

This is very interesting, this could even demostrate why vanilla handles packages in a different way (like I told some posts ago, about putting them all in their AI tabs and use conditions to evaluate them). Like in the case of Malcolm Holmes, he will stalk you for a long time, no matter what event happens, until he really will speak with you.

[prideslayer]

So apparently ListClear works now? Or does it?

Just had me a quick test & it seems to do as it's told.

Possibly, jaam has been a busy little bee lately.