Illuminiel: I received your personal message and email address. Should we need to pass the travel script between us an email attachment will be much more efficient.
My first question is for the initial quests would it be easier for me to use clones using a global state to enable/disable them at appropiate points - or do I have a master script that references each of the other travel scripts?
Both are valid approaches as melian confirms. The travel script for this one adventure will be so long that it may not be possible to script the second AIEscort adventure this way. I think clones can be problematic where dialog is concerned - particularly if that dialog toggles local variables. It might involve having to duplicate more dialog than you would like. The travel script can be run as a global however its local variables cannot be used as dialog filters. However such local filters can be declared on your scout's local script and their values set remotely by the global travel script if necessary. Another matter is that all instructions referencing the scout will have to be explicit using a fix - it cannot be implied as it is currently. This mean:
set playerDistance to ( GetDistance player ) ; for efficiency BECOMES
set playerDistance to ( "Scout_ID"->GetDistance player ) ; for efficiency
if ( GetCurrentAIPackage == 2 ) ; check to see if player is keeping up BECOMES
if ( ( "Scout_ID"->GetCurrentAIPackage ) == 2 ) ; check to see if player is keeping up
if ( GetCurrentAIPackage == -1 ) BECOMES
if ( ( "Scout_ID"->GetCurrentAIPackage ) == -1 )
SetHello 0 ; prevent idle greetings BECOMES
"Scout_ID"->SetHello 0 ; prevent idle greetings
AIEscort player 0 x y z 0 ; point 1 - Caldera gate BECOMES
"Scout_ID"->AIEscort player 0 x y z 0 ; point 1 - Caldera gate
if ( GetAIPackageDone == 1 ) ; NPC at point 1 BECOMES
if ( ( "Scout_ID"->GetAIPackageDone ) == 1 ) ; NPC at point 1
Face x y BECOMES
"Scout_ID"->Face x y
AIWander 0 0 0 0 0 0 100 0 0 0 0 0 ; scratches head BECOMES
"Scout_ID"->AIWander 0 0 0 0 0 0 100 0 0 0 0 0 ; scratches head
ForceSneak ; inspects base of signpost BECOMES
"Scout_ID"->ForceSneak ; inspects base of signpost
ClearForceSneak BECOMES
"Scout_ID"->ClearForceSneak
...and all over such instances throughout the script. (Perhaps is it about time you revealed the ID of the scout so I can reverence it directly.) The only concern I have it the effect these extra instructions have on the size of the script. It could become so large that it may bump its head on the script buffer size - I suppose we will deal with that if it happens.
It is not possible to toggle the local short
debugOn remotely, but it could be declared as a global variable or simply discard the debug code. The good news is that the global script can accurately monitor the passage of time should you choose to make this a timed quest.
Second question - I'm still foggy about where I enter the waypoints into the script? this section was unclear to me
I could not have put it any better than melian:
AIEscort player 0 x y z 0
I really like the idles you thought up and the message box is good - though I suspect if the player abandons her I think I would prefer to disable her once the player leaves the cell - a journal entry will come later saying she came to a sticky end on her own.
Not a problem - even more reliable as a global script. It should be coupled with a distance check since the player and the scout will cross several cell boundaries during their journey together. Using the current code's
playerDistance will be adequate in most instances. I already have a section of code for you to insert the journal update and disable the scout:
if ( playerDistance < 5000 )else Journal "Journal_ID" 200; or whatever the index is "Scout_ID"->Disable StopScript "IllyTravel"; or whatever it will be namedendif
A positive check for interior cell would also be an indication of the player abandoning the scout (and a good way to disable the scout after the quest is completed if that is appropriate):
if ( GetInterior == 1 ); player indoors if ( ( GetJournalIndex "Journal_ID" ) < 100 ); quest not completed successfully Journal "Journal_ID" 200; or whatever the index is endif "Scout_ID"->Disable StopScript "IllyTravel"; or whatever it will be namedendif
If you still want to have a time limit, I will have to add some additional code but I will not speculate about that until you confirm how you want to handle it (it will be easy).
Also if my waypoint crosses between cells eg westgash into bittercoast - will that impact the NPC?
This will not be a problem. Pathgrids do not cross cell boundaries, but AITravel and AIEscort can take you any where so long as there is a clear line of sight between waypoints (or a working pathgrid).
@ Cyrano:
Sorry to butt in again, just wanted to ask: Why would DaysPassed be unreliable?
DaysPassed is not a reliable keeper of the passage of time. It will work in some circumstances and not in others, and it is pretty much impossible to know when that is going to be. It depends on the combination of master and plugin files that are running when your mod is being used. Here is an explanation from JOG from the old forum.
A Mod that requires Bloodmoon won't work when you don't have Bloodmon.
If you need to use Dayspassed (there are other ways to count days) you need to use Tribunal.ESM as Master File.
The Bloodmoon and Tribunal Master-Files are nothing but Plugins, the functionality of the global variables Gamehour, Day, Dayspassed, Month and Year is hard-coded in Morrowind.EXE. But since Dayspassed didn't exist before Tribunal, the variable is included in Tribunal.ESM and only this one works reliable. A new global variable defined in a non-tribunal mod, won't conflict with existing Dayspassed-Scripts but won't work either. (At least not reliable)
And a few posts later?
Once the script is compiled, variables aren't accessed by their name but by an internal index-number, thus the compiled scripts in a Tribunal mod and those in a non-Tribunal mod use different variables.
Dayspassed works fine with v1.0 - v1.2 (Vanilla Morrowind) You don't even need to declare it if you just want to read it. If you actually want to change the current day, you have to declare it, though. (Remember? I was the one who found this "hidden global" while working on Haldenshore two months before Tribunal came out...)
Dayspassed also works fine with v1.3 and v1.4 (Tribunal only) when your mod IS dependent on Tribunal.esm. No need to declare it.
The variable also works with v1.5 and v1.6 (Bloodmoon only, Tribunal NOT installed) as long as you declare it. It will no longer work when you don't declare the variable.
And finally it also works fine with v 1.5 and v1.6 (Tribunal AND Bloodmoon installed) as long as your mod IS dependent on Tribunal.esm. (No need to declare the variable)
So... when is Dayspassed NOT working or at least not reliable? Well, this happens with v1.3 - v1.6 when you HAVE Tribunal installed, but your mod IS NOT dependent on Tribunal.esm:
? If you don't declare the variable MW crashes or returns an left-eval error when you try to use it in the script (the Construction set accepts the script without problems)
? If you declare the variable in an ESP that is not dependent on Tribunal.esm, the script works but the Dayspassed-Variable that is used by your scripts will never be count up
? If you declare the variable in an ESM that is not dependent on Tribunal.esm, the Dayspassed-Variable from your mod is count up but the one used by Tribunal and Tribunal-dependent ESP's isn't.
? If another non-tribunal ESM declares the variable, and this other mod has a later file-date than your own, then your mod will share Tribunal's fate, and the Dayspassed variable used by your scripts will also cease to work.
In short, if you want to know for certain that your script will reckon time accurately, then you had better use a workaround rather than DaysPassed. The easiest is a global script that checks for when the Day value is not the same as a stored value, sets them equal and updates a counter. Or you can store the current day, month and year in your local script, and compare them to the current values when the player returns to the cell.
The former might look something like this (it sounds like you are inserting this into an existing script). However for this to work reliably, the script must process the whole time (i.e., it must be global or always in the same cell as the player if local). If you need self-terminating global script to update your variable then post again if you need help.
short daysElapsedif ( currentDay == Day ) returnendifset daysElapsed to ( daysElapsed + 1 )if ( daysElapsed >= 4 ); 3 days passed since count starts at 1 set yourVariable to 2endif
You can also incorporate a GameHour check if you want your three days to actually be 72 hours.