[h1]Introduction[/h1] As many have noticed, it has been many months since the last pre-alpha release, and nearly a year since the last [i]stable[/i] release. To begin, I will attempt address some common questions about this release, and the status of Mindustry in general. [h3]Why is this update taking so long?[/h3] Up until this point, all (pre-classic) Mindustry updates have been incremental additions or changes to existing content. Everything I've made has been designed to fit in with existing blocks on the Serpulo planet campaign. In v7, this is no longer the case - I am adding an [i]completely new planet[/i] - Erekir - with its own unique set of blocks, environment tiles, units, turrets, transportation, etc. Aside from certain items, [i]everything[/i] is different - there is no re-used content from Serpulo, not even walls or conveyors. This is a little bit like making the entire game over again. When it is complete, it will be the biggest single content update in Mindustry history. To give you an idea of the content volume, there are currently 70+ new build-able blocks that have been added when compared to the last pre-alpha, with more than 130 new blocks added total - and I'm still far from done. In addition, I am making significant changes to many various mechanics (again) - the campaign, unit control, and logic, for instance. Keep reading for more information on these topics. With all of these factors combined, this update will take much longer than normal to complete. Please be patient. [h3]When will v7 be released?[/h3] I really don't know. While I already have a fair bit of content complete, I would estimate that it's only [i]half done[/i], if even that. Many mechanics are still in the "prototype"/"brainstorming" phase. All I can say is, [i]don't expect it anytime soon.[/i] [h3]When is the next pre-alpha/alpha/beta release?[/h3] As mentioned above, I'm still early in the process of implementing content/mechanics for Erekir - it is not ready for testing, and will likely not be for a while to come. I would like to have the entire campaign complete before I even release an alpha build. In short: Again, [i]I don't know.[/i] [h1]Erekir Content Preview[/h1] Below are some sneak peeks at content I've been working on. This is by no means a comprehensive list. Keep in mind that these units can (and have) changed significantly over the course of development - the final version [b]may be radically different, or removed entirely![/b] [i]Note: Many of these GIFs are taken from the #dev-previews channel on the Mindustry Discord. Consider following that channel for more frequent updates.[/i] [h2]Units[/h2] [img]https://i.imgur.com/1runP3l.gif[/img] [i]The T1 core, and its corresponding core unit. This unit can repair blocks, but does not have any offensive capability.[/i] [img]https://i.imgur.com/hdSnctu.gif[/img] [i]Shielded walker unit. Only blocks projectiles from the front. Very much WIP - weapons and legs will likely undergo significant changes prior to release.[/i] [img]https://i.imgur.com/EyPLjW4.gif[/img] [i]Small insect-like unit. No special abilities. Demonstrates a new unit animation system.[/i] [img]https://i.imgur.com/Lba4Jw9.gif[/img] [i]Hovercraft. Missiles are technically units that can be targeted, and will follow the player's cursor.[/i] [img]https://i.imgur.com/gHDKPLC.gif[/img] [i]Yes, I'm finally introducing tanks. This further demonstrates the capabilities of the new unit animation system.[/i] [img]https://i.imgur.com/fGdRPhf.gif[/img] [i]A smaller tank variant.[/i] [h2]Blocks[/h2] As mentioned earlier, Erekir will have a completely different set of blocks from Serpulo. The production/crafting tree is still a work-in-progress, so I will not be showing it here, but here's what some of the distribution systems look like at the moment: [img]https://i.imgur.com/ZRhtx1K.gif[/img] [i]Ducts transporting items to Duct Routers. These routers only accept from one direction, and can double as sorters when an item is selected.[/i] [img]https://i.imgur.com/2bn9tFm.gif[/img] [i]Duct overflow gates. Only accept from one direction.[/i] [img]https://i.imgur.com/c4BCjyH.gif[/img] [i]Duct bridges. No linking or weaving allowed; output only in one direction.[/i] [img]https://i.imgur.com/emyPWhc.gif[/img] [i]Duct unloaders. Only input and output in one direction.[/i] [img]https://i.imgur.com/Z317hIn.gif[/img] [i]Beam "drills", connected with new orthogonal power nodes. Note that, while there are still certain ores on the ground in Erekir, beams are the primary way of gathering resources.[/i] [h1]Unit Control[/h1] As many of you may know, unit control in Mindustry is terrible. As of the latest available version, there are four ways of controlling units, all of them with significant flaws: [olist] [*] [b]Manual control:[/b] This is the obvious and most common way of controlling units; while effective, it only allows for controlling exactly one unit. Furthermore, once the unit ceases to be controlled, it resumes its normal AI, making this method useless for moving groups of units anywhere. [*] [b]Formations:[/b] An unfinished, unwieldy and broken system. Not only do units constantly get stuck on terrain when in formation, but they can frequently bump into the main unit. Formations are also lost on commander death, subject to numerous unit type limitations, and feel extremely laggy even on low-ping servers. [*] [b]Command Centers:[/b] Unwieldy, complicated, lacking precision. While they are effective to some degree in performing basic tasks like grouping together units, they are very imprecise (global control), tedious to manage (require building a block), and painfully limited (are unable to order units to attack specific targets). [*] [b]Logic:[/b] A cursed creation. While technically the most powerful unit control method, it is orders of magnitude more complex than anything else in the game. Commanding units with logic either requires copy-pasting schematics you don't understand, or spending hours learning a bespoke programming language with very sparse documentation. Neither of these are acceptable. Even beyond the complexity, logic unit control is incredibly clunky, un-intuitive, and subject to limitations (like lack of proper pathfinding). Players should not need to know how to program to play this game properly. [/olist] Something had to be done. Thus, I have made the following changes: [list] [*] Formations have been removed completely. [*] Command centers have been removed. [*] No logic blocks are available on Erekir. [i]EDIT:[/i] Based on feedback, I [i]will[/i] definitely be keeping it on Serpulo. [*] A new RTS-like unit control system has been introduced. [/list] I've been hinting at adding them for a while, but after experimenting with the mechanics, I am confident that RTS controls are the best way forward. Here's how this looks in-game, so far: [img]{STEAM_CLAN_IMAGE}/35810448/bd03297dbc65679175859ca4d6a58dcfa31672ad.gif[/img] Now, I know that this raises numerous questions, such as: [list] [*] How will this affect PvP? [*] Will units have sub-commands ("fire at will", "patrol"), like some other RTS games do? [*] Will builder/repair/miner units be controllable as well, and if so, how? [*] How will build assistance work without formations? [*] Does this mean that fog of war will be introduced as well? [*] How does the player switch between building with their unit, and commanding? [/list] I will [i]not[/i] be answering these questions, as I don't have a good answer to most of them - and even if I did, my answers could change over the course of development. All I will say is that, at the moment, I am trying to keep things as simple as possible. In my testing, even the current bare-bones RTS control system is worlds better than anything the game had previously. [h1]Logic "World Processors" / "Map Scripting"[/h1] This is a relatively minor feature I've been developing for use in campaign maps. Essentially, they are processors for [i]scripting maps.[/i] These can only be placed or interacted with in the editor, and are for [b]map-makers only.[/b] World processors can currently do the following things; I may add more functionality as necessary: [list] [*] Spawn units. [*] Set blocks. [*] Get blocks/buildings at any location. [*] Create explosions. [*] Show the player notifications or mission objectives. [*] Pan and zoom the camera, for cutscenes. [*] Sense any block info without linking to it. [*] Set a limited amount of game rules, such as lighting, build speed and waves. [/list] World processors are meant to be placed in a corner of the map; while they are blocks with teams, they cannot be accessed, shot, broken or hovered outside of the editor. Note that they are simply [b]logic processors with special instructions[/b] - this is not a new language or scripting system. Below is a simple demonstration of a "cutscene" implemented with a world processor. Note that the trigger is a button for simplicity, but in most cases, you would have the trigger be something else out of the player's direct control. [img]{STEAM_CLAN_IMAGE}/35810448/171f6047a301bf44b79d9ca105d5ca995a78c615.gif[/img] Some examples of what can be done with world processors: [list] [*] Display a special objective for the player, e.g. "destroy building X", sense when the block is destroyed, and perform actions based on that event. [*] Spawn custom waves in any location based on time, or any other variables. [*] Activate enemy base functionality only when the player has achieved a certain objective, like surviving X amount of waves. [*] Day-night cycles in custom maps. [*] "Defense" objectives wherein the player core is destroyed if they fail to prevent a different block from being destroyed. [/list] [h1]Internal/Modding API Changes[/h1] In addition to all of the above, I've also been working on improving the modding API, fixing inconsistencies, and adding more features for modders to utilize. Unfortunately, this also comes with the downside of breaking the overwhelming majority of older mods - after discussing this with the community, I've come to the conclusion that this is the only way forward. Here are some examples of changes I've made so far - everything is still subject to change. If you're not a modder, feel free to skip this section. [h3]Weapon/Unit/Turret Animation System[/h3] Turrets, units, and weapons now support animation [i]parts[/i]. These can rotate or move individually depending on their [i]progress[/i] value, which is usually the weapon warmup or reload. [i]Close-up of the tank shooting animation:[/i] [img]{STEAM_CLAN_IMAGE}/35810448/29242d2997c188bfce48a1598eea35091eaea4fd.gif[/img] [i]Code (minus the blades, which are defined in a loop)[/i]: [img]{STEAM_CLAN_IMAGE}/35810448/6e063256335ce606ddfe7093d6359f3d9ca4a465.png[/img] [h3]Weapons, Turrets and Units[/h3] Weapons and turrets have long suffered from an inconsistent feature set and API. I've attempted to improve the situation by implementing a unified system for bullet patterns and shooting behavior. This means: [list] [*] Turrets and units can now have an arbitrary amount of bullet barrels. [*] Units now support duo-like double-shot patterns. [*] Swarmer and Cyclone turrets now correctly have 3 true barrels instead of randomly spewing bullets everywhere. [*] Java/JS mods can easily define complex bullet patterns for their turrets without creating subclasses of [i]Turret[/i] or [i]Weapon[/i]. [/list] As an example, here's what the new Swarmer bullet pattern looks like: [i]'shoot' is a field of each Weapon and Turret that defines its bullet pattern. This defines a 3-barrel shot pattern.[/i] [img]{STEAM_CLAN_IMAGE}/35810448/823c922139a521561eba59cdddb871d5322cd15e.png[/img] [i]Result:[/i] [img]{STEAM_CLAN_IMAGE}/35810448/79c623d1feda23e729d8e13e3e64aa4cdcff6a60.gif[/img] It is also possible to chain together shot patterns, to make things like this ([i]demonstration only![/i]): [img]{STEAM_CLAN_IMAGE}/35810448/85c689208794557232ba7784364de59fc2e98470.gif[/img] Bullets can be created with custom movement callbacks. This pattern, for example, creates two bullets that move in a helix: [img]{STEAM_CLAN_IMAGE}/35810448/6a62c9b2be82860b19a528052a7bad2868c4c5a0.gif[/img] [h3]Consumption & Generators[/h3] The block consumption system has been rewritten to allow for: [list] [*] Multi-liquid consumption [*] Multiple consumers of the same type, e.g. two ConsumeItems [*] Filter/efficiency consumption that does not depend on specific block type [/list] Most old generator classes - SingleTypeGenerator, BurnerGenerator, ItemLiquidGenerator and DecayGenerator - have been replaced with a single class, ConsumeGenerator. As an example, here's what the new definition for the combustion generator looks like: [img]{STEAM_CLAN_IMAGE}/35810448/9e4d8411973db2fb2a4d6d186a5e636c89187733.png[/img] [h3]Drawing[/h3] The [i]DrawBlock[/i] system has been expanded to support more block types, including generators, pumps and turrets. This means that it is no longer necessary to extend these classes for custom drawing behavior. All drawing-specific GenericCrafter subclasses (Smelter, Cultivator, ...) have been removed. In addition, all DrawBlock subclasses have been made modular. For example, this is how a smelter draw implementation can be defined on a GenericCrafter (or generator): [img]{STEAM_CLAN_IMAGE}/35810448/4d89b264125bd795ef1fde7c06a53b27bb0ba72b.png[/img]