I would suggest that to do what you want, it's a bit complicated, and what you want is not to set something on the PC, but something on the quest itself. In other words you can aim your variables at either the character or the door, the door is much more likely to be entirely under your control, while who kills who, or even if the PC object is talking to the final conversation owner is an open question - rail roading the player though can ensure this is a non issue of course.
This eliminates the entire issue of the PC and what they are doing, and allows for the player to use companions, remove some of those companions and swap them out, and even do some wonky save game editing and this all should work.
void main()
{
object oQuestGuy = GetObjectByTag( "QuestGuysTag" );
int nInt;
nInt = GetLocalInt(oQuestGuy, "0001_killed");
nInt += 1;
SetLocalInt(oQuestGuy, "0001_killed", nInt);
}
Now the object which has the tag "QuestGuysTag" can be a waypoint, ipoint placeable, or it can be the actual object you are going to be talking to later ( which you would have as a object with the convo parameters already ).
If you want the speaker to know if the killer was the person talking to them at the moment ( ie companions or player ) setting the name as well, but this ensures that no matter who kills or talks, your module will work if those 3 ( or whatever ) hoodlums have been killed.
Not you can remove this code entirely in the on killed code, and put the code into the conversation the character is doing, with some thing like the following, this could be put into a conditional script, and solve the exact same problem.
You can use "gc_obj_valid" which i think already exists to test for your guards, but is mainly useful if you want to really test if they are all dead instead of having different convos based on how many are left alive. Lets assume your guards have the tag of "QuestGuard". This could be adjusted easily to test for guard 2 being alive, guard 3 by putting a number in GetObjectByTag(sTag) after sTag as i do in the example code below.
int StartingConditional(string sTag, int bAreaOnly, int nNth )
{
object oObject;
if ( nNth == 0 )
{
nNth = 1;
}
if (bAreaOnly == 0)
{
// Search module
oObject = GetObjectByTag(sTag, nNth);
}
else
{
// Search area from owner only
oObject = GetNearestObjectByTag(sTag, OBJECT_SELF, nNth );
}
return GetIsObjectValid(oObject);
}
I kind of wonder what would happen if the player saw the given guard, used a clone, simulcrum type of spell on it, which ended up also using the original event and tag on the copied creature. Then proceeded to get that simulcrum killed, thus increasing the number killed above the number you were expecting. This could create rare conditions where the integer is higher than you expect, or that one of the guards is still alive but the count is equal to the number which expected when all are dead.
Storing it on the PC though id suggest if you happen be using a situation where they have to personally kill a certain type of creature, sort of like the kill 3 rabbits quest, but you could use a journal quest to do it instead. To make this work you'd actually want unlimited rabbits that are spawning, or enough so that a npc casting fireball does not block the quest. ( or make them plot to keep them alive until the player kills them ). Note that GetLastKiller() only works in the npc on death event per the lexicon, most of these functions are special purpose like that. The journal parameters will work regardless if its' a companion or a player doing the killing as well, and you'd have to set up 3 journal entries in the module for each number that have been killed.
Of course this is really the same code as what is being used for the local integer, its main difference is the feedback the player is getting, just another way to tackle this problem.
void main()
{
object oKiller = GetLastKiller();
int nInt;
nInt = GetJournalEntry("killedthemquest");
nInt += 1;
if ( nInt > 3 )
{
nInt = 3; // limit to 3 only
}
AddJournalQuestEntry("killedthemquest", nInt, oKiller );
}
Modifié par painofdungeoneternal, 27 octobre 2011 - 09:51 .
Retour en haut
