Difference between revisions of "Papyrus FAQs"
m
Fixed indentation on script elements
imported>Digitalparanoid |
imported>Kicoax m (Fixed indentation on script elements) |
||
| (14 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 268: | Line 272: | ||
=== Are scripts saved in save games? === | === Are scripts saved in save games? === | ||
According to SmkViper: | |||
<pre> | |||
Scripts are not saved in your save game. Script variable values and currently running functions are saved so they can be resumed. | |||
</pre> | |||
=== What's the alternative to OnUpdate, RegisterForUpdate, and RegisterForSingleUpdate? === | === What's the alternative to OnUpdate, RegisterForUpdate, and RegisterForSingleUpdate? === | ||
You can use the [[OnTimer - ScriptObject|OnTimer]] event alongside the [[StartTimer - ScriptObject|StartTimer]] and [[CancelTimer - ScriptObject|CancelTimer]] functions. | |||
=== 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. | |||
=== How do I create key-value pairs? === | === How do I create key-value pairs? === | ||
=== | According to SmkViper: | ||
<pre> | |||
You can basically fake a map using structs and the new FindStruct function. Just | |||
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.) | |||
</pre> | |||
=== In the Papyrus log, why do the FindAllReferences* functions appear to return references in the player's inventory? === | |||
According to SmkViper: | |||
<pre> | |||
When a persistent reference is moved into a container, the container basically | |||
ends up pointing to the original, now mostly-deleted, reference in the world. | |||
FindAllReferences* is simply finding that mostly-dead reference in world and | |||
returning it. If you were to pick up the item, and run far enough away, | |||
FindAllReferences* likely will not find it, because the original reference is | |||
nowhere near your location. | |||
The inventory system is not designed to be iterated over in such a manner, and | |||
Papyrus is generally is set up to discourage that kind of access by not providing | |||
it at all, and (in F4) preventing you from receiving inventory events without | |||
filters in place. | |||
The good news is that several Papyrus functions can now interact more reliably | |||
with the inventory in F4 so, for example, GetBaseObject will always work, no | |||
matter if the object is in the world, in a container, persistent, or not persistent. | |||
</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> | |||