Referencing Papyrus Scripts in Skyrim Quests

In Skyrim Papyrus SCripts I have several scripts attasched to a Quest. The Quest is called Printscreen_MainQuest One script is calledPrintscreen_MainQuest and another is Printscreen_formula/ I need to reference a formula defined in Printscreen_Formula, defined as String Function CheckPath( String Path) global native. I am trying to use the form Printscreen_Formula.Checkpath(Path) where path is itself a strfing Property defined in Printscreen_MainQuest. Is this reference correct? I am geting an error about Printscreen_formula not being linked to an object. I was shortening the file names by truncating *script from the name to save typing. Is this causing a problem ? Do I need to ecplicitly add *script to the filenames? Is herer a better was to solvve thase references? I beed to be able to refer to both data items and functions from other dcript files linked to the MainQuest

Edit

In Skyrim Papyrus scripting, you're running into a common issue with script references. Let me clarify the correct approach:

Script Name vs File Name

Yes, the truncation is likely causing your problem. In Papyrus:

  • File names end with .psc (source) and .pex (compiled)
  • Script names in code should match the actual script name declaration, which typically includes "Script"

So if your files are:

  • Printscreen_MainQuestScript.psc
  • Printscreen_FormulaScript.psc

Then you need to reference them as Printscreen_MainQuestScript and Printscreen_FormulaScript in your code.

Correct Reference Syntax

For a global native function, you should use:

papyrus

String result = Printscreen_FormulaScript.CheckPath(Path)

Better Approaches for Cross-Script References

1. Quest Script Properties (Recommended)

Since both scripts are attached to the same quest, you can create a property reference:

In your main quest script:

papyrus

Scriptname Printscreen_MainQuestScript extends Quest Printscreen_FormulaScript Property FormulaScript Auto String Property Path Auto Function SomeFunction() String result = FormulaScript.CheckPath(Path) EndFunction

Then in the Creation Kit, fill the FormulaScript property by pointing it to the same quest with the formula script attached.

2. Quest Alias Method

Attach the formula script to a quest alias, then reference it through the quest:

papyrus

Printscreen_FormulaScript formulaRef = (Self as Quest).GetAlias(0) as Printscreen_FormulaScript String result = formulaRef.CheckPath(Path)

3. Global Function (Your Current Approach)

If you keep the global native function, ensure:

  • The script name matches exactly (including "Script" if that's how it's declared)
  • The function is properly marked as global native
  • Both scripts are properly compiled and linked

The property-based approach (#1) is generally preferred as it's more reliable and easier to debug than global function calls.

Retry

WL

OK I hace both global natif and ordinary funcion to address. Should I declare my functions as global?

Edit

In Skyrim Papyrus, you generally should NOT declare your custom functions as global unless you have a specific need. Here's why:

When to Use Global Functions

Use global only when:

  • You need to call the function from scripts that have no direct reference to your script object
  • You're creating utility functions that should be accessible anywhere in your mod
  • You're extending the base game's functionality with widely-used helper functions

Problems with Global Functions

  • Performance: Global calls are slower than direct object references
  • Debugging: Harder to trace and debug
  • Dependencies: Creates tighter coupling between scripts
  • Memory: Global functions stay in memory longer

Better Approach: Property References

For your quest-based scripts, use property references instead:

Printscreen_FormulaScript.psc:

papyrus

Scriptname Printscreen_FormulaScript extends Quest ; Regular function (not global) String Function CheckPath(String Path) ; Your logic here return "processed_" + Path EndFunction

Printscreen_MainQuestScript.psc:

papyrus

Scriptname Printscreen_MainQuestScript extends Quest ; Property to reference the formula script Printscreen_FormulaScript Property FormulaScript Auto String Property Path Auto Function SomeFunction() ; Call via property reference String result = FormulaScript.CheckPath(Path) EndFunction

Setting Up Properties in Creation Kit

  1. In the Creation Kit, select your quest
  2. Go to the script attached to the quest
  3. Click "Properties"
  4. Fill the FormulaScript property by selecting the same quest (since both scripts are attached to it)

This approach is faster, more reliable, and easier to debug than global functions. Reserve global for true utility functions that need to be called from anywhere in your mod.

Retry

WL

So can I reference a data value then as well by writing Dara =Formula_Script.OtherData

Edit

Yes, but with some important caveats about Papyrus data access. Here's how it works:

Property Access

You can access properties from other scripts using the same syntax:

Printscreen_FormulaScript.psc:

papyrus

Scriptname Printscreen_FormulaScript extends Quest String Property OtherData Auto ; This can be accessed from outside Int Property SomeNumber Auto ; Private variable - cannot be accessed from outside String MyPrivateVariable

Printscreen_MainQuestScript.psc:

papyrus

Scriptname Printscreen_MainQuestScript extends Quest Printscreen_FormulaScript Property FormulaScript Auto Function SomeFunction() ; Access properties from other script String data = FormulaScript.OtherData Int number = FormulaScript.SomeNumber ; You can also set them FormulaScript.OtherData = "new value" EndFunction

Important Limitations

You can only access:

  • Properties declared with Property ... Auto
  • Properties declared with Property ... Auto Hidden
  • Functions

You cannot access:

  • Regular variables (like String MyVariable)
  • Local variables inside functions
  • Private data

Best Practices

  1. Use properties for shared data: If data needs to be accessed from other scripts, make it a property
  2. Use variables for internal data: Keep script-internal data as regular variables
  3. Consider getter/setter functions: For complex data access, sometimes functions are cleaner:

papyrus

; Instead of direct property access String Function GetProcessedData() return ProcessData(MyInternalVariable) EndFunction

So yes, Data = FormulaScript.OtherData will work as long as OtherData is declared as a property in the formula script.

Retry

WL

Ok I already define all my variables as properties so I think my problem is basically the lact of the script term in the filename

Edit

Exactly! That's almost certainly your issue. In Papyrus, the script reference name must match the actual script name declaration, not just the filename.

The Problem

If your files are named:

  • Printscreen_MainQuestScript.psc
  • Printscreen_FormulaScript.psc

And the script declarations inside are:

papyrus

Scriptname Printscreen_MainQuestScript extends Quest Scriptname Printscreen_FormulaScript extends Quest

Then you must reference them as:

papyrus

Data = Printscreen_FormulaScript.OtherData ; Correct Data = Printscreen_Formula.OtherData ; Wrong - causes "not linked to object" error

Quick Fix

Change your references from:

papyrus

Printscreen_Formula.CheckPath(Path)

To:

papyrus

Printscreen_FormulaScript.CheckPath(Path)

And make sure your property declaration matches:

papyrus

Printscreen_FormulaScript Property FormulaScript Auto ; Use full script name

The "not linked to an object" error is Papyrus telling you it can't find a script with that exact name. Since you've been truncating "Script" from the names, it literally can't find Printscreen_Formula because no script exists with that name - only Printscreen_FormulaScript exists.

Once you use the full script names in your references, everything should work properly.