Talk:Unplayable Items

I removed the following recommendation for placing a token more directly on the player:

(1) set tokenRef to player.PlaceAtMe MyPlayerToken 1

(2) tokenRef.Activate player

... [commands done on successive frames] ...

I can't remember if I actually got this to work - in theory it shouldn't. GuidoBot 20:15, 18 October 2006 (EDT)

---

It should be noted that token wasn't first used or first created in the game Oblivion, so no one should really be creditable for "creating" the token concept. However, one can be credited with creating the token concept "for" Oblivion. Reinhartmenken 16:28, 31 October 2006 (EST)

Dragoon Wraith TALK 20:18, 31 October 2006 (EST): In reality, there's no need to credit the technique at all... but for now, Guido's the only one actively editting and contributing to this page, so I think his opinion counts a little more than ours. If credit is to be given, it does make sense to just say that so-and-so came up with it, because the technique is kind of specific to Oblivion - there may be similar things for other games, but in terms of this particular technique, it's for Oblivion.

It's just reading the bottom portion of the great article I realized that it could be somewhat misleading because of the implications and the names named (note that those are great modders named, and I actually love both of them's work and are currently using their mods. I mean no offense to them), along with the wording. In actuality, another game I know of has exact use of the tokens used here (in Oblivion), adding abilities, used for checks, etc. But yes, since GuidoBot is actively maintaining it he has more say, I'm just voicing my concern, because this is for the entire community who views and maintain the Wiki. Reinhartmenken 19:49, 31 October 2006 (EST)

Dragoon Wraith TALK 01:57, 1 November 2006 (EST): Fair enough. The main reason I'm against crediting anyone with it is because lots of people came up with it independently; it's not exactly the biggest intellectual leap out there. For one, I certainly had the idea without knowing about JOG's PoC mods, but those mods were released before I remember having thought of the idea (came to me when needing work arounds for Danger Sense). *shrug* Matters little to me. Guido, feel free to post your thoughts.

I agree with you as you said that many individuals came up with the idea on themselves, and actually cannot careless about credits. I came up with it before I knew this was used in Oblivion too, instead inspired by NWN mods I've played in the past. I'm only against misleading miscredits (if one wants to credit at all).

Anyways, on a sidenote, I recall seeing the script that GuidoBot removed above, and remember using it in one of my private mod too, and it works. However, when used in succession for too many times (in my experience twice) can cause the game to freeze up combat keys (block, attack, cast) and crash when trying to load. One way to solve it is to delay the time between two "reference.activate" functions are executed; either by placing the other "reference.activate" function somewhere else in the script and use another condition to fire it (such as doonce, etc), or try to put some other script to fire before executing the next "reference.activate" function (haven't tried one of these, can't remember which, sorry). Just so you know, GuidoBot *wink* Reinhartmenken 01:03, 7 November 2006 (EST)

Thanks for the info. I believe this came from my early version before I was using a shadow to do much of the work. Looking back I doubted it because you are not supposed to be able to place unplayable items in the 3D world. The script above would now be the simplest way to add a token to the player w/o msg spam. It would also imply that tokens were yet another, and in fact the easiest, way to place invisible 'activators' in game. If you could verify these details it would make for an excellent additional comment to the article. GuidoBot 18:05, 15 November 2006 (EST)

Actually, I dont think the original notion of scripted tokens was that big of a deal since really they aren't much different from adding any scripted item to an actor. All you are doing is preventing it being seen in an inventory and, unless you use something like a 0-value ring, you still have to take steps to ensure it is not equipped. My initial interest started in a thread discussing the issues using ability-spells to add scripts to actors. I think the original term 'token' actually reflected adding (a number of) non-scripted items as a means to flag an actor. With respect to my knowledge I doubt anyone has had as much experience with using these to script the player as myself, at least not at the time of writing. Here they also have uses that are more related to being unplayable. For example, I have a pair of gloves that requires equipping of an unplayable shield to ensure I get an equipped message rather than an unequipped message. However, I'm sure now plenty of people have there own experiences and hopefully they will contribute to the article. GuidoBot 18:05, 15 November 2006 (EST)

Unplayable tokens on the player

I've found setting a token as a quest item allows the token to be on the player and unplayable (hidden). Without setting the token to quest the item seemed to disappear.--mmmpld 07:49, 27 April 2007 (EDT)

Token Help

My token's don't seem to be working. I have created a token to check when certain dynamic NPC's die and then process code which removes them from the game. Pretty much my procedure at present is as follows:
1.Activator which summons the NPC's
2.Create's FullActorCopy's of persistant ref's in a dummy cell
3.A new reference is given to the copy (so the original is never touched)
4.Copy is moved to a location near the player, token is added
5.I duel the summoned copy to the death
6.The token's script should fire upon my success

But it doesn't very frustrating, Can anybody help? I can post my scripts if necessary. Here is the script on my token (the one on the activator seems fine as it behaves the way I want it to):

scn RSTokenScript

ref Holder
short DeathTimer

Begin OnAdd
 Set Holder to GetContainer
  Holder.Kill  ;this was a debug line to see if the OnAdd block was firing, being dead is rather visually cognisable
End

Begin GameMode
If Holder.GetDead == 1
 Set DeathTimer to ( DeathTimer + GetSecondsPassed )
  Holder.SetDestroyed 1
 If DeathTimer >= 3
Message "The corpse of your opponent has been disposed of"
 Holder.Disable   ;I know that this line is rather redundant, no need to tell me
  Set DeathTimer to 0
   Holder.DeleteFullActorCopy
endif
 endif
End

If you are wondering the DeathTimer is so that the Holder isn't disabled instantaneously after dying, the timer allows them to fall to the ground and stuff.
--Antares 09:26, 15 October 2008 (EDT)

Found the source of my strife, DeathTimer needed to be a float and not a short. Got a new problem though, the game crashes when the actor is disabled/deletefullactorcopy'd. Anyone got any ideas?

--Antares 10:41, 15 October 2008 (EDT)

Confirmed the problem is when the FullActorCopy is deleted, A CTD occurs. Yeh, help.

--Antares 10:47, 15 October 2008 (EDT)

Just a guess: DeleteFullActorCopy may cause the token to be destroyed while its script is still running. Try, instead, moving the Holder to the hidden cell, just to see if this is the cause. Or maybe, somehow, run DeleteFullActorCopy from another script (not the token script). QQuix 11:18, 15 October 2008 (EDT)

I had theorised that destroying the holder from a script that would be terminated by the deletefullactorcopy function may be the cause of a CTD. I am going to attempt to call it from another script and see how we go. Thanks for the help

--Antares 20:56, 15 October 2008 (EDT)

I got it to work using a quest script, I originally tried using a spell and utilizing the ScriptEffectFinish blocktype to destroy the copies, this produced results (see this talk page for more info) that were less than satisfactory.
Using a quest script I reckon is the only way to go. Thanks for your help, it now works pretty flawlessly.
--Antares 22:47, 15 October 2008 (EDT)

Little confusion...

the section Properties of unplayable items states in its point 3: Local variables are persistant. Scripted spell effects and abilities reset when the actor comes into scope (same cell) as the player, meaning any local variables are re-instantiated (to 0).

Assuming the Actor in question has some scripted token (unplayable item) in its inventory, are its script's local variables persistent or not? The citation says so, but then it explains this with a totally irrelevant issue with spell scripts variables by concluding that they are not persistent (re-instanciating to 0 when getting in scope means the OPPOSITE of "persitance")... If we try to follow the sentence, can a spell be a "token", and if so, how can a spell be "unplayable"? I don't understand, all I can dig here is that a token script's local variables are persistent, as well as that they are not persistent.. ??? --HawkFest 22:36, 22 October 2008 (EDT)

Different meaning of persistent? A local/persistent point of view doesn't work for variables. Anyway - spells have a nasty habit of resetting to 0 when the actor leaves the cell... I suppose they'd need to re-enter before you could tell if they're 0 or not, but a problem either way. That's all you need to know from that.

--Haama 01:59, 23 October 2008 (EDT)

Thus could we conclude as such: spell local variables are not persistent, whereas token (unplayable inventory item) local variables are persistent? I was confused because the sentence explained an opposite behavior of the subject in matter (talking about spells where tokens were the issue, thus the confusion about any conclusion we could dig out of this)--HawkFest 17:51, 30 October 2008 (EDT)

Correct (just remember that this is persistence in the sense of keeping the variable value, not the usual sense of staying in memory and able to access directly with dot syntax). Changed the wording, hopefully better.

--Haama 01:18, 1 November 2008 (EDT)