Right so, I've been working on my Lich mod for quite some time now, and there has been a massive amount of scripting required to bring my ideas to life. Yesterday, as I was tweaking/adding features to one of my Lich scripts, I was greeted with a brick wall. I was typing, but no characters were appearing. Yes, it seems that I had reached the maximum script size, and the editor wasn't planning to allow me to add any more to the script.

Now, I have a ton of comments in my scripts--some of it is old unused code that I had decided to leave in for reference sakes. I ended up removing most of that to gain the room I needed, so it's not that big of a deal. However, the fact that I am very close to the "cap" is very much still true, and I wonder about what I should do next. The obvious first thought is to reduce the size of my script in any way possible. I can probably work out a few tweaks here and there, but I believe the script is already as efficient as it can get, from both length and functional perspectives. The real problem, is that I am not done adding to the script.

The script in question is a Quest script. This script is running on a control quest that is always running if the Player is that specific type of Lich. This quest has several aliases with scripts attached that I also am using frequently. (I only use events in these scripts currently.) My first thought was to move some of the code to the aliases, but I have a feeling that overloading those with code might not be a good idea--not to mention it will require me to state the same properties multiple times across multiple scripts in order to properly function.

Before proceeding I'd like to first mention a few things.

• I do use OnUpdateGameTime in this script, but the time set is every 6 game hours, and is unaffected in any way if it runs later than that. I stop it on occasion, but not often.
  
• All properties within my script are static unchanging values such as Spells, Races, MagicEffects, and ReferenceAliases (Though I do change the object reference that is contained within the reference aliases on a regular basis.)
  
• The script is also conditional, but to be perfectly honest that's still one of the things I don't fully understand the implications of.

I'm left wondering a few things at this point.

• Is it bad to overload an alias' script with code?
  
• Does stating the same properties (such as a spell or race) in multiple scripts cause any performance hits?
  
• Does stating a single script as a property across multiple scripts cause any performance hits?
  
• Just how big of a performance hit is there if your script is excessively lengthy?
  
• Would it be viable to simply create 1-2 more scripts within the quest, with each one containing the same properties, and have them reference each other on a regular basis?
  
• Have any of you done this yet or am I the first?

Thanks in advance for any responses.

That must be one humungous script. You can compartmentalize and put various functions in other scripts, even on the same quest. Anything longer than about 20 lines in, for example, a while or If block, could be given a descriptive function name and put in an alternate script, passing the needed variables in as parameters (Or making them properties so the other script can change them, if you need more than one return value.)

The script is currently sitting at 890 lines. The "script maximum size" seems to be character based though, not line based. It of course contains a large list of functions that each do different unique things. Functions that I re-use whenever possible, and re-code to be reused when able.

There are many functions that are used multiple times for completely different sets of the Lich's features. I've done a bit of programming outside of Papyrus, so I'm familiar with many of the common coding practices that should be used here. Which is why I was thinking of doing as you suggested--compartmentalizing the script into say, 3 different scripts, that each control a separate core set of features. However, as I mentioned, each feature uses many of the same functions, properties, and aliases--this is why I asked these two questions:

1) Does stating a single script as a property across multiple scripts cause any performance hits?
2) Would it be viable to simply create 1-2 more scripts within the quest, with each one containing the same properties, and have them reference each other on a regular basis?

I highly recommend using an external editor. I wonder how you've made it this far in such a big script without the ease of line numbers, or real editing tools. I use UltraEdit. But NotePad++ is free. Besides having line numbers to compare to your debug log, there is also no limit in size. One of my scripts is 1851 lines long. (although 2/3 of that is double-spaced). But the CK text editor cannot add to the file (except I can still add properties through the editor)

The wiki gives instructions on how to set up your external editor to color code your functions and class ids. It really make it much easier. Plus... no size limit.

http://www.creationkit.com/Notepad%2B%2B_Setup

(there are others besides Notepad++ that will support Papyrus, they are listed on the scripting reference page)

Oh to clarify, I am using an external editor. Dear god I'd never survive in the internal one. However, in order to get my point across more easily I worded it in a way that would imply I was not. Sorry for the confusion. (I'm using Sublime Text 2, if you were wondering.)

I noticed that it does indeed compile when I use the external editor, but I cannot paste the code into the internal editor and save it. (I do this so that I can edit the properties of the script.)

My original thought was "Well I could just copy the script to the source folder and just keep compiling it through ST2", but I wasn't sure if the script size limit was just a limitation of their crappy editor, or if it was an intended limit placed to prevent oversized scripts.

1851 lines though eh? And you don't have any issues with that at all? Is it running all the time?

So, I'm a new modder myself. But not too new to programming, and I also am using pretty big scripts. I have answered some of your questions, in what looks like a formal way below, but I remind you, I'm new to this as well. This is just based on my experiences so far. I hope it's helpful.

Q: Is it bad to overload an alias' script with code?

A: I would assume it's bad to overload any script with code. Some functions may require time to complete, and the script will suspend itself until completion of the function.

• Example: Game.GetPlayer().GetAngleX() A function like this takes a tiny amount of time to process, and would normally go unnoticed. Do this, and similar functions 25 times in one event or function, and you'll definitely notice the lag.

Q: Does stating the same properties (such as a spell or race) in multiple scripts cause any performance hits?

A: Not that I can tell

Q: Just how big of a performance hit is there if your script is excessively lengthy?

A: It's only as big as the function you're currently running, and what's taking place in that function.

Explanation:

• The script can be 2000+ lines long, but your only calling one function at a time (object oriented). If your function is only 5 lines long, then it will run like a 5 line script. Very fast.

Q: Would it be viable to simply create 1-2 more scripts within the quest, with each one containing the same properties, and have them reference each other on a regular basis?

A: Sure you could do that. That's up to you. The cool thing about the object oriented nature of Papyrus is that if something goes wrong, it only terminates the function or event that the error occurred it. So the script stays in tact, allowing you to continue on using other functions, or even the same function again. So, it's very safe to have all of your functions, properties etc. in one big script (easier too).

Seems to be just limited on their editor. All my functions perform normally. (as normal as I wrote them )


Well, it's active as long as the quest is active. But it's not doing anything unless I call one of it's functions.

I do have another script in the same quest running parallel what is registered for 1 second updates. It's much smaller, but will occasionally call functions from the first script depending on certain conditions.

Alright cool, thanks. I've been coding since the CK came out myself, but I still consider myself "new" to it. Really we're all new here, so for questions like this the best I can hope for is some personal experience or an actual Bethesda response (which I've been lucky enough to receive on a couple of occasions).

I'll probably end up keeping everything in this one script, but find a way around the property issue. Things would be so much easier if I could make the "compile" script copy the file to the source folder though. I'm pretty sure this is possible, but I can't figure out how to do it. Quite frankly I'm pretty annoyed with having to copy/paste the files in the editor just so I can edit the properties anyways and I'd love it if I could figure this out. ><


Hm, I see. Well alright then.

Phew.

Yeah, I can code simple stuff without one but once the script gets longer than an event or two it just becomes too unreadable for me. I had originally used Notepad++ but I found the functionality and coloring of SublimeText 2 to be much better. It's free, but they do have a licensed version, so they spam you with "You should buy this already" messages every 25 saves or so. A small annoyance, and quite frankly I may actually buy it some time--it's a pretty awesome editor. A screenshot for reference: http://3.imgland.net/obA6J.png

When I compile using ultra-edit, it will update the CK version. Meaning, if I add a property to the bottom of the script in the editor. Then compile... I will find that new property in the editor, where I can change it's value.

Are you saying you aren't able to do this with your editor?

No, I am not, but this is because I am not editing the script from the source folder. (Either your editor copies the file or you are editing directly from the source folder)

The CK reads the scripts from the Source folder, so if that version is not the one you are "compiling" then it won't update the properties in the CK. It will run in game perfectly, but it will not update your properties in the CK. I chose to store my scripts elsewhere so that I can search through them and manage them more easily. The only problem is that my properties in the CK don't get updated until the source file is updated. (I do this by highlighting the new script and pasting it into the editor, but, yeah..it's kind of a pain.)

Yes, I'm editing them right out of the source folder. I just right click in the editor and "open in external editor".


Yeah, I know what you mean about wanting to organize/search. I try to prefix my file-names with something unique so I can pick them all out of a folder, or list easier.

I do the same, but I have about 20 scripts right now. It's just much easier to store them elsewhere for me.

So when you're done editing the file 'outside' of the source folder, can't you just overwrite the one 'inside' the source folder? Either Save as, or literally drag-drop copy/overwrite.

Yes, I could, and that's what I do if I'm not working in the editor while writing the script. I was simply saying that I'd prefer it if the actual "compile" action (which is running a .bat file) copied the file for me. I can't seem to find the syntax to use to make this happen though.

Ok.. now we're getting down to business... what's the batch file look like ? Can you post the one you have?

It's not the same for everyone? I was sure it was automatically generated by the CK, and that our external editors simply make use of it.

"%ProgramFiles(x86)%\Steam\SteamApps\Common\Skyrim\Papyrus Compiler\PapyrusCompiler.exe" %1 -f="TESV_Papyrus_Flags.flg"-i="%ProgramFiles(x86)%\Steam\SteamApps\Common\Skyrim\Data\Scripts\Source"-o="%ProgramFiles(x86)%\Steam\SteamApps\Common\Skyrim\Data\Scripts"

Add this to your batch file (after the first line):

copy %1 "%ProgramFiles(x86)%\Steam\SteamApps\Common\Skyrim\Data\Scripts\Source"

Cool. I'll give it a shot.

EDIT: Works great, thanks!

Cool. NP.