Setting a Quest Stage when entering an exterior cell

[Isskini]

What do people think the most reliable way to set the stage of a quest when exiting an interior cell into an exterior cell is?

I can check for a variable I set when the quest is "done", but I'm not sure where to put the script, you don't seem to be able to set a script on entering an exterior cell.

For example: I enter a shop and do something inside, I set a global variable indicating it's done. I then exit out into an exterior cell and I want the quest stage to advance. I know I could advance the stage when setting the global variable, but I want to wait until the player has left the cell.

Any ideas?

[zippy57]

Check for your quest variable and Player.IsInInterior == 0 in your quest script.

scn example

int didSomething

Begin GameMode
    if didSomething && Player.IsInInterior == 0 && GetStage MyQuest == 0
        SetStage MyQuest 10
    endif
End

[Isskini]

Oh. I see. Thanks! I've read that GameMode is expensive to use, it checks quite often and with a large enough set of quests you can affect performance. Is that something I should be worried about?

[zippy57]

GameMode is indeed run every frame. However, it's probably used in 95% of scripts. The impact from adding a few more GameMode blocks with your own mod is negligible considering how many GameMode blocks are in the vanilla scripts alone. As long as the computer you're running isn't fifteen years old or something, GameMode blocks are not going to lag the game unless there's faulty code in them or related to them (such as checking an ever-growing formlist every frame). There are a lot of ways to do things like this without a GameMode block, such as with a trigger, but the GameMode block is the simplest and most-foolproof for a mod creator.

You also may want to stick with quest variables and not use globals, as globals are 1) much easier for players to screw with using the console and 2) additional records that must be added to the plugin, and FNV appears to have a limit on the number of records that can be present in-game before it gives up and crashes out.

[Isskini]

I see. Since there is a separate quest for each NPC I don't anticipate GameMode being a huge problem as I don't think the player will pick up every quest at once. I just tried it out then and it worked great. So thanks again!

I've heard of quest variables but I've never seen where they're configured. Is it in the Quest Script or is it a menu item?

EDIT: If you are talking about variables that you just declare in the quest script, can I set them from Result Scripts in Topics? If so how? "set varname to 1" tells me it doesn't recognize the variable.

[Isskini]

Nevermind, figured it out. Set Questname.Questvar to 1

[Guest ThatOne]

You can just script the specific door...

scn EX

var DidSomething

Begin OnActivate

If DidSomething == 1 && GetStage MyQuest == 0

SetStage MyQuest 10

Endif

Activate

End

Note that you'll need to make a special door ID to avoid attaching the script to all doors.

It's better to use in cells added by your own mod, rather than vanilla ones; it might cause conflicts otherwise so use wisely.

Edit - second note: if you don't want the player to be able to leave the cell through the scripted door until he actually did whatever it is, you can place the "Activate" line inside the If block and add a Return line, like this:

scn EX2

var DidSomething

Begin OnActivate

If DidSomething == 1 && GetStage MyQuest == 0

SetStage MyQuest 10

Activate

Endif

Return

End

The script stops at the Activate line, if it reaches it, so anything you place after it is ignored.

However, you should use this kind of scripts only rarely because it's a VERY aggressive way of forcing the player to do what you want him to.

[zippy57]

Creating a new door and scripting it is making things more complex than necessary.

EDIT: Additionally:

• You can't declare a variable as "var", you can use "short", "int", "long", "ref"...
  
• You probably shouldn't place a variable like that in the door script, it should be contained in the quest script so you can 1) not have to make the door a persistent ref, 2) keep all your variables in one spot (the quest script) and 3) debug the variable using sqv
  
• That block should be "Begin OnActivate Player" because otherwise it will set that variable even if an NPC uses that door.
  

[Guest ThatOne]

More complex than necessary? You've lost me there.

I can't see how double-clicking the door ID, changing an the ID and hitting OK -> Yes is complex. The extra script is instead of your GameMode one, and I believe it's worth it as it doesn't run nearly as many times.

However, you certainly had some valid points:

-I said it should be a var, and var isn't used in Oblivion. Thanks for correcting me. It should be short or possibly int but long is definitely not called for.

-It should definitely be OnActivate Player, not only for the reasons you mentioned but because it would drastically reduce the amount of times the script runs.

However, sqv is rather useless here; it's a simple if\endif block on the door script. Either the variable is set correctly or not, setting it manually wouldn't do you any good in debugging (you'll want to check the script that sets the variable, not the door).

Also, holding all variables in the quest script isn't that grand of an idea unless you want to re-use the variable later on.

Both that and making the door persistent aren't needed because the fellow is using a global variable, and he can just check that instead (no need to make a new variable).

[zippy57]

It's more complex because it requires creating a new door record and a new script as opposed to just creating a script. 2 > 1, therefore your method is more complex than necessary. Additionally, the impact of this if/then check in this GameMode block is so small as to be non-existent.

-In the CS, short, int, long, and float are actually all the same thing. The CS actually stores all of these as a float, regardless of what you declare it as. The only difference is that variables not declared as "float" will round decimals.

-Again, this script could run every frame and the impact would be so unnoticeable.

sqv has nothing to do with setting variables. It's "SHOW quest variables". However, this one's on me as after double-checking I don't think Oblivion has the sqv console command. I think it was added in FO3.

Again, there is no reason to use Global variables here. You should be using quest variables. Globals add records, and you need to keep the number of records as low as possible. Plus if your variable are in a quest you can sqv to see them all at once instead of having to enter each variable into the console individually to check them.

[Guest ThatOne]

Wasn't SQV "SetQuestVariable" in Oblivion? I'll check...

Nope, you are correct. It is indeed ShowQuestVariables. That might actually be useful then, if there are more than two possible values to the variable.

I really didn't know that Oblivion behaves that way to short, long and float. Oh well, live and learn.

Anyway, yeah I suppose the variable could be in the quest script and just referred to in the door script.

Unless, of course, this also has some unwanted side-effects I am not aware of...

As for more complex... Is it really that much more difficult or time consuming to be warrant substituting it for another script that runs in the background?

[zippy57]

There are almost always at least two possible values: 0 and 1. Otherwise why have the variable?

Difficult? No. Time-consuming? No. But again, the number of background scripts already in the game combined with the incredibly low impact of adding a single if/then check makes it a better choice. And it's always best to use vanilla resources whenever possible to allow maximum compatibility with other mods. When you have to create a new record, go ahead, but when you don't (as in this case) you should just re-use vanilla ones. For one reason, using a vanilla door means it will retain the language of the user's original game. Creating a new record means everyone will see "Door" even if they have a non-English game. And any fixes made to vanilla records won't be kept by your custom record.

Additionally, games with this engine have a soft record limit of some kind, probably dependent on a user's memory capabilities. The game can start to crash on startup even if the player has all required masters and has not reached the hard limit; while I don't think anyone has tracked this down to a specific cause, personal testing has suggested that the game can only handle a certain number of records before giving up and crashing out. So keeping your record count as low as possible is a good idea.

And just to stress this, the addition of one if/then check in a GameMode block has next-to-no impact in game performance.

[Guest ThatOne]

You read what I wrote wrong; I said if there were MORE than two possible values, not just two.

His example implied that the stage should either be set or not - thus two values, and checking what the value is isn't helpful since we can simply deduce if it was changed or not by checking the stage itself.

Also, much like your one if\then check, one more record will have "next-to-no impact".

But, I guess I really shouldn't argue with you since we both agree the differences are negligible. And you did teach me a few things I didn't know, so thanks for that.

[zippy57]

I didn't mis-read what you wrote, I thought you have mis-typed it. Checking the variable could be necessary (if the stage wasn't set) to determine if the problem was in the action setting the variable, or in the script checking the variable. Even if there were only two options, 0 and 1, it is still entirely possible that the variable would need to be checked.

I just explained how the addition of one new door record can have a considerable impact.

• One record can be the difference between a working game and a game crashing on startup
  
• Creating a new in-world record can undo changes made by other mods that are intended to be "universal"
  
• Creating a new in-world record can introduce incorrect-language elements into the game
  

An if/then will not crash the game if done correctly and the addition of one will not be the difference between a working game and a non-working one. The mere presence of an extra record can crash the game even if there is nothing wrong with it. Thus (unless the script is that extra record, which in this case it is not) the script's impact is next-to-nothing; the new record's is not.

[Guest ThatOne]

*Sigh* not sure what I've done to deserve this.

I can address each and every one of your points and counter them. Really I could. But the moment you wrote how one record could be the difference between a working game and a ctd, I decided this is not going anywhere.

Why? Because if that's the difference then the next time the guy gets an update that adds ONE record to one of his mods, CTD. He gets a new mod? CTD.

That's such an edge-case scenario I don't even want to begin to argue about it.

So, you win the argument; please excuse my foolishness for even thinking I could attempt to make an alternative script to yours.

Please forgive me for thinking one record doesn't make much of a difference.

I hereby leave the thread. Good day, sir.

[zippy57]

All I'm doing is pointing out that the quest script has the least potential to cause issues. I'm not saying that it will cause issues, I'm saying that given the two possibilities the quest script approach has fewer theoretical drawbacks than the new door approach.

To claim that adding a single new if/then check in a GameMode block will cause a noticeable impact on game performance is just as much of an "edge-case scenario" as a new record causing a CTD. That's why I brought it up in the first place. To point out that even in the absolute worst-case scenario, the quest script is still less likely to cause an issue.