Rayek Posted February 9, 2017 Author Share Posted February 9, 2017 Good tips. I have everything in place now and am fine tuning...reducing script size is next on the list. Thanks again guys. I've learned a lot along the way as well as am nearing completion of my player home. 2 birds...1 stone. Link to comment Share on other sites More sharing options...
steve40 Posted February 11, 2017 Share Posted February 11, 2017 (edited) Then with your activator you set a linked ref to the xmarker. In your activator script you can use GetLinkedRef() to query the state of the xmarker. No properties needed at all, as less properties is less save bloat. Also your script is faster over all since it only disables or enables 1 item. Not so. Adding more object references to the game, such as xmarkers or activators etc, requires more ram than a property which is simply a pointer to a form in the esp. Remember, any Object Reference (including xmarkers) will inherit a new instance of the ObjectReference.psc script, and it is quite a large script, so it automatically negates your perceived memory (and save-game size) savings compared to using a simple property. The xmarker form itself, when placed as a reference, has lots of additional settings (which you can see by right-clicking on it in the Render window in CK, which all consume more memory - so much more than a few little properties :wink: Speed is irrelevant here, as disable() is a latent function. We could use DisableNoWait() in its place. Also, you may want/need to enable and disable objects in a particular order as it can produce a better/smoother visual effect in-game. Edited February 11, 2017 by steve40 Link to comment Share on other sites More sharing options...
sLoPpYdOtBiGhOlE Posted February 11, 2017 Share Posted February 11, 2017 Not a fan of multiple properties in scripts for no reason. Adding 20+ properties to toggle multiple objects just is not needed for reference that your dropping in the game world via the render window in the editor.That's what linked refs are for.. why not utilize them instead of loading the papyrus script engine. Different story if your placing object in the game world at run time.But even then I work around most properties as possible. Link to comment Share on other sites More sharing options...
Lisselli Posted February 11, 2017 Share Posted February 11, 2017 I'm thinking no one's mod idea would ever take off if they obsess over every approach they take might be too costly. Link to comment Share on other sites More sharing options...
KiokothePirate Posted June 16, 2017 Share Posted June 16, 2017 (edited) So I've read through this thread and it seems to hold the answers to the issue I'm having with my player home. The script I've made is meant to disable some items in the home and enable others. This is meant to provide players with the ability to make the home compatible with the Hearthfire Multiple Adoptions mod if they so choose. I'm going to post my scripts below. The Top script is the script as it exists now. The bottom script is the rewrite following some of the tips given in this thread. ObjectReference Property HFOff AutoObjectReference Property HFON AutoEvent OnActivate(ObjectReference akActionRef)If akActionRef == Game.GetPlayer()HFOff.Disable()HFON.Enable()EndifEndevent----------------------------ObjectReference Property HFOff AutoObjectReference Property HFON AutoEvent OnActivate(ObjectReference akActionRef)If akActionRef == Game.GetPlayer() If HFON.IsDisabled() HFOff.Disable() HFON.Enable() Else HFON.Disable() HFOff.Enable() EndifEndif Endevent---------------------------- Could someone let me know if this new script looks correct? Edited June 16, 2017 by KiokothePirate Link to comment Share on other sites More sharing options...
Recommended Posts