jshepler

So what was the problem?

No, you had it right before. Those methods take a Form, which Armor extends so that should be ok. I was referring to the necklace that script is attached to. When you attached the script to the necklace in the CK and loaded a savegame, I don't believe that script is automatically added to any existing necklaces. Scripts attached to Form objects are only attached to instances of those Form objects when at the time the instance was created. So I was suggesting that you spawn a new instance of the necklace and equipping that instead of the existing necklace you already had. Assuming my understanding of how this works is correct.

Yeah, that's fine. There are limited options to choose from, none of them perfect. There some other potential issues related to time... "Real time" is number of seconds since the game launched. Period. Meaning, it's not paused when the game is paused (e.g. in a menu). It does not advance with waiting/sleeping or anything else that affects game time. Saving games and loading games doesn't affect it. And, as we've found, it inherently resets when the game is launched. It's the absolute worst thing to use for this... ... except it's in seconds. "Game time" is completely different and is exactly what should be used, except it's not in seconds. It's in days. Granted, it's a float, so technically it can be used. If the precision is high enough, the "diff" (as a very small fraction of a day) could be multiplied by 86400.0 to get seconds to compare to the stored cooldown (or divide the cooldown by 86400.0 to get days, but divides are much slower, especially floating point divides). Time to do some tests...

Yes, the global cooldown is how long no shout could be cast, but super short like a second or two. I thought it would represent the player having to draw in a breath before shouting again. The bug might be from saving the game. I use GetCurrentRealTime because it returns seconds, but it is the number of seconds since the game launched. So, after playing for a while, saving, quitting, launching, loading, the saved timestamps would be large but current times would be small, resulting in negative numbers when calculating the difference. The code is assuming (i.e. not validating) diff will always be positive. It would end up calling SetVoiceRecoveryTime with a large negative value which probably jacks it up.

I think I see what you're talking about now.. If I don't wait for the shout animation to finish, it doesn't let me change shouts, but I don't think that's because of this mod as the game does the same thing without it.

I've updated the script to add a "real" global cooldown of 1.5 seconds. I want to make it configurable in-game. I still need to figure out how to determine if the spell cast was from a shout or not; otherwise casting a normal spell triggers the gcd. I also want to add groupings such that a group of shouts share a cooldown. For example, grouping shouts into damage, buff, debuff, utility where each group shares a cooldown. And I want that configurable in-game. Not sure what the problem you're describing is. I haven't noticed any problems doing a shout and being able to immediately change shouts using favorites or the magic menu. I haven't tried hotkeys yet. Put a Debug.MessageBox("boo!") after the part of the code that saves shout info. It should immediately pop up when you shout (it does for me). I'd be interested in seeing anything else you do with this.

If you're loading a savegame where you already have the necklace from before you attached the script to it, I believe the necklace won't have the script. Because it didn't exist at the time it was spawned, it wasn't saved with the script attached, it won't be there when loaded. Try spawning a new necklace and equipping it.

True, it probably wouldn't stick. Maybe create a new magic affect with the script attached to it and apply the effect with an enchantment? Even still, if we can't access scripts attached to objects inside containers, it's kind of moot isn't it?

I've been thinking of a better way to get your armor script onto armors without having to manually attach them in CK. First of all, holy crap the truckload of armor objects to edit and attach a script to... But mostly because I think it would conflict with any other mod that also directly alters vanilla armor objects. Plus any mod that adds new armors wouldn't benefit from your mod. Lastly, you had mentioned before about it not working on pre-existing armors. Presumably because scripts directly attached to base objects (forms) are only added to instances at creation. Since they didn't have the script when the game was saved, they're not going to get the new script when savegame is loaded. By dynamically attaching the script as needed, all those issues aren't issues. So far, the only way I've seen to do this is by attaching a ReferenceAlias script to a reference alias and then setting the target of the alias at runtime using ForceRefTo which effectively attaches that ReferenceAlias script to the ObjectReference. Anyways, just some thoughts I had. Not sure if anything would pan out from it. I'd like to see your modified code, if you wouldn't mind. Reading other people's code helps me learn.

I believe you can use a ReferenceAlias with Fill Type set to Find Matching Reference, In Loaded Area, Closest, with a match condition of IsHostileToActor.

I think these might get you in the right direction... http://www.creationkit.com/OnObjectEquipped_-_Actor http://www.creationkit.com/AddItem_-_ObjectReference http://www.creationkit.com/EquipItem_-_Actor

Well, there's http://www.creationkit.com/Dynamically_Attaching_Scripts but I didn't care very much for it. I probably don't know enough yet to, uh, properly appreciate the samples. I was thinking along the lines of having script A on the player to handle OnSpellCast that would call out to the ReferenceAlias script B passing the spell, which would do a Self.ForceRefTo(passedInSpell), at which point script B is now attached to the spell just cast. I don't know if that's how it actually works or not, it's just an idea.

I don't really know, I haven't done one yet, but it looks like you attach the script to the trigger, not the marker or quest. Also, it looks like you resize the trigger to cover the area you want. OnTriggerEnter would/should fire when an actor enters the area - you shouldn't need to also call GetDistance.

How about a ReferenceAlias script and calling ForceRefTo ?

http://www.creationk...ObjectReference is the direct answer to your question, but I think you might want to consider a volume trigger so that you wouldn't have to constantly poll the distance.