Hi,

I have a problem. Im currently in the process of creating a separate wewewolf ability and quest. As you propably know this requires new feed perk. Now, everything works fine. I can transform into werewolf and back. Problem is I cannot feed. Everytime I do this I turn into human(argonian). I have discovered that it is because of the playerwerewolffeed perk. I tried to remove it and repace it with a new perk via script but I CANT! I always have the old perk not the new one. Anyone has any idea?

Perks cannot be manipulated via script.
Sorry.

Apparently you are right, but in that case why there are appropriate commands in papyrus?

You can manipulate perks with the "appropriate commands" for the player only. For NPC Actors it will not work.

You can certainly add and remove perks to the player with a script.
AddPerk(perkname) and RemovePerk(perkname) both work.

To check ingame if you have the perk, use the console and type

player.hasperk PerkIDHere

I did that and it is not working. I check it before the way you mentioned. I tried to do that with PlayeyWerwolfFeed perk and my custom perk which is a modified copy of the above. What is interesting is that in the PlayerWerewolf quest there were such commands but for some reason they were erased and the perk was applied to the player via CK. Perhaps the method is working for other perks, but I think its not working for such sophisticated perks as the above. Please, prove me wrong.

i tried it in a script and it throws up errors,and it cannot be removed via the console either.
I'm not sure what else you could try.

Well, I simply added my perk via CK. I didnt remove the vanilla perk, I just transform into custom werewolf race and the vanilla perk applies only to vanilla werewolves:)

Oh, didn't read carefully enough to see you wanted to do it to the player.

I'd have to see your perk to see if it were going to work correctly.

Both perks (vanilla and mine) work correctly. The only problem I had was I couldnt remove vanilla and add mine via script and then reverse it. I no longer have to do it because now there is no collision between them. Vanilla perk is for vanilla werewolves and mine is for my alpha werewolf.

I have now run into the same issue:

Scriptname aadpCombatQuest extends Quest Actor PlayerRefint doonceGlobalVariable Property aadpStopAllScripts  Autoactor Property PlayersCombatTarget auto ObjectReference Property UnownedChestREF  AutoPerk Property aadpShieldWall  Auto  ;-- BasicFork01Perk Property aadpGapBullsEye  Auto  ;--BasicKnife01Perk Property aadpFastDraw  Auto  ;-- BasicPlate01Perk Property aadpBustKneeCap  Auto  ;--BasicPlate02Perk Property aadpBowAccuracy  Auto  ;--BasicWoodenBowl01Perk Property aadpBlockFastRest  Auto ;-- Basket01MiscObject Property BasicFork01  Auto MiscObject Property BasicKnife01 AutoMiscObject Property BasicPlate01 AutoMiscObject Property BasicPlate02 AutoMiscObject Property BasicWoodenBowl01 AutoMiscObject Property Basket01  Auto MiscObject Property BasicTankard01 Auto  ;-- aadpHolyWaterScroll Property aadpHolyWater  Auto  ;-- BasicTankard01WEAPON Property aadpMrPointy  AutoEVENT onInit()Playerref = game.getPlayer()debug.messagebox(UnownedChestREF.getitemcount(BasicFork01))if UnownedChestREF.getitemcount(BasicFork01) > 0Playerref.AddPerk(aadpShieldWall)  ;<-----------------------------------------  will not add to player!UnownedChestREF.RemoveItem(BasicFork01)debug.messagebox(UnownedChestREF.getitemcount(BasicFork01))endifif UnownedChestREF.getitemcount(BasicKnife01) > 0Playerref.AddPerk(aadpGapBullsEye)UnownedChestREF.RemoveItem(BasicKnife01)endifif UnownedChestREF.getitemcount(BasicPlate01) > 0Playerref.AddPerk(aadpFastDraw)UnownedChestREF.RemoveItem(BasicPlate01)endifif UnownedChestREF.getitemcount(BasicPlate02) > 0Playerref.AddPerk(aadpBustKneeCap)UnownedChestREF.RemoveItem(BasicPlate02)endifif UnownedChestREF.getitemcount(BasicWoodenBowl01) > 0PlayerRef.AddPerk(aadpBowAccuracy)UnownedChestREF.RemoveItem(BasicWoodenBowl01)endifif UnownedChestREF.getitemcount(Basket01) > 0Playerref.AddPerk(aadpBlockFastRest)UnownedChestREF.RemoveItem(Basket01)endifif UnownedChestREF.getitemcount(BasicTankard01) > 0Playerref.additem(aadpHolyWater, (UnownedChestREF.getitemcount(BasicTankard01)), true)UnownedChestREF.Removeitem(BasicTankard01)Playerref.additem(aadpMrPointy, 1, true)endifUnownedChestREF.Removeitem(aadpHolyWater)Endevent

All the other PERKs will get placed on the player but not aadpShieldWall. I see the fork is counted as ONE then as zero (after ) indicating that the code ran but still no perk for the player.
And yes I have checked to be sure the Perk property is set many many times. And the perk CAN be selected int he game like any other perk.

I just now changed that perk to a vanilla perk and it still would not add! I am beginning to think it has to do with the fact it is the first perk on the tree!

Try using Game.GetPlayer() instead of PlayerRef. It may be that the ref is not correct. Also, do you mean for it to be local private scope?

I realize you assign it, but it is best to eliminate that possibility.

It might be that, every time I have tried to do something like that before, it never worked. I always end up using Game.GetPlayer() unless the player is passed in somewhere else (i.e. as a parameter of an event).

I will try that, but I know it will not work because ALL the other perks DO get added to the "PlayerRef" doing it the way I am doing it.

<--- this is me chewing on some CROW....


WOW....wow...W O W !

Changing the perk to Game.GetPlayer() WORKED!

WHY WOULD IT WORK FOR ALL THE OTHERS IN THE SAME SCRIPT BUT NOT THAT ONE PERK?

Thank you very very much, but this also scares the HELL out of me.
Do you guys have any idea HOW FREAKING MANY times I use PlayerRef = Get.gamePlayer in my 50 plus scripts?

This is !

I found one script that Bethesda did this: ObjectReference PlayerActor = Game.GetPlayer()

What do you guys think of this? OBJECTREFERENCE not ACTOR ?

This could possibly be one of the many perils of multithreading. When using a variable, if the game is very busy then its new value may not be assigned before the AddPerk line runs, but by the time the second perk is to be added the value has been assigned. However, when the line is Game.GetPlayer().AddPerk(aadpShieldWall) it works because, in this instance, Game.GetPlayer() must return a value before AddPerk(aadpShieldWall) can run.

If I remember correctly, the absolute most efficient way of referring to the player is to use a property and set its value to the player reference in the Creation Kit itself.

ObjectReference PlayerRef = Game.GetPlayer will work because http://www.creationkit.com/ObjectReference_Script is an ancestor of http://www.creationkit.com/Actor_Script (the return type of http://www.creationkit.com/GetPlayer_-_Game, so it can be automatically cast. The downside here is that functions and properties available only to objects of type Actor will not be available. I guess in that particular script they only use functions and/or properties that belong to the ObjectReference type.

Cipscis

I thought that doing it that way was also dangerous because the REF can change? So assigning it periodicity would catch the player even when the REF changed.
I have no idea how it could change but that was a conclusion in the thread that I started months ago when we all talked about the best way to get the player.

I will see if I can find the thread again...

I don't remember seeing anything about the player reference changing (I was under the impression it was hard coded to be 20, or 0x14) but I've been absent for a while so I could be wrong. The "most efficient" thing is from a post by SmkViper, one of the devs. I'll see if I can find the actual post...

Cipscis

EDIT:

Here it is - http://www.gamesas.com/topic/1352280-most-efficient-way-of-referencing-the-player/page__view__findpost__p__20378748

Cipscis

See here:

http://www.gamesas.com/topic/1360171-playerref-gamegetplayer-or-do-it-in-properties/page__view__findpost__p__20520338

Example: Mod where you go to sleep and dream you are a child, that child actor object reference is now the player, the "PlayerRef" would no longer point to the correct actor.

Vanilla example: And what about the werewolf or the new Dawnguard player Vampire?

I am not claiming this is true I am asking if it is.


Maybe it would be best to do this:



While PlayerRef == none || PlayerRef.gettype() != 62 || !Playerref.haskeyword(actortypeNPC)
PlayerRef = game.GetPlayer()
endwhile

As far as I know, there isn't any way to change the player's reference and it's a hard-coded aspect of the engine. If you open up the Creation Kit but don't load any data files, you'll be able to see that the player object (hard-coded with formID 0x7) is already there, apparently with a count of 1. The Creation Kit doesn't seem be entirely functional without any data files loaded, though (for example, nothing shows under "All"), and I can't find the player reference here.

The player reference can be found once Skyrim.esm is loaded, though. For example, if you set up a condition using GetIsReference you can use the filter to find "PlayerRef", with formID 20 (0x14). As far as I'm aware this is hard-coded and will never change. If the player appears to change into something else (like turning into a werewolf or vampire lord, or like when you in Fallout 3) their reference doesn't change, but instead the player's data (like their race) is manipulated.

Of course, I could be wrong about this, but unless someone has encountered a case in which the player's reference changes or a dev can weigh in and say that I'm wrong, I'm pretty confident that this is correct. Confident enough, at least, to rely on this assumption in any mods that I would create and release.

Cipscis

ok, but then why would the DEV SmkViper advise us to use actor REF = Game.getplayer() ?

Or was he/she only saying that was the "fastest" way to do it, not necessarily the best?

Anyway, I think instead of editing my 50 plus scripts with new properties I will just add this to each one (much less of my time to do and it would seem to cover all bases we are talking about here) :


While PlayerRef == none || PlayerRef.gettype() != 62 || !Playerref.haskeyword(actortypeNPC)
PlayerRef = game.GetPlayer()
endwhile

I wouldn't recommend calling Game.GetPlayer over and over like that. I'm curious, does this work?

Actor Function ReturnPlayer() global	Return Game.GetPlayer()EndFunction; ...PlayerRef = ReturnPlayer()

Cipscis

He'd stated http://www.gamesas.com/topic/1352280-most-efficient-way-of-referencing-the-player/page__view__findpost__p__20378748. Might have just tailored the code to match the code on the table at the time. A PlayerREF property is about *1,000 times faster/cheaper than Game.GetPlayer() it turns out.

*

• PlayerREF Property
  

  Actor Player = PlayerREF

  [08/24/2012 - 02:24:30AM] Start test 0: 37.743000, Iterations to complete: 10000[08/24/2012 - 02:24:30AM] Finished test 0: 37.778000, Iterations completed: 10000[08/24/2012 - 02:24:30AM] Time elapsed for test 0: 0.035000[08/24/2012 - 02:24:30AM] Approximate time for each iteration: 0.000003

• Game.GetPlayer()
  

  Actor Player = Game.GetPlayer()

  [08/24/2012 - 02:25:10AM] Started test 1: 42.814999, Iterations to complete: 10000[08/24/2012 - 02:25:10AM] Finished test 1: 77.383003, Iterations completed: 10000[08/24/2012 - 02:25:10AM] Time elapsed for test 1: 34.568005[08/24/2012 - 02:25:10AM] Approximate time for each iteration: 0.003457

Well it is not a matter of how fast it is, because I only do it ONCE in the script.

But per the thread : http://www.gamesas.com/topic/1360171-playerref-gamegetplayer-or-do-it-in-properties/page__view__findpost__p__20520338
There was at the time a question about the reliability of using a property, and a danger of making actors persistent as well (for other actors, not the player).

However if there is no question NOW that the Player ref can change then I will "start" to use that now. But I am not going back over 50 scripts and making that change when I can just paste in:


While PlayerRef == none || PlayerRef.gettype() != 62
PlayerRef = game.GetPlayer()
endwhile

And this will NOT be run over and over and over UNLESS PlayerRef = game.GetPlayer() refuses to get the player. If that happens I have bigger issues than the script slowing down.

I was wrong about what SmkViper said, I think I was thinking about how THERE ARE NO BETHESDA SCRIPTS (that I have found so far) that use a property, they all use getplayer()