Skip to content

(Starfield) Adding a new Alias for a Quest will result in a "null pointer" #1259

Description

@VivecGod

What is the version of xEdit you are using?

SF1Edit 4.1.5 Experimental x64 ( last public version to date while writing this bug report )

Describe the bug

Adding 1 new Alias in a non-empty "Aliases" list ( The last "Aliases" list, not the first "VMAD > Aliases" one ) for a quest, new or copied from vanilla, and bounding this Alias to a Script Property, will result in the Papyrus log to mention the game can't bound this Alias to the property. Example of meaningful log :
error: Property AliasMsgTxtToGetObjRefName on script myScript attached to myQuest (0B00086C) cannot be bound because <nullptr alias> (1) on quest myQuest (0B00086C) is not the right type

To reproduce

Steps to reproduce the behavior:

1. Create a new quest with DNAM - General Flags : Start Game Enabled, Starts Enabled, Run Once.

2. Add to this quest 2 Aliases set with :
► ALST - Reference Alias ID : Respectively of 0 and 1
► ALID - Alias Names : Respectively of prop1alias and prop2alias
► FNAM - Flags (sorted) : Both being Optional, Stores Text

3. In a texteditor, create a new "myScript" script extending "Quest", with 2 ReferenceAlias Properties having for names, respectively, "prop1alias" and "prop2alias". Then, for instance in an OnQuestInit() event, use the function ForceRefTo to fill the 2 properties with 2 different ObjectReferences ; It could be :

ScriptName myScript Extends Quest
  ReferenceAlias Property prop1alias Auto Const mandatory
  ReferenceAlias Property prop2alias Auto Const mandatory
    Event OnQuestInit()
      prop1alias .ForceRefTo(Game.GetPlayer() as ObjectReference)
      prop2alias .ForceRefTo(Game.GetPlayerHomeSpaceShip() as ObjectReference)
    EndEvent

( Compile your script with last version of Caprica: https://github.com/Orvid/Caprica )

4. In SF1Edit, add this script for your quest ( in VMAD > Scripts (sorted) )
Add to this quest script in SF1Edit 2 properties being prop1alias and prop2alias ; Type = Object / Object v2 FormID = the quest / Alias = 000 prop1alias ( and pick the equivalent Alias = 001 prop2alias, for prop2alias ) . Save & quit SF1Edit.

Launch the game and have a look at the error about "not bounding" and "null pointer" in the Papyrus log in "my documents / My Games / Starfield / Log"...

...Also, you might create in SF1Edit a message object, and the property tied to it in the quest script, which you'll be triggering in your script with the "show()" function. The message text might be something like :
Here I should be reading the Player name : <Alias=prop1alias > and here his current starship name : <Alias=prop2alias >
As you'll then see in game, a weird thing will happen and you'll have for result that :
Here I should be reading the Player name: [...] and here his current starship name: MyCrazyPlayerName!

Basically, only 1 alias, the first filled, will be kept by the game which will be read it where it should have placed the last one.
This can basically be reproduced also with 3, 5, 10 or more aliases :
Only one is kept and is read at the end while all the other will just be "not bounded".

Expected behavior

The expected behavior can be obtained with a simple trick ; Find any existing vanilla quest with yet enough aliases set, copy it into your .esm as a new record and modify it so you get the exact same thing as above EXCEPT you'll never be creating a new Alias ( removing an Alias or more remains possible, though and won't trigger the issue ).

Then everything will work without errors, and you'll have a correct messagebox in game :
Here I should be reading the Player name: MyCrazyPlayerName! and here his current starship name: ShieldBreaker
I did not tried any other setting for aliases, only with "Stores Text" as it is the simplest way to test and it's what I need currently for my own game mod... However, I am affraid anything involving Aliases would result in the same issue making many ( advanced ) scripted features unavailable.

On my side, as mentionned above, I still can cheat in recreating vanilla quests with working Aliases lists for my project, and maybe not much modders will try to work with aliases in the further weeks and monthes (? Well, despite of its mid success, Starfield is yet another Bethesda' monster when it comes to mods, thus it's not that sure ! :P )
Still, it would still be very appreciated if this feature could be fixed ( or at least disabled to prevent modders searching for hours and days what's wrong with them and their code :P )
In the meaning time, thank you very much, Elminster, Sharlikran, Zilav & Hlp for all this tremendous work of yours, you yet nicely shared with us!

Screenshots

I think the description was detailled enough, but I can provide .Esm and scripts to make the tests if needed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions