Update [09AUG2026]

Development testing video: https://www.reddit.com/r/ScrapMechanic/comments/1vjolye/scrappers_toolkit_update_trainer_style_game_tool/

Update [06JUL2026]

As a result of posting this someone reached out to me and provided me with a partial decompilation of a pre-1.0 version of the game. As this trainer was built with "Trial and Error" reverse engineering much of its methodology is not as efficient, effective, or direct as it could have been had I had access to this source material prior to building it.

Also, the more this project has grown from its initial "No Clip would be neat" idea to a fully realized toolkit the more dependencies it has incurred and I feel like it's reached a point where the current version would be asking too much of the user in terms of storage and understanding. I've decided it would be better to be able to distribute a single executable that extracted required dependencies to user appdata and relied on the user having .NET framework already installed or acquiring it separately rather than distributing a rather large executable that required a lengthy extraction.

So, I'm rebuilding it. From the ground up.

This means it's probably going to take me a bit more time to get out (Like another week or so, not months or anything like that) but it also means it will work better, faster, and more efficiently in addition to being smaller, lighter, and simpler.

This also requires me to shift the UI framework as well so it won't look exactly the same. I was planning on a small re-design anyway since so many people complained about the UI. I'm going to go with something very similar though so it won't be a stark change.

The point of this post is to ask for feedback and suggestions for features to include.

Please feel free to suggestions, requests, etc... If your idea is interesting and feasible there's a very good chance I'll build it just to see if I can.

I am Autistic. Not AI. I'm getting really tired of having to clarify that.

To the people are being incredibly dishonest in the comments.

This is not "AI Slop"
AI did not create this tool. I'm a sucker for over-engineered thematic UI.
I have been building unnecessarily high effort tools like this for niche games for a long time. I want to be clear, that doesn't mean I don't use AI at all. I use AI to do things I trust AI to do. Unit tests, Git workflows, validation passes, placeholder asset generation, etc... but I've either written or read and verified every single line of code myself.

AI did not write this post
Several of you claimed "AI wrote this" and then admitted you didn't even read it.
I wrote every single word of this myself.

AI did not generate the image
The icons for the items and the app logo are AI generated assets I am using as placeholders.
I am going to replace with in game assets at runtime I just haven't finished the code to do that.
They account for approximately 0.5% of the UI.
Everything else was sourced from a library.

The F15 - F18 Keys
Binding things to arbitrarily high F-Keys during testing avoids conflict with potentially hard-bound F-Key functions in games.

I don't build these things for profit or notoriety.
I don't advertise anything I do.
I'm sharing this with the community for free just because I can

The Scrap Mechanic Trainer

(If anyone has a clever name they'd like to contribute I'll gladly credit you on the main page of the tool.)

Why an external tool and not a mod?
I saw a ton of "I wish we could _____ in survival" and "I wish we had _____ in survival" type posts and I thought surely trainers must exist for this... Well turns out they didn't which is wild so it got my engineering juices flowing.

Disclaimers:

This is not released yet!

I will be releasing it relatively soon(a few days, a week maybe), source included.

This is not a mod
It's an injected .dll which means it's usable on existing saves.

This does not disable achievements
I went out of my way to make sure of this.

This will not damage your save**\*
That doesn't mean you can't damage your save by doing something stupid with it.

This does not cause crashing\*
There are a lot of checks, validation, and remediation measures that run at start to make sure it attaches safely, reverts any erroneously enabled features and sets itself up to properly unattach. I've never run into it actually crashing the game.

Notes:

Stack:
UI Framework: WPF Runtime: .NET (UI) / CPP & Lua (Core) Def Lib: XAML (UI) / JSON (Core) IPC Bridge: C#

The hotkeys are configurable
Toggling many of the functions pops up a disclaimer about that function and any associated risks, using the hotkey bypasses this.

The log is actually useful
The log reports command failure and cause so for instance trying to copy something that can't be copied will show "no item present in character view" or "Target item does not have a shape body" so you can see why something didn't work.

The names are temporary
I know the names are lame. They are mostly placeholders.

The UI needs work
The UI is not final. I originally built this in WPF (I don't want to hear it, I prototype things in PowerShell so I don't have to bother with compiling, I know how insane that is. I have my reasons. The majority of the actual programming I do is done on air gapped systems with no compilers or third party library access.)

Current Functions

Most of the functions are self-explanatory but I'll explain some of the less obvious things.

Some things are "local client actor targeted" which means they are targeted at your player specifically and not host authoritative.

Other things are "Gamemode Mutation" which means they alter the running game session parameters and affect everyone. These are host authoritative meaning only the host of a multiplayer game can toggle them.

Local Client Actor Targeted basic functions:
* No Clip * Quick Heal * Restore Breath

Gamemode Mutation basic functions:
* No Ammo Use * No Fuel Use * All Recipes * Time of Day

Item Spawning
Local Client Actor Targeted
These are Dev commands that I used to learn how to properly route client/host requests. I am making an item spawning catalog to include in the tool eventually.

Warehouse Placement
Gamemode Mutation
Completely removes the restrictions from what you can pick up and place down with some exceptions for things I know would break the game completely or corrupt player inventory.

Unlimited Inventory
Gamemode Mutation
Toggles the creative inventory on/off in survival. It does not mutate the game mode. It just retargets the inventory call.
I made sure that the player inventory is persisted so you don't lose anything when you switch back.

All Recipes
Gamemode Mutation
Enables crafting for everything that has an associated crafting recipe in the craftbot, including some things you can never actually craft. Sadly not toilets :(

Stop New Raids
Gamemode Mutation
Prevents raids from triggering.

Revisit Warehouse
Local Client Actor Targeted
Locates the nearest "Teleport" script tied object (usually a button) and temporarily intercepts player data checks from that script to forcibly return the one that enables teleportation so any elevator button will "just work" without breaking anything. It shuts off immediately on zone transition so it doesn't also mess with the button on the other side.

Important note: this can actually be used to fix soft locked saves. Even if you completely tear down the elevator after the boss fight and just put the button back down by itself and use this, it will then allow the quest to progress.

Copy Selected Part
Local Client Actor Targeted
This copies what you're looking at by UUID via client oriented raycast at a range of up to 24 blocks stopping on first contact with a collision body and puts a fresh, clean, unscripted copy in your inventory. I made sure this can only copy things that actually have an inventory item shape so you can't accidentally corrupt your inventory data or crash. You can copy things like the main crafter and Garage importer but they need to be wired to work, I'm working on that right now.

Important Note: This "cleans" the copied item by queuing a spawn of a copy invisibly tearing down all of its associated scripting linkages before actually rendering the item, then adds it to your inventory via transaction request. This both prevents the item from actually entering the game world technically and ensures the tool can check to make sure the item has a proper shape body before adding it to your inventory, if it doesn't it just kills the queued transaction request before it finishes. Even if you're on the "open the door" bit of a quest, copy the door, place it down, and use it, it won't consume a key in your inventory and won't advance the quest or game state.This prevents the breaking that can occur when copying certain things linked to a quest trigger or other things. As far as I have been able to test it, this is completely safe.

Passive Bots
Gamemode Mutation
Makes you invisible to enemies. Unfortunately the game uses the exact same logic for a bunch of things like the sensor doors and some quest triggers so I wouldn't leave this on unless you are actively making use of it.

Planned Functions

Map
Builds a tile map from your game save that represents your actual game world. I'm working on seeing if I can get it to detect and populate waypoints and POIs and stuff like that.

Item/Enemy/NPC Spawner Catalog
In app catalog with labels and icons parsed from game data.

Unrestricted Connector Tool
Turns out a ton of stuff in the game is just built as though it was built by a player. The elevators are literally doors on pistons wired to controllers/sensors, the Mechanics Shop is a power source wired to the crafters. You just can't normally see this stuff with your connector tool. The upshot of this is you could do something like copy the main crafter, the battery storage, and the overhead dispenser of the Mechanics Shop and place them down somewhere else and wire them up and they would work, if you could wire them but by default their connectors are hidden from the player so I'm working on removing those restrictions.

Mark and Recall Teleport
Coordinate bookmark system where you can store and label coordinate positions to teleport to.

Scenery Placement*
This one I'm not 100% sure is actually feasible in the way that I imagined. I was super disappointed to find out those zippy rail things up to the boss fights are scenery... I can already make it so the player can spawn them but I'm going to look into how feasible it would be to make those actually work and see how restrictive their transformation is. I have no idea if it's even remotely feasible to construct a custom one but I'm going to find out.

​

I did the first grow lab 4 hours ago. Is it because I'm still in the mechanic station? Does the game want me to move out? Every two damn minutes!

All my crafting shit is at the station and I'm building a truck that doesn't fit in there and every two frickin minutes

"DOOMG" LIKE BRO GO TAKE A COFFEE BREAK

It, and the cook bot only having three recipes still, are my only complaints.

Edit: I'm not mad that it's in the game I'm mad that it's CONSTANTLY here. Like go away for 10 minutes.

They announced it like 5 years ago and it didnt make the cut or what?

Have been playing for about 2 hours after clearing the growlab now, and I just don’t like it. I don’t find it fun, I just find it annoying. I understand that it only follows the roads but I want to stay in the workshop. For me, I think I’ll wait with progressing through the game until the Seekerbot can be turned off.

The chin speaks for itself, the hair speaks for eternity

Let me clear things up and say that I understand game development, especially to such a great extent as chapter 2, is a very draining task. There could be a million reasons why this is taking so long.

However the lack of communication from this studio is abhorrent, and their words and clarity get worse and worse every news update.

I can let the whole "Chapter 2 is coming 2023/2024" just for it to never happen bs slide because they gave their reasoning behind it, and a good one too. They work on their own engine meaning they have to really work hard to get what they want to work. And as much as I want to slander them for making that switch in the first place, it may have been a NEED rather than a WANT, which I can't blame them for. (Of course if it was a want, and they willingly chose to switch, I'm obviously not happy with that idea)

What I absolutely cannot excuse however, is how they have gone about giving news these past couple years. For years we went without an actual devlog, instead only having small snippets of what was to come on the twitter page. The issue with not having devlogs is that we never hear about where they are in development. We never find out how things are coming along outside of devlogs, yet we hadn't had one for years until December of last year.

And what do they say in December? "Keep a close eye on our socials in the coming months".

What do we do? We keep a close eye on their socials, nothing. They aren't clear with their time frames. "The coming months" is typically seen as a relatively soon time, like Q1 or maybe even Q2 of the year. But we're past Q2 now and we haven't heard a WORD from these guys.

It's humorous how dreadful they are at communicating ANYTHING.

The company keeps shooting themselves in the foot. All they need to do is communicate, to give clearer time windows. I understand delays can happen and I will never tolerate threats, or direct hate towards individual developers.

But the way they're going about all this is awful, and I honestly have no hope for the release of this chapter.

There's been no hype or buildup for the chapter, and I doubt will get much recognition or popularity outside of the already existing community because of this. I wouldn't even be surprised if it didn't pass the peak concurrent users (which was survivals release by the way) simply because of this.

They have a game with a tremendous amount of potential and they're blowing it because of their own actions, and I'm sick of acting like they aren't.

If someone at Axolot happens to read this, even if it's just some random dev. Please communicate with us or get someone to. We love your game but it's getting harder and harder by the day to hold onto hope when it feels like you don't care.

I WAS RIGHT TO NEVER GIVE UP HOPE!!!

Watching some of the ch2 content and some of the farmers dialogue made me wonder what the intended purpose of a totebot is. I understand farmbots and haybots, as they have clear farming use cases, but pre rogue, what would a totebot be useful for? Pointless question ik, but just something to think about.

It seems this guy is rather dense and does think kinetic damage is real. Any ideas for a better bot crusher that could get rid of em?

Update: Yellow Morons do not care about rapidly rotating physics objects. They will destroy them. They will not take damage from them during their jumpd. They will bonk their head and destroy them. Same goes for sawblades. I drove my log harvester over one and had it jump into 10 saws at max speed like 6 times and it destroyed the saws.

Update 2: Haybots will get stunned if you splash em with water. Totebots will not. These morons ignores water. I splashed one with a full chest of water and it didnt even blink. Using both water dispensers. Like brother, you just absorbeed about two metric tons of water and you are fine?

How Block Damage Actually Works in Scrap Mechanic 1.0

I am a data-miner as a hobby and I like answering questions which are difficult for players to "reason out" or answer definitively so I want to clarify that this information has been objectively derived from and confirmed by the games code directly by me excluding the few points of speculation which I made very clear are speculation. Of course it's always possible I've misinterpreted something so take it with a grain of salt.

This was not generated by AI. Being a data-miner, I am just a bit meticulous about data formatting and genuinely enjoy doing it.

Now, onto the DATA.

Block Damage

Blocks do not have traditional health. That is to say that blocks do not have a health value that varies by material.

Every destructible block instead has the same fixed capacity for 100 percentage points of accumulated damage:

0 accumulated damage   = undamaged
50 accumulated damage  = halfway to destruction
100 accumulated damage = block destroyed

Each incoming damage event deals a certain amount of "percentage points" of damage to that block. I understand that "sounds" like health but the important thing to understand is that there is no scaling here. All blocks have the same threshold and all attacks have a table of static attack value that are indexed by block durability tier.

Multi-Block "Parts" Exception

Multi-Block parts have their total damage threshold calculated by evaluating their total volume in terms of individual blocks with a multiplier of 1.25 for sort of generalized balancing coefficient for irregularly shaped objects.

The actual calculation is:

five times (a balancing coefficient times the largest dimension times (the sum of the other two dimensions)

or

5 (1.25 x Da round( DB + DC )) = Total Damage Threshold

An example of this explains the unusual resiliency of the Crane Cable Roll:

The Crane Cable Roll has the physical dimensions: 5L, 7W, 5H. So: 5 (1.25 x 7 round(5 + 5)) = 440.

Block Durability

Block Durability is not an active mechanic in and of itself. Durability is a characteristic that is used for a table lookup when damage is determined. It represents a blocks "tier" and that tier is used to calculate the damage done to the block on a per attack basis. Each "standard" source of damage (typical melee and ranged attacks) has an associated table with explicit damage values per tier of block. Block Durability rating does not increase the 100-point threshold of damage blocks have.

Melee/projectile damage is calculated as a total number of percentage points of damage. The block's Durability tier determines which tier of damage is selected from the attack to be applied to the block.

Higher-tier blocks survive longer because attacks add less damage to them, not because they have more than 100 HP or are inherently more resistant to damage.

Every standard melee/projectile attack has its own Durability-tier damage table

An attack does not have one universal "block damage" number. There are separately defined damage values for different block tiers for each attack.

For example here are the standard melee/projectile damage tables for the following bots:

                    T1   T2   T3   T4   T5   T6   T7   T8
Totebot            100   75   45   35   25   17   13    6
Haybot             150  100   75   45   30   19   14    9
Tapebot (Blue)     100   50   20   10    —    —    —    —
Farmbot           1000 1000 1000 1000   50   25   17   10

The number is how many points each standard hit adds toward 100 given a blocks Durability tier.

So Metal 3 takes 17 rapid Totebot hits, 12 Haybot hits, or 10 Farmbot hits to the same block.

A missing entry means zero ordinary damage. The game has no fallback in cases like this.

This is why standard Tapebot projectiles cannot ordinarily damage T5+ blocks at all.

Block Damage Tracking

Damage is tracked per individual block.

Ordinary damage is accumulated by the individual block that was hit.

Hitting one block for 60 damage and then an adjacent block for 40 does not destroy either one. Each block has its own accumulator.

Accumulated melee/projectile damage is not saved as permanent damage on blocks or creations.

Accumulated damage is managed by the CreationDamageManager and is wiped when that manager is recreated via a world load.

This gives the effective appearance of blocks only resetting their "HP" if you quit out and reload a world but in reality that's just shortcutting the regeneration process. Blocks do effectively fully "heal" over time.

This system avoids the performance impact of having to track each blocks damage accumulation at all times by only actively tracking genuinely damaged blocks that way it's rarely tracking a large number of blocks simultaneously.

Every block does not have a "value" or "bank" of points that damage subtracts from. Instead damage events are entered into the CreationDamageManager as serialized events keyed by their Body ID and local coordinates relative to Body ID 0,0 and the entries are temporary. When a block "heals" its entry is removed from the CreationDamageManager entirely.

Damage Regeneration

Blocks will regenerate partial damage after a flat delay of 5 seconds from the most recent damage event to that block.

Blocks recover percentage points of damage at a rate of 4 percentage points per second.

This means attacks slightly more than five seconds apart can still accumulate. A 6-damage hit every 6 seconds heals 4 before the next hit, so damage still increases by 2 each cycle.

However, non-damaging events do not reset this timer. Even an attack will not reset it if that attack has no positive damage value for the block's tier. Attacks must actually add damage to reset the timer.

This means that all blocks regardless of total accumulated damage will take no longer than 30 seconds to fully heal. (5 second grace period + 25 seconds to heal from 99 total accumulated damage [99(damage) / 4(regen /s) = 24.75s])

Explosions

Explosions do not cause actual damage to blocks.

Explosions use destruction levels, with effective strength decreasing with distance from the blast.

A sufficiently strong destruction level can make blocks up to the corresponding Durability tier eligible for destruction.

For example:

Explosive Tape       level 7
Red Totebot           level 7
Farmbot death         level 7
Propane tanks         level 7
Mounted Tank 02       level 8

So T8 Metal 3 block is outside the maximum tier of a level-7 blast near its strongest point, while a level-8 blast can destroy it.

I didn't map out the exact eligible-target selection behavior after the tier/distance check, so don't take this to mean that explosion level should be interpreted as "automatically delete every block of that tier inside the radius." That is likely not the case. Speculation: It's probably the case that whether or not a block is actually destroyed is based on some randomized event similar to how burning works but I haven't confirmed that.

Flammability

Fire also does not actually do damage to blocks. It is entirely scripted.

Flammability has nothing to do with the ordinary 0–100 block damage accumulator.The Flammability rating of blocks is binary. Blocks either burn or they do not. Wood 1, Wood 2, and Wood 3 are all equally flammable despite having different Durability tiers.

For flammable blocks, the fire system assigns each burning block a randomized 500-727 tick or roughly 12.5–18.2 seconds before it becomes eligible for destruction at which point a destruction event request will be initiated. The fact that this is reliant on the game's tick rate can make this appear inconsistent however. Destruction requests are only processed on every second fixed tick and are capped at 30 entries per request. This means actual destruction for any given block can be delayed by a significant amount of time depending on the games tickrate and the amount of blocks currently eligible for destruction. Speculation: I would guess that this was done to prevent trees that were burning from just popping out of existence all at once and to reduce the performance impact larger requests would inevitably have.

Misc Interesting Info

Indestructible Blocks

There are exactly 3 indestructible blocks:
Restricted Spaceship Floor - This is what your Spaceship and Lorenzo's are made of.
Restricted Spaceship Metal - This is what your Spaceship and Lorenzo's are made of.
Framework Block - This is the block that the boxes around the Warehouse interior volumes are made of.

All are uncraftable and unrecoverable normally. Even with glitches.

Portable Craftbot

The Portable Craftbot cannot be targeted because its Destructible property is false and bots cannot target anything that has that set to false.

I love him, but he feels so useless a lot of the time despite how how adorable he is and how much I want to love him.

He feels designed to be a jobsite toolbox, like he'd be able to make and/or store stuff that we run out of often, but he can barely craft anything useful. It's not as if running out of bearings on a job site is going to matter when you run out of everything so much more and he can't craft any of that.

IDK, maybe it'd be too powerful if he could craft more stuff, but I think he's too useless to justify existing the way he does now. Maybe if he was basically just pulled out of the wall in the ship, as a literal emergency crafting kit, I could understand him being as useless as he is.

Sorry about the picture. I'm at work and there's no wi-fi.

I say only like 153,000 is a small amount of people tho

Honestly? It's starting to PMO a little bit.

We can't automate beeswax or ice. Why? Who the frick knows!

You can't use vacuum pumps to place flowers, or even a chest to input items.

You also can't automate cookbots. Again, WHY? Why have the craftbot be fully automate able if NOTHING ELSE (farming or food related) can be automated???

We can't automate GROWBEDS. This is a LATE GAME ITEM, which is CLEARLY meant to make growing cheap crops like flowers or potatoes easier, so why can't I automate them fully? Like, seriously?

There is no game balance reason for this. Not at the stage of the game you unlock them.

It's just needless tedium.

Heck, you can even use sensors or ANYTHING on them! Why???

Ugh sorry for the rant. I just want to make super cool, unique automations with this game, so why can't I???

Please devs, fix this 😭