Just for your reference, this is a type of mod that I subscribed to and equipped from the Steam Workshop!!!

So delicious isnt it? get a giant spoon!

Temperatures are hitting up to 2,000°C (3,630°F). Because it’s orbiting right on the doorstep of a massive star, the sheer thermal radiation and solar winds are stripping it apart. That golden shroud you see in the silhouette is likely a massive ring of vaporized rock and planetary debris. Ultimate doom world vibes. (RS code in comments!)

I know the green line is the trajectory, but what is the purple line? Is it the warp trajectory? The ship I'm using doesn't have the warp drive

EDIT: Also, I haven't seen other ships that have the purple line even ones with warp drive

When ever I try to play Space engine with mods the launcher never opens the game and just keeps sending me back to the addons screen dose anyone know how i can fix this?

jool but evil

how big do these stars get

edit i found a bigger one

since i've got almost no other post ideas i thought i'd might as well just explore my modded galaxy

i don't recommend trying any of the rs codes shown here since you'll either get something wildly different or just get nothing at all. in fact, i don't even know why i included them

So i am a newbie in space engine and i don’t know why sometime I starts to move in a direction the movementjust jams and it keeps on moving ahead without stopping and no matter what i do to stop it just won’t and i am in free mode not in spaceship or anything. I also checked my keyboard for any input errors but its fine so now i am confused about why it would just jam onto one direction and start going that way.

Can someone please help me??

I only have 8 gigs of ram w/ an intel i3, but I was still able to explore space with minimum graphics and take 8K ultra pics !

I love auto for seeing what it is like during the day on planets or from space what it would be like in real life, but in my opinion auto really falls off at the night side of planets. The exposure goes up so high just to see any stars making the ground and any satellite around the body extremely bright. What I have found is HDR seems pretty decent for night sides of planets simulating dark ground and glow from bodies but not overwhelming and of course stars. Is there any workaround to make auto not so bright at night and more like HDR on the night sides of planets besides just flipping between auto and HDR?

Also yeah the clouds are glitching

I’ve been a fan of SpaceEngine for over 10 years now, but as a Mac user I never got to use it very much. In the past, I used Boot Camp to switch to Windows on my Mac just to use SpaceEngine, but it was a very tedious process. On Apple Silicon, Boot Camp is no longer supported and Wine and CrossOver don’t seem to work.

Using Claude Opus 5.5, I was able to create a port that works flawlessly.

I don’t know too much about all the technical details, but it took Claude about 5 hours to create the port.

It’s about 12,000 lines of new code, plus about 1.6 million lines the translator generates from the game itself.

Below is the report written by Claude

TL;DR: Using Claude Opus 5.5 (Anthropic's AI model), I got the Steam release of SpaceEngine running natively on an M5 MacBook Air: full Retina resolution at 60 fps, with Steam, sound, controllers and Workshop all working. This is a personal proof of concept. Below are the technical findings, which might help if the developer ever considers an official Mac version.

Setup

• Game: 0.991, build 50.2155 (Steam)
• Mac: MacBook Air, Apple M5, 32 GB
• OS: macOS 27
• Built with: Claude Opus 5.5
• Date: October 2026

Why I tried this

Wine and CrossOver can't run SpaceEngine on a Mac because the game needs more OpenGL than macOS provides, and Boot Camp is gone on Apple Silicon. I wanted to see whether a native build was possible at all. It is: the game boots, renders at full Retina resolution at 60 fps on a fanless laptop, and I've spent hours flying around the planetarium.

Most of the technical work was done with Claude Opus 5.5: translating the executable, building the compatibility layer, tracking down the shader and driver problems below, and writing up this report.

To be clear about what this is: it was made from my own purchased copy, for my own use only. Nothing from the game has been or will be shared: no executable, no translated code, no data. The encrypted .pak archives were never opened outside the game itself, and Steam's ownership checks run normally.

What works

Findings for a native Mac build

These are the places where macOS behaved differently from Windows drivers. Each one stopped something from working until it was handled.

1. OpenGL stops at 4.1, and a few 4.2+ features are used

The engine runs on 4.1 once the version check is waived. Beyond 4.1 it relies on GL_ARB_buffer_storage (persistently mapped uniform buffers, and pixel-pack buffers for frame capture) and calls glReadnPixels (4.5) when recording video. Reverse-Z depth (glClipControl) and direct state access are unavailable, and the existing fallbacks work.

What worked: persistent mappings backed by ordinary memory, uploaded before each draw and filled after each pixel read; glReadnPixels mapped to glReadPixels.

2. Apple doesn't list extensions that became core

Capabilities are decided by extension name through GLEW. Apple's core profile reports only a short list, so GL_EXT_texture3D and GL_EXT_framebuffer_multisample appear missing even though 3D textures and multisampling are core. Without the first, the atmosphere model cache refuses to initialise and every body reports an unknown atmosphere model. GLEW also only loads glReadnPixels when 4.5 or GL_KHR_robustness is present, yet the recorder calls it unconditionally.

Suggestion: test the GL version for features that are core in it, rather than the old extension names.

3. Program binaries are "supported" with zero formats

Apple's 4.1 includes glProgramBinary but reports GL_NUM_PROGRAM_BINARY_FORMATS as 0. If the shader cache trusts the extension, the first run works and every later run draws a black screen, because no cached program can be loaded back.

Suggestion: enable the cache only when at least one binary format is reported.

4. Apple's GLSL compiler is strictly 4.10

45 shaders needed at least one change and 4 programs failed to link. Each problem is a construct other vendors accept:

• #if on a name that was never defined is an error rather than 0.
• An interpolation qualifier must come before in/out.
• const with a run-time initializer, and stray semicolons after function bodies, are 4.20 features.
• texture2D and similar 1.20 names don't exist in the core profile.
• A variable named like a struct type is parsed as the type, so name.field is a syntax error.
• Stage interfaces are paired by name, not by layout(location): a vertex out and a geometry in with different names don't link (orbit lines).
• Two active vertex attributes at the same location are a link error (cube-map orbits).

Suggestion: compiling the shader set once with Apple's compiler, or with a strict validator such as glslang at version 410, would catch all of these.

5. Contexts and threads

Loader-thread contexts that share objects with the main context work well, as long as only the main thread uses the window's drawable. Contexts on other threads should be made current without one.

6. Retina displays

The engine thinks in pixels throughout, which suits macOS. The window just needs a high-density backing store, with sizes and mouse positions converted from points at the boundary. Rendering at native resolution held 60 fps.

7. Mac keyboards

Modifier shortcuts work once left and right Shift, Ctrl and Alt are tracked separately, since the engine checks them per side. Laptop keyboards have no numeric keypad, and Home, End, Page Up, Page Down, forward Delete and F1–F12 all need the fn key. Many default bindings use those keys. Mac users also expect Cmd where Windows uses Ctrl.

Suggestion: a Mac default key map, or Cmd accepted as Ctrl.

8. Video encoders

LGPL FFmpeg 8 builds cleanly for arm64, and SVT-AV1 runs well on Apple Silicon. NVENC, AMF and QSV don't exist on a Mac, but Apple's VideoToolbox encoders (H.264, HEVC, ProRes) are hardware-accelerated and LGPL-compatible, so they'd be the natural Mac counterpart in the encoder list.

9. Steam needs nothing special

Valve's macOS Steamworks library is arm64-native and initialises app 314650 for a native process; ownership, interfaces and Workshop queries all work.

How it was done

There's no public source, so Claude Opus 5.5 translated the shipped Windows executable instead. Each x86-64 function was converted mechanically to C and compiled for arm64, then checked instruction by instruction against the original in an emulator. A small layer stands in for the parts of Windows the game uses: windows, files, threads, OpenGL contexts, SDL and FFmpeg.

It's a working proof of concept, but it's tied to this exact build and can't be distributed, so it isn't a substitute for a real port.

Long-term caveat: Apple deprecated OpenGL in 2018. It still works well on macOS 27, but a lasting Mac version would probably move to Metal, or to Vulkan through a Metal translation layer.

planet:
RS 11057-60838-0-0-3708 3

so, I was bored and tried to find the game(space)'s border, because outside of the universe it still extends, anyway, here's what happened when I reached 493,322 Gly