The cheats are programmed into the game. They can be accessed through the developer menu in Chrome by pressing F12, opening the 'page' div, then the 'leftColumn' div, then right-clicking, and selecting 'Edit as HTML'. Scroll down to the green section, and delete the HTML comment tags (the green '<!--', and the ending '-->'.) This will open up the cheat codes.
Besides the obvious utility, the cheats are the only way to reset the game without Quantum Temporal Reversion (hard to do on the late game), although on Stage 1 you can also do Xavier Re-initialization. You can also edit the game state directly on local storage on your browser. See Resetting the game for tips.
Finding the cheats[edit | edit source]
Any way to cheat a HTML game that is saved and then played on a browser instead of it being hosted on a site? Tried to use CE on Chrome and Firefox for a game that is saved but when I choose the right process the value can't be found after the 1st search.
The cheats as seen in-game[edit | edit source]
Game.paperclips=9999999999999999999999999999999999999999999999999
Probe Design Trust Boost[edit | edit source]
Probe design trust can be forced to go past the maximum value eg: 44/40
Sugarcube Cheat Engine Extension
To perform this bug set the trust to one below the maximum value and then click the up arrow as fast as possible (3+ above maximum trust is possible with regular clicking, 6+ above maximum trust is possible with an auto-clicker, 20+ above maximum trust is possible if you refresh the page with your autoclicker already running on the spot where the arrow will be.)
Sugarcube Cheats
JavaScript Console Cheats[edit | edit source]
You can also cheat using the JavaScript Console, located in the developer menu.
| Command | Explanation |
|---|---|
| clips | all total clips made |
| unusedClips | always change this alongside clips |
| funds | available funds |
| unsoldClips | unsold inventory |
| clipsSold | all sold clips |
| margin | price per paperclip (in dollars) |
| marketingLvl | marketing level |
| wire | wire in inches |
| clipmakerLevel | number of AutoClippers |
| megaClipperLevel | number of MegaClippers |
| trust | Trust |
| processors | Processors |
| memory | Memory |
| standardOps | Operations |
| creativityOn | whether getting creativity is enabled |
| creativity | amount of creativity |
| yomi | Yomi |
| availableMatter | All available matter |
| totalMatter | Total matter |
| acquiredMatter | All acquired matter |
| foundMatter | All found matter |
| processedMatter | Wire |
| factoryLevel | how many factories you have |
| harvesterLevel | how many harvester drones you have |
| wireDroneLevel | how many wire drones you have |
| boredomLevel | how bored the swarm is becoming |
| boredomFlag | whether the swarm is currently bored |
| giftCountdown | how long till the next gift |
| nextGift | what the next gift is |
| maxTrust | Max Trust |
| honor | Honor |
| probeTrust | Probe trust bought |
| probeUsedTrust | Probe trust being used |
| probeSpeed | Probe speed |
| probeNav | Probe exploration |
| probeRep | Probe Replication |
| probeHaz | Probe hazard remediation |
| probeFac | factory production |
| probeWire | wire drone production |
| probeCombat | Probe combat |
| refresh() | Refreshes all the newly cheated values |
| reset() | resets all progress |
| hypnoDroneEvent() | Enters stage 2 |
Source: [1]
I admit - right from the beginning, so to say, that I am not a HTML coder. So in any programming language that I am familiar with I was forced to use < or > only rarely - mostly in comparisons, sometimes when setting up pipe redirects.
So in Twine and Sugarcube (it's different in Harlowe, I know) I get flooded with the excessive use of << and >> and, of course, also < and > - especially in HTML 'in between' statements.
The worst, though, is that the 'editor' that comes with Twine (1 or 2) is ... somewhat lacking ... whoever came up with the colour coding of a properly working <<>> set and a not working <<>> set should be ashamed. Both are shown in bold and - at least on my monitor - the colour difference is minimal.
Try <<set<<print <<M<yWidget>>>>
Yes, the right ones are blue but honestly, when I glance at the screen (scrolling for error spotting) the difference is so small that I don't really notice it.
My next big problem is the way conditional clauses are handled. I have some complex logic at work and if you have a 7 level if elseif else endif construct and have 3 - 6 new if elseif else endif conitions nested in any of those ... it's ok when you start out because I usually do the empty construct right from the beginning and then fill in the content. But once in a while you may find you have to add/change/delete something and then it is ... er, where was that passage again? ...
In a 'normal' programming language you have 2 things that help you. (a) You have a 'matching brace' function that will show you which { or } belongs where and you usually have a expand/collapse function for if, for and similar constructions that will allow you to quickly find the level you are looking for.
But Twine (especially with SugarCube) defies all that - even when you copy and paste the code to a somewhat decent editor because no editor I own is capable of handling <<if>> as a token for conditions that would allow me to set up a if hierarchy so I could collapse. (Well, they might but then I haven't found out how
So - first question - did anyone else run into those problems and found an editor that would allow them to handle analysis of multi page if statements in a somewhat efficient manner?
Next problem: While Twine 1 or Twine 2 - in their native formats - allow for this nice Debug checkbox that really does show some good information I am pretty much out of luck with SugarCube so far, so I find myself littering my script parts excessively with Debug: <<print ... statements to ensure program flow is as intended.
I did read somewhere that there was a CTRL+ALT+SHIFT+D hotkey for a console but this key combination does nothing on my computer. There is some debugging aid on the Sugarcube site as well but I am too stupid to have an idea how to use it.
Has anyone found a way to achieve something better than tons of <<print messages in the code to have a peek at what code is being executed and what values passed variables have? Any help here would be greatly apprechiated as I find myself spending more and more time hunting elusive errors than doing something, um, productive.
Coming from debugging other language ... I find Twine somewhat lacking in that regard, to put it mildly.