Difference between revisions of "Papyrus FAQs"
m
Fixed indentation on script elements
imported>Digitalparanoid |
imported>Kicoax m (Fixed indentation on script elements) |
||
(7 intermediate revisions by 2 users not shown) | |||
Line 16: | Line 16: | ||
=== To whom do I send fan/hate mail about Papyrus? === | === To whom do I send fan/hate mail about Papyrus? === | ||
[https://community.bethesda.net/people/SmkViper SmkViper] created Papyrus and actively helps scripters in the official Fallout 4 Creation Kit forum. | [https://community.bethesda.net/people/SmkViper SmkViper] created Papyrus and actively helps scripters in the [https://community.bethesda.net/community/fallout/fallout-4/creation-kit-beta official Fallout 4 Creation Kit forum.] | ||
== First Steps == | == First Steps == | ||
Line 167: | Line 167: | ||
<PapyrusProject xmlns="PapyrusProject.xsd" Flags="Institute_Papyrus_Flags.flg" Output="D:\Steam\steamapps\common\Fallout 4\Data\Scripts" Optimize="true" Release="true" Final="true"> | <PapyrusProject xmlns="PapyrusProject.xsd" Flags="Institute_Papyrus_Flags.flg" Output="D:\Steam\steamapps\common\Fallout 4\Data\Scripts" Optimize="true" Release="true" Final="true"> | ||
<Imports> | <Imports> | ||
<Import>D:\Steam\steamapps\common\Fallout 4\Data\Scripts\Source\User</Import> | <Import>D:\Steam\steamapps\common\Fallout 4\Data\Scripts\Source\User</Import> | ||
<Import>D:\Steam\steamapps\common\Fallout 4\Data\Scripts\Source\Base</Import> | |||
</Imports> | </Imports> | ||
<Scripts> | <Scripts> | ||
<Script>AutoLoot\Fragments\Terminals\TERM_dubhAutoLootMenuAdvance_0100272C.psc</Script> | |||
... | |||
</Scripts> | </Scripts> | ||
</PapyrusProject> | </PapyrusProject> | ||
Line 196: | Line 196: | ||
== Advanced == | == Advanced == | ||
=== Are data types distinct? Or are they ultimately floats as in the Oblivion scripting language? === | |||
In the Oblivion scripting language, bools were integers and integers were floats; the bool and integer data types were therefore clarifying abstractions and ultimately floats. However, in Papyrus, each data type is distinct, but although each data type is distinct, the compiler will automatically cast certain types to other types that are determined to be safe. | |||
=== Are While loops safe to use for persistent or continuous effects? === | === Are While loops safe to use for persistent or continuous effects? === | ||
Line 281: | Line 285: | ||
=== Are arrays limited to 128 elements? === | === Are arrays limited to 128 elements? === | ||
* Arrays that are created by scripts via the <code>New</code> operation or <code>Add()</code> function '''are''' limited to 128 elements. | |||
< | * Arrays returned by native functions, and editor-filled array properties, are '''not''' limited to 128 elements. | ||
=== How do I create a dynamic array? === | === How do I create a dynamic array? === | ||
Dynamic arrays grow to fit the number of elements. | |||
To create an empty dynamic array, pass <code>0</code> as the size. | |||
<code> | |||
ObjectReference[] dynamicArray = new ObjectReference[0] | |||
</code> | |||
Also: | |||
* You can pass in a variable or calculation for the array size. | |||
* You can call <code>Add()</code> and <code>Remove()</code> on the array to add and remove items. | |||
call | |||
=== How do I create key-value pairs? === | === How do I create key-value pairs? === | ||
Line 304: | Line 311: | ||
make one struct variable your key, and the other the value, and then run Find on | make one struct variable your key, and the other the value, and then run Find on | ||
the key. (Unlike maps, duplicates are permitted since it's just an array.) | the key. (Unlike maps, duplicates are permitted since it's just an array.) | ||
</pre> | </pre> | ||
Line 344: | Line 335: | ||
</pre> | </pre> | ||
=== Can structs store arrays, other structs, and var types? Can arrays store arrays? === | === Can structs store arrays, other structs, and var types? Can arrays store arrays? === | ||
According to SmkViper: | |||
<pre> | |||
Structs are intentionally forbidden from storing arrays, other structs, and var | |||
types to eliminate possible sources of circular references. | |||
Arrays cannot store arrays for the same reason (and because it requires more | |||
work on the part of the type syntax). | |||
</pre> | |||
=== Can CallFunction() be used for reflection? === | === Can CallFunction() be used for reflection? === | ||
According to SmkViper: | |||
<pre> | |||
CallFunction is designed for inter-mod communication and does not have type | |||
information as a result. It is very finicky to use and the compiler can't tell | |||
you if you're doing it wrong. It also is going to be more expensive than a | |||
normal function call both in terms of how fast it runs and the amount of memory | |||
used because you're going through the abstraction of a var array. Therefore - | |||
avoid using it unless you absolutely have to. It's there to solve a very | |||
particular problem, not be a general catch-all for reflection. | |||
</pre> | |||
=== How do I use custom events instead of CallFunction()? === | === How do I use custom events instead of CallFunction()? === | ||
=== | |||
According to SmkViper: | |||
<pre> | |||
You can pass your script as one of the parameters of the custom event and they can call | |||
a function on your script in return to give the value back. The big advantage of custom | |||
events is they can dispatch in parallel, greatly speeding up processing. | |||
</pre> | |||
== Troubleshooting == | |||
=== What happens when Papyrus is "overloaded"? === | |||
According to SmkViper: | |||
<pre> | |||
The only thing "overloading" the script system will ever do will be to slow down all | |||
script processing. You could theoretically run your system out of memory at some point | |||
but the game would be unplayable long before then. | |||
</pre> | |||
=== Does Papyrus affect framerate? Or "drop" function calls? Or "lose" entire scripts? === | |||
No. According to SmkViper: | |||
<pre> | |||
Papyrus never affects framerate, nor does it "drop" function calls. It doesn't "drop | |||
scripts" either, whatever the heck that would mean) You wouldn't have an "overload" | |||
problem if it did, because then it would just throw things out instead of slow down, | |||
but that way lies madness - randomly not running function calls is just silly. | |||
</pre> |