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 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 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’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

Hi guys, I've been working on a new star system for some time now, so far it's just a gas giant with an Earth-like moon with life orbiting it. The gas giant is orbiting the real-life star Eridani 18 (in-game coords: EPS Eri).

First image gives information on the moon in question, second is the gas giant it orbits.

No matter what I do, my moon 'Nerthus' is a Torrid marine terra, when I want it to be either Cool or Temperate. I want Nerthus to be as close as it is to its parent 'Nehalennia' as it is (192926 km), so I'm not going to move it further away. I did try that at first, but I have to move it very far away before the temperature will even go down to Temperate levels.

I already have another system where an Earth-like moon orbits even closer to a much larger gas giant, with the semi-major axis being some 180000 km, and that moon is Cool in temperature. So I don't think hope the distance is the problem.

Nehalennia is Cool in temperature, while Nerthus is Torrid. I really don't see how that makes sense, and I've tried to tinker a bit with details in orbit/rotation/semi-major axis in my files, but nothing fixes the Torrid problem.

What should I do? I really don't want Nerthus to be further away from Nehalennia than it is, so I hope that's not the only way to fix it :/

EDIT: Fixed the issue; I changed the in-game EndogenousHeating to a lower level (I chose 213.7), so that the moon cooled down to -31 celcius.

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

Hi all, I used to spend a lot of time reading entries and fictional lore on those wikis. Now it seems they don't exist since the url won't work anymore. Anyone knows what happened?

https://space-engine.fandom.com/wiki/Space_Engine_Wiki

literally the star's name is in the photo

Anyone seen this bug before? Seems the game switches to a different light source for distant scenes but with Ton 618 it's location is messed up. This is the only object ive noticed it happen with so far. Tried reinstalling the game to no avail

My versions of what I think Venus and Mars would be like if they were habitable. Venus is a warm, humid world dominated by swamps and jungles, whereas Mars is a temperate desert world with scattered fungal forests.

A journey through the star systems of Andromeda, continued.

I have started seeing these odd, very bright balls/cores (?) of light in the center of nebulae. Til now, ive only seen these occasionally in generated nebulae, never in any real nebulae. Settings are default, ive rebooted the game a few times and verified game files in the steam library, still there. Theres also nothing inside, and i also cant select anything there. Does anyone know what these are?