DrakeTheDragon

Hmm, that looks pretty straight forward to me. It simply exchanges the contents of the NPC's inventory with a temporary holding container, activates this one so you can exchange it contents, and then after you closed it exchanges them back into the NPC's inventory. Equipping the new stuff is done by the NPC itself, which sounds totally fine and legit. It should not be able to prevent OnEquip events from triggering. There's some major trouble with the line "Begin OnEquip self", which could very well be the explanation for it "sometimes" working sometimes not. "Begin OnEquip self" means execute this block whenever the item this is running on gets equipped by the actor reference "self". I told you already "self" cannot be expected to be initialized or even pointing to its current wearer, thus a line such as this is bound to fail many times. If the item got added and equipped in the same frame, so the GameMode block wasn't executed before the item was equipped, "self" will not hold the actual wearer, yet, and the event will never trigger! I'd just use "Begin OnEquip" instead. Now, where are we at? What's already working and what still isn't?

Keep in mind different games sites have a different range of tags. As we're in the "site" suggestions and questions section here, you at least should consider adding the "game" you're talking of. You mentioning "femdovakins" gives a hint, but don't expect anybody to know this right away. Eiries is right though. A quick look through the Skyrim tags available and there very well is a tag for male armor, female armor, male clothing and female clothing individually already. On the other hand though let's also not forget the many mods which are as of yet not tagged at all or not yet tagged for everything they contain. Tag search depends on people tagging mods, which is a voluntary business after all.

Look a little further down, about three times clicking "more...", starting around "16:53, 30 Jul 2012", there you'll see logs of you "endorsing" several images. However, as you're complaining about it "now", I take it as rather unlikely the last time you endorsed an image actually was "16:53, 30 Jul 2012". This reminds me that a post I made last week still isn't in my posting history by now. I know it will be inside there at least by next week, but that's still a little late, if you ask me. Seems user activity on the sites/forums still takes its weeks to get registered by the several tracking systems involved is all.

Hmm, I mixed up the Message you're using with a MessageBox call. My bad. That's different behavior for the two. Yes, you can use this OnEquip approach just as fine. Variables exist for the whole script. All blocks share the same and as such have access to the same values. Setting "wearer" to something in the GameMode block makes "wearer" also accessible from inside the OnEquip block. The trouble with the Message call not appearing for an NPC perhaps lies within the fact that you cannot always compare "player" and "self". A condition like "self != player" is not always guaranteed to work. The WiKi advises to use "self.GetIsReference player == 0" instead. So maybe this will help. The same comparison worked for you before though, so that's not very likely the problem. Oh, but I just realized "self" is not necessarily initialized in this case. It could help adding the "set self to GetContainer" line at the start of this block, too. Just so it is always initialized by all means. And coming to think of it, it depends on the inner workings of the inventory exchange mod you're using if the OnEquip block will be called at all. If the NPC itself decides to equip the item, so the mod only exchanges inventory contents, it will be fine. But if the mod uses the old "EquipItem" calls to force-equip those items onto the NPCs, this will fail. EquipItem does "not" trigger the OnEquip event. (I learned that the hard way.) I'm still clueless as to why the script I posted doesn't cease to display the Message though. Putting the wearer into the faction and only displaying the Message when this is not the case should work the same as a do-once condition. Technically it "is" a do-once condition. Yet, it still doesn't work as one... something must go wrong behind the scenes. Or the condition line is messed up but still compiles. For some cause the game doesn't like multiple function calls in a condition. It always mixes up what's a function parameter and what's another condition then.

Hmm, while you could solve this task via an enchantment as well, saving you the need to check the container for if the item is worn (if it is worn, the enchantment runs, else it won't), it won't help you much with your current issues. I don't know if there is a way to detect when the enchanted item is unequipped at all in enchantments. Right now I see no way for the enchantment approach to remove the no-longer-affected actor from the faction again. ScriptEffectStart blocks always work, execute once as soon as the spell effect gets applied, and never repeat, ever. ScriptEffectFinish blocks act the same, just when the spell effect runs out, but I don't know if they're even triggered at all when an enchanted item gets unequipped/dropped/whatever! ScriptEffectUpdate blocks, in my observations, turned out absolutely unreliable, period. You cannot tell if they will execute or not in all cases, and do not expect them to "regularly" repeat either. Plus neither do I know if they're even executed in an enchantment at all. So, from my point of view we're back at a GameMode block, repeatedly checking for the affected actor having the item equipped, for the scripted effect spell the enchantment uses anyways. And this time, when you unequip the item, the script of the enchantment "dies", stopping execution right on the spot and taking all stored variables with it. There is no way an unequipped item could remove you from the faction via an enchantment approach, as while not worn no script will exist. You're pretty close with what you have already. Why not stick with what's already working? Scn ATPrisonerCollarScript ref self ref wearer Begin GameMode Set self To GetContainer if ( wearer != 0 && wearer != self ) ; container changed and still has reference to previous wearer wearer.SetFactionRank ATPrisonerFaction, -1 set wearer to 0 ; delete reference to previous wearer endif if ( self.IsActor == 0 ) ; item got dropped, previous wearer got removed from faction by previous check in this case, too Return endif set wearer to self ; store reference to current wearer if ( ( self.GetEquipped ATPrisonerCollar ) && (self.GetFactionRank ATPrisonerFaction < 0 ) ) self.SetFactionRank ATPrisonerFaction, 0 if wearer != player && doOnceNPC == 0 Message "NPC has been added to the faction", 5 elseif wearer == player && doOnce == 0 Message "You have been added to the faction", 5 endif elseif ( self.GetFactionRank ATPrisonerFaction >= 0 ) self.SetFactionRank ATPrisonerFaction, -1 endif End That script should do, and also pop up the message only the first time the collar gets detected as worn while it is worn, as the actor now is only put into the faction once when he's not already in it. If you put on the collar, whether on yourself or an NPC, the messagebox should pop up, only once. If you take it off and put it on again, again the messagebox should pop up, and again only once. (That is only if GetButtonPressed actually works the way I expected it to work in this script.) Is this coming closer to what you had in mind? edit: Hey, just realized the whole "do-once" stuff and button checking is no longer needed at all now that the whole "put into faction"/"remove from faction" business is also only happening once each time! (cleaned up the code accordingly)

While there is no such 6-limbed dragon in existance on Nirn, all Nirnian dragons are of wyvern anatomy by design, I personally couldn't care less about this so-called "lore". I know of a few attempts into this direction in the past, but as far as I know none of them was finished, yet. It is rather difficult to create a whole 6-limbed skeleton, a properly rigged dragon mesh and a complete set of 6-limbed movement-, combat- and idle animations, all more or less from scratch, and I know only a handful of people capable of doing this. Most of them proceeded to Skyrim already by now. (I am no longer counting myself to this group, since my "poses" always turn out acceptable and fitting, but my "animations" look like crap. This total lack of free time lately preventing any new projects of mine just adds to it.)

Hmm, that's a tougher one. These are the times I wish I could still start the CS to give it a try, but the game is installed on an external drive which is just on the verge of dying and I'm not going to power it up again before I have another one ready for backups. I think this could be handled by catching the response you give by clicking the ok button (GetButtonPressed should return "0"). Try adding these lines to the start of your modified script and see if it helps already: Scn ATPrisonerCollarScript ref self ref wearer short doOnce short doOnceNPC short button ; for storing the result of the messagebox Begin GameMode set button to GetButtonPressed ; store the result of the messagebox if ( button != -1 ) ; reset do-once flags when a button was pressed set doOnce to 0 set doOnceNPC to 0 endif Set self To GetContainer if ( wearer != 0 && wearer != self ) ; container changed and still has reference to previous wearer wearer.SetFactionRank ATPrisonerFaction, -1 set wearer to 0 ; delete reference to previous wearer endif if ( self.IsActor == 0 ) ; item got dropped, previous wearer got removed from faction by previous check in this case, too Return endif set wearer to self ; store reference to current wearer if ( self.GetEquipped ATPrisonerCollar ) self.SetFactionRank ATPrisonerFaction, 0 if wearer != player && doOnceNPC == 0 Message "NPC has been added to the faction", 5 set doOnceNPC to 1 elseif wearer == player && doOnce == 0 Message "You have been added to the faction", 5 set doOnce to 1 endif else self.SetFactionRank ATPrisonerFaction, -1 endif End In theory, or going by documentation, GetButtonPressed should return a value != -1 the first time it's called after the messagebox closed. If this doesn't work the way I did it up there, try adding a MenuMode block instead and catch it in there. I always call my messageboxes in GameMode and catch their result in MenuMode, which you're in while the messagebox is open. But if the documentation is right, it can also be done in GameMode, which you return to anyways right after the button was clicked and the messagebox closed. I have no way to test this though. edit: No, wait a second. The bottom part of the code will execute over and over again, putting self into the faction again and again, and popping up the messagebox again and again. A check if self already "is" in the faction (e.g. faction rank >= 0) becomes really mandatory here.

Sounds similar to how it was with Oblivion. Plugins created with a new version of the Construction Set (v1.2 and up) "didn't exist" for a game version lower than 1.2. It ignored their presence, activated or not. You not updating your game likely means you also didn't update your CK. So now you can use the plugins you create with your outdated CK in your outdated game version quite fine still, but plugins created with a newer CK won't be readable by an older game version anymore. I haven't seen any mods stating which official game version they require anymore since years back, and quite honestly, considering the frequency in which Bethesda spits out new patches, it's highly unlikely for this to happen... unless you need to regularly update your plugins anyways for them to keep working with a newer patch... but that'd be a nightmare of a design decision.

While the "ideas" and concepts from DLCs can always be "reproduced", putting actual "contents", as in meshes, textures, sounds, etc. from a DLC into the Vanilla game without it "requiring" the DLC to be installed, is highly illegal, similar to piracy of DLC content. To the example of crossbows, all of those mods "require" the Dawnguard DLC to work. The whole crossbow system is already provided by this DLC, adding your own crossbows to it using this system is much easier than recreating an own crossbow system from scratch. While it could be done, most authors likely don't see any need for it, while DG already provides all they need. and the 4 random examples above: - requires Hearthfire - requires Dawnguard - requires Dawnguard - requires Dawnguard so all of them are fine and legal.

And never forget about the Official Patches. A game version other than 1.2.0416 shouldn't be used anymore at all. Most ESPs/ESMs nowadays were created with a recent v1.2 Construction Set. Any game version lower than 1.2 will just "silently ignore" these plugins/master files! There will be no errors or warnings, it'll just be as if there were no such files. Game version is the very first thing I'm asking for when reading of "mods contents don't show up" these days. File and folder trouble only comes into mind when it's resource files missing. If it's actual plugin-added content not showing up, while the respective plugin was very well activated and all, the files can impossibly be missing/misplaced or the launcher won't have found them to begin with.

That's the files I meant, technical term "loose files", as they're normally contained within the BSA files and only a mod replacing them will place them outside into the folders, loose. The original game doesn't contain those files or even the folders "meshes", "textures", etc., outside of the BSAs, and as such Steam can impossibly "revert" them. The trouble comes from making the game use the loose files over the ones inside the BSAs. For disc Oblivion to do this one only needs Archive Invalidation for textures. But with Steam Oblivion one needs Archive Invalidation for just about everything, PLUS the too-recent BSA file dates will prevent this from working until fixed as I explained. The UAC issues Hickory's aiming at come with actually "placing" the loose files into the folders. It's highly likely they will be put into some other place, a compatibility folder or what it's called, instead and not even end up inside the folders you put them into to begin with. "program files", "program files (x86)" and the likes are far too over-protected in this regard. But if the loose files indeed are inside the correct folders and still won't work, it's the issue with using loose files over BSA contents I mentioned to blame for it.

No need to apologize. I wonder why it didn't work on the player, if it previously did, as that part of it wasn't even touched. "wearer" is always set right after the "if self.isActor == 0" block. So if "self" is an actor, "wearer" stores a reference to it. However, you're right, I actually missed the very purpose I explained that much in detail. "self.isActor" will never be "0" under your conditions, as you're in MenuMode while the temporary holding container is open and the check will not run, and when you close it, the items either go back into the NPC's inventory or into your's. They will never be "dropped" that way. My check only serves a purpose, if You, the player, actually "drop" the item to the ground without unequipping it. That's the only way "isActor" could return "0". It should rather be used in a "self != wearer" approach, to check if the item switched from one's inventory into another's, which is what happens when using the temporary holding container to access NPCs' inventories. Let me see... maybe this will do better: Scn ATPrisonerCollarScript ref self ref wearer Begin GameMode Set self To GetContainer if ( wearer != 0 && wearer != self ) ; container changed and still has reference to previous wearer wearer.SetFactionRank ATPrisonerFaction, -1 set wearer to 0 ; delete reference to previous wearer endif if ( self.IsActor == 0 ) ; item got dropped, previous wearer got removed from faction by previous check in this case, too Return endif set wearer to self ; store reference to current wearer if ( self.GetEquipped ATPrisonerCollar ) self.SetFactionRank ATPrisonerFaction, 0 else self.SetFactionRank ATPrisonerFaction, -1 endif End That should be more robust now and serve the actual purpose. Sorry for the confusion last time.

Going by the last script posted it won't even work for the player, if you don't "unequip" but "drop" the item. As you cannot interact with NPCs' inventories by default, the mod you're using drops all their belongings into a temporary holding container you can interact with and when you close this container again it will drop all its contents back into the NPC's inventory. When an item is "dropped" though GetContainer will return 0, as it now has none anymore. The reference to its previous wearer is lost and as such the wearer can't be removed from the faction. How about you define an additional "ref wearer" and modify your code the following way: Scn ATPrisonerCollarScript ref self ref wearer Begin GameMode Set self To GetContainer if ( self.IsActor == 0 ) ; item got dropped if ( wearer != 0 ) ; still has reference to previous wearer wearer.SetFactionRank ATPrisonerFaction, -1 set wearer to 0 ; delete reference to previous wearer endif Return endif set wearer to self ; store reference to current wearer if ( self.GetEquipped ATPrisonerCollar ) self.SetFactionRank ATPrisonerFaction, 0 else self.SetFactionRank ATPrisonerFaction, -1 endif End This sure can be further improved on, but it should do what you want for now. Even if dropped, the item is still able to remove its previous wearer from the faction.

Steam's more than unlikely to replace any "loose" files. The game doesn't have any loose files apart from music tracks. Everything is stored inside the BSA files (Bethesda Softworks Archive, or something like that) and used from inside there directly. What could be happening is the loose files you installed won't be used by the game, as it will prefer its BSAs' contents over loose files all the time. This is a rather common issue with Steam, preventing any "replacer"-type mods from working at all. The BSA timestamps are dated far too recently, and in Oblivion file date beats everything else, even Archive Invalidation. The newest file gets used no matter what. Steam's BSAs being dated around when they last downloaded will always win over loose files dated around when the mod author released his/her work. You will need to redate the BSAs back to somewhere around 2006 (or whatever retail Oblivion was). A simple way to do so would be by using the Oblivion Mod Manager's (OBMM) Archive Invalidation Utilities and clicking "Reset BSA timestamps" once right before applying BSA Redirection for Archive Invalidation. Or do you have any signs of Steam actually "downloading" loose files which never were part of the game to begin with?

Looks like this situation to me. Can't hurt checking your preferences.

Re-read the EULA. Non-exclusive rights =/= ownership.

Biggest issue of all, such option cannot be applied "after the fact". When a mod author published his/her mod here on the Nexus agreeing to specific conditions, trusting on all rights being protected by these even in his/her absence, said conditions can neither be changed nor expanded while the author is away. As this discussion is all about authors who left the scene a long time ago and aren't responding to permission inquiries since months, it won't be of much use now to introduce such option. Said author will have to explicitly agree to the alterations him- or herself in person or the option is void. How would You feel coming back after 4 years of unvoluntary absence, just to be greeted with "Sorry, pal, they changed the rules while you were away. All your stuff are belong to us now!"? :blink: I for one will take special care that, should I ever really have to leave the scene for an unforseeable time, I'll give appropriate permissions for my stuff's reuse in my absence (oh, wait, I already did!)... but that still doesn't mean everybody who didn't can safely be robbed of all his/her belongings only because of being absent now.

I'm having a little trouble here understanding why people keep thinking (and telling) this "new" system was strict or tight or anything, while all there was done was improvements to the moderation "tools" and more means to "warn" before banning. As a matter of fact the rules are still the same they were for years. There's just another layer of warnings before bans now, so bans will actually occur "less" often than before, not more. After years of so-called "harsh" moderation, zero-tolerance, no-strike zones etc. they come up with a system allowing for more leniency and people call the "improvements" strict, harsh, whatever? Doesn't make much sense. (Guess it just shows how few people actually were aware of the rules before.)

Any such threateningly drastic change to the ToS, like restricting or waiving authors' rights on upload as you depicted it, will require a majority decision to get implemented. Judging by past discussions of the matter you will never get the majority of mod authors to agree with this. From my point of view it's a slap into the face of authors even suggesting it. But I'm a little on the protective site when it comes to other authors and my point of view is generally irrelevant. Prepare to get massive fire from other sides soon though.

Another one of those topics... While I'm all for informative, descriptive, well-written descriptions and readmes, and usually write mine that way as well, I fail to see why I shouldn't be allowed to express my disappointment with the way Bethesda again and again half-arsed implementation of certain features in my descriptions, if I feel like doing so. I don't and usually won't, although I could ramble on and on for several pages worth of well-founded complaints, but I don't see why I shouldn't be allowed to. I for one would never use that word though. No, sorry, you are not. There is no such thing. I'm releasing my mods after I created them, because I was asked to share. I am "not" creating them with releasing in mind. "Creation" always comes first, then maybe "releasing" follows afterwards. Once you start "paying" me, so I become somewhat responsible for what I create to you, you may call yourself "target audience". But as it is forbidden to give mods for money, that's rather unlikely to ever happen. Not that I would even accept it, if it wasn't. I'm not even "targeting" a release, so how could there possibly be a "target audience"? Oh, yes, please do! I don't give a damn if someone uses my mods or not. Not that I would ever put a line such as this into my description, but that's besides the point. +1 for no longer sharing my mods in public. Keep these topics coming. We're getting closer.

Sure, I have a "single" mind. I'm not into a multiple personality disorder. Maybe I am "arrogant", but do I care about what others think of me? No, not the slightest. Maybe I am "invalidating others viewpoints", but only in my mind and only for me. It's my damn right to have a mind of my own, and only I decide what's going on inside there. What you just called me shows you know nothing about me and just proves the others' points. Thanks for all the name-calling hidden inside a wall of gallant words, but it won't work with me. Personal attacks and insults like this have no effect on me. And you won't see me returning the favor, ever. My viewpoint is just that, "mine". Others may take it and use it as their own, if they must, but I'm not making anybody do so. What's going on in my mind and what I'm thinking of others does not have any effect on the outside world, nor do I want it to. My thoughts are "my" thoughts, my opinion is "my" opinion, they don't matter to anybody else but "me", "myself" and "I". I fail to see how this is "dangerous". But I'm not interested in further wasting my time and only receiving more insults in return either. The likes of You are not worth it.

-overly defensive post removed- I'm not a white knight. I don't care enough. The Nexus doesn't need my protection. Even talking to the likes of you makes me look like an idiot for the attempt already. It's not worth my time. You aren't worth my time. I really have to stop being so protective of others lately. I can already see myself end up with a knife in my stomach for preventing a street robbery next. Ever since I became a member here many years back, actually far longer than my joined date shows, I was never disappointed so far. While the new features mentioned here don't change it a lot from what it was, they still improve on the little important details. It's definitely yet another step forwards and I support it. The more transparency the better it is. Thanks, Robin and staff, for maintaining such a nice and welcoming place throughout all the years. While the Elder Scrolls community in general as of late might make me leave and stop sharing publically in the end, the Nexus will definitely be a place I'll stay around for longer. Thanks.

Is there a similar thing to an "Activator" in Skyrim? In Oblivion this task was usually solved through activators rather than creatures/actors, as they can cast spells, can have an invisible mesh (a NIF without content), but have no havoc or a "mind of their own", thus will stay in place wherever you put them or move them to, and they don't know gravity either. Just a thought. :unsure:

Not always are mods and images of banned users automatically removed as well. Usually they're only removed, if they were against the rules to begin with, or if the banned user requests their removal. I agree though, files which break the rules should not remain "under review" for an eternity, and mods under review shouldn't even show up in search results or category browsing. That'd be something worthy to consider for site improvements.

If it's not the technical issues with mods being "falsely" reported as "hidden by owner" which usually go away after one or more page refreshes, I could imagine you've fallen victim to some illegal uploads. Especially with Fallout/NV and Skyrim over the last months I've seen quite a number of users getting banned and their mods getting removed for illegally uploading/including content they had no permission for, or in the worst cases even infringing copyrights and risking legal actions being taken against the site for hosting them. Read up about "RIPs", assets from one game used in another, even if both games are from Bethesda, or using copyright protected materials in mods without permission, and why these things are not allowed. And keep in mind it's "not" just a Nexus thing. The site is only playing within Bethesda's stated rules here... not to risk the same fate as MegaUpload did.