Far-Beyond-Pulsar/Pulsar-Native

Description The viewport camera controls (right-click drag for rotation, middle-click drag for panning) do not work on native Wayland sessions without XWayland. Root Cause The viewport input thread uses raw X11 FFI calls (XQueryPointer, XWarpPointer, XGrabPointer) for cursor position querying, warping, and confinement. These functions only work under X11 or XWayland — they silently fail or are unavailable on native Wayland. Affected code paths crates/editor/ui_level_editor/src/level_editor/ui/viewport/platform.rs — mod x11 (lines 454+): all cursor manipulation functions (lock_cursor_to_window, set_cursor_position, get_cursor_position, hide_cursor, etc.) crates/editor/ui_level_editor/src/level_editor/ui/viewport/mod.rs — spawn_input_thread_once() mouse poll section: uses get_cursor_position() + set_cursor_position() for delta computation What works on Wayland WASD keyboard movement (reads /dev/input via device_query) Mouse click selection (GPUI/winit Wayland events) Scroll whee

Components in the level editor are not allowed to have unique field values when multiple components of a type are present by the current engine: This will no doubt be fixed during the SceneDB overhauls

Introduction The scripting engine is the final piece that allows gameplay code; whether written in Rust or authored through Blueprints; to interact with the world at runtime. Rather than exposing raw pointers or direct object references, gameplay code will operate on lightweight references that internally resolve to handles into SceneDB. These handles provide stable access to actors and their components while allowing SceneDB to remain the authoritative source of truth for object lifetime, serialization, networking, and editor integration. Once a reference has been resolved, the scripting runtime will be able to invoke methods on actors, query and modify component data, and interact with reflected types through the Pulsar Reflection system. This architecture provides a unified programming model regardless of whether gameplay logic originates from native Rust code or Blueprint graphs. Every scripting backend ultimately communicates through the same reflection layer, ensuring consistent

The level editor hierarchy For reference The blueprint plugin does this perfectly so this may be a place to ref for a rework of the penal in the level editor

Summary All 6 plugin vendor crates have zero translation support — no rust-i18n dependency, no t!() calls, no locale files. Collectively they contain ~300+ hardcoded English UI strings that cannot be localized. This was previously tracked in #63 ("We need a way for plugin UI to support localization") which was closed, but the underlying gap remains. Affected crates and estimated hardcoded strings Crate Est. Strings Key examples blueprint_editor ~100+ Toolbar (Save, Compile, Debug), palette search, properties panel, overlay zoom/debug, prefab/event/macro panels shader_editor ~50+ Toolbar (Save, Compile, Reload), panel titles, palette, properties, compilation messages, overlay zoom table_editor ~30+ Query editor toolbar (Execute, Clear, Export CSV/JSON), row actions (Add, Duplicate, Delete) Common patterns All crates hardcode strings via these patterns: .child("English text") — text nodes .tooltip("English text") — button tooltips .label("English text") — button la