Creation kit limitations Fallout 4

[SMB92]

Hi folks,

 

Decided to start a thread about certain limits I have come across in CK. I'll update it as I find more.

 

1. Hard limit of 10 parameters on functions. You can pass no more than this or compiler will tell you that there is too many.

 

2.Hard limit of Properties. If you have too many properties you will exceed CKs bit-count of the properties field. It spat an error box and no longer allows you to open it. I am not sure at this stage if using more arrays allows to fill more properties.

 

3. UI limit on fragment scripts. I have some fragments that are too long for the UI to show, therefore it will cut them short and break your code. You can however overcome this by editing the fragment directly, at least on quests. What you have to do is, everytime you want to add a fragment you do so normally through quest UI, and just add a bogus line to the fragment something like 'int bogus' and then compile and save. Then add your code directly into that stage on the fragment script and save. Bring up the Papyrus manager and compile it. Then you reload your mod by going to Data and selecting OK. Your fragment now sticks, but do not ever click on that stage in your quest ever again (you can still add fragments in same way).

 

4. Random Packages not working as intended. It seems the Random Branch/Procedure stops working after a re-evaluation. It also never selects the first procedure from our experience. Bethesda themselves have used Globals for random packages from what we can tell. Best not rely on this one.

[JonathanOstrus]

Hi folks,

 

Decided to start a thread about certain limits I have come across in CK. I'll update it as I find more.

 

1. Hard limit of 10 parameters on functions. You can pass no more than this or compiler will tell you that there is too many.

 

2.Hard limit of Properties. If you have too many properties you will exceed CKs bit-count of the properties field. It spat an error box and no longer allows you to open it. I am not sure at this stage if using more arrays allows to fill more properties.

 

3. UI limit on fragment scripts. I have some fragments that are too long for the UI to show, therefore it will cut them short and break your code. You can however overcome this by editing the fragment directly, at least on quests. What you have to do is, everytime you want to add a fragment you do so normally through quest UI, and just add a bogus line to the fragment something like 'int bogus' and then compile and save. Then add your code directly into that stage on the fragment script and save. Bring up the Papyrus manager and compile it. Then you reload your mod by going to Data and selecting OK. Your fragment now sticks, but do not ever click on that stage in your quest ever again (you can still add fragments in same way).

 

4. Random Packages not working as intended. It seems the Random Branch/Procedure stops working after a re-evaluation. It also never selects the first procedure from our experience. Bethesda themselves have used Globals for random packages from what we can tell. Best not rely on this one.

 

1. Good to know. Perhaps passing an array of your parameters would work? You can use Var[] ParamArray = new Var[somenumber]. Then put in the variables in the indexes. You'd have to keep track of that so you don't forget which order they need to be in.

 

2. Also good to know. I've never run into that personally. Curious to know about solutions though.

 

3. You must have some insane code going on in the fragment. Which arguably shouldn't be in "a fragment". Fragments by design I believe were intended to be for small one off execution of code. Not really for complex routines. What you could/should do for the immediate solution is make a function somewhere (could be in the fragment script file or another script on the object/quest/whatever) and call that function from the fragment proper. Like this:

 

 

 

;BEGIN FRAGMENT CODE - Do not edit anything between this and the end comment
Scriptname DoLotsOfWorkFragment Extends Quest Hidden Const
 
;BEGIN FRAGMENT Fragment_Stage_0010_Item_00
Function Fragment_Stage_0010_Item_00()
;BEGIN AUTOCAST TYPE SFTO_Holotape
Quest __temp = self as Quest
;END AUTOCAST
;BEGIN CODE
INeedToDoLotsOfWorkNow()
;END CODE
EndFunction
;END FRAGMENT
 

;END FRAGMENT CODE - Do not edit anything between this and the begin comment
 

Function INeedToDoLotsOfWorkNow()
    ; do your crazy amounts of work. you might need to set properties on the script, or pass parameters to the function depending on your work.
EndFunction

 

 

 

This would prevent any issue of overflowing the edit box and causing truncation of the script code. The side effect is that you'd have to use an external editor to change your function code rather than the built in CK code editor (which sucks anyway IMHO). Personally I'm concerned about what you might be doing in a fragment that would be so large, and how long that might take to complete as to whether it belongs in a fragment. Or if it might cause other issues.

Edited July 9, 2017 by BigAndFlabby

[SMB92]

Hey he's back! How was your holiday?

 

Actually I'm using the fragment as a menu. It works absolute wonder for such a deep menu. So organized and reliable.

 

I'm in the process of converting over the properties to use arrays to bypass the limit as you mentioned. Gonna take all week to catch up to where I was but gonna add a lot more in while the opportunity has presented itself :)

 

I'll send you a link to the discord server