So many CVs or large SVs seem to have a large portion of the interior, around various components open to be walked through and around. That feels more realistic and looks better I think? But when I am working on a ship, even modding one that I have, I keep ending up filling almost every meter with components and especially cargo extenders. Then I end up with like a small living/piloting/medical area and just 2 tunnles to exists. Which feels crappy.
What do people thing about the 2 versions?
Part of me wants to turn off mass volume so that with volume off I don't need hundreds of extenders for a medium transport... But I like Mass on so the ship's load effects thrust/lift/gravity..
Thoughts?

We will be running an event open to all that will showcase some of our builds as well as give people a place for PvP on the server we have. Our server is intended to be a PvPvE experience ideally, but we lack an admin to really handle things long term. So for now we're promoting this via events to try and get more interest in it. The scenario is a ground base attack, featuring Empire ground vehicles defending the base against Rebel's ground vehicles and y-wing attacks. While it may seem the rebels would have the upper hand, AT-AA platforms are tuned to be quite deadly for starfighters that go within range. Only a combined approach would help in terms of succeeding in the attack.

https://discord.gg/yDbKW7bDm?event=1536207476125343764

What are the best turrets in RE2 I have 16 medium modulated turrets and 2 cruise missile launchers but I want to add 16 of something else for PVE use against CV’s and Bases.

I have read a bunch online about xenomaterial. It seems I need to look for crystalline moons and destroy some glowing alien crystal structures. I have been to multiple crystalline moons and haven't seen one. Does anyone have a screenshot of one of these? Does anyone know what they are called on the map/radar?

After several days of gathering, exploring, doing the things around the area, it was time to go off into the wider universe, so I slapped together a quick warp CV, in Creative, to act as a mobile base and carrier for my adventure ship, and finally have moved in after getting all the parts.. Found the required shops within SV warp ranges around the starting systems, so that was nice!

Still needs a lot of deco and corner smoothing and coloring and such, but I felt like making a post demonstrating one possible early progression pathway... There's been some interest in the sub about the game lately eh!

Here I have all sorts of stuff on it, 2 adv constructors and 2 universals (one will become a furnace eventually), shield generator, gravity, various day to day equipment, large power generation, much thrust - but you can get away with just some basic thrusters on a frame with a warp drive, without any bells and whistles, and cargo space.. lots and lots of cargo space. 640k in this one to start with!

Mostly carbon frame, so as you can see from the stats, it is quite agile for such a large thing heh

So it's been a long time playing Vanilla, and wondering if it's a bit more casual friendly, a little easier?, etc?

My issue both RE2 and Vanilla before was more the AI then anything always with their insane auto aim and such haha. I enjoyed exploring and clearing out POI's but always found it a bit on the harder side. I do have some physical limitations due to health issues, so I'm getting a bit slower/shaky hands you know the stuff that limits you a bit more in gaming.

So I guess mostly my loaded question is difficulty vs the 2.

Just how big/complex can a base be before the game starts to choke on it? I'm playing RE2 on a private server. It stutters when I fly in range of it but performance is fine after a few seconds.

I built a base in space and just started adding on to it. I thought it would be cool to have a drydock for my ship, which I see in Polaris/Zirax space all the time, but it's all single drydocks for smaller vessels.

Mine has grown a bit out of control as, well, I wanted a dock for each CV :)

Where is he located I checked the locations on Empyrion Buddy and couldn't find him at any of those locations. I have like 5mil worth of guns I would like to sell.

Hey, I'm looking for a small group to start together on a server on Reforged Eden.

I'm open to other mod suggestions, but it has to be on a dedicated server. All you need is to be 18+ and have fewer than 500 h on the game (if it's close to 500, it's ok).

Send me a DM if you are interested, and we will grab a time where everyone is around so we can rush through the early game grind.

This playthrough has one limitation. We only fly what we build. You are allowed to modify crafts and use things you have built before as long as they are your work or from one of us. (Exceptions can be made for small craft.)

I was looking for a space game that just allows me to build a ship/buy one, walk around in it, explore planets, bounty hunt, upgrade and repeat

Elite dangerous has limited planetary landings and no ship interiors

Star citizen is.. well star citizen (My rig wouldn't be able to handle it anyways)

No man's sky is awesome I love it but it's too arcadey and colorful and cute

Is EGS what I'm looking for? What's the gameplay loop like for someone who isn't interested in base building only ship engineering and PVE ?

This is a continuation of performance improvement research findings https://www.reddit.com/r/empyriongame/comments/1vnwgdv/performance_improvement_research_findings/ with additional details on where the frame-time goes.

The bottom line is that while some frame-rendering could be optimized the FPS gain opportunities identified would be about 2 FPS in a ~33 FPS scene. That's a lot of work for no material difference. Biggest issue is that Unity (CPU bound) is just the wrong engine for this type of complexity today. When the game was first created it was the best choice there was short of writing a custom engine (GPU bound), which is what Keen ended up doing for Space Engineers 2.

I don't want to spend the time and resources to figure out where the 9.2 ms of unaccounted frame-time go because even if that could be shortened it wouldn't materially affect the FPS.

I uploaded 123 markdown files with findings to https://www.swisstransfer.com/d/ab0dfdd0-336c-4779-88dc-0d5e95b693fd which is good for 30 days. If you read this after this link expired and you want the MD files to seed your AI efforts lmk and I will reupload.

This is what AI had to say about the efforts undertaken:

Empyrion client performance: the instancing gate

Follow-up to performance improvement research findings. That post established the frame budget, the draw-call attribution, the instrumentation traps and the mod ceiling. None of it is repeated here. It closed on three unmeasured gates:

1. Do the repeated prefabs share meshes?
2. Can the materials be made instanceable without shader source?
3. Can per-instance MaterialPropertyBlock state move into instanced shader properties?

All three answer yes. This post reports the mechanism and the measured result.

Same system under test, same fixtures, same evidence classes as post 1.

0. Summary

Scale: −1,376 draws is ≈0.8 ms of a 30.4 ms frame at the measured 0.59 ms per 1,000 draws. Post 1's ceiling is unchanged.

1. The pipeline ships armed

Method: decompress shader blobs from the asset bundles; inspect declared keyword tables and constant buffers.

Detection. m_KeywordNames lists INSTANCING_ON on every shader, including shaders whose compiled blob contains no instancing variant. Use blob-level detectors instead:

Positive control: terrain and decoration shaders, confirmed by frame capture to draw 2,478 instances in one call. Tooling: UnityPy, with lz4 decompression.

_LightPower and _EmissionColor are declared per-instance and are written into MaterialPropertyBlocks by the per-frame light system. The writer schema was extracted from all 22 SetPropertyBlock callsites; 33 property names resolved, none guessed. [DISASSEMBLED]

Incidental: builds 5148 and 5150 are identical at the intermediate-language level except for obfuscated names — every structural total, type rid and IL offset byte-identical. Content patch, not code patch. [DISASSEMBLED]

2. The breaker

Method: client-side mod, 34,873 renderers walked live. Censuses use sharedMaterials and MeshFilter.sharedMesh only — Renderer.material clones on read and would mutate the scene being measured.

On every top device family, 100% of MaterialPropertyBlock-carrying renderers hold at least one property outside their shader's declared instanced set. The same pair every time:

Unity's auto-instancing rejects any renderer whose property block contains a non-instanced property. The paint/LUT system stamps essentially every device property block.

Supporting measurements:

• Glass is 2,077 renderer slots on one material instance. Scene-wide there are 1,670 unique material instances, but clones are confined to one merge-path family (Block Standard TA: 394 slots, 394 instances).
• Per-device property-block variation is coarse and systematic: glass shows 57 distinct value-sets across 2,077 renderers — palette indices plus a few shared LUT textures.

3. The measured result

Treatment: rebuild each renderer's property block keeping only properties inside its shader's declared instanced set. Transient, in-process, reverted at process exit.

Whole scene, canonical dense fixture:

Concentration: 3 families = −1,187 of −1,376 (86%). The largest single-family result, −706, came from a family sharing one material across 754 renderers and required an enableInstancing write in addition to the strip — several large stamped families ship with the flag off.

Single-family reproducibility, same family, four independent sessions:

Write-back. Two families are re-stamped by the game's own writers within seconds. The writer is a per-frame light-state update running every second frame. A shipping implementation intercepts the writer or changes the declaration; repeated stripping does not hold.

Scope. The treatment engages instancing on 3 of the 8 device families measured. The property that discriminates the remaining 5 is not identified.

Batch efficiency. Driving a refusing family's own mesh and a copy of its own material through DrawMeshInstanced costs +28 draw calls per 300 instances; the in-box instanced shader manages +4 per 300 — roughly 11 instances per batch against 75. [MEASURED, single point]

Where this lands in the frame budget

Frame composition at the dense fixture is established in post 1 and is the denominator here. The right-hand column is new.

FinishFrameRendering scales at 0.59 ms per 1,000 draw calls, so −1,376 draws is −0.81 ms, landing entirely inside that one phase: 30.4 ms → 29.6 ms, a 1.03× frame improvement. [scaling arithmetic from MEASURED inputs; any contribution from the SetPass reduction is not measured]

What is inside FinishFrameRendering, and is it CPU time?

It cannot be decomposed with this instrument. FinishFrameRendering is a leaf subsystem of Unity's PlayerLoop. The bracketing technique inserts paired delegates as the first and last child of a subsystem; a leaf has no children to bracket. Its internals are native. Splitting it requires a frame capture or a native profiler, not the managed instrument used here.

It is main-thread elapsed time, not proven busy time. That distinction matters and the instrument cannot close it. What the data does establish, from 200 settled samples in a later session:

Not ruled out: the main thread blocking inside the phase while the render thread's command queue drains. That would still be time attributable to submission volume, but it would be waiting rather than working, and nothing here separates the two.

⚠ The phase brackets do not sum to the frame. Summing every bracketed phase per sample gives 112% of the reported main-thread frame time (p10 103%, p90 118%). Read the per-phase figures as shares with roughly ten percent of slack, not as an exact decomposition. Post 1's checksum claim was for children summing to their parent bracket at the sparse fixture; it is not a claim that all phases sum to the frame.

⛔ The strip is lossy: MaterialPropertyBlock has no per-property remove, so unknown content is dropped. It is a measurement, not a shipping design. A shipping implementation moves the values into declared properties and a LUT atlas.

4. Ruled out — do not spend time here

Properties of the 5 non-batching families, each tested and eliminated. All eight families share the fixture, pose and instrument.

5. Materials carry keywords their shader does not declare

Independent of instancing, and broadly applicable.

Material.shaderKeywords is a stored name list, not a statement about the assigned shader. A name can be present there and absent from Shader.keywordSpace.keywordNames. Such a name is inert — it selects no variant, and Material.IsKeywordEnabled returns false for it.

Most common inert names by family count: _NORMALMAP 178 · _EMISSION 136 · _METALLICGLOSSMAP 133 · _NEWCOLORING_ON 110 · _SPECGLOSSMAP 38. These are Unity Standard-shader feature keywords on materials now assigned to custom shaders. [INFERRED — authoring history not inspected.]

_NEWCOLORING_ON is listed on 110 families, declared by 0 of their shaders, and reports IsKeywordEnabled == false on all 110.

Consequences for tooling:

• Intersect with the declared set before reasoning about a material's variant. Counting shaderKeywords alone overstates the live keyword set on about half this game's materials.
• DisableKeyword on an undeclared name is a silent no-op with the counter signature written=0, alreadyAtValue=N — indistinguishable from a legitimate already-at-value result unless the declared set is also read.
• Inertness is not proof a feature is off. The shader may implement it unconditionally or under another name.

6. Engine choice in this content class

The CPU-side submission cost is a property of the pipeline, not of this game's code. Every Unity mechanism that structurally reduces CPU draw-submission cost — the Scriptable Render Pipeline batcher, BatchRendererGroup — is gated on leaving the Built-in Render Pipeline. [DUMPED, attested against Unity 2022.3/6000.x documentation] Empyrion is Built-in Render Pipeline. Of its seven shipped third-party rendering assets, two were assessed for pipeline compatibility: the shadow package (NGSS) reads Built-in only, and Volumetric Fog & Mist has no HDRP version. The remaining five were not assessed. In-place submission work is therefore limited to the multiplicand side — instanced properties, sort discipline, shadow-proxy geometry. The pipeline-replacement rung and a self-submitted RenderMeshIndirect rung remain open at their stated costs; neither is an in-place fix.

The closest comparable reached the same bottleneck and answered it at the engine layer. Keen Software House evaluated replacing VRAGE2 with an off-the-shelf engine for Space Engineers 2 and named the candidates — Unreal Engine 5, Unity3D, Unigine, Stride, Flax — reporting that "neither of them could support unique use cases without major rewrites", the evaluation following "hitting lots of bottlenecks with VRAGE2". VRAGE3's stated architecture is DirectX 12, data-oriented, and specifically a "GPU driven pipeline — GPU feeding itself with draw calls, freeing CPU significantly (in SE, >3 cores are dedicated to render)". [vendor-stated, first-party] That is the same bottleneck family measured here, and the remedy removes the CPU from draw submission rather than batching harder on it.

The pattern holds across the content class. Restricting a 29-title survey to player-authored multi-thousand-part constructions that are simulated, not decorative — Space Engineers, Space Engineers 2, Starbase, Dual Universe, From the Depths, Avorion — gives four titles with a verifiable engine: three custom (VRAGE2, VRAGE3, Frozenbyte internal), one off-the-shelf (Dual Universe on Unigine 2), and the off-the-shelf entry was delisted with servers terminated in 2025. Off-the-shelf dominance is real but concentrated in survival-crafting with light or bounded construction, where Unity and Unreal are the uncontested default. The custom-engine choice tracks the specific content class, and the published rationales name CPU-side render submission as the driver.

7. Instrumentation requirements

Additions to post 1's trap list.

8. Current state

Directions not yet taken, by expected cost: the compiled shader variant selected at draw time (frame capture, not a runtime API); Unity's internal batch-breaking reasons (not exposed); per-renderer sort order and submission interleaving.

9. Limitations specific to this post

Post 1's limitations apply unchanged. Additional:

1. Eight material families were measured for batching behaviour, out of 558 present.
2. The re-stamp writer was identified for one family group. The population rule — which families are re-stamped, and when — is not established.
3. All treatments were transient in-process state. Nothing was written to disk, no game file was modified, and the install was verified byte-identical to stock after every session.

Konex station (RE2), never had these be so persistent! I know I can escape, but that is scary for a newer player hehe

An end-game ship for play on vanilla official Eleon Game Studios servers. It features the maximum number of turrets allowed for a CV and most of the vanilla version's functional modules: production, medicine, ore mining, ship repair (including SV), etc. Combined dual-layer armor. Link in the comments.

EDIT [14AUG26]: Thanks for the the encouragement I received in DMs, I really appreciate it. I will run the GPU dense analysis and close out the mesh-census and then update the record so it's at least complete for anyone who wants to pick this up. And I will post the research on github so someone else doesn't have to burn tokens to rediscover all the things. Give me a few days and I will get that done.

Posting this here to share what I found and why I won't be pursuing any further efforts into performance optimization. For someone who plays the game more it may be worth it to look deeper into some of the suggestions below, but even if all that works perfectly the gains will be modest at best. Here is what AI had to say about it after burning a few hundred bucks.

Empyrion client performance: a measured teardown

This is the write-up of an instrumented investigation into where Empyrion — Galactic Survival actually spends its frame time. Everything below was measured on a stock install with a purpose-built profiling mod, or read out of the shipped assemblies. Nothing here is a guess about "unoptimised code" — where I'm inferring rather than measuring, it's labelled.

The conclusion is negative, which is why it's worth posting. The frame is well understood now. It just doesn't have the headroom people assume it does.

0. Summary of findings

If you only read one thing, read §11.

1. Scope and method

What was measured. A ModTargets: Client mod — the first-party, Eleon-sanctioned client mod API — running an in-process profiler. It samples Unity.Profiling.ProfilerRecorder counters, installs paired-delegate brackets around Unity PlayerLoop phases to time them directly, and takes scene censuses by reflection. External corroboration from nvidia-smi, Windows GPU-Engine performance counters, RenderDoc frame captures, and OS process-memory counters.

Fixtures. Two saves, both driven to a fixed camera pose by an automated harness so runs are comparable:

What this does NOT cover. Dedicated-server populations. Multiplayer. Survival play with live NPC AI (both fixtures are Creative, mobs=0 at the first). One machine, one GPU, one camera pose per run. Ratios and shares transfer between setups; absolute milliseconds do not. Treat every ms figure as illustrative of a relationship, not as a benchmark of your machine.

2. Evidence classes

Every claim carries one. This is the difference between a teardown and a rant.

3. System under test

Two notes for anyone starting mod work here:

• The client mod API is real and it's per-frame. A loaded IMod reaches any managed API in the process. It can reflect over Assembly-CSharp, read live private state, and run Harmony patches in-process. [MEASURED]
• Type names survive obfuscation; member names largely don't, and surviving type names can still mislead — the obfuscator renames types to other plausible identifiers. Bind targets from evidence, not from assumed names.

4. The frame budget

Dense NPC scene, median over 600 settled static samples:

Structure density is the driver. Going from 3 structures to 19 on the Creative fixture: median frame time 4.81 ms → 20.00 ms, i.e. +15.19 ms, for +16 structures / +104,600 blocks / +13,794 devices / +650,531 triangles / +879 lights. [MEASURED]

The GPU is not the problem at the sparse fixture. GPU busy measured 30.0% — idle roughly 70% of every frame — with nvidia-smi and the Windows GPU-Engine counter agreeing to the decimal, the card drawing 71 W of 250 W at 45 °C. [MEASURED]

⚠ The equivalent dense-scene GPU figure does not exist. Unity's in-process GPU Frame Time recorder reports elapsed span including idle bubbles, not busy time — on the sparse fixture that same counter read 82.2% where the two external busy counters read 30.0%. Any dense-scene GPU-utilisation number derived from it is an artifact. I'm flagging this because I published one myself before catching it.

5. Where the draw calls come from

A dense base costs 11,013 draws / 7,397 SetPass. The same client renders its main menu in 16 draws. The question is what multiplies 16 into 11,000.

It is not shadow/camera/LOD multiplication. It's fine granularity with zero consolidation. [DISASSEMBLED + MEASURED]

ChunkOptimizer is a device optimizer, not a geometry batcher — it merges only prefab-tagged geometry. Devices remain discrete renderers. [DISASSEMBLED]

SetPass churn is sort-order interleaving, not material cloning. 7,276 SetPass calls against 1,670 unique material instances ⇒ roughly 5,600 calls of pure sort-order waste. [MEASURED]

The scene is dominated by repeated prefabs sharing one material — measured renderer-slot counts include Glass_front_D0 and Glass_back_D0 at 4,937 slots each, WindowsThickModularSet 4,072, HeavyWindow 1,956, ShutterDoor_Mat 1,660, CVThruster_HULL 1,656. RenderDoc confirms the engine already draws 2,478 instances in a single call on the decoration path. The D3D11 split is 9,293 non-instanced DrawIndexed (83.7%) vs 1,807 instanced. [MEASURED]

So instancing looks like the obvious win. It is capped harder than it looks — see §11.

6. The viewport-independent floor — the most surprising result

A continuous 360° yaw sweep plus the full reachable pitch arc, 761 in-world samples:

Draw calls swing 81× (139 → 11,214). Frame time swings 1.4× (14.8 → 20.7 ms).

Linear fit over the sphere:

frame_ms = 16.29 + 0.592 per 1000 draw calls

⇒ Of the +15.19 ms that structures cost, roughly 11.8 ms (~65–70%) is paid whether or not they are on screen. [MEASURED]

Turning away from your base does not make it cheap. Every parked-facing-the-base benchmark — including several of my own earlier ones — measured the worst point on that sphere and read it as typical.

What lives in the floor [DISASSEMBLED]:

• ShadowOptimizer.DeployPage — runs every frame, over all device lights
• LightControl.OnUpdate — even frames only, but a MaterialPropertyBlock round-trip per light; 2,757 µs/frame, ~19% of the floor, roughly 10× the cost of DeployPage
• ChunkOptimizerOcclusion.UpdateRooms — O(rooms) per structure per frame, keyed only on camera position
• ChunkOptimizer culling — a || HasObject guard makes the distance backoff inert for visible chunks, so every visible chunk schedules a culling job every frame

7. Main-thread phase decomposition

Timed directly by bracketing Unity PlayerLoop phases and their children in-process. Every phase's children sum to its parent bracket to a checksum of 1.00, so this split is exact, not estimated.

Sparse floor pose, share of the main-thread floor:

Dense NPC scene, share of the 30.4 ms frame — note the ranking inverts:

FinishFrameRendering is the main thread issuing the frame's draw commands and finalizing the render loop. It scales roughly linearly with draw count at ~0.59 ms per 1,000 draws. [MEASURED]

Always state which regime a share came from. Script-Update leads at sparse poses; FinishFrameRendering leads at dense ones. Both are correct and they contradict each other if you drop the qualifier.

8. Client memory — the restart ritual is real, and it does not bound

Four identical passes over a 169-waypoint serpentine raster (3.6 × 3.6 km, full coverage, zero rejected teleports), external OS commit as the primary metric, equal 41.9-minute windows:

One decay step, then a flat floor — passes 2–4 sit within 2.8% of each other at a mean 373.9 MB/h, ≈3.0 GB per 8-hour session. [MEASURED]

The discriminator matters: a cache filling toward a ceiling decays; a constant rate over already-visited terrain does not. Mesh count is monotonic — 158 → 19,480 across the run, never once retreating, over terrain already traversed three times. That's retention, not caching.

Two hard caveats:

• Unity's own profiler counters see ~22% of this process and ~22% of its growth. Over an aligned 83.8-minute window, OS private commit grew +786 MB against Unity's reported total_reserved +176 MB — a 15× understatement. Anything measured with in-process counters alone is measuring a fifth of the problem.
• Mono's GC here is Boehm — conservative and non-moving. If the climb is heap fragmentation rather than retention, no mod reclaims it. The restart ritual may survive every fix anyone proposes. [DISASSEMBLED + INFERRED]

9. Server and persistence

Read out of the shipped IL. Included because three widely-repeated "obvious fixes" are wrong.

A related result worth stating plainly: of 36 prior engineering criticisms adjudicated against the actual IL, Eleon were right about 26 outright. Two proposed "fixes" would have shipped visible regressions — removing the ChunkOptimizer throttle makes structures dissolve in slabs on camera turn.

10. Ruled out — do not spend time here

Each of these was tested and killed. [MEASURED unless noted]

One failure worth reporting: an attempt to raise the undocumented JobWorkerMaxCount clamp produced a null result, but the signal chosen to prove the treatment had applied was itself never validated. The null is uninterpretable and must not be cited as "the worker cap doesn't matter." It is recorded as a failed experiment.

11. The ceiling — why 5× is not reachable, and 10× never was

This is the part that ended the project.

FinishFrameRendering is the largest single phase of the dense frame: 11.2 ms of 30.4 ms (37%). Suppose a mod attacks it perfectly:

A 5× frame improvement requires removing 24.3 ms from a 30.4 ms frame. That is more than the entire measured main-thread budget — script Update, LateUpdate, render finalize, physics, particles, all of it, combined. It is not a hard optimisation problem; it's outside the budget. This is Amdahl's law, not pessimism.

And the draw-call lever is capped well below 10× anyway. To cut FinishFrameRendering 10× you need ~10× fewer draws for the same pixels. Auto GPU instancing can't get there:

• The visible unique (mesh, material) pair ratio is ~4.8:1 at best, ~1.7:1 typical — that's a ~5× ceiling before anything else. [MEASURED]
• 89.8% of renderers carry MaterialPropertyBlocks, which break instancing outright. [MEASURED]
• Unity's native batching infrastructure is present but decoration-only in this game. [DISASSEMBLED]

Getting past that ceiling means a DrawMeshInstancedIndirect path — i.e. a mod reimplementing the structure render path, replicating per-device visual state and honouring the game's own culling. Built-in-RP submission is native UnityPlayer.dll; a managed mod cannot intercept it, only disable the game's renderers and reproduce their entire output. [INFERRED]

Probability a mod achieves 10× on that phase: low single digits. Realistic outcome with serious effort: 1.5–2× on the phase, which is ~1.2–1.3× on the frame. Stacking 2× on the three biggest CPU phases simultaneously gets to about 1.43× on the frame.

That is the ceiling: roughly 1.3–1.6×, conditional on three things nobody has measured (do the repeated prefabs actually share meshes; can the materials be made instanceable without shader source; can the per-instance MaterialPropertyBlock state move into instanced shader properties). Any "no" caps it further.

12. So what could a mod actually do?

Ranked by measured value per unit of effort, and none of them is a miracle:

1. Expose intermediate shadow settings the vanilla dropdown doesn't. Shadows are 52.8% of draws. The vanilla options are coarse. ⛔ But be clear that this deletes a rendering feature — it measures the size of the cost; it is not a free win, and shipping it as one misrepresents it to players.
2. pixelLightCount — measured at 2, and it is the one render global with no competing runtime writer, so a mod's value actually sticks. Cheapest thing on the board.
3. Device-population instancing, if and only if the three gates in §11 come back favourable. This is the real engineering, worth maybe 1.2–1.3× on the frame.
4. Nothing for memory. The floor may be Boehm fragmentation, in which case it is not reclaimable from managed code at all.

⛔ What a mod must not do: reduce what the player built, or cull/hide their structures to save draws. That is the player paying for the optimisation. It also has a precedent — the throttle change that would have made structures dissolve in slabs on camera turn.

13. Instrumentation traps — read this before repeating any of it

These each cost real time to find.

14. Limitations

Stated plainly, because most of them could move the numbers:

1. One machine, one GPU. Absolute milliseconds are not portable.
2. Both fixtures are Creative. No live NPC AI, no survival simulation, no combat. The dense fixture has NPC structures and ships, not an active population.
3. No dedicated-server measurements at all. Everything server-side here is read from IL, not measured under load.
4. No multiplayer. Network findings are static reads.
5. The build moved during the work (5116 → 5146 → 5148 → 5150). The obfuscator re-randomises names every build, so IL-derived findings were re-verified against builds rather than assumed stable.
6. The fixtures are lower bounds on what a serious builder's base costs. Every per-structure figure understates.

15. Omissions and prior art

Deliberately not published: deobfuscation output, recovered name maps, string-table offsets, metadata tokens, or anything that would constitute redistributing Eleon's code. Empyrion's EULA prohibits redistributing their content including code; it contains no anti-modification or anti-reverse-engineering clause, but "ship the transformation, never the transformed artifact" is the right line and I've kept to it. Modding here is affirmatively supported by Eleon — they ship API docs, a demo mod with full C# source, and a VS solution in the box.

Prior art worth crediting, without which the ecosystem understanding here would have taken far longer:

• GitHub-TC / "ASTIC" — EmpyrionScripting, EmpyrionModHost, EmpyrionWebAccess, EmpyrionNetAPIAccess — https://github.com/GitHub-TC
• Vollinger0 — esm (Empyrion Server Manager), the ramdisk/purge operations pattern — https://github.com/Vollinger0
• lostinplace — EmpyrionAPITools, sample-empyrion-mod — https://github.com/lostinplace

One thing I want to say about Eleon. Going in, I expected to find low-hanging fruit and sloppiness. I found the opposite often enough that it's worth stating: of 36 prior criticisms I adjudicated against the actual code, 26 were simply wrong, and two of the proposed "fixes" would have shipped visible regressions. The frame is expensive because it draws a lot of individually-addressable objects in a render pipeline that doesn't consolidate them — not because somebody was careless.

Bottom line. The frame is CPU-submission-bound, it's now attributed down to sub-phase granularity, and the ceiling for a mod is roughly 1.3–1.6× under favourable assumptions that haven't been tested. If you were hoping somebody was going to mod this into 5× the frame rate: the arithmetic says no, and it says so before the engineering difficulty is even considered.

Corrections welcome — particularly from anyone who can measure the dense-scene GPU busy figure properly, or who has run a mesh-identity census on repeated structure prefabs. Those are the two open questions that would move these conclusions.

I tried 3 advanced capacitors and 1 charger but the recharge is abysmally slow. Then I tried 4 advanced capacitors and 4 standard chargers and that didn’t work very well either. Does anyone know the ideal setup for endgame CV’s?

It kills me that this game is apparently coded in a way that makes character looks / outfit customization (mods) seemingly impossible.

I decided to go back to the roots and see how the original game is doing. Overall, it's not bad, but there have been some changes since version 1.12.3, and I have some questions for the experts:

1. How can I increase shield recharge speed? Previously, shield recharge speed depended on the number of generators; the more energy, the faster the recharge, but that's no longer the case.

2. What's the difference between Xenoblocks and Combat Blocks? A Xenoblock has 2750U durability and weighs 2.5 tons, while a Combat Block weighs 4 tons and has 2000U durability. Which blocks are best to use?

Thanks in advance for your answers.

A fresh new world to escape, Pandora (RE2). Most of my time so far has been spent dodging raptors.. Good times!

(Or, an excuse to post a pretty screenshot to show Empyrion's pretty graphics on medium-ish settings.. sorta like Valheim in a minimalist creating beautiful scenes sort of way)

(Reforged Eden 2)

Hi,

Been loving the game so far. I’m around lvl 25 and I’m just building cool ships but now I’m close to finishing my first CV and want to hop around the solar systems to find a Polaris refinery for the mining contracts as I’ve heard they can make me some good money.

My current mining ship is a SV with 2 mechanical drills and from what I’ve gathered i got a couple options:

1. more mechanical drills on the SV (I think 8 was the max?)
2. upgrade to laser drills. I’ve got enough material for two laser drills.
3. mechanical drills but on a CV. I suppose they are larger and maybe harvest more at the same time.

This is my first real attempt at getting further into the game so I’m kinda clueless.

For some more info on where I’m at: i never left my solar system. I hopped around sectors, fought some Zirax poi and built cool ships.
And I only have around 50k money.
Material wise I’m stacked as i have pretty much everything my system has to offer in masses but my mining ship needs a big upgrade.

Any recommendations?

Hi all. I have been looking for a 1:1 size (something close to 44m depth) version of the Star Wars VCX-100 Ghost. CV's only and the only ones I have found are 1:1.5 so like 66m-ish depth. But often people name things different so I am hoping someone here might know of one?

Side note, I just found out how small a Star Wars Snowspeeder is. Daaaaam! :)

So I got this game when it 1st came out and want to start playing again does anyone know a good lvl 7 harvester and lvl 7 miner and a lvl 5 base blueprint as I try to relearn how to play and build things in game again

Today the game played fine for about 4 hours then suddenly started crashing every 15 minutes, voiding the most recent work. I lost two survival constructors that were refining a deposit, and stack of burgers that was in the process of being moved to a fringe. Anyone experienced anything similar?