next »

[gimymblert]

[TheWing]

Simply awesome analysis

I was wondering if you could (somewhen in the future) incorporate those graphing tools to the game itself, for public use.. I'd love to be able to see stats like that from my own runs only..

But, anyhow, it's a damn great game and a damn great tournament!

[Kyzrati]

Glad you're enjoying everything, TheWing

I would like to include some types of graphs in the game, one day, yes; and to a greater degree perhaps something online. None if this would happen soon, but it's something I do hope to have.

Yeah, and me preparing that post:

[JobLeonard]

You're not human, Kyzrati.

[Kyzrati]

Where do you think my intimate knowledge of robots from the 23rd century comes from!

But damn, sometimes I wish I knew how to slow down and relax. It was easier before I started taking

Simply awesome analysis

I was wondering if you could (somewhen in the future) incorporate those graphing tools to the game itself, for public use.. I'd love to be able to see stats like that from my own runs only..

In other news, yesterday I worked on a mockup for a new blog post coming up. Some local stat ideas:

[JobLeonard]

Once you're done with this game you should try teletext graphics

[Kyzrati]

The resemblance is there!

I'm all about 100% saturation; if anything it takes one more variable out of the style equation

[standardcombo]

Nicely done. Impressive stats gathering.

In terms of non-game-specific I always look for retention/return rate as the most important stat. That, in addition to some funnels to understand where players stop playing. It's a good way to find UX snags. I look for how retention changes between versions (hopefully goes up!).

[CoreGG]

I like the unique graphics, keep on

[Kyzrati]

Nicely done. Impressive stats gathering.

In terms of non-game-specific I always look for retention/return rate as the most important stat. That, in addition to some funnels to understand where players stop playing. It's a good way to find UX snags. I look for how retention changes between versions (hopefully goes up!).

Where players stop playing isn't yet too meaningful since the game is still alpha so right now many will try out new releases just to see what's up, then stop to avoid spoiling too much of the full experience they're waiting for. With early access you almost need a direct survey to eliminate confounding variables, especially for very small-scale games. Unless of course it's an F2P/demo/online game which tend to have a much larger pool of players right away--observations there can certainly help guide design.

Another important difference with the Cogmind player base, which further contributes to the "buy now, wait until 1.0" mentality, is that the average player age is much higher than other games, so players don't have as much time to play games as, say, the teenage segment.

Lots of interesting stats to look at, but man doing all this spreadsheet stuff sure gets in the way of coding

I like the unique graphics, keep on

Thanks, keeping on is the skill I rely on most

[Kyzrati]

I took part in an interview with Darren and Mark of Roguelike Radio, the only roguelike-focused podcast on the web! You can listen to it here.

Of course the interview was about Cogmind =p. But we did also talk about some personal stuff and a few other aspects of my work, among other interesting topics. It was a lot of fun :D

(Check out the other RR episodes as well--lots of interesting topics over the years.)

[Kyzrati]

Morgue Files
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Death is fairly frequent in roguelikes, but the fun doesn't stop there! We usually still have access to post-game "content" in the form of text files detailing how a particular run played out.

The typical traditional roguelike player tends to love statistics describing their performance, and detailed morgue files are a good way to satisfy that desire, while at the same time enabling players to show off achievements, get opinions from other players, and review an experience to perhaps learn more from it. Looking back through an overview of their game, a player might discover something they hadn't noticed before, or the file may directly reveal unknowns like the fully identified contents of one's inventory. (I had a potion of what?!)


Other Roguelikes
A lot of the major roguelikes have been modernizing their community services with extensive public databases that allow for searching, sorting, and all manner of additional features. (References: DCSS Online Players and Scoring Overview; ToME4 Characters Vault; Angband Ladder; Nethack High Scores) I've written a little bit about Web Support in Single-Player Roguelikes before, while here we'll just be focusing on a survey of text info data referring to a specific run/character.

DCSS morgue file header (complete file).

DCSS begins with a summary of vital information, followed by:

• basic character stats and status
• detailed descriptions of each inventory item
• dungeon locations visited and features discovered
• message log and map immediately before the run ended
• complete list of kills
• long list of important chronological notes from throughout the run
• chart containing a breakdown of all major actions taken

I really like the density of information at the top, probably the best example of a character file where so many details are available without scrolling--even equipped items are summarized right there. The actions chart found at the end is an interesting tool for reviewing general strategy and comparing it to other runs.

DoomRL morgue file header (complete file).

DoomRL also begins with an overall summary, though subsequent sections come in a somewhat unexpected order, seemingly aimed at front-loading information reflecting final results:

• special levels
• awards earned
• snapshot of the map/surroundings where the run ended
• basic character stats
• equipment and inventory items
• complete list of kills
• history of important events
• message log immediately before the run ended
• meta information comparing previous runs

My favorite part of this one is the history, which in describing only important events in a condensed format does a better job of telling the story of the run than a full message log can. I'd like to incorporate something similar into Cogmind, later when story elements are in place and such a feature would be a lot more meaningful.

Meta info tracking the player's progress from other runs is a nice addition, too, though here it's quite limited.

Angband morgue file header (complete file).

Angband's file opens with a very dense block of character stats, then:

• detailed equipment list
• carried inventory items
• home inventory items
• history of important events and when/where they occurred
• UI/game options

As with DCSS, I like the density up front, the one drawback being that it is more complicated to parse when writing code to scrape the data. The best way to handle this is of course to store the information in a separate format meant to be parsed, then it can be output in any format necessary. Nethack, for example, does exactly this with its Xlogfile format, but it surprisingly doesn't have human-readable morgue files, at least nothing official. The online system linked earlier does record and display basic run information, however.

ADOM morgue file header (complete file).

ADOM begins with a complete screenshot of the final game state, map, stats and all, followed by:

• character background
• equipped items list
• backpack (inventory) contents
• weapon skills
• skill list
• spell list
• major achievements
• artifacts generated
• other player characteristics
• monsters vanquished
• meta data (play time, version)

The screenshot opening is a nice approach, as it provides a pretty effective summary, which honestly a good UI should be capable of in the first place--putting it directly into the log reflects that effectiveness. ADOM is capable of outputting the character log in both an abbreviated and verbose form (the latter is what's shown above).


Format
All of the above games provide their morgue files in a simple text format, enabling players to easily share/paste them on forums or elsewhere. Of course an alternative is to just link directly to an online record, text or not, which is currently the only way to share complete character information in ToME4, for example. That does have the advantage of providing a more interactive experience for understanding the contents (ex: ability descriptions), though the information itself isn't as easily posted elsewhere in a predefined format.


Terminology
There is no common term for referring to these files throughout the genre. In fact, there are almost as many terms as there are games...

• Character File: The official term for DCSS morgue files, and the most generic of the bunch that doesn't really have any additional connotations, except that it perhaps doesn't imply that a run has ended. Technically this one's generic enough that it could be confused for a save file.
  
• Morgue File: Generally associated with DCSS as well, though not an official term. (It happens to be the one I've picked up on.) The name implies that a character is dead, and therefore may not feel all that appropriate for victories (although as we know death is more common). That said, your character will die eventually, right? (On that note, even when you win UMoria, it will indicate that you died of "ripe old age.")
  
• Character Dump: This term implies that the information might have been exported from a game still in progress, though Angband uses it even for completed games.
  
• Post-mortem Character Dump: DoomRL adds a qualifier to indicate that the run has actually ended.
  
• Character Log: The ADOM community uses this one (though it's not written anywhere in the file itself); it's pretty generic and applies well enough to this use, although there is that chance of confusion between a record of everything about a character and just the message log itself.
  
• Character Record: Another generic term used by some games not discussed here.
  
• YASD/YAVP: Colloquial abbreviations that can just as easily refer to the files themselves as they can the final outcome, adding a little extra meaning since we know both that the run ended and how.
  

Not that terminology is super important; I just thought it was interesting to note while doing this survey.


(continued in the next post...)

[Kyzrati]

(...continued from the previous post)


Cogmind Score Sheets
I've always called Cogmind's morgue files by yet a different name (of course...): score sheets. When first created the intention was to essential just show a score breakdown and a handful of character stats, but even early on that changed rapidly and score was left as only a very small portion of the file contents...


History
Shortly after Cogmind's birth for 7DRL2012 I decided to hold a player tournament for fun, but felt that basing it on score alone wouldn't by very exciting, so the first update in preparation for that was to add to the score sheet a variety of other collected stats that described the player's run. Not just the number of kills on enemy type X, but also some less obvious values like "number of tactical retreats," "shots fired from each class of weapon," "number of items of each type lost to attrition," etc.

At the time there were 78 variables, along with a few separate lists of varying types. These served as the basis for a more interesting tournament while I was still working on improving the game by implementing feature requests.

Then of course as a little side project the game was put on permanent hiatus with no plans to revive it.

Then of course "no plans to revive it" turned into making it something really big, and throughout more than a year of pre-alpha development I kept adding more of those score sheet variables as new features were added (and I came up with more ideas).

Now we have 350 of them.


Score Sheet 0.10
After completing the above survey of morgue files in other games, I'm surprised that none of them go as far as to record numerous statistics describing events or highly specific actions that shed light on player behavior, or derive other meaningful stats from the game data. (The DCSS action chart is a notable exception, but still limited in scope.)

Perhaps it's that Cogmind is much more a tactical game than a strategic one. Most roguelikes on the other hand have a strong emphasis on long-term character development and therefore recording and reporting information about the player characters themselves already tells you so much. That's where a majority of the gameplay decisions are reflected, whereas in Cogmind there is almost no emphasis on character development at all; instead it's a game about making minute-to-minute decisions without certainty that your condition or form will be even remotely similar on the next floor, or even around the next corner. As such, the focus of a score sheet should be more about actions, behavioral statistics, and factors external to the character.

To be more specific, here are some of the variables recorded for each run in Cogmind:

Cogmind score sheet excerpt; data columns doubled up to save space / show more.

In any case, without additional variables like these Cogmind's score sheet would be pretty barren. Having all the extra data also came in handy when the recent Alpha Challenge 2015 took a page from the 7DRL tournament playbook and added lots more achievements based on them. With data like this there are also the many useful graphs that come out of comparing runs or combining data from multiple players as shown in the previous post about player metrics.

As with the other games, let's look at the header of a Cogmind score sheet then discuss the contents:

Cogmind morgue file header (complete file).

(The first thing you'll notice is it doesn't use horizontal space very well. More on that later.)

Cogmind begins with a complete score breakdown, then:

• player stats
• attached parts
• inventory contents
• peak state
• favorite item of each type and subtype
• many gameplay stats (e.g. the earlier variable lists)
• list of identified prototype items
• meta data (play time, UI preferences, etc.)

So-called "peak state" is very important, added because unlike characters in other roguelikes, most Cogminds die naked and alone. Sad, I know. We'd never know what a player's equipment really looked like if only recording it at their point of death (unless they made it to the surface, as in the sheet shown above).  So the game also shows what a fallen Cogmind looked like at their best, defined as when the combined combined rating of all their attached parts is at its highest.

Sample peak states, for fun :D.

Because Cogmind's gameplay revolves tightly around the items you use, which may change significantly throughout a game (since there is no such thing as skill/class/race limitations that might lock you out of using anything in particular), simply looking at peak state is only informative about a relatively short duration of the run. To tell us more, there are lists of favorite items of each type, further divided into subtypes:

Sample favorite item lists, for double the fun.

Taking the bottom-left list as an example, while that player may have been a hovering hacker bot at their peak state, according to their favorites they spent most of the game as a treaded heavy weapons platform.


Format
Having become bloated by simply tacking on more and more variables, while the content is sufficient the score sheet's overall format is far from perfect, with its combination of vertical lists and simple VARIABLE=VALUE format all the way down. All that horizontal white spice should be put to work as we see in the DCSS and Angband morgue files. Many variables could be expanded to show more details, reorganized into meaningful charts, and more...

I'd really like to redesign the entire file to better condense the information, though as mentioned earlier that's a problem for parsing. Using two files, one machine-readable and one human-readable, isn't the greatest solution since players tend to share human-readable files so there would be no way to easily import a file shared that way. However, seeing as the game directly uploads the score sheets now anyway, maybe that would be a route worth considering. Upload a non-human-readable version of the data which is easy to parse, while separately outputting a local text file for the player's own records.


Additional Post-Mortem Features
Like many other roguelikes, at the end of a run Cogmind shows a summary window. It contains a complete score breakdown (there aren't all that many score components) as well as select stats, serving as an abbreviated version of the score sheet.

Cogmind gameover screen.

Because a full message log is too verbose to include in the score sheet itself and there is no short version yet, that is not included. Instead, in the options menu the player can choose to not save it (the default) or output it to either a text or html file. The latter has the advantage of being able to use the same colors as the in-game log, making it easier to parse.

Sample message log output, the same segment in txt (left) and html (right).

I thought this would be enough, but players have since requested even greater detail in the output logs to better follow progress of the game when re-reading it for learning purposes.


The Possibilities!
Outside the existing score sheet and log files, there is the potential for quite a few other related features that serve similar purposes, or present the same information in a different form. Keep in mind that none of what I mention below is 100% certain to happen, but with unlimited time (haha) I'd love to be able to at least test, if not implement, many of these features:


Dumps
Mid-game character dumps are useful for sharing progress and getting feedback online, so it would be nice to have a dedicated way to do that.

Image sharing is so common on the web now I'm not sure how many players would bother to use a text-based dump option if available. The latter is less readable due to lack of color information, and any time someone pastes/views it without a monospace font it would look terrible, but I put together a mockup anyway:

Progress dump mockup (text version).

The current stand-in method for character dumps--a simple screenshot of the HUD--already works pretty well (and is what players have been using) since it shows nearly everything you'd want to know. Its primary drawback is an inability to show more than 12 inventory items at once, an issue for some combat builds. Screenshots are also exceptionally wide for those players using high resolutions since it uses their font settings, making them harder to view on smaller screens.

By rearranging some of the existing windows I put together a mockup of a somewhat more condensed "image-style progress dump," though this one doesn't look so great, and is too wide.

Progress dump mockup (image version, style 1).

Instead here's an alternative mockup of a truly condensed version without any secondary information--it's nice and tight, and includes space for a lot more inventory items, but no map:

Progress dump mockup (image version, style 2).

Even cooler would be a way to output your current build--or peak state from a run--using the game's ASCII art to represent the items. Unfortunately at the high end you can have so many parts that the combined art wouldn't fit within any reasonably sized image.


Score Sheet 1.0
By the time the score sheet is complete, it should include not only more stats, but also expand to contain a written summary of a run's history, told like a story, as well as a world map showing the route taken through the world.

World route mockup (text).

Along with the score sheet, there might also be an option to output an accompanying image of the entire last floor explored (not just the part viewable on the screen). This wouldn't uncover unexplored areas (which would too easily reveal secrets), but players could at least learn something about map layouts without having to try to map it themselves (we'll leave that practice in the 80s, or to games with smaller maps). The problem there being that maps can get quite huge, not to mention the data loss to corruption by this point:

Explored map image (sample). (Click for full size.)

It would be a nice addition if the map also highlighted the specific path taken through the map.


Long-Term Performance
For those players who can't or don't want to upload score data, we could add a local history of personal high scores. Taking that a step further, we know that roguelike players appreciate more data, so why not track even more performance indicators over time.

Currently the results of each run are stored and viewed in complete isolation, except that each record shows the total number of runs that came before it, and a meta data file stores which items have been discovers and allows their art and usage counts to be viewed in the gallery.

Some examples of performance graphs/charts that could be interesting (mockups).

I can see this being a huge development time sink for too little value if not limited to only a handful of the most useful data.

Another much simpler yet more granular approach to progress, is to have a place where players can review what discoveries they've made in the game so far. We already have this in the form of an "art gallery" that shows all the items collected throughout previous games, including their name, ASCII art, and how many times each was found and used (plus of course a name chosen by the item's associated early supporter as a perk).

Cogmind's in-game art gallery, with data and discovered/used items from my own runs (click for full size). DON'T OPEN THIS AND LOOK AT THE PLAYER NAMES if you are an alpha supporter and would like to discover your item for yourself!

This feature is a great incentive to keep players exploring, while showing just how much more there is to discover (a lot!). Recording the number of times each item has been used also gives this feature some statistical value for even those players who've discovered most of the items (discovering all of them is impossible at this point, since many of the best ones can't yet be found).

It would be nice to expand this to include other parts of the game, such as types of maps and robots (however, I don't believe I'd be drawing the latter).


Online Database
As mentioned before, it would be nice to have an online database with sortable tables and customizable graphs based on the data. Before we get to that point, I may further expand the current leaderboards by increasing the number of generated html pages to at least include some sortable charts that also link directly to individual records. I'm not rushing into that since I would want to make sure it's somewhat future proof when it comes to new versions.

For the tournament I already wrote a data parser which scrapes a directory for all of its score sheets and compiles everything into a single CSV file. That formed the basis for the stats and analysis I shared earlier.

Complete CSV data from the tournament, 234,048 fields in all :D.

[JobLeonard]

Image sharing is so common on the web now I'm not sure how many players would bother to use a text-based dump option if available. The latter is less readable due to lack of color information, and any time someone pastes/views it without a monospace font it would look terrible, but I put together a mockup anyway:

Well the benefit is that it's easier to do data analysis on text than on images. At least the kind of data analysis people would do on this.

Maybe export as Markdown or even Markdeep?
http://casual-effects.com/markdeep/

[Kyzrati]

Well, you have to consider the purpose--a progress dump isn't for data analysis. Players share them as a one-off thing to either gloat, show something interesting or funny, or ask for help. So it's about sharing the basic information in the most understandable and quickly digestible format.

For data analysis, as seen during the tournament, I already have a program that mass-reads score sheets and compiles the data into one or more CSV files, which is a great format for reading into anything like spreadsheet software, or other unique solutions. I do, however, hope to eventually make an alternative intermediate format just a little more flexible than CSV, when I get around to it... so it'll be a special format that can be either converted into a score sheet or merged with a CSV file. That way this "special format" could then theoretically be converted into any number of other formats more easily than the existing score sheets, which aren't quite so parse friendly.

[Kyzrati]

Alpha 4 lands next week. The original plan was for a content-heavy release this time, but development ended up taking an interesting detour through mechanics land, so instead we have a half-and-half content/mechanics release. The latter refers to new mechanics, not tweaked old mechanics (though there's some of that, too). Some of the new content suggested a number of mechanics that would add interesting strategic options, the best course of action being to add these immediately rather than overextending the content. After the release I'll be publishing a series of dev blog articles about the design behind these new features. I think you'll like some of the new strategic options

Below is a collection of some of the more showable features:

The Garrison Access, a brand new type of machine:


Packrat support in the form of page-wise scrolling for the inventory UI (Ctrl-[/], or Ctrl-Wheel for mouse users):


Machines have their own info window--examine them as you would any other object:


A fifth visualization mode for the parts/inventory list, Relative Heat:

Activated by pressing 'e' again (the energy view command) or clicking on the respective button. Orange for generation, yellow for dissipation, gray for inactive. This makes it easier to quickly determine what's causing your heat problems, or what's doing the best job of solving them

"Unauthorized hacks," divided into two classes: brute forcing, and Trojans. The latter allow you to install delayed or persistent effects like creating a bot net by linking multiple Terminals.


Or infect explosive machines to turn them into massive proximity bombs


There is also a brand new type of map, quite unlike the rest of the world, which while it is very showable, I don't want to spoil it for you. (All the juicy details will be coming later in a spoiler-filled blog post, but I'll let you check it out on your own first.)

[JobLeonard]

Botnets... what are you going to do with those?

[Kyzrati]

What else do you do with botnets? Use them to attack other systems without getting caught yourself

[Kyzrati]

I'm on a roll this week, burning through anything easy on the near-term TODO list, including some requests both old and new. So here are yet more upcoming features I've recorded to give you a preview

Part rejection is now animated:

(plus there's a sound effect and the movement block has been extended from 500ms to 1 second, so you're much less likely to walk away from a suddenly rejected part)

When manually Schematic()/Analysis() hacking, enter just the robot class name to automatically hack the best variant available:

No more need to remember specific designations (unless you're intentionally trying for an older model because they're easier to hack).

You can now "go naked" as a free action with a single command that simultaneously "releases" all your attached parts (requires confirmation):

Perfect for that quick getaway.

A command for keyboard players to cycle between different forms of propulsion, and activate/deactivate all of them at once:

(I'm holding down the button at the end there for fun )

Also a command to toggle all weapons on/off:

[Kyzrati]

Alpha 4 is now the latest and greatest Cogmind! We have an entirely new type of map accessible from many locations in the world, and, unexpectedly, a lot of new mechanics!

A portion of the new mechanics and content are actually secrets, some of which cannot yet be easily discovered (but will be easier in the future via relevant lore/story/NPC interaction). I will be publishing a series of dev blog posts throughout November detailing (read: completely spoiling) these mechanics and content, which you can read if you don't mind spoilers. There are also hints to some of them in images I've shown around lately. And I may occasionally drop some answers here on the forums, our subreddit, or Twitter if the opportunity strikes :D

Regardless, even if you don't immediately discover a lot of what's new (except of course all the nice usability features explicitly listed in the changelog =p), to an extent the world will likely "feel different" now. In terms of gameplay, overall you'll find the enemy is a good bit more responsive to your actions since they can often reinforce/investigate from closer by, especially once you reach the Factory. This doesn't necessarily imply a greater absolute difficulty, just slightly more transparent strategic and tactical decisions. I playtested several times yesterday and had a blast, especially when it came to factoring in some of the new mechanics (EM spectrums are quite interesting...).

On the usability/user data side, note that your existing manual hacking buffer will be converted to a new format, and external text file. You'll see this file appear after your first game, containing any manual hacking commands you've used before. Feel free to update it yourself in a text editor as necessary (most recent commands at the bottom).

For a visual summary of a few of the new features, see here.

(As usual, if you haven't already, remember to use the form linked in your original download email to provide the name you want to use in game. Attribution/names are added with each major release.)

The full Alpha 4 (0.10.151103) changelog:

* NEW: Garrison Access points, hackable entryways used by the central AI to dispatch squads
* NEW: "Special Map" (outside regular Complex 0b10, but not a normal branch)
* NEW: 8 Trojans, a new category of unlisted unauthorized hacks that offer delayed or persistent benefits
* NEW: 3 brute force hacks, a new category of unlisted unauthorized hacks that permanently disable a machine for some greater benefit
* NEW: "Index(Garrisons)" terminal hack
* NEW: 4 new terminal records
* NEW: Phase Walls, a new form of hidden door (only found in one map)
* NEW: Lots more sound effects to go with new content
* NEW: Electromagnetic weapons have a "spectrum," capable of coupling with power sources and causing them to explode
* NEW: Part/inventory data visualization now includes heat mode (toggle via energy 'e' command/button)
* NEW: Inspect machines in sight via their own info window (RMB/d, as with other objects)
* NEW: Structural Scanners give extra info about machines via info window
* NEW: Any Signal Interpreter can decipher garrison signals to report time until future response squads from that garrison
* NEW: Score sheet records 52 more stats (total: 390)
* NEW: Speed wins receive bonus to final score ([5000 - #turns] * 3)
* NEW: Some non-machine props have unique messages when partially destroyed, rather than all indicating "X disabled"
* NEW: Unique sound effects for destruction of heavy doors and storage shells
* NEW: Robot states "DORMANT", "UNPOWERED"
* NEW: Sensor scrambling mechanic
* NEW: Dropping/swapping containers always retains surplus resources (energy/matter) however possible
* NEW: Move over loaded containers to extract their resources automatically, either to main stores or applicable containers in inventory
* NEW: Resources can be collected/extracted while stationary over a source
* NEW: Flying robots under the effect of a Stasis Beam/Projector lose their 10% bonus to dodge
* NEW: Overweight flying robots lose their 10% bonus to dodge (your HUD overweight indicator will appear red)
* NEW: At death, robots affected by corruption have a chance for otherwise salvageable sensitive components to be fried ([corruption - base part integrity]% chance)
* NEW: For Cogmind, only parts at less than 50% integrity susceptible to critical strikes (excludes armor, which always takes double damage)
* NEW: Storage Units immune to Saboteur attacks and critical strike instant destruction effect
* NEW: Part rejection due to corruption is animated in your parts list, with sound effect
* NEW: Where removing a Storage Unit will auto-drop excess inventory items, confirmation is required (repeat the command)
* NEW: Instantly release all attached parts to "go naked," a free action (Shift-Alt-q)
* NEW: Keyboard players can direct-drop an attached item, bypassing even an empty inventory, by first pressing ','
* NEW: Cycle through all propulsion modes at the press of a key ( ; )
* NEW: Toggle all weapons on/off with a single key ( ' )
* NEW: Press 'd' to open info for item at current location (even in mouse mode)
* NEW: Both scan window and map labels display container contents, if any
* NEW: Scan window automatically updates integrity indicator color for old robot/item scans
* NEW: Robot Schematic()/Analysis() manual hacks can simply indicate robot class to auto-select best available (e.g. "Schematic(Swarmer)")
* NEW: Manual hacking buffer contents stored in readable format (/user/buffer.txt), which you can ignore or edit as necessary
* NEW: Options menu option descriptions also automatically shown in keyboard mode (on selection)
* NEW: All supporter names registered since Alpha 3 added to in-game list (see Credits menu)
* NEW: All item-attribution names registered since Alpha 3 added to the item collection gallery
* MOD: Security levels rise faster, but assault force dispatch frequency reduced
* MOD: Investigation and reinforcement squad response times significantly reduced
* MOD: Ambush traps cap melee robot count, attempt to put them further from the trigger position where possible
* MOD: Propulsion energy cost visualization in parts/inventory list shown based on cost per full turn, based on speed
* MOD: Machines 50% less resistant to electromagnetic explosions
* MOD: Blast/heavy doors +35% resistance to explosives
* MOD: Rooms (not Storage Shells) in Storage now contain sets of parts akin to stockpiles, rather than numerous disparate parts
* MOD: Engineers rebuilding walls/doors push blocking items out of the way rather than destroying them
* MOD: Improved clarity of context help for robot damage resistances in info window
* MOD: Reversed green/red coloring of damage resistance bars for robots
* MOD: Behemoths equipped with Dynamic Insulation Systems
* MOD: Tweaked damage against Programmers: TH = 125% (+25), EX = 75% (-25), EM = 25% (-25), (KI unchanged at 125%)
* MOD: Robots killed via corruption (EM) or meltdowns now count towards score, and increase presence accordingly
* MOD: Terminal damage from EM +50%
* MOD: Terminal hacks inapplicable due to no valid targets now shown, but grayed out (includes Emergency Access, Purges, all Trap hacks)
* MOD: "Index(Fabricators)" terminal hack 10% easier
* MOD: Fabricators no longer produce faulty prototypes
* MOD: Part rejection due to corruption blocks movement for 1000ms rather than 500ms
* MOD: System corruption effect on machine/robot hacking chance reduced by 66%
* MOD: Misfires due to corruption don't affect your weapons' active/inactive state (but does reset any OVERLOAD settings)
* MOD: Storage Unit removal behavior consistent in all situations--detachment allowed regardless of kb/mouse mode and inventory size
* MOD: Info window identifies permanently broken robots as "BROKEN" rather than the all-encompassing "DISABLED"
* MOD: Improved robot meltdown mechanics, and hostiles will no longer meltdown on their own
* MOD: Ctrl-[/] (or Ctrl-Wheel) scrolls inventory by page, rather than to beginning/end
* MOD: Removed Undo Drop command (Shift-Alt-d)
* FIX: Parts affected by hacking feedback and failed repairs/Scanalyzer analysis were only partially disabled [zxc, Draco18s]
* FIX: "Inventory(Prototypes)" manual hack was being parsed as "Prototypes" [fernsauce]
* FIX: Could get double item labels if opening manual labels before auto-label took effect [Adraius, bluemoo]
* FIX: Main access points could rarely appear in narrow corridors, even hidden corridors [zxc]
* FIX: Score sheet "Keyboard" value was inverted [zxc]
* FIX: Allied Operator hacking bonus was giving +0 rather than +1 per Operator after the fourth
* FIX: Dynamic Insulation System calculations were providing 20~33% greater benefit than intended
* FIX: Typo in successful Scanalyze hack output when simultaneously identifying a prototype
* FIX: Many hack results weren't reporting nouns in singular form if only one found
* FIX: "Access(Main)" terminal hack was reporting current map name as destination
* FIX: Item comparison window one line short when displaying Datajack vs. Remote Datajack
* FIX: Derelict ambush trap encounter dialogue never triggered
* FIX: Inactive Watchers were still able to jam sensors
* FIX: Non-penetrating AOE projectiles that impacted a multi-cell door were using the door itself as the explosion origin (now outside)
* FIX: Door open/close sound effects played in more instances than they should while robots passed through
* FIX: Explosions out of sight but within audible range were playing their sound effects twice, simultaneously
* FIX: Standing within range of two or more unique ambient sound sources while one is disabled could stop playing the wrong one
* FIX: Closing the help/commands/game menu while in range of an ambient sound source didn't resume playing the sounds