Hoamaii

@ Cumbrianlad: my, you're right, you can apparently transform collision objects when they're in a NiNode block... I had never even tried that. And the game doesn't complain too much about that? Good tip, thanks!..

Oh yeah, excellent question!.. My bad, I should have been more explicit than that!.. Short answer: just to be safe, yes - just put a piece of floor static anywhere under the cell's current floor or beyond the walls, and move both the actor's REF and its marker on that piece of floor. But there's no real short answer to what you're tyring to do, so: Not so short answer: static objects are not subject to havok, so if you'd be moving a piece of static furniture or wall out of your way, they would have never budged from there in game. Best example of that is the Khajiit caravans' containers which lay underground under their camp - in some instances, they're positioned so close to the "surface" that you can activate them without even "seeing" them. They don't need to be placed on a piece of floor to remain in place, they have their own collision. Actors, however, like armors, weapons, miscobjects, etc., are subject to havok when loaded in game and not disabled - I guess the best example of that is what we've all seen in the Vanilla game: some guard falling from the sky when we use "coc Riverwood" console command. Often, unique actors which first appear in game when called by a quest are set to be "initially disabled" in the CK, to be later enabled and teleported to their marker when the quest starts. In that case, preventing that quest to start is enough to keep he actor disabled forever. But if your modded actor is not enabled by a quest, yes, he'd very likely start falling forever the minute you load that cell until he finds some collision object to stop his plunge. So yes, if you move any non-static object outside the visible boundaries of a cell, do place him on some collision object. EQUALLY IMPORTANT: make sure that actor is not going to run some package that'll get him to sandbox. So find that actor in your object window, double-click to open it and go to the "AI packages" tab. If they're any package in there, remove them. Now right-click in your now empty packages list and choose "add". In the list of packages to add you'll have to choose from, look for "MQ105DoNothing", select it, click "ok". Now double-click on that "MQ105DoNothing" package you've just added to your actor, that'll open the Package form which you'll rename to "_PM65_MyActorDoNothing", click ok, the CK will ask if you want to create a new form, click "yes" (NEVER edit a Vanilla asset, always create your own forms): you custom package has now been added to the package object window. Back to your actor's package list, now delete the "MQ105DoNothing" package (we just added it there to use it as some template), and add your newly created "_PM65_MyActorDoNothing" package. Double-click to open it again, make sure everything's unticked in the "flags" tab and that all schedules are set to "-any" in the schedule tab. Click ok, now your actor is set to never move from where you've placed him. Finally, go to the "scripts" window on the left side of your actor's form, and make sure that your actor is not running any script - in other words, that window needs to be empty. You should be ok, I guess, now - but again, I've never done this to my game (killing non-unique actors always seemed like an easy solution... :wink:) - and I'm not seeing what this mod you're editing does nor how it is built. Chances are the author created this actor for a reason, other than decoration... Like CumbrianLad said, do not edit the original mod, create your own plugin which edits that mod and make a clean save before you add it to your game, so you can return to that save in case your edit breaks anything. Often, edits like what you're trying to do do not induce immediate bugs, it may bug many saves later, when the original mod finally calls for that actor to do something... Good luck!

@ Cumbrianlad: ah, I remember when I started modding, more often than not the modding jargon (like reference, instance, form, object, etc.) did not have a clear meaning to me... Takes time to get into it!.. :wink: @ Poorman65: yup, exactly - that's why you don't want to move it into some other cell, you want to keep him and his spawn marker in its origin cell, but just under the floor if he bothers you so much. The origin cell of an NPC is just as important info to the game as the actor's Ref ID. An actor ID is a form ID, forms get never placed into the game, only instances of them (like copies of the original form if you prefer). If you click on an NPC in game, you'll see that the Ref ID you get is never the Form ID. At runtime, the game essentially deal with ref IDs. When you reference an actor as property in a script, the game needs both its origin cell and its ref ID to know what NPC you're pointing at. For all the game cares, you could shrink it to 1/10 of its size and hide it under a bed, but whatever you do keep it in its origin location. Good luck!

Well yeah, it'd sure make our lives easier if we could "glue" all meshes we need together to create a new one - but I haven't seen anyone able to do that. In the CK, you can still select a good number of objects together in the render window by holding Ctrl and clickin on all the objects you need, then select "copy" and "paste" them together in some other cell (provided the CK doesn't crash in the maneuvre!..) But in nifskope no way. Each object has its own collision node and you can't really move around collision in Nifskope. You'd probably need to import all meshes one by one in a 3D program, place them as you like, and create a completely new bkhRigiBody covering the whole thing - if anybody's managed to do that in Skyrim, I never heard of it. But you could ask Tamira, she ported a lot of Oblivion's modders resource houses to Skyrim, she sure does know a LOT more than most of us about houses and collision. Good luck!

Oh, I'm pretty sure "PathToReference(...)" fails completely in non-navmeshed places. It fails for both player and NPCs. That "straight path" it draws between its initial position and its target is usually what you get when you test a cell's navmesh with "Test Navmesh" or "Toggle Preferred Pathing". I tested it plenty in MannyGT "GrayCowl of Nocturnal" mod (most dungeons where he didn't place enemies are not navmeshed, which means unplayable for NPCs but not for the player - call a package in there and you get completely stuck). Also tested it in some of my mods' holding cells before navmeshing them, NPCs never budge from the COCmarker. I'm still testing stuff and making some progress (at least I think...) - I'll probably create a new thread when I get some consistent results.

Not to add to your stress but you really should be careful with that, even if it's just tweaking some other mod and not the base game itself. Click on your Actor base in the CK and go for "Use Info" tab. That'll tell you where in the game that actor is being used and needed. If it's a quest, package ,scene or dialogue, I'd advise you don't touch it if you don't know how to modify these to cleanly remove your actor from them. However if you find only 1 use for it, like it's placed in some cell for Editor Location, Load that cell in the CK, your actor's ref is probably linked to a marker just to make sure he spawns at the right place in game. What you can do then rather than disabling it, is move both the actor and the marker under the floor or behind the walls of your cell. That way, you'll no longer see him in your game, but the game should not complain about it. One note about deleting forms in the CK (other than the "you should never do it if it's not your own mod" N° 1 rule): marking a form to Delete in the CK is like deleting objects in game (not recommended either unless placed at runtime), the program only really deletes them when you close it. So after marking a form for deletion in the CK, you need to exit the CK first. Next time you reload your mod in the CK, the deleted objects will be erased for good from your mod.

Just use "AddItem(...) on your actor script, the game will create a new instance of your object form and the other instance already placed in your chest will stay there. AddItem is basically a COPY(myForm) / PASTE(an instance of MyForm) kind of function.

Hey Max, thanks!.. Yeah, that's why I have only ever used "PathToReference" in cells where I had completely redone the navmesh so far. From my experience however, packages can have the same issue, if the actor encounters a navmesh island which prevents them to "Travel" to their destination, the package never completes - but at least you can stop your quest when that happens. Before I completely give up on packages, I'm going to try and use a different animation set first, and another furniture mesh as well - I'm still unsure whether collision has something to do with this "sliding" effect. Then try that on NPCs too. I'm kind of stubborn - so far, I've always been lucky enough to find workarounds to the game's limitations, but that involves some documentation and custom furniture is one of the least documented aspect of modding Skyrim. I used the same procedures in F04 and had no issue whatsoever, but of course F04 CK lets us create custom furnitures way more easily. You're probably right about your "suspiscion" ;): I created new sleep animations which I can't use as replacers yet because they only work on 2 actors sharing bedrolls or beds - and that's a set of 9 x 2 synched animations per furn type, no other way to implement these but on custom furnitures (or using loose anims but that'd be an even worse nightmare positioning my actors properly!..). So far, I've only been trying to spawn my custom furn on top of a regular bedroll with an activate perk and even though I disable footIK, I'm still unsure whether the underneath bedroll's collision isn't partly responsible for improper positioning. As for "PathToReference(...)" if I have no other choice but to use it, I was thinking of trying to mimic the "Sit" package with a spell while running a countdown on the furniture to dispell it in case path gets interrupted. No idea if that would be enough to cut "PathToReference(..)" short on bad navmesh though but that's easy enough to test. You ever tried that? Thanks for being around, Max, that's very helpful really. The simple fact of being able to discuss issues and share experiences with other modders often brings up possible workarounds I had not considered yet :). I'll probably be back sharing more of my stupid trials... Cheers, man!

... HOURS of frustration later... For the first time in years of modding and fighting the CK, I'm on the verge of giving up!... * :pinch: No matter what I test, my PC keeps SLIDING away from my furniture when completing (either) package!.. Adding SetVehicle(target) at the end of package makes it even worse because he will then position on the pivot point of my furniture rather than on the entry point!.. Then I wondered if this idiot "sliding" thing was not due to some collision setting on my furniture - tested more stuff in Nifskope... to same sliding results!.. :wallbash: Now I'm thinking these procedures don't really end when activating the furniture... or ending is delayed by some other other procedure while my PC is being slowly pushed away by other collision objects in the landscape (pure hypothesis!). I made an interesting discovery though: you can use the "Sleep" procedure (Template or not) with "Sit" furnitures (no "shut eye" bug issues as long as the sleep animation does not play) - and that package is the "less bad" of them all (sliding stops faster) :rolleyes:. This whole experience seems to completely defeat using custom furnitures with packages!.. I'd probably be better off scripting my furniture directly and using markers to get my actors to "PathToReference(...)"!... Sigh... Well, if any compassionate soul wants to share his experience... I'm still listening!.. Thanks! :smile: * giving up that approach, not giving up modding ;)

Hey Max, thanks :smile: and you're right, very frustrating!.. Been at it for at least 10 hours, trying different data input, sequences, procedures... for not worse but certainly not better results!.. Only consolation is using Beth's templates doesn't make it any better!.. And to think: I'm only trying to use Furniture because they're supposed to lock actors on entry points!.. only to watch them "slide" away from the damn entry points it took me forever to position properly... :wallbash:

Hey guys, I need a second set of neurons to figure this one out: I'm trying to create a custom package to get the player to find, travel to and use a custom Sit furniture (SpecialFurniture keyword) using custom animations. My custom furniture works fine when activated directly in game or thru script: the actor positions correctly and plays the intended animation. BUT when using a package, I get totally unreliable results: - when starting the package from a fair distance of the furniture (approx. > 128 units), it will: a. sometimes: walk to the furniture alright, position correctly on the entry marker and play the animation ok - that's good. b. at other times: start walking, stop, start running (tho' preferred speed is set to "walk"), stop again, then jump to the entry position before playing the anim - NOT good. - when starting the package from activation distance (less than 100 units), it will walk to the furniture ok, position on the entry point alright, then start SLIDING away (probably translating) and end up playing the animation in a completely misaligned position - NOT good at all!.. I tried this on Sit packages and on Activate Packages - I get the SAME unreliable behaviors no matter how I sequence procedures and no matter what package I test: SIT PACKAGE 1 - variation based on the "Sleep" template Sequence Procedure: Travel Simultaneous Procedure: Find Procedure: Sandbox Simultaneous Procedure: Sit - "Success completes package" Procedure: Wait ACTIVATE PACKAGE - variation based on the "Sleep" template Sequence Procedure: Travel Simultaneous Procedure: Find Procedure: Sandbox Activate - "Success completes package" SIT PACKAGE 2 - variation based on the "Sit" package Sequence Simultaneous Procedure: Find Sequence Procedure: Travel Procedure: Wander Simultaneous Procedure: Sit - "Success completes package" Procedure: Wait What I dont get is if I use a Sleep package to get the player to walk to a bed and activate it, it'll work flawlessly everytime and no matter how close or far from the furniture the package starts. I probably can solve this with script but I really need understanding what's going on here before I experience further with packages. Any idea what may cause my actor to translate around after he activated or sat on my furniture on package? (again, my furn works just fine when activated directly in game or thru script) Or what may cause his Find/Travel procedures to stutter like that at times? Many thanks in advance for any enlightening input!.. And a happy new year to you all, guys! Hoamaii

Wow, I cannot thank enough 1ae0bfb8 for mentioning haveibeenpwned.com service!.. Turns out I'm one of the "lucky" ones who's actually been pwned on the Nexus, except that was back in 2015, possibly 2013, and I never knew!.. Luckily, I've changed all my passwords many times since then and it would appear the harm was minor and containable. I'm one of these dinosaurs who keep a very low profile on the Internet, with no social media account whatsoever and very limited web usage, at least compared to most of my friends. The Nexus is the only online community I take part in and I apparently got hacked only months after I became a premium member!.. I'm not blaming anybody here, the mistake was mine, and that mistake was to think that my profile was low enough to be safe. Sure, I was aware enough as to use complicated passwords and change them every now and then but obviously that was not enough: I checked all my emails accounts on haveibeenpwned.com and turns out the only one which was ever compromised was the one I used on the Nexus and was indeed pwned on the Nexus!.. So the MOST IMPORTANT and definitely useful info I got from this whole thread came in the end from 1ae0bfb8's comment: everybody knows that breaches happen and there's no reason why the Nexus should be spared - BUT not everybody knows about that website where we can verify in real time if we're indeed safe or not. And I cannot urge enough other users to use it too if they haven't already. I can only agree with other comments, BigBizKit and PickySaurus, if that's feasable, please do warn us by email next time a breach happens, and please don't wait weeks before you do, and do direct us to haveibeenpwned.com in that email. If some of us have been compromised, we need to know asap so we can take actions immediately. There's a huge difference between wondering if you've been hacked like we all did in this thread and being able to actually verify if that's the case or not. When we know we've been compromised and when, we can do something about it - and that's what matters most. Changing our Nexus passwords is not enough, we may also need to change our emails' passwords, and that, we need to know as quickly as possible. Thanks.

In response to post #75806628. #75806658, #75807068 are all replies on the same post. Thanks BigBiKit. I don't use passwords accross sites but I'd hate my email to be compromised as I use it for work too - I haven't noticed any suspicious activity but then I was not paying that much attention to spams either.

Does that mean if we changed our passwords on November 20 like you recommended in your last security notice, we should be safe?

Yeah, I got that, moveabaleStatics' collision is not lost in translation, I know - but I was talking about furniture too. No idea yet how they ultimately behave when you change collision objects motionsystem or layers. I'm experiencing with custom furnitures right now for different reasons than you were, and I found that in some instances modifying their collision box makes them unactivable. So there's more to furnitures' collision than just havok - I'm trying to figure that out.

My experience is more often than not, the mesh will translate but the collision box won't - and will probably remain in place where your mesh was before translation, creating some invisible wall in your cell. You can try to use MoveTo instead, or disable the first mesh and PlaceAtMe a new one where you want it repositioned, though visually of course, the effect will be signifcantlly different in game. A combination of both may do the trick: first translate your mesh, then spawn a new instance of it right on top of it (same world coordinates), and as soon as your placed object is 3Dloaded, disable and delete the old one, that should rid your cell of both the unmoved collision box and the moved furniture, as well as still visually look like the furniture has been "pushed" where you want it to be. A lot of Skyrim's modding is finding workarounds to "cheat" the game's limitations... ;) Be aware however that if you're trying to do this with pieces of furntitures in Vanilla cells like player homes for instance, furnitures won't budge no matter what - they seem to be baked in your saves the first time you enter the cell. They may seem to do what you want at first, but will respawn in their original position as soon as the cell resets.

Well, I found a way which seems to work in my first tests... In case anybody is interested: - with 2 actors in the same scene in 3DS, 1 male + 1 female (same skeleton), let's say you want the female to be 5% smaller than the male - leave the male skeleton as it is, select the female skeleton's NPC_Root bone and scale it down to 95% (in 'World' view), that should rescale the whole skeleton to 95%. - if you're also using Pornphile's 2 actors controller rig, you will also need to scale down the Root_Controller to 95% so that all transforms will scale accordingly. - assuming you're using the default male skeleton for both actors, now select both female "Hand" bones in world view, and scale them down to 85 % (exact number is 85.186), all fingers will rescale accordingly - the only difference between default skeleton and skeletonFemale is the hands size. - create your animation for both actors, the rescaling will now allow to properly position and align hands and limbs to reflect what it's going to look like in game. - before exporting your animations, you need to rescale everything back to 100% (all in world view) - female hands' bones first, then female NPC_Root bone, and finally Root_Controller if you're using it. - export each animation separately as usual. And finally, in your animation script you need to make sure to scale both actors in game to reflect your 3DS scales: once the female actor is rescaled to 95% of the male scale, everything will align exactly as it did in 3DS.

Ooooh darn!.. If that's it, that's going to be impossible to track!.. Thanks Steve!

Hey guys, I'm fairly new to creating custom animations. I've manged to resize female hands properly in 3DS to fit female's hands size in game. I'm now trying to rescale the whole actor (skeleton + mesh) directly in 3DS, so that when I'm animating two actors together, one can be smaller than the other one in game (completely independantly from rescaling them thru scripts). The purpose of that is to be able to polish positions adjustments directly in 3DS before exporting the animation. I've made some tests scaling NPC_COM down to 95%, creating the animation I want, then right before export restoring it all to 100% (like we do when rescaling hands) - it loads ok in game but positioning is messed up - so I must be forgetting something. Anybody has managed to successfully do that who could give me some advices? Many thanks in advance!

Thanks again, guy! Changes affected at runtime by another mod, .dll or not, is what I tought first. I cant' think of any mod that would forcibly change lesser powers to equippable spells - do you know any? They could be running patches that I don't know about, would there be any chance that such patches could embed changes in their saves the way some custom meshes or variables can become embebded? My lesser power doesn't use any existing magic effect, it's a scripted magic effect which in turn triggers an ability - that ability works as intended. Brainstorming too, completely out of the box: - spells are affected by behaviors, if only to trigger the animation and draw weapons, maybe a change in behavior files has become embedded in their saves? Is that even possible? - or is there maybe some .ini settings which affects spells, powers or shouts, which could have been modified? - or yet again, could that be caused by one of these mods who automatically reassigns keys? This affects only a handful of users out of thousands - I suppose I could ask them all to send me their load order and look for a common denominator, but if it's a .dll, change in behavior, custom .ini or reassigned key, load order won't give me any clue about that. Then again, it could also be just a bug...

Hey Steve, hey Cdcooley, Thanks for replying. Yep, all animations converted, .esp saved in SSE CK, and I even recompiled the original scripts inside SE's CK. A bug in the software? Didn't think of that, never happened to me with Skyrim in 8 years, but I ever hardly play SE, is it more prone to bugs? I been searching around and the only "hint" (sort of) I could find was there's a a lot more new mods modifying SE directly from .dll's rather that doing it in the CK or Xedit. Some of these .dll's don't even require skse. Unfortunately, I can't read .dll's - Papyrus is the only code I know. Do you think a .dll only plugin could do that? Modify the game in a way that could change significantly some CK-made plugins?

Hey guys, A small handful of users (4 that I'm aware of - SE only) have reported this: 1. When using a lesser power, their games equips it like a spell, forcing weapons draw. 2. When they install and load my animation mod which uses a lesser power to trigger the animation, their .esp gets somehow modified: Exact same .esp version I uploaded, same date, same hour, but when they load the .esp in Xedit, the spell which was originally tagged as a "lesser power" is now tagged as a "spell" :wallbash: 3. I'm pretty sure none of them has modified the original .esp, they're not comfortable enough with Xedit to do that. 4. At least 2 of them have for sure a completely legit version of the game. 5. None of that happens in the LE versions of my mod. Any of you guys has any idea what the heck can turn a lesser power into a spell by just loading it in game?.. Or which SE mod may be doing that? I mean, I know mods can change objects tags at runtime with skse... But how the hell could it affect the .esp itself? Is it even possible to change the content of any Bethesda's games plugins without modifying it in the CK or Xedit? That completely blows my mind... Any idea? Thanks!

Thank you all, guys, for your hard work and efforts to keep constantly improving the Nexus - you're a great team!

If you're making an update version of a mod you created and wish to delete a custom ID or object placed in your previous version, you'll probably be safe. Only "probably" though, that's when you'll need a lot of testing to make sure. As an example, I once wanted to replace a bookshelf I had placed in one of my mods. But I couldn't delete it because users had already placed that mod in their games - I had to move it beyond the walls instead and place a new one for the update to go smoothly (no complains whatsoever after many years :wink:). On the other hand, I could safely delete another piece of furniture I had mistakingly placed 2 instances of in the same mod. There's really no telling which may bug or not even when it's custom objects you wish to delete - you'll only get your answers in testing!

In response to post #73890068. Okay, found it - was a bit of a treasure hunt though!.. If anybody has the same issue, you'll need to click on "Mods" then go to "My Mods" on the right handside of the dropdown menu, that'll load your mods management main page. I see 3 issues here if I may: - Faded white font on a grey background is not exactly the best choice for readability. - Poor naming really, the old "manage my mods" was way clearer. - Questionable placement: now that everything related to our accounts and profiles has been moved to the right side of the header menu, it'd only be logical that we can access and manage all our mods, including the hidden ones, directly from our profile.