Auto-Sorting Script Issue

[EPDGaffney]

Well, that script could certainly be optimised a bit more than it is. First of all, there's the Enable Parent feature. Second, the current word is that scripts still run on disabled objects, so a quest script that gets turned on and off via a trigger box would do the same thing but more efficiently, provided this has not changed since the community first found this information in whatever game it was found in (I'm drawing a possible parallel between this and what we learnt about GameMode scripts).

 

But we can make even further improvements. Why not make this an OnActivate script? That way, this just happens once when the player opens the armoury door. If you're concerned about anything visual, place a harmless smoke explosion or something there. I think Mr House has something like what I'd use when you open his thing. You can use trigger boxes as well, for when the player leaves the area without closing the door or whatever it is. It's really hard to read your script as it's so long and I'm probably what you'd call an intermediate-level coder, if that, but the way it looks is that if the player is within the specified distances, you have the script setting the collision and enabling/disabling the meshes every frame. I don't see a reason to do that.

 

And last, I would severely truncate this code with arrays and loops. I'd probably do a quest script that sets up the array(s) initially and then stops modifying it/them so that another, less intensive script can simply reference that array at strategic times. This is assuming I understand correctly and that the player does not interact with these weapons, just looks at them, hence turning off collision.

[GeneralGred]

First off I would like to state that the performance hit is resolved as soon as the weapons are disabled. I'll look into turning the containers into a quest script, though I'm not sure if a single script can hold the entire armory. The problem with an OnActivate script here I need this script to run constantly while the case is open, if the script stops the weapons fall to the ground. The reason for the Collision scripting is because without it the weapons make a lot of noise due to the fact that their collision geometry clips with the display case, I've actually waited a long time for this function to come out. Lastly no, I've taken the next step in armory displays here by having each weapon scripted allowing the player to grab it without going into the container, these weapons are OnActivate only scripts.

 

Edit: I noticed the last part of your post and wanted to say that one of the best parts of the ToggleObjectCollsion function is that it still allows the player to interact with it.

Edited January 31, 2018 by General Gred

[EPDGaffney]

That's weird, because whilst I've never used the function, this is what it says on the wiki:

 

 

This function will affect ANY other objects in the game using the same world model as the calling reference. However, while the calling reference will be effected immediately, other objects will only be effected once their 3D is reloaded by the game. For this reason, when using this function to disable an object's collision, it would probably be wise to re-enable it once the player has moved to another cell.

 

JIP said there used to be errors in the function. Is your JIP LN up to date? Likewise for your NVSE.

Edited February 1, 2018 by EPDGaffney

[GeneralGred]

Ya both freshly downloaded about 2 weeks ago

 

If your talking about the fact that you can still interact with it I think it's because while the function disables collision, the model still technically has it. I would be a liar if I said I understand exactly how it works, but I think it's simply something that acts as a work around. Do to the large danger it poses, as it affects all models of the base object, I'm very careful to reenable the function and thus have never tested this after leaving the same cell.

Edited February 1, 2018 by General Gred

[EPDGaffney]

What I meant was that you said this:

'The problem with an OnActivate script here I need this script to run constantly while the case is open, if the script stops the weapons fall to the ground.'

And that does not appear to be the intended design of the function. I tried it just now and I can just set it once and forget about it, and it remains as I set it. These objects can't fall to the ground if they have no collision, and yet JIP states that not only will the function not revert, but it will affect all other meshes that share the same .nif file, which is what you're saying as well. So if that's true (and it was true in my testing just now), how could they fall to the ground?

 

This appears to be the major hitch in your script, concerning performance, and I believe there's a way to fix it. The most obvious and probably correct way would be to make new .nif files and new static versions of these weapons without collision and disable/enable them as needed, but I think you're trying to avoid that and use scripts. Even with scripts only, I think we can manage to make this less intensive.

 

The other thing I don't understand is what if you were to drop your own weapon and it has the same model as one of these? Did you somehow stop the player dropping weapons there?

[GeneralGred]

Ok I'm seeing the confusion I think, so this function disables the collision and only the collision on the object, it's Havok physics are still in play, and basically what happens if you drop an object with it toggled off is it will fall through the world. So even with this function I still need to constantly update the script. ATM I'm finishing an "Armory Performance Mode" that you can toggle which basically separates the cases into individual sections (eg: Melee, Sidearms, Shotguns, and etc. are now seperate) to lower the number of scripts running simultaneously.

 

And yes I am not including new meshes/textures. I may later on make a separate add-on for those who need it

Edited February 1, 2018 by General Gred

[EPDGaffney]

Ah now, I see what you're saying.

 

However, constantly running that command on an object to turn off its collision when it's visible, that really should not stop it falling through the ground if that were a side effect of the function. But it makes sense to me that it's not falling through the ground because when I tested it before, nothing fell through the ground, nor could it be interacted with in any way. It stayed in the air and I could run through it, shoot through it, any thing; it retained just the visual representation of the mesh and nothing more, and it stopped moving and reäcting entirely. I tried this on several objects, and it seemed to work on anything that normally had Havok physics, but not non-movable statics.

 

On turning collision back on with this function, objects that were in the air remained floating until I shot or otherwise initiated physical contact with them.

 

So, what were the conditions when you used this function and saw objects fall through the ground? Though I did try this on objects that were falling and watched them stop moving in mid-air, perhaps being in your container or whatever they're in is causing the Havok to go a bit mad and perhaps the function would work as intended if something were tweaked and no physics were allowed to interact with the objects before toggling off their collision.

 

Splitting up the script the way you're doing is a very good idea. I still maintain using arrays and ForEach loops would be better. I've read it's better for performance but have no real experience noticing a difference, and I'm saying it as much for how much time and probably sanity it would save you.

 

Also, what happens if a player drops a weapon when standing in the spot where collision gets disabled on them?

[Mktavish]

Sorry if this is off base ... but a quick scan of the last 2 pages , led me to believe you are trying to hold weapon Item Refs in place , like displayed up on a wall. But of course they will fall to the floor in game or what ever collision plane is below them.

So if this is the case and you are not aware that most of those items , also have a static version of them.

You can place the static model on the wall without needing to keep it from falling.

And if a particular one hasn't been converted to a static. It's done easy enough by unpacking the BSA , and putting the mesh in a loose folder. Make a new static object within the object tree where the other static weapons are found. Then find the mesh in the loose folder from it's model drop down. And now you have a static version of it. Plus you can get rid of the loose folder item after, if you kept the directory structure of the BSA. So it will then find it there.

 

Sorry if that is not the case , or you guys already discussed that. Just thought I would mention incase.

 

Add edit : Err wait ... since I'm guessing you need clickability on the item. You can place an invisible activator over it. But then ... you might as well make the item an activator instead. Which you still do the same process with unpacking the BSA.

And then you just have a bunch of OnActivate scripts.

Edited February 1, 2018 by Mktavish

[EPDGaffney]

PSA: DO NOT UNPACK BSA IN GAME FOLDER. If you try this, unpack it elsewhere and then drop in only the files that you need. With BSAopt at least, it's very hard to unpack just the files you want, and will unpack everything in the archive, regardless of how it looks to you (unless you're experienced with the software). You can overwrite your mods and ruin all the hair in the game if you don't unpack it outside of your game folder.

 

That out of the way, have you ever tried taking an item with Havok physics and using it as an immovable static, Mktavish? I would expect it still to have Havok physics even if the engine is told to treat it as immovable. Far as I know, only the .nif file's collision can determine the physics in-game, apart from a script function like this that turns off that collision. But if you're right, that would be extremely useful, and I hope you are right, if not for OP then for some of my own stuff.

 

In the past, I've copied the path of a model that was not unpacked (from within the GECK itself if the model was being used for something already) and pasted it where I'm to choose a model for another type of item and it worked, no BSA-unpacking needed.

 

The weapons should fall to the floor, not through it, without such a function as ToggleObjectCollision. The discrepancy here is that OP has used this script and seen the weapons fall through the floor when the function is affecting the designated weapon, and that's not how JIP intended the function to work, nor is it how it works in my tests. In my tests, the model stays still exactly where it was when its collision was turned off and becomes inactivable.

 

OP, if it's not too much trouble for you, how about some screenshots of your armoury so I can really understand what's going on? I think I get it, but it would be nice to be a bit more confident about that.

[GeneralGred]

I'll get some screenshots when I can. @Mktavish, I haven't found static versions of the weapons in the game, if your talking about the 1st Person Biped Models, I've tried these in the past and they don't move at first, but eventually they snag or something and will fall.

 

One thing that maybe cause confusion here that I should clear up is the weapons on display are not the weapons themselves, they are pre-placed Activators that represent whats inside the container. Now when I first tested ToggleObjectCollision I did it without the MoveToEditorLocation script to see what happens, and like any other object it moves and falls when another object collides with it, in this case it't the doors to the display. I've tried a few scripts that use one time activation to keep the weapons up, but to no avail.