A.J.

It depends by many factors. But 10 seconds delay is an enormous, giant, huge amount of time. If I were you I wouldn't be so much preoccupied in any case.   These are UDFs.

The problem is not really the code itself, you can run it fine and then you run the same code on another computer / another installation with heavy mods and it breaks. I would simply avoid a situation like that, it saves me headaches. I have a (not so different) scanner and it breaks in heavy modded environments, especially when I turn ENB on. I solved staging it: first I scan the cell and I fill an array with the references I find, then in the next stage I walk the array and check every reference with the conditions. But I guess if you use a UDF you could still not risk to break the script.   By the way, when you need indexes, NVSE documentation has them all.

GetWeaponAmmo could help you For what concerns the script going wild, I suggest to avoid that... when I'm at risk, I call an UDF, as result I notice in game a stutter if there's something too much "heavy" in the code to be handled

  Disable / Enable does the trick, if it's viable for you

I finally had the occasion to try these tails. I just wanted to write down that they are so amazing for me... the only problem of these, like for the ribbon, is once I start to use them then I can't play anymore without them... they're too addictive!   Thank you Jacques00, thank you so much

Esperiments with LOD and skyscrapers in a metropolitan environment  

It's a thing with custom races in general. It CTD when Player chooses both eyes and hair in the same time when they custom themselves in ShowRaceMenu, they should do it in two different moments. There's no risk for NPCs.

  It's not really "not bugged", they do good, but I don't need them in these cases.   I noticed Get functions return an error on console when the ref doesn't exist.   For example, I have a script that checks all the slots for equipped object but it spams an error if there's nothing in the slot. I don't need it, I'm actually checking what is equipped.   Another example, I have a script that spawns a creature with PlaceAtMe and then executes the code on its ref. It needs "some time" to be spawned, so the script will constantly check with If GetType 43 when the creature is really spawned. But in the meantime, for some frames, it returns a error on console of course, it's the time the creature needs to be spawned.   They do good, they are right to notify the error, but I'm aware of those errors and I find it's normal, that's why I wanted to remove them, because I guess if all the mods work in this way all togheter it would be impossible to track down "real" errors in console   @Odessa thank you I'll check it

  I was hoping in something more... easier, something like "DontShowMeErrorsOnConsoleForThatMod", better with a shortcut like DSME... I can't even get the OBSE example

  FOV works pretty fine, I use it for cutscenes and I change it gradually, or with mouse wheel to emulate a zoom. However, after the script, when I go back to my default, I need to refresh ini settings because it messes up the view.   Only problem is there's no function to store the original fov and not everyone plays on default 75

  That's what I said, it's not a bug if a skeleton has no bones that a certain body is rigged with. SO breeze doesn't suffer of that behaviour cos it's not rigged with any penis bones. I agree, it doesn't make sense having two penises, it becomes too much chaotic, just like 8 breast bones

  Not really a "bug", I guess it's because Amra downloadable body is weighted on Penis bones while this skeleton has Dick bones (there are 2 different penises around, when it comes to skeletons)

  For you it isn't persistent? I was remembering the contrary so I just tried. On my NV it is persistent, both on player and npcs, even after quit and reload

Hats off to you!

  If you mean the conditions you insert inside the package itself, I just tried it today. I AddedScriptPackage MyPackage via console, MyPackage was a Dialogue package with a condition absolutely false (GetItemCount Abraxocleaner 20), still the npc talked to me when I closed the console

  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.

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.

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.

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?

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

 

of course I should know the whole purpose of why you are scripting it, you surely have good reasons. But my suggestion is, when there's not really need to script something like that, use the tools vanilla gives you to handle packages, they are pretty reliable.   So for example the usual way to handle packages is by their own specific windows, like for example adding a list of packages in the ref AI package window, and setting a numeric variable which will condition the package that the ref will pick. So for example, I add a dialogue / find package on a ref, then as condition I use myquest.myvar == 1, then inside my main script I set myquest.myvar to 1 and myref.evp, this automatically leads the reference to pick that package and talk to me. To end this package, inside the dialogue result script I set myquest.myvar to 0 and I MyRef.evp. More than once I had to use MyRef.ResetAI instead evp because on dialogues it happens often that they will start again to talk (like happened to you if I understood well)   now addscriptpackage usually it's used when something is not usual, some package must be used only in some specific situation. But I'm not sure this is your case. Since you are even checking if MyPackage is really a Package (GetType 73), this leads me to think you are doing some generic function that passes parameters so that you can spam a generic package and force it whatever it is, in whatever situation you want. Is it what you are trying to do?