A) I have no idea if this will work or not because the system relies on Bioware's default waywalking code and the design is not conducive at all to running scripts during waywalking. Plus I did not compile or test this in any way. It should get you most of the way there however...it will be a little funky tho.
Your arrival scripts must always do this:
1) Clear action queue and assign your actions (i.e. lamp lighting). Clearing the queue is a requirement if you are going to have the script assign actions to the guy.
2) Add one final action at the end that re-enables waywalking (the heartbeat following this will start him going again automatically). The command is:
ActionDoCommand( DeleteLocalInt( OBJECT_SELF, "X2_L_WALKWAY_SUSPEND" ));
-or-
2a) Add an action at the end that re-enables waywalking:
ActionDoCommand( DeleteLocalInt( OBJECT_SELF, "X2_L_WALKWAY_SUSPEND" ));
2b) Add one final action at the end:
ActionDoCommand( WalkWayPoints( nRun, fPause )); where you must specify the appropriate nRun and fPause values manually.
Doing 2a & 2b insted of just 2 will get him walking waypoints again immediately instead of at the next heartbeat, thus eliminating a pause (potentially as long as six seconds) at the end of your arrival script before he gets going again.
You may find that the guy skips ahead one or more waypoints after running your arrival script. This will break the solution I have come up with (below) and here's why. Because you have to clear actions in your script to do what you want in that script, you will wipe out any animation, pause, and execute departure script actions that are set up on the waypoint to occur after he arrives. When you re-enable waywalking it basically causes a call to WalkWayPoints to occur which sets all the actions back up again. So, your script may need to mess with the WP_CUR variable to force him to return to that same waypoint to be assigned the animation, pause, and execute departure script actions again.
This is absolutely critical because it will cause him to arrive a second time. To avoid a kind of "loop" where he never continues his patrol -- stuck at the same waypoint doing the arrival script over and over again, I have worked out a dynamic way to blank out the arrival script name variable on the waypoint so it doesn't run again after running the first time, and gets set back up again when he arrives the second time.
If he never arrives at the same waypoint again, the waypoint will effectively have been set to no longer have an arrival script anymore. Even worse, arriving at the next waypoint will cause the script name to be set up on that waypoint instead, thus causing your arrival script to start running on the next waypoint instead, and subsequently propagate along the patrol route from waypoint to waypoint...very bad. This isn't such a huge problem if the route only has one waypoint such as when you are using a POST or NIGHT waypoint.
So maybe also add:
1a) Adjust WP_CUR so the waywalker will return to the same waypoint instead of moving on to the next. This is not trivial to compute. Study x0_i0_walkway to learn how. You will need to take into account, what direction in the route he is going, what happens at the end of the route, what time of day it is, circular vs palindrome style walking, whether night waypoints are being used, and IIRC a couple of other similar types of things.
Your departure script need not worry about WP_CUR (I think) and there is no blanking out of the departure script name from the waypoint since it does that action last anyway, however if you plan to perform any actions there, clear the queue, and re-enable waywalking when complete exactly like I just described for the arrival script. Neither the arrival nor the departure script will be able to support any waywalking (calls to WalkWayPoints will be ignored).
Your departure scripts must always do this:
1) Clear action queue and assign your actions. Clearing the queue is a requirement if you are going to have the script assign actions to the guy. Otherwise it probably isn't necessary, although to be safe I think it would be best to always do so.
2) Add one final action at the end that re-enables waywalking (the heartbeat following this will start him going again automatically). The command is:
ActionDoCommand( DeleteLocalInt( OBJECT_SELF, "X2_L_WALKWAY_SUSPEND" ));
-or-
2a) Add an action at the end that re-enables waywalking:
ActionDoCommand( DeleteLocalInt( OBJECT_SELF, "X2_L_WALKWAY_SUSPEND" ));
2b) Add one final action at the end:
ActionDoCommand( WalkWayPoints( nRun, fPause )); where you must specify the appropriate nRun and fPause values manually. Doing 2a & 2b insted of just 2 will get him walking waypoints again immediately instead of at the next heartbeat.
The system is not compatible with CEP anymore. The comments in the KWW vault page has a post that describes what you have to do to make it compatible. It is a lot of tedious work to discover which CEP scripts need to be recompiled, simple but time consuming to find them all. That's why I stopped updating it with every CEP release awhile ago when CEP started bloating wildly every other week. Lilac Soul's BioSearcher is invaluable during this process. I think acaos's version of nwexplorer.exe also has a search function that should work equally well, tho I never did it using that tool.
C) After implementing the changes below, you need to force a recompile of every script in the KWW package. If you're using the HAK, you have to then replace all the scripts in the HAK with the updated stuff. I always did this by using a simple blank one area module with no custom scripts in it to work on the KWW system. Import KWW ERF, make changes to the KWW scripts, force all the scripts to recompile, export the results back into the ERF (renamed with new version is how I complete that step), use nwexplorer.exe and nwhak.exe to export the scripts from the ERF to some folder and the put them into the HAK (also renamed).
D) It will run the departure script, if specified on the waypoint, regardless of the setting used for fPause or X2_L_WALKWAY_PAUSE. You can write your departure script to look at the waypoint and perform appropriately when there is a pause set should you want that type of behavior.
E) If you want him to "go somewhere else at dawn,day,dusk,night" you can use the Bioware standard WN or NIGHT style waypoint setup for the night patrol. It will switch to use WP or POST tags when day starts (maybe dawn I forget but I think it's day) and WN/NIGHT when it turns to night (again, I forget -- it might be at dusk). There is no way to distinguish dawn/day or dusk/night in the Bioware system, they are treated as only two time periods not four...and I am not gonna take the time to do that because it is fairly extensive.
F) For the same reasons given above, you will probably be unable to use arrival UDSs successfully with a cross-area waywalker.
The script you need to change is the x0_i0_walkway library
At Line 856 you will find this bit:
if( GetLocalInt( oWay, "X2_L_WAYPOINT_SETFACING")) ActionDoCommand( SetFacing( GetFacing( oWay)));
// * 2006/10/31 - by Axe Murderer for KWW v1.0
// Modified to use the new KWW-pause variable if it was found.
if( fWaypointPause > 0.0) ActionWait( fWaypointPause);
// * 2006/10/31 - by Axe Murderer for KWW v1.0
// Added in this section for playing the animation if one was found.
if( iAnimation >= 0)
{ ActionDoCommand( SetLocalInt( OBJECT_SELF, "KWW_PlayingAnimation", TRUE));
ActionDoCommand( DelayCommand( fAnimationDuration +0.05, DeleteLocalInt( OBJECT_SELF, "KWW_PlayingAnimation")));
ActionPlayAnimation( iAnimation, fAnimationSpeed, fAnimationDuration);
if( fWaypointPause > 0.0) ActionWait( fWaypointPause);
}
ActionDoCommand( WalkWayPoints( nRun, fPause)); // February 14 2003 added else route only happens once
Make it look like so:
if( GetLocalInt( oWay, "X2_L_WAYPOINT_SETFACING" )) ActionDoCommand( SetFacing( GetFacing( oWay )));
// Run User Defined Arrival Script if specified on the waypoint. (1-12-2012)
string UserDefinedScript = GetLocalString( oWay, "X2_L_WAYPOINT_ARRIVAL_UDS" );
if( UserDefinedScript != "" )
{ // Disable waywalking for this guy, save the arrival script name on him, clear the arrival script name from the waypoint,
// and call the arrival script.
ActionDoCommand( SetLocalInt( OBJECT_SELF, "X2_L_WALKWAY_SUSPEND", TRUE ));
ActionDoCommand( SetLocalString( OBJECT_SELF, "KWW_UDS_ARRIVAL", UserDefinedScript ));
ActionDoCommand( DeleteLocalString( oWay, "X2_L_WAYPOINT_ARRIVAL_UDS" ));
ActionDoCommand( ExecuteScript( UserDefinedScript ));
}
// If he's arriving for the second time after running an arrival script, restore the arrival
// script name on the waypoint. (1-12-2012)
UserDefinedScript = GetLocalString( OBJECT_SELF, "KWW_UDS_ARRIVAL" );
if( UserDefinedScript != "" )
{ ActionDoCommand( SetLocalString( oWay, "X2_L_WALKWAY_ARRIVAL_UDS", UserDefinedScript ));
ActionDoCommand( DeleteLocalString( OBJECT_SELF, "KWW_UDS_ARRIVAL" ));
}
// * 2006/10/31 - by Axe Murderer for KWW v1.0
// Modified to use the new KWW-pause variable if it was found.
if( fWaypointPause > 0.0 ) ActionWait( fWaypointPause );
// * 2006/10/31 - by Axe Murderer for KWW v1.0
// Added in this section for playing the animation if one was found.
if( iAnimation >= 0 )
{ ActionDoCommand( SetLocalInt( OBJECT_SELF, "KWW_PlayingAnimation", TRUE ));
ActionDoCommand( DelayCommand( fAnimationDuration +0.05, DeleteLocalInt( OBJECT_SELF, "KWW_PlayingAnimation" )));
ActionPlayAnimation( iAnimation, fAnimationSpeed, fAnimationDuration );
if( fWaypointPause > 0.0 ) ActionWait( fWaypointPause );
}
// Run User Defined Departure Script if specified (1-12-2012)
string User_Defined_Script = GetLocalString( oWay, "X2_L_WAYPOINT_DEPARTURE_UDS" );
if( User_Defined_Script != "" )
{ ActionDoCommand( SetLocalInt( OBJECT_SELF, "X2_L_WALKWAY_SUSPEND", TRUE ));
ActionDoCommand( ExecuteScript( User_Defined_Script ));
}
ActionDoCommand( WalkWayPoints( nRun, fPause )); // February 14 2003 added else route only happens once
After making this change, you should be able to set string variables on the waypoints called
X2_L_WALKWAY_ARRIVAL_UDS and
X2_L_WALKWAY_DEPARTURE_UDS to identify the User Defined Scripts. In these scripts OBJECT_SELF will be the waywalker.
One thing that must be avoided at all costs when using arrival scripts anywhere on a waywalking route is killing or destroying the waywalker before he is able to return to the waypoint and restore the script name on it. If he is running the arrival script when day turns to night or vice-versa, things will break for the reasons I cited above...I did not work that out.
My advice is to never use arrival UDSs on waywalkers that make use of both day and night waypoints. I also advise making the waywalkers plot and immortal whenever using arrival UDS's anywhere in his route for the same reason. Whenever you use arrival scripts you absolutely must ensure he will always return to the waypoint that told him to run the arrival script when his waywalking resumes.Specifying a non-blank arrival script name that does not exist on a waypoint, or writing an arrival UDS that does nothing will also break the waywalking.
It is probably going to be a little wonky...but maybe not if you can follow the rules I just outlined precisely every time.
Good luck!
Modifié par Axe_Murderer, 11 janvier 2012 - 12:17 .
