Problems using the intimate animations script
#1
Posté 18 juin 2012 - 11:11
I paste the script here to make things easier:
void main(){
object oPC;oPC = GetPCSpeaker();
object oMan;oMan = GetObjectByTag("Ramar");
object oGirl;oGirl = GetPCSpeaker();
effect eEffect;eEffect = EffectCutsceneGhost();
// Set the variables//SetLocalInt(oPC, "Ramar_disp", 5);
//SetCutsceneMode(oPC, TRUE);
DelayCommand(0.01, FadeToBlack(oPC, FADE_SPEED_FAST));
DelayCommand(0.3, AssignCommand(oPC, ClearAllActions()));DelayCommand(0.3, AssignCommand(oMan, ClearAllActions()));
DelayCommand(0.3, ApplyEffectToObject(DURATION_TYPE_PERMANENT, eEffect, oPC));DelayCommand(0.3, ApplyEffectToObject(DURATION_TYPE_PERMANENT, eEffect, oMan));
DelayCommand(1.0, AssignCommand(oPC, ActionJumpToObject(GetObjectByTag("WP_girl1"))));DelayCommand(1.0, AssignCommand(oMan, ActionJumpToObject(GetObjectByTag("WP_boy1"))));
DelayCommand(2.0, SetPhenoType (9, oPC));DelayCommand(2.0, SetPhenoType (9, oMan));
DelayCommand(0.6, AssignCommand(oPC, SetFacing(270.0)));DelayCommand(0.6, AssignCommand(oMan, SetFacing(90.0)));
DelayCommand(1.0, AssignCommand(oPC, ActionUnequipItem(GetItemInSlot(INVENTORY_SLOT_CHEST, oPC))));DelayCommand(1.0, AssignCommand(oPC, ActionUnequipItem(GetItemInSlot(INVENTORY_SLOT_RIGHTHAND, oPC))));DelayCommand(1.0, AssignCommand(oPC, ActionUnequipItem(GetItemInSlot(INVENTORY_SLOT_LEFTHAND, oPC))));DelayCommand(1.0, AssignCommand(oPC, ActionUnequipItem(GetItemInSlot(INVENTORY_SLOT_CLOAK, oPC))));
DelayCommand(1.0, AssignCommand(oMan, ActionUnequipItem(GetItemInSlot(INVENTORY_SLOT_CHEST, oMan))));DelayCommand(1.0, AssignCommand(oMan, ActionUnequipItem(GetItemInSlot(INVENTORY_SLOT_RIGHTHAND, oMan))));DelayCommand(1.0, AssignCommand(oMan, ActionUnequipItem(GetItemInSlot(INVENTORY_SLOT_LEFTHAND, oMan))));DelayCommand(1.0, AssignCommand(oMan, ActionUnequipItem(GetItemInSlot(INVENTORY_SLOT_CLOAK, oMan))));
DelayCommand(7.0, AssignCommand(oMan, ActionPlayAnimation(ANIMATION_LOOPING_CUSTOM3, 1.0f, 99999.6f)));DelayCommand(7.0, AssignCommand(oPC, ActionPlayAnimation(ANIMATION_LOOPING_CUSTOM3, 1.0f, 99999.6f)));
//test setting PC to not commandable while maintaining manual camera controlDelayCommand(2.3, SetCommandable(FALSE, oPC));
DelayCommand(2.5, FadeFromBlack(oPC, FADE_SPEED_MEDIUM));
DelayCommand(60.0, FadeToBlack(oPC, FADE_SPEED_MEDIUM));
DelayCommand(60.0, SetCutsceneMode(oPC, FALSE));DelayCommand(62.0, SetCommandable(TRUE, oPC));DelayCommand(62.1, RemoveEffect(oPC, eEffect));DelayCommand(62.2, RemoveEffect(oMan, eEffect));
DelayCommand(63.0, FadeFromBlack(oPC, FADE_SPEED_MEDIUM));
}
#2
Posté 18 juin 2012 - 02:12
1. Use Gestalt Cutscene framework. (its on the vault)
2. Never make direct changes to the PC - it never ends well.
The best practice for cutscenes is to copy your PC, and make all appearance changes to the copy, and during this process, your real PC is cutscene invisible - they are the camera focus point.
If you want the camera focused on the 'participants' then you JumpToObject your invisible PC, to the fake PC, so they are side by side eachother.
Also - is it intentional that oPC and oGirl are the same object?
I think your delay commands are kinda messed up a little.
DelayCommand(1.00,MyAction1()); DelayCommand(2.00,MyAction2()); //You might think - Hey... it takes 3 seconds for it to get to 'End' but actually, it takes less than half a second. End<--
All DelayCommands are kicked off almost immediately.
It is up to you to specify times in the delay, that wont conflict with eachother.
eg
DelayCommand(7.00,MyAction1()); DelayCommand(2.00,MyAction2());//My Action 2 is gonna get executed before MyAction1 - because the delay is shorter. DelayCommands are not blocking, and will allow the script to progress, irrespective of the delay time.
This being the case, when all those DelayCommand 1's get kicked off, they do get added to the Players Action Queue, but they may not work.
The player after all, is non-commandable?
I never get these problems, because I use Clones of my PC, which are always commandable.
Also, try following a more linear approach to your cutscenes.
Delay 1
Delay 1.5
Delay 4.6
Delay 12.2
And so on.
This is the order they would get executed anyway, even if you jumbled them around.
#3
Posté 18 juin 2012 - 02:33
This prevents anything from being put into the action queue, and because you have the delay at 2 for this, and the delay for the looping animation at 7, the SetCommandable will be executed first, preventing the loop from taking place.
//test setting PC to not commandable while maintaining manual camera controlDelayCommand(2.3, SetCommandable(FALSE, oPC));
Change this, so that the delay is larger than the delay for the Animation/Loop.
#4
Posté 18 juin 2012 - 04:32
#5
Posté 18 juin 2012 - 05:33
But yes. He's got a lot of delays here, in a muddled fashion.
At the very least, he should order them by delay ascending. For readability.
#6
Posté 19 juin 2012 - 01:56
#7
Posté 19 juin 2012 - 04:08
Baaleos wrote...
Some would be needed to specify when to do an action, assuming he wanted some sort fog delay between some actions.
But yes. He's got a lot of delays here, in a muddled fashion.
At the very least, he should order them by delay ascending. For readability.
Fog delays shouldn't need delay commands. ActionWait() should be able to cover an in between time span. Plus if you have the entirety as non-delayed actions you can prevent the PC from interefering by SetCommandable().
#8
Posté 19 juin 2012 - 05:32
Mrhandy12 wrote...
...I lack deeper understanding of scipting in general. For now, Im just trying to familiarize myself with the tools and making basic things work. Im going to have a closer look at the delays too as the both of you suggested.
In order to help you understand scripting in NWN. There are a few base concepts that really need to be understood.
First is that every script is attached to an object. If the object ever gets deleted/removed/destroyed from the game, so does the script.
With that in mind when you have code like this.
DelayCommand(0.3, AssignCommand(oPC, ClearAllActions()));
It means that even if the PC left the game, What ever object this code is running on is still going to waste time trying to tell the PC to clear all his actions. Thiis would be a better way to go in many situations, If the delay was needed.
AssignCommand(oPC,DelayCommand(0.3, ClearAllActions() ));
This was the Delayed command is already running on the object that is going to use it. If something happens to the object the delayed command just gets removed along with the object. as opposed to commands running in the background for an object that is no longer there.
it also helps to understand the differance between Commands and Actions.
Both Commands and Actions are Void returning functions. The diffrance is how they are handled by the object they are ran on. Commands are executed by the Object as soon as it gets them. Actions are placed into a the Action Que for the object, in the order recived. The Action Que executes one action at a time and does not execute the next action in the Que untill the current action is finished.
the function ActionDoCommand allows you to take a function that would normally be a command and get excuted rith away and add it to the Action Que to wait its turn to execute.
with the above you can build a frame work like this:
// Assign command for the PC to clear his action que.
AssignCommand (oPC, ClearAllActions());
// AssignCommands of actions to be added into the PC's ActionQue to be done in turn in order.
AssignCommand (oPC, SomeAction);
AssignCommand (oPC, SomeAction);
...
AssignCommand (oPC, SomeAction);
// allow the PC to command himself once again after doing all the actions.
AssignCommand (oPC, ActionDoCommand(SetCommandable(TRUE)));
//Set The PC uncommandable, Locking the actionque from having anything else added to it.
SetCommandable(FALSE,oPC);
....
Modifié par Lightfoot8, 19 juin 2012 - 05:34 .
#9
Posté 20 juin 2012 - 03:32
#10
Posté 20 juin 2012 - 09:11
WhiZard wrote...
Baaleos wrote...
Some would be needed to specify when to do an action, assuming he wanted some sort fog delay between some actions.
But yes. He's got a lot of delays here, in a muddled fashion.
At the very least, he should order them by delay ascending. For readability.
Fog delays shouldn't need delay commands. ActionWait() should be able to cover an in between time span. Plus if you have the entirety as non-delayed actions you can prevent the PC from interefering by SetCommandable().
that wasnt meant to say fog delays - I was on my iPhone - and for some reason 'of' came up as fog, in predictive text.





Retour en haut







