GENERAL CHANGES New music, better performance, bug fixes, security tweaks, and changes to the economy to make PvP more exciting! - New music! Four new tracks from Ryan Ike. - New post-processing effects. Less CPU/GPU intensive, and better looking. - New text rendering engine. Better performance, and no limit on colors! - New text scaling: - Text scales with the width of the window to maintain relative text size as window size increases. - gui.size can be used to control relative text size. - The chat window now has a text entry field. - Provides modal control of where chat inputs get sent. Specify a user with +<username> or a channel with %<channelname>. - By default, chats are sent to 0000. - Set chatscript with &<chatscript> - New shell commands have been added to manipulate the ui: - gui_binmat opens two new fields which are used for Binary Matrix. - gui_reset resets the ui to default values. - context.is_brain notifies scripts that the code is being run by a bot_brain - Count no longer required as a parameter for single-count market items. - Player settings are now saved locally as well as on the server. This includes gui.vol, gui.vfx, etc. - Cross-platform copy-paste improvements. Now works on Linux! - Fixed issues with inviting multiple users to a corp. - Added microtransaction support for new Steam currencies (Ukrainian Hryvnia, Argentine Peso, Costa Rican Colón, Israeli New Shekel, Kuwaiti Dinar, Kazakhstani Tenge, Polish Złoty, Qatari Riyal, Uruguayan Peso.) - Esc key now cancels running /auto commands NEW FEATURE: BINARY MATRIX DEFENSE SYSTEM A brand new PvP system: Binary Matrix is a high-speed strategic hacking game designed to test your decision making, communication and bot creation skills. Players may have already encountered Binary Matrix when it was teased last Christmas, or subsequently played its player-created web version. In-game, BINMAT takes the form of a text-based strategy game where attackers and defenders compete to play stacks of resources to a series of lanes. The attacker's goal is to breach the defender's stacks in a single lane, while the defender must hold out for a set number of turns. A Binary Matrix session can involve up to 32 players - 16 per side - each interacting with the same set of resources within alternating 5-second windows. This isn't just a test of your decision making, memory, or strategic skill - it's a test of communication, bot programming, and social engineering too. Upgrade your system with the BINMAT Security Shell by participating in a match against a player who already has it. Talk to other players to find out more! - BINARY MATRIX Security Shell online - A BINMAT session will be launched after a user's lockstack has been unlocked if Binary Matrix is enabled on the system. - Both attacker and defender automatically attempt to join the session, requiring the payment of an ante to Trust. - If the attacker cannot join, binmat continues as normal until system lock rotation. Other users may join in their place. - If the defender cannot join, the system is breached as normal. - BINMAT sessions last until the attacker team wins or the hosting system's locks rotate. - BINMAT antes and winnings. - Users pay an ante based on the tier of the defending system. - t1 8MGC - t2 512MGC - t3 8BGC - t4 32BGC - Successful combat encounters during BINMAT sessions result in GC being drawn from the ante pool and distributed to players who contributed to the success. - Players who consistently help their side can earn back their ante and ultimately turn a profit. - BINMAT 'bot brains' - Players can register 'brains' to run on both attack and defense. - BINMAT brains are run as soon as the opponent's turn has resolved into a new gamestate. - 'autobrains' can be set up for system defense. These are automatically loaded whenever a defender joins a BINMAT session. - BINMAT multiplayer - Users can join either side of a BINMAT process during the session, for a total of 16v16 at any one time (including the original attacker and defender.) - Users can join a match in progress. - Users that fail to make valid moves within a certain number of turns are disconnected and cannot rejoin. - Users that are breached or disconnect their hardline are disconnected from the session and cannot rejoin. - BINMAT edge cases - Users can't sys.init or run sys.* PVP scripts while connected to a BINMAT process. - Users that have joined a BINMAT session cannot join another BINMAT session or defend their own systems using BINMAT until the match ends. - A BINMAT session requires a minimum amount of time before system locks rotate. If that time is not present, then the BINMAT process is placed in stasis until rotation has occurred. - BINMAT connections can only be established to lower or same-tier systems. PROSPECTIVE BALANCE CHANGES In addition to the above, we're looking into some far-reaching balance changes designed to encourage and reward PVP while also protecting the low-tier NPC hacking experience for new players. - Maximum lock count. No more than 8 locks can be loaded on a system at a time. - If a sys currently has more than 8 locks loaded, the first 8 will be used in the lockstack - Added expire_secs spec to l0ckjaw. Successfully feeding a l0ckjaw deactivates it for a period of time. - bot_brains can script kernel.hardline. Use {activate:true} to activate. By making locks matter less, we're hoping to promote BINMAT as a more exciting way of defending your system. This also guards against edge cases in lock configurations. - Minimum breach time. System locks for breached users don't rotate until 120s after time of breach at the earliest. This is intended to make attacks more rewarding while raising the stakes for defenders. - xfer limit of 32BGC. Applies to xfer_gc_to and xf_gc_to_caller. xfer rate limiting applies: - New global xfer_to rate of 200 transfers per minute from a user to any other user. - No price cap on escrow or market, but payouts are capped to 512BGC every 60s. - Escrow and market both list the seller in the transaction. - Escrow carries a usage fee of 2.5%. Slowing down the transfer of GC between users encourages PVP by making high-value systems more vulnerable, and gives users with deep pockets more interesting decisions to make. -Rate limiting of kernel.hardline: - The number of kernel.hardlines a user accrues in a given 12-hour period is gated by your system tier. Hardline count is capped at the same value: - Tier 0: 256 - Tier 1: 32 - Tier 2: 24 - Tier 3: 18 - Tier 4: 12 - Hardline caused by a BINMAT defense do not subtract from your hardline count. - Only one system can be connected to per hardline connection, but each successful breach grants an extra connection attempt up to a maximum of three bonus connections. - A Tier 4 user who is successful in all of their breach attempts, therefore, can potentially breach 48 systems using their 12 available hardlines in a 12-hour period. - One connection log is left per system, per hardline - making log spam more costly. - Hardline count and accrual is listed in sys.specs This is a set of changes intended - alongside the xfer changes - to make both system tiers and hardline matter more. In particular, we want to make it more rewarding for high-tier users to engage with content at their own tier, rather than farming T1 corps with no drawbacks. We're working with the community to refine these changes and make sure that they're achieving what they're intended to achieve. As a result, some adjustments will continue to be made as players settle into version 2.0.0. We'll update this document as and when changes occur!