BBB NMS Save File Manipulator — Help

Understand what setting player location changes before saving it.

Use case 52 · Working with teleport endpoints

Help Index → Working with teleport endpoints → Use case 52

Separate the endpoint record you select from the player/spawn fields that the command changes. The reassuring completion message does not establish that the destination is safe.

Before you start

  1. Identify the loaded save, active Main or Expedition context and intended endpoint. Make a full backup before experimenting.
  2. If you need a precise before/after comparison, export the loaded context before invoking the command and retain it separately. An endpoint-only text selection cannot show every affected field.
  3. Before sync, formatting or structured refresh, copy EACH pending Raw JSON pane to its own external file: one sync can overwrite all others. Reapply non-inventory edits one pane at a time, syncing and comparing exact values before the next. Parse errors can leave an old tree with green status; [] is ignored, and Pretty Print can erase invalid text.
  4. Do not sync/Pretty Print Inventory Raw JSON: dictionary assignment is defective. Use Organizer for supported moves or Replace Items from Backup for supported replacement.

Steps

  1. Preserve EACH pending pane externally before refresh: one sync can overwrite the others. Reapply non-inventory edits one pane at a time, syncing and verifying exact values. Stop after parse errors even if green; [] is ignored and Pretty Print may erase invalid text. Use structured tools, never defective Inventory Raw JSON sync/Pretty Print. (control reference)
  2. Inspect the endpoint’s UniverseAddress and all three Position values in Teleport Endpoints. These are the source values, not a terrain survey or a newly calculated arrival point. (control reference)
  3. Review the scope before using Set Player Location to this Endpoint: it replaces PlayerStateData.UniverseAddress, writes Position[0], Position[1] and Position[2] into SpawnStateData.PlayerPositionInSystem, and sets SpawnStateData.LastKnownPlayerState to OnFoot. (control reference)
  4. If you have already invoked the command, export the current loaded context for comparison with your earlier export. Check those exact fields in the external inspection rather than expecting them all to appear in the endpoint pane. (control reference)
  5. Decide whether to retain the staged change. Save only after verifying the target and destination; otherwise preserve other needed work and reload the original disk data deliberately. (control reference)

Expected result

  1. The selected endpoint supplies the saved address and three player-position coordinates, with the saved player state explicitly OnFoot.
  2. There is no active safe-height adjustment, collision check, terrain validation or in-game teleport performed by this handler.

What changes, and when to save

Setting the location updates app memory. Context export is an inspection aid, not an NMS live save or full backup. A separately confirmed File → Save is required to write the retained live target.

Check the result

  1. Compare the exact address, coordinate values and OnFoot state, not just the completion message. Check for unrelated pending edits before deciding that the complete context is ready to save.

Important details and recovery

  1. The endpoint list can remain visually familiar even though player/spawn fields changed elsewhere in the context.
  2. Do not infer that ship position, orientation or other unlisted fields are recalculated by this command. If safety is uncertain, do not write the staged location.
  3. A context export copies the shared model, not pending editor text. Keep each pending pane’s external copy separately when comparing before/after exports.

Application controls used here

  1. Location action
  2. Export context
  3. Separate live save