jayne2132 Posted February 5, 2015 Author Share Posted February 5, 2015 Same quest? Are you trying to link to the script within the same session that you created the script? If so, that may explain it. Create your scripts first. Close all open records. Reopen the records and then fill the properties. Sometimes the CK won't update an open record's information about what is available. Closing and reopening should fix it. But I've never experienced this, it is the first I've heard of it. So... take it all with a grain of salt. I would have had a ready explanation if you were attaching the script(s) to place-able objects. Did all that. Closed and reopened CK and same problem. Some work, others don't. I'm going to give up for the night and hope the problem fixes itself by the morning. :) Thanks for your replies! Link to comment Share on other sites More sharing options...
jayne2132 Posted February 5, 2015 Author Share Posted February 5, 2015 Update. So, didn't work this morning. I renamed the properties, still didn't work. I then set all the scripts to extend Quest instead of ObjectReference, and after compiling, closing, opening, etc, it worked! Unfortunately I'm not sure I've actually found the solution, as a couple of the previously working properties were referring to the same ObjectReference scripts without a problem. If anyone else has this problem, please post if you know why this is happening/how to fix it. Link to comment Share on other sites More sharing options...
lofgren Posted February 5, 2015 Share Posted February 5, 2015 I'm confused. Are your scripts attached to object references or are they attached to quests? Link to comment Share on other sites More sharing options...
jayne2132 Posted February 5, 2015 Author Share Posted February 5, 2015 I'm confused. Are your scripts attached to object references or are they attached to quests? They're all attached to the same quest: _wsManagerScript - extends quest, deals with OnInit() and outside trigger calls, and calls functions in the other 3 scripts_wsManager_Static - does heavier processing, uses properties from ManagerScript and calls functions in Position_wsManager_Dynamic - does heavier processing, like Static but acts on different objects_wsManager_Position - deals with calculations, uses properties from ManagerScript I made the last 3 scripts extend ObjectReference, it was an arbitrary choice because they weren't dealing with any quest objects, but maybe I chose wrong? They now extend Quest and work the same way. Do all scripts attached to an object/quest have to extend the form type they're attached to? Or should a generic script extend "Form" instead? I originally had these all in one script, but it was getting unwieldy and, with my very very amateur understanding of multithreading, I assume that dividing the heavier processing (the main function takes several seconds to run) into multiple scripts is more efficient. Let me know if my logic is wrong here -- I'm still learning and appreciate the feedback. Link to comment Share on other sites More sharing options...
lofgren Posted February 5, 2015 Share Posted February 5, 2015 Take a look at this page: http://www.creationkit.com/Category:Script_Objects It's acceptable for a script to extend another script type that is higher on the tree rather than the object type that it is actually attached to IF and ONLY IF you do not intend to use any of the functions associated with the extended-script. As you can see from the tree, "quest" extends "form," so if you are not using quest-specific functions you can make your script extend form instead. Generally there is no real reason to do this, though, unless you plan to reuse the script attached to many different object types. For example if you have a script that sets a quest stage when the object is acquired, and you want to attach it to a piece of armor, a weapon, and an ingredient, you might decide to have it extend form instead of writing three separate scripts. However, scripts should not extend script types that are on different branches of the tree. As you can see, quests are not object references, nor can they ever be. Scripts attached to quests should extend either quest or form, and that's it. Link to comment Share on other sites More sharing options...
lofgren Posted February 5, 2015 Share Posted February 5, 2015 With regards to multithreading, I do not consider myself an expert either. However I believe that it is irrelevant whether the functions are stored in multiple scripts or the same script. Link to comment Share on other sites More sharing options...
jayne2132 Posted February 5, 2015 Author Share Posted February 5, 2015 Thanks Lofgren -- I understood inheritance in terms of casting objects to different types, but didn't realize it also restricted what scripts could be attached to what forms. Yes, my intention was to create generic scripts that I could potentially add to objects as well as quests, so if I decide to do that, I'll have them extend "form". As far as multithreading, I just skimmed through Chesko's wiki guide and it sounds like exactly what I need to do, so I'll try to tackle that once I get everything else working. I thought I'd read in one of the best practices threads that it was better to divide up scripts, but I must have misunderstood. It does make sense that it would *not* make a difference, though, as the primary function waits for each function it calls to complete before continuing on to the next one. Thanks again Link to comment Share on other sites More sharing options...
lofgren Posted February 5, 2015 Share Posted February 5, 2015 With regards to multithreading, as I said I am not an expert. I know that Chesko recently made some huge leap in effective use of multithreading so I would definitely trust his word over mine. Whether or not it is beneficial to break scripts up for other reasons, I just don't know. I doubt there is any harm in it though. Link to comment Share on other sites More sharing options...
Recommended Posts