Detailed Explanation of All Features

[Heisa]

Version v1.0.0 · Early Beta

Get GoS: SWTOR - 1 Week or 1 Month access

Welcome to the official home of GoS: SWTOR Core. This topic is the starting point for the feature overview, setup notes, and everything the Core allows the user to do.

The Core Menu

Core runs as part of GoS for SWTOR and manages everything in game, with no external tooling. Scripts live in the Core script folder, which Core creates automatically on the first run.

• Open Folder - opens the active live script folder.
• Reload - reloads enabled scripts.
• Folders - sets custom script and log folders, with Defaults and Apply & Reload.

To install official scripts, use the Script Library. Your own scripts go in the Core script folder: drop them in, press Reload, and enable them in the script list.

The menu has two panels: the left panel manages scripts and ESP, and the right panel inspects the selected script.

• Scripts - every script with an enable checkbox, a primary marker, and a live status dot. Clicking a row selects it; the checkbox only enables or disables it.
• ESP - compact feature checkboxes with a color swatch per row: Dots, Boxes, Labels, Toughness, and Effects.
• Selected Script - enable or disable the script, then use the General, Controls, Overlay, and Log tabs.

Controls are generated from the script's own settings schema: toggles, sliders with live values, dropdowns, hotkey pickers, and color swatches.

Log is a per-script console: it shows only that script's output, can be cleared, and can be saved to a log file next to the script. Extremely useful if you vibe code your own scripts and addons!

GoS: SWTOR Core - Core menu with the Lua Developer browser

 

Script Library

Script Library is the official home for GoS: SWTOR Core scripts, built into the overlay. Browse the catalog, install or update in place, and read the changelog before you commit - no downloads, no file copying, no external tools. Core reloads Lua automatically, so the latest release is ready the moment you update.

Official Script Library - installed scripts and available releases

Lua Developer

The Lua Developer button opens an inspection workspace for exact, live ability, effect, and inventory data. Browsing and copying are read-only; its separately confirmed Cast... action is the explicit exception. It sits below Open Folder, Reload, and Folders and keeps your selected script untouched.

• Abilities - action bar and known rows with cooldown, readiness, metadata, charges, and resource cost. Search by name, then copy a name or a full row straight into your script.
• Effects - current buffs, debuffs, and passives with timers, charges, and ownership, plus filters and a last-known group while a refresh is pending.
• Targets - effects are read for your character or your current target, matching the self/current target model your scripts use.
• Inventory - searchable Inventory and Materials Inventory views over the prepared public snapshot. Bag rows use one-based physical slots; Materials rows are prototype-keyed quantities and do not invent physical slots.
• Cast... - runs one confirmed test cast of the selected ability through the normal command path, so you can check behavior without writing a script first.
• Copy Snapshot - copies the current public view, with no private identifiers.

Casts are checked before anything is queued: cooldowns and GCD handling (off-GCD abilities stay usable during the GCD), exact resource cost, range, facing, target state, your own alive/stun/incapacitation state, and line of sight. An explicit cast also keeps your visible target unchanged, because Core saves and restores it around the request.

Lua Developer - live abilities, effects, and targets

 

 

ESP

ESP draws live unit information directly in the game world. Every feature is an independent toggle with its own color.

• Dots - compact unit markers.
• Boxes - a bounding box per unit.
• Labels - full nameplates with fallback text.
• Toughness - unit toughness display.
• Effects - buffs, debuffs, and passives with an All / Buffs / Debuffs / Passives filter.
• Targeting you - shows the units currently targeting you as lines, a list, or a hybrid of both. Each line is colored by line of sight - clear, blocked, or unknown (dashed) - with optional LoS labels and markers above nameplates. Hostile players are always included; friendly players, hostile NPCs, and friendly NPCs are separate filters. Useful for timing a line-of-sight break or a clean kite.

Unit type and reaction classification drive what is drawn, and all ESP settings persist between sessions.

ESP - entity filters for players, companions, and NPCs

ESP features - dots, boxes, labels, toughness, and effects

 

 

Nameplates

Core can draw its own nameplates instead of the ugly stock plates, centered above the character model and scaled with distance.

• Name, distance, and item rating (iLvl) at a glance.
• Exact health with a color gradient bar, plus an optional resource bar with its type and values.
• Combat identity rows: combat style and discipline are resolved for other players from their owned ability families. A discipline needs at least two matching families and no competing spec evidence; a loadout transition shows no spec instead of a stale one.
• Distance scaling: full size up to 30 m, shrinking to half size by 60 m so far units stay readable without clutter.
• Target highlight: red >< markers on both sides, drawn at 100% opacity while other plates use your overall opacity setting.
• Layout controls that persist between sessions: width, text size, gap above the character, opacity, text and bar colors, and bar heights.
• Label output: full nameplates only, or full nameplates with a simple name fallback when exact health is unavailable.

Stock nameplates are turned off in the game's interface settings. Core never writes to the game's own nameplate clips.

Nameplate settings - content, layout, and colors

Actual layout in game

Nameplates - combat style and discipline resolved for the selected target

 

 

World Objects

Harvestables and placeables are labeled with their names, so gathering routes and interactables are easy to spot while moving.

• Type filters choose which object categories are shown.
• A distance limit keeps the list focused on nearby objects.
• Missing data stays unavailable rather than being guessed.

World objects - type filters and a 300 m max distance

Quest item - Trivoris Gas Canister

Heroic quest interactables and objects

Bioanalysis harvestable

Lore object

Scavenging profession world object

Datacrons

Archaeology profession world object

Slicing profession world object

Security chest world object

 

 

Combat Scripting (Lua)

Core exposes a documented Lua API for combat automation. Scripts run sandboxed on Core's update cadence, are enabled, configured, and monitored from the Core menu, and never block the game or render path.

• Runtime - sandboxed Lua on a bounded update scheduler (gos.on_tick) with optional intervals, monotonic time (gos.time_ms), and no render or blocking loops. Process execution, bytecode loading, and native modules stay unavailable.
• World & units - players, companions, NPCs, and objects with type and reaction filters, health, resource, distance, position, rotation, velocity, and on-screen state. Generation-safe handles keep identities valid across updates.
• Targeting - read the current target or request a persistent selection through SWTOR's native target path. Explicit casts never take over the visible target. Simply explained: you can cast on any target, without changing your currently selected one.
• Abilities - loadout and action bar queries, cooldowns, charges, resource cost, GCD, and cast or channel state. Casts are asynchronous with explicit or selected targeting, plus replace and cancel through the command lifecycle.
• Effects - buff, debuff, and passive observations with timers, stacks, charges, and ownership. Status flags separate ready observations from pending or unavailable data.
• Combat events - an ordered, bounded stream for damage, heal, ability, effect, resource, death, and combat, with cursors and drop reporting, plus current cast and instant snapshots for simple presentation.
• Inventory - one prepared, read-only snapshot for occupied physical bag slots and prototype-keyed Materials storage, with explicit pending / ready / unavailable status. Missing item metadata stays absent instead of becoming zero.
• Input - keyboard and mouse state with pressed and released edges, for script keys and toggle logic.
• Settings - each script declares its own menu cards: toggles, sliders, dropdowns, hotkeys, and colors, with activation modes and discipline or ability gates.
• Overlay, logs, and files - unit-anchored and screen draw calls, a per-script console with log levels, and sandboxed modules and file helpers. See the sections below.

Casts pass the same checks as manual play, including resource cost, range, facing, target state, and line of sight. Explicit targets are saved and restored, so your visible target is never taken over. Each cast is asynchronous, and scripts poll the command until it reports a terminal result.

Every public class routine and feature script has its own release thread, linked below.

Current routine support: Sage and Sorcerer; Commando only; and Operative only. Mercenary and Scoundrel mirrors are documented for future Lua support, not advertised as active routes.

Sage / Sorcerer Combat Routine [Level 80]
Commando / Mercenary Combat Routine [Level 80]
Operative / Scoundrel Combat Routine [Level 80]

Feature scripts and libraries

Better Ally Frames · Crowd Control Viewer · Combat Meter (DPS / HPS / DTPS)
PvP Sense · Combat Events (Lua library)

 

 

Sandbox

Every script runs in its own isolated Lua environment. Core treats scripts as untrusted by design, giving them exactly the data and reach they need and nothing more.

• Isolated environments - each top-level script gets its own Lua state with a read-only gos table, and modules resolve only from approved script roots and are cached per script. Simply explained: each script runs in its own sandbox and can only use what Core gives it.
• Safe standard library - base, table, string, math, UTF-8, and coroutine functions are available, plus os.clock, os.date, os.difftime, os.time, and debug.traceback. Process execution, unrestricted OS access, bytecode loading, and native modules are not. Simply explained: scripts get the everyday programming tools, not the ones that could touch your PC or the game.
• Cooperative execution - work runs on Core's update cadence through gos.on_tick. Scripts cannot create render or blocking loops, and an unhandled error disables only that callback until scripts reload. Simply explained: scripts take turns on Core's schedule and can never freeze the game; if one fails, only that script stops.
• Bounded budgets - at most 256 callbacks, 512 active draw commands (192 per callback), 32 unit labels, and 64 interaction rectangles. Each script also keeps its own bounded log buffer. Simply explained: every script has a fixed budget of work and on-screen elements, so none can hog your game.
• File isolation - file helpers stay inside the approved script folders and cannot escape them, with ceilings on listings, downloads, and ZIP extraction. Simply explained: scripts can only read and write inside their own folders.
• Prepared data only - scripts read immutable snapshots prepared off the render path. Missing or pending data stays missing and is never replaced with a guess. Simply explained: scripts only see confirmed information, and unknown values stay unknown instead of being guessed.
• Opaque identities - unit, ability, effect, and command handles are for comparison and round-trips only, and are never parsed or kept across sessions. Simply explained: units and abilities are referenced by temporary IDs that mean nothing outside the current session.
• Validated settings - a script can update only its own registered fields, and field values are validated before they apply. Simply explained: a script can change only its own settings, and every value is checked before it applies.

Overlay & Custom UI

Scripts can draw their own interface on top of the game, anchored to a unit or to the screen.

• Text, lines, rectangles, bars, circles, and images.
• World-space markers that stay at a captured position.
• Clickable rectangles for lightweight buttons and panels.

Scripts refresh their draw calls from the update callback, keeping overlays in sync with the game state.

better_ally_frames - clickable ally frames drawn by a script

 

better_ally_frames shows what script-drawn UI can do. It adds a separate compact ally panel with players, companions, and friendly NPCs; clicking a frame requests selection of that unit. It does not hide or replace SWTOR's stock frames.

combat_meter - live damage and healing tracking drawn by a script

combat_meter is a full script-built window: it reads the combat event stream and shows damage, healing, and damage taken, with contributor/source totals, DPS/HPS/DTPS, breakdowns, bounded incoming history, and explicit incomplete-data warnings. A completed summary remains until Reset or the next encounter.

crowd_control_viewer - ability sprites with live countdowns

crowd_control_viewer draws bundled ability-art sprites for timed debuffs whose normalized reported names match its explicit catalog. Live rows show countdowns; retained last-known rows are dimmed presentation continuity.

Seer rotation - the combat routine's live actions

Seer rotation also draws its own window, listing what the routine is doing while it runs: healing targets, shields, and force recovery, action by action.

pvp_sense - cooldown awareness and action cues

pvp_sense turns known active timed buffs on players into defensive/offensive icons and fresh current-target action cues. It also shows a movable objective-interaction window for five exact active cast names; clicking a row requests that player as your target.

 

 

Modules & Helpers

Scripts can be split into modules and reuse the shared libraries that ship with Core:

• ability_executor - one owner for a rotation's command lifecycle: submit, poll, replace, and safely cancel.
• combat_events - target-scoped combat event handlers with preserved ordering.
• cleanse and cleanse_db - shared cleanse decisions with a catalog generated from the installed client: tiered must / movement / pressure effects, dispel categories for Force, mental, physical, and tech, and per-class cleanser rules for Sage, Operative, and Commando. Definition-key based, with no name guessing.
• combat_meter_incoming - incoming damage, interrupt, effect, and death rows from the combat event stream, plus explicitly labeled local-player CC snapshot observations from exact definition keys.
• actor_labels and healer_action_window - bounded actor-name continuity for meter/history rows, and the shared recent-action panel required by the current Operative and Commando healer entrypoints.
• interrupt and interrupt_db - a shared, class-agnostic PvP interrupt system: the engine runs as an isolated per-class controller through Interrupt.new(), and the database knows every combat style's interrupt ability and ranks 41 exact must-interrupt casts by priority (battle rezzes, healer channels and big heals, long CC, major burst, and pressure casts). It waits until about 85% of the observed cast has elapsed by default (configurable 50-95%) instead of assuming a cast duration, scans every hostile player cast rather than only your target, fires the class's own interrupt through an explicit target so your visible selection never changes, suppresses casts with proven interrupt immunity, conservatively skips Sniper / Gunslinger cover immunity, preserves Stealth by default, and fails closed when cast timing is unreliable. Four exact objective interactions are kept in a separate direct-damage recommendation table, not sent to an interrupt ability. The Operative routine is the first adapter, mapping the shared recommendation into Distraction.
• Class routes - loadout-aware spec modules shared by the live scripts: sage.telekinetics, sage.balance, sage.seer, commando_assault_specialist, commando_combat_medic, commando_gunnery_kit, operative_concealment, operative_lethality, and operative_medicine. Optional abilities come only from the current loadout, never from character level. Current support is Sage and Sorcerer, Commando only, and Operative only; the Mercenary and Scoundrel names remain future mirror references. sentinel_concentration is development-only and excluded from the official package map.
• Support modules - stealth_detector for standalone combat-event last-seen markers, operative_stealth_detection for detector-effect awareness, operative_dps_self_heal and operative_route_common for the Operative kits, and commando_cleanse for Commando dispels.

File helpers stay inside the approved script folders for reads, writes, listings, downloads, and ZIP extraction.

 

Roadmap

Planned work and longer-term goals - not yet implemented:

• Pathing and questing - a pathing system with visual helpers that show where to go (for example, the path to a quest objective), built to support user-made questing profiles.
• Galactic Trade Network (GTN) API - the GTN is the player-driven auction house for buying and selling items for credits; planned script access would let Core automate market tasks such as price checks and listings.
• Gear helper - build on the implemented read-only Inventory API after exact combat-stat aggregation and hypothetical equipped-stat comparisons are validated; current item metadata is not enough to claim which item is better.
• Companion window API - read the companion window from scripts: available companions, offered crew missions, and mission progress.
• Companion gather sender - while your single companion is summoned, send it to gather Bioanalysis, Slicing, Archaeology, and Scavenging resources for you; it returns to you faster, so you can keep going while it gathers.
• Companion mission sender - a quality-of-life sender for Mission skills (Diplomacy, Investigation, Treasure Hunting, and Underworld Trading), so companions keep bringing back resources and rewards.
• Interface performance toggles - turn off individual parts of SWTOR's interface when you want the frames back.
• Per-script performance diagnostics - see the update cost of every loaded script, so heavy callbacks are easy to find.

 

Lua developer documentation and full API reference: gos-swtor.github.io

Edited 12 hours ago by Heisa