Nyrin

For sure don't want too much performance-sensitive stuff in the lua layer -- what I mean by all this is for what is in the lua layer to be more modding-friendly. Concrete example I'm hitting right now: I want to experiment with making Trade available to non-merchants. That's all in the lua layer: tradecommand.lua. Should be easy, right? It's just a couple of "if not captain:hasClass(CaptainClass.Merchant) then return end" checks. But oh. Oh. That call's an early abort right at the beginning of the 200-line onAreaAnalysisFinished, and it's done with a ShipDatabaseEntry computed from the metadata used for everything else. Hmm, there are normally some tricks... Tricky approach 1: temporarily replace the "has" function to always return true, or at least for Merchant -- but unfortunately, that's not at the lua layer and not writable. So no can do with replacing it. Tricky approach 2: make a fake captain, swap things out, run the needed steps, then swap back. ...Except, despite appearing like it should work, :setCaptain on ShipDataBaseEntry:getCrew() doesn't appear to do anything. Entity():setCaptain works, but captain commands are all about not having the entities available. That leaves blunt instrument #3: copy and paste the entire function just so I can comment out the two lines that check the class. And now it's all but guaranteed to be broken within a few patches, and all but guaranteed to conflict with any other mods wanting to touch the command. The pattern then repeats for two more 100+ line functions in the file, with the same comment of two lines. "Modding" TradeCommand to remove merchant restriction boils down to replacing 2/3 of the file in its entirety despite the change really being six lines of code. (I'm exaggerating a little bit, but not that much) That's what I mean about the opportunity with lua moddability -- just making structure more bite-sized for palatable change sizes.

Now, I know that making it work is the first priority--but given how awesome the modding potential is, the better we can make it... well, the better. None of this is intended as a whine; you've invested a lot into making Avorion nicely moddable (thank you!) and as a player and a modder I'd just like to see that investment maximized. The problem A lot of state and behavior is embedded inside of functions in ways that can't be easily augmented or changed via mods--replacing entire, often very large functions is necessary if you want to change the thing in the middle, and that's enormously fragile and problematic for maintenance and compatibility. Three examples I've hit recently that are only representative: 1. mapcommands.lua -- I want to add logic to secure/restore the button state for "show these ships," and *that* part of it is easy enough to do since the shipList variable is file-global. But for updating the button overlays in the UI, there's no way--the buttons are created as temporary, local variables in the 320-line initUI function and, since the callback functions take the button table as a parameter, there's no way to modify these without replacing the entirety of that function -- which would be a very bad idea! 2. tradecommand.lua (this is common across commands) -- similar pattern, except this time I want to add UI. The almost 400-line buildUI function does almost everything UI-related as temporary variables, meaning there's again no way of changing or modifying existing state without replacing the entire function and signing up for all but guaranteed future compatibility headaches. I was able to add UI by retracting the steps of the top-level rects and then drawing where it "should be," but although this is less likely to break it's just as likely to end up drawing over the top of something it shouldn't in the future. 3. Also tradecommand.lua, just wanted to give a non-UI example: the generateAssessmentFromPrediction function adds lines in that are pulled from function-local variables rather than a global table or atomic helper functions, meaning that replacement or augmentation of a category requires either replacing the whole function (fragile, loses out on interoperability and future changes) or blind manipulation of table entries (potential very weird compatibility breaks, though less likely to all-out break). Fixes First and foremost, and I mentioned this on another feedback: please consider open-sourcing the public part of the .lua files! By that, I mean put it on GitHub or somewhere that can accept public pull requests that you can take a look at and summarily approve or reject. We already have the files thanks to the modding strategy, so this just lets you get potential free fixes and work from the community. Beyond that, though, I know nobody's going to go redo everything (I hope not, anyway), but just principles to keep in mind for mod-friendliness: - Whenever possible, keep UI elements in distinct, global(/file scope) variables and/or have atomic helper functions that build each piece of a bigger part. Every something important goes off to die in a local variable, our ability to interact with it is diminished. - Likewise for constants, string tables, etc., disprefer putting them as local variables in big functions -- I had to completely replace ScoutCommand:revealSectors to add new lines, whereas ideally you'd just be adding to to a table! Even if it's normally a weird practice, keeping more at a higher scope than immediately necessarily keeps a lot more options open. - In general, try to keep functions smaller. That's a good practice in general, but if TradeCommand had a "buildHeader," "buildSliderRect," "buildAssessmentBlock," etc. instead of everything being flat inside of buildUI, it's be possible for mods to change things with much less collateral damage. You read this? Well, thanks! I really do appreciate the work that's gone in.

Yes, this really needs another pass. Especially with the introduction of 2.0 captain commands and their very trusting use of sheet dps, these kinds of disparities make for weird dynamics with weapons you keep "just for simulation," weapons you actually use, and weapons that look good and you just throw away. And good luck to anyone who isn't completely nerding out on the specifics and just equipping the thing at the top of dps/slot sort. Another piece to add to this: it looks like energy recharge on a weapon does *not* factor into listed DPS, while heat cooldown *does.* Given how a lot of energy-based weapons end up with long recharge cycles, this makes for a horrible disparity between listed and observed DPS. Worst example of this is burst-fire plasma guns, which will often do less than 25% of their listed damage over fire cycles.

I wonder: in the event that it's not feasible to reinstate official support to vanilla, is there anything that could be done to make the mod-supported approach feel more reliable? What makes that approach feel too risky? I'm all for restoring the original commands to the base game if it's not inordinately expensive (taking too much away from other things, like improving economy balance and richness at the moment) and as long as it's added as a freeplay/ini toggle (so server admins can turn it off if it's tanking their servers). And that's from someone quite happy with the 2.0 systems.

For doing more interesting things with the new Captain commands, it'd be great to have more robust information available for background/out-of-sector ships (via ShipDatabaseEntry or otherwise). Specifically, I'd love to be able to get a CraftStatsOverview or equivalent to experiment with adding more "lifelike" variables into ambush and yield calculations.

I'd love to have a little more exposure to galaxy map functionality. Specifically: the ability to interact with the upper-left search box for sector highlighting; getSearchText, setSearchText, focusSearchText (for things like a search hotkey), and onSearchTextChanged would open a lot of cool possibilities equivalent capability to things in the right-click context menu for a sector, e.g. inputting a jump path (without turning autopilot on), tagging a sector, changing notes, and all that -- *tons* of really cool things mods could do with this Having all the new hotness with 2.0 captains in the .lua layer has been very nice, but it's also made me yearn for having even more I can do in this more-used-than-ever mode of the game. Thanks!

It would've been cool if they were incorporated into the post-XWG convoy. "Returning to the homes of our ancestors" or something. Maybe something for the sequel, where we discover the Adventurer was the true villain all along.

I love how much of the game magic is effectively open sourced as published in our /data folders, and it's made modding a lot of fun to get into. And I wish the people I work with were always as good about commenting things 🙂 As I'm working through things, though, I'm finding a lot of stuff I'd love to submit as candidates for base game improvements and not mods--little bug fixes, refactors of common script, moving some locals out to globals for moddability options, and so on. And, at least when that "free work" isn't unreasonable or outright bad, I imagine you'd love community submissions, too. To that end: have you considered putting the published .lua contents on a GitHub project and using that as the proxy into the release process? I don't know your build system, but things like e.g. CMake's FetchContent make automated merge back into your closed-source project a breeze--you'd essentially just update the release tag from the main lua branch whenever you want to with the CMake example. That'll help modders with official diffs and version history, but it'll also make it possible for people to submit pull requests that you ignore or remove/merge at your leisure, as well as track .lua-specific issues and discussion separately in a way that's alongside the script itself. You wouldn't give up any control for this as sole maintainers and you wouldn't be making public anything that isn't public already via the releases. If you put a wish list or .lua roadmap on there, I bet you'd find some eager volunteers willing to do some of it, too 😄 Just a thought, anyway! Thanks for the awesome modding system and it's a blast to work with.

Yeah, if we actually "built" the fighters and didn't just allocate stat points to them to tweak what the input turret spits out, it'd make a lot of sense to have capabilities (like fighter loot transport) depend on what was put into the fighters. As it is, though, fighter designs are just decorative skins and I imagine it'd be a *big* game rework to change that. I do like the idea of having fighter pickup behavior scale to transporter distance. Increasing the power of your transporter to increase your raw harvesting efficiency would feel a lot less arbitrary than a binary on/off switch with the yellow ship warning.

I really like the idea of having this pickup as the highest pri bit for salvage and lowest-pri (non-idle) bit for patrol. That seems to make a lot of sense.

Not trying to be a Goldilocks whiner--each of the two options right now just doesn't feel right. I'd like ship death to be something that feels scary and worthy of going out of my way to avoid without a ship getting destroyed tanking my motivation to play. Right now: Without permadestruction, you lose very little when a ship is destroyed. Towing/reconstruction isn't that expensive, you keep all crew, subsystems, and turrets, and full repair if you can wait a bit for mechanics to restore non-lost blocks isn't a big drain on credits/resources, either. If you had valuable cargo on board, that's one thing, but most of the time my reaction to death without permadestruction is "meh, oh well." I lose a few minutes of time while I get things up and running again, but that's it--there's not much incentive for me to try hard to not die. Ship incarnations are totally expendable and spending extra care and attention to keep them alive isn't worth the effort. With permadestruction, it's the other extreme. Every turret, every subsystem, every crew member (including that Captain you've been working on) are all gone and you need to spend every credit and resource to rebuild, from scratch, before you collect new crew, scrounge up new turrets and subsystems, and claw your way back up. It's meant to be "hardcore" and it succeeds in doing so. I'd love something between. Some ideas for such an option: Keep reconstruction/towing, but with more lost blocks and increased guaranteed resource cost relative to the full cost of the ship. Lose some crew ("the ones that didn't make it to the escape pods"), but keep some of it, too, usually or always including the captain. That is: make the effort to recrew necessary, but don't make it a total wipe. Lose a number of your turrets/subsystems at random (for turrets, block destruction could have a fixed chance to delete vs. drop it) but keep some/most of them. You really don't want to die because you may well lose some of your best stuff, but you aren't guaranteed to lose all of your best stuff. Maybe (though this is stretching) apply a longer "debuff" to the ship performance (not just until it's repaired) to make it feel like you need time to get things running well again. Hard to balance this with people just deleting/recreating the ship, though. In the end, I'd love a way for my reaction to dying to be 'grrr, that hurts, this is going to take some work but I can keep going' and not either 'meh' or 'maybe it's a great time to start a new galaxy!'

Well, your forum username is apt, I'll give you that. To the last one: you quite literally do this by selecting the block, pressing ctrl+c to copy, and pressing ctrl+v to paste. Same block, same dimensions, same color.

Most players are familiar with the quirk once they unlock Xanion: a 0.5x0.5x0.5 transporter block (or even smaller!) does everything a bigger block would, so you just throw the block in as a token inclusion and call it done. 2.0 changes make this more of a thing: relative nerfs to hyperspace core improvement make it even *more* likely that you'll just include a single speck of Avorion for rift passage, and the shift of shield boosters to flat bonuses now make it appealing to have single-speck shield blocks in Naonite and perhaps Trinium space to acquire a meaningful shield with no real block or processing investment. I think it'd be great if building these tiny "on/off" switch blocks weren't a good way to go. To that end, making the behavior of corresponding subsystem upgrades work as "matching function" to blocks would help: For shield boosters, switch to a capped +% boost rather than a completely flat boost. E.g. "+300% shield (up to 200000)" -- you'll still need some block investment to take full advantage of the booster For transporters, allow blocks to logarithmically increase range (like hyperspace cores) and have a rarity-decreasing minimum "base range from blocks" requirement for the corresponding transporter subsystem: e.g. uncommon transporter subsystems may require 20-30 cubic blocks of transporter volume before they can start working work, but a legendary one may only require 4-8 thanks to its awesome efficiency (though you could still use bigger ones for better range!) To complement this, more advantages for increased transporter range would help, e.g. improve r-mining/r-salvaging operation efficiency based on transporter performance (e.g. as an input like the "time to find asteroid" variable) For hyperspace cores, cap or scale subsystem bonuses based on block investment and scale rift passage with the size of your Avorion core: Total +range and -cooldown from subsystems should be limited (capped or scaled) -- if my ship has no hyperspace core at all, I shouldn't be able to put in three subsystems and have +20 range, and bigger cores should progressively make these subsystems more valuable How far you can travel through rifts should be purely based on the size of your Avorion hyperspace core. E.g. a 0.5x0.5x0.5 Avorion hyperspace core shouldn't let you fly through anything, while a bigger one (as scaled by subsystems) should be an advantage for easy travel This could further be reflected in efficiency bonuses to operations around/across rifts, making it beneficial to have a "big enough" Avorion core to navigate The end goal would be to make it feel like scaling these blocks up in your ships always had purpose and value and to get rid of the silliness of a massive, 120-fighter r-mining operation being optimally powered by a cargo transporter with a volume of one cubic centimeter.

The beta branch recently got a new potential key binding for "target self" (the MMO F1). I love having that and now I'm reminded there's at least one more that would be very helpful! I almost never want to actively select and target a torpedo or fighter. With the rare exception of occasional use of seeker weapons for extra PDC coverage, I trust defensive fire to do the right thing (and I'd be pretty useless doing it myself with dumbfire, anyway). That makes "target nearest enemy" a big source of frustration sometimes, especially in pirate sectors that generate near-constant incoming torpedoes. My ability to hotkey to a target is effectively denial-of-serviced and I find myself forced to resort to searching around with the mouse (meaning no aiming in the interim) and/or going to strategy view (in the middle of the fight!) looking for my next real target. So the suggestion(s): I'd be perfectly fine with removing torpedo/fighter selection from the 'r' keybinding, but I suspect that's not universal and some people get more value out of it than I do. To that effect, one or both of these as new eligible key bindings would be fantastic: Target nearest enemy ship (not torpedo/fighter) Target *next* enemy ship (not torpedo/fighter, could follow along the strategy view list of red names)

Adding more depth to captain development and customization would be awesome! I'd be happy with all sorts of things, but having some means of molding and improving captains over time is a fantastic idea. It'd be a better fix for the problem I noted in my almost concurrent suggestion, too: Better (and more expensive) captains closer to the core - Suggestions & Idea Voting - Avorion Forums The root of that is that the "best way to get the best captains" right now is to (repetitively and randomly) recruit/dismiss captains over and over again, which is boring and unfulfilling (IMO). Having a more deterministic and involved way of improving your existing captains would be more fun, add more sense of attachment to your crew (they have names, so I assume this is a goal), and add another interesting dimension to progression options.

This isn't urgent, but there's a funny (though not unique) quirk with captain recruitment via "A Lost Friend:" you do it best by returning to iron space and steamrolling. The captains you get from distance 450 "A Lost Friend" are the same ones you get from distance 150 "A Lost Friend" You'll need to roll the dice quite a bit if you're looking for specific combinations of classes and perks Ergo: collecting a bunch of early-space versions of the mission and curbstomping it all it one shot is the "best" way to seek out your preferred captains That's not dissimilar to things like building economy far away to minimize defensive needs, but given we're scaling other stuff (like trade output) with core distance, it probably makes sense to encourage players to do the most challenging version of captain acquisition and not just ignore the missions close to the core unless it's convenient. It doesn't need to be dramatic, but having bonuses, positive trait count/distribution, or some other "goodness" characteristic of captains go up a little bit as you get closer (and conversely down a bit as you get further) would align the incentives the right way. Initial cost and salary can follow: if core captains can be somewhat better than iron-space captains, it's completely reasonable to make them a bit of a credit sink.

I really like the idea of being able to engage with fighters earlier given all the love they've been given, but I see one potential problem: this takes away trinium's "cool new feature." With the exception of ogonite (which everyone can agree is lame), each tier gives you at least one "cool new thing" to make it not just a stat upgrade: Titanium gives you generators (though titanium itself is a virtual non-tier) Naonite gives you shields Trinium today gives you hangars Xanion gives you transporters (and cloning vats, if you use that) Ogonite... I'll skip ogonite. Avorion is "better most things," including rift-jumping hyperspace cores and not-iron dampeners Trinium is already an outstanding tier just for its weight and durability (and it's the first material you get to that's really used and loved through the rest of the game), but it should likely keep something functionally new, too. Assembly alone (if we went that route) doesn't seem like quite enough.

Agreed that this can be a pain--combined with turret travel, DIY salvage has a lot of frustrating do-nothing time built in. One unintuitive thing that can help is to target your own ship (or something distant), which will cause the salvage turrets to give up and just face straight forward like a coaxial turret. You have to aim it by crudely moving your ship around at that point, but you eliminate all the little pauses and movements that can make things so inefficient. I notice that seeker launchers have a very nice (and cool looking) tendency to spread their projectiles out across the full surface of what you're targeting (including wrecks, which is helpful for turret salvage). It'd be great if that same code/behavior were applied to turret groups, at least for salvage lasers (or maybe more generally duplicate turret types in the group).

Lore-wise, "The Event" happened ~200 years ago and nobody outside the barrier knows if anyone's alive inside the barrier--and vice versa. Resistance leaders are shocked (and thrilled) to meet an outside-the-barrier newcomer. Yet: Radar and scanners work just fine through rifts and the barrier, implying communication should function, too (blink green twice if you're alive! OK!) The same factions (with no differences) span inside and outside the barrier, including your reputation with them. They may not have spoken with an outsider for 200 years, but they know about your potato delivery in trinium space and it's much appreciated! Suggestions: Radar and deep scan should not penetrate rifts (exception: Avorion processing core? but that's a tangent) and what's behind a rift should remain mysterious. This could be a directional thing (rift one square "up" blocks you from seeing three squares "up" even if your scanner could traverse around with its range) or just a plain distance limitation. No faction inside the barrier should exist outside the barrier, too. For factions that would have spanned the barrier, the internal portion could be a new faction similar to the outside one but with "Old" in its name, e.g. I could find 'The Followers of Uexip" outside the barrier and "The Old Followers of Uexip" inside, with its own reputation. This opens up the possibility of fun "reunification" sorts of missions at some point, but that's really a tangent) The main gameplay reason for this is that, with 2.0 progression, factions crossing the barrier breaks the intent of knowledge progression. You can effectively skip Ogonite and often even Avorion knowledge just by virtue of having already increased your reputation with a faction outside. Breaking into the barrier should feel like entering a new and hostile environment, not a "welcome back" party from your good friends a few sectors ago.

Agreed; there's really not much of an opportunity to exploit this given that there's hyperspace cooldown to contend with (with a disruptor present, it's considerable). If your ship just outright isn't built to fight or get away, then yeah--you get blown up, just a few seconds later when you can actually see it happen. But especially with Avorion's direction moving towards more ships, it's completely reasonable to build things that are designed to take a few seconds of fire and then flee; you really shouldn't be shoehorned into every ship you use being a combat juggernaut with 5M+ shields. I also really doubt that anyone is loading into a complex sector in "2 seconds." Empty ones, sure, but anything with a bunch of asteroids/ships/stations (like most of the sectors with pirates in them!) take a lot longer. Let alone the occasional sector with many giant container fields--I've been convinced that the game froze on those. Regardless, though, if the only way you feel less disadvantaged is better hardware, that's not good design past reasonable minimums.

Contextual autopilot on a hotkey would be great! It could be the exact same behavior you get if you select the unit from the strategy map and right click what you're targeting (dock at a friendly station, escort a friendly ship, attack anything unfriendly, mine an asteroid, etc.) but just kicked off without the extra trip to strategy mode.

Just to add to this: in addition to the great suggestion to add a little more differentiation between the functional and non-functional hull versions, it'd be great to revisit the relationship between hull blocks and armor. In general, you can swap in armor for hull at a 1:2 ratio and up with similar weight, half the volume, and *way* more HP. It seems like there's a way to make each of the blocks (both hull variants and armor) have their own role; "smart" hull could be a main/important source of processing power but give less HP, blank hull could be the best and most efficient way to increase HP, and armor could stay specialized by giving less HP than blank hull and weighing considerably more. Right now, you can (and maybe should!) just ignore hull blocks entirely. Which seems weird.

I've grown to love the spirit of the 2.0 changes but there's one thing in particular that keeps bugging me: AFK operations reward and even encourage me to not play the game. I'd like to see if we could get things to where operations always funnel into actively playing more, to where that active playing feels like it matters a lot, and to where leaving my computer on overnight for no reason but getting ticks on guaranteed resource timers isn't a thing. This is long, but it's just an elaboration of a few, almost certainly contentious, suggestions: Get rid of operations that can give lots of "stuff" AFK with zero risk and replace them with the ability to safely increase the output of future (non-zero-risk) operations Let operations simulate without the game running to remove/reduce the motivation to leave the client or even computer idle just for operation progress Add a little more risk, like Trade has, to operations like Mine/Salvage so that the bad outcomes aren't as predictable and inconsequential --- Concrete example of why I think this is a problem: in my current 2.0.2 insane playthrough, I'm losing a lot of ships. Which is way more fun than I expected, but it's also *very* resource hungry. Running out of iron and titanium after sacrificing captains to Swoks, here's what I did: Pumped out a few copies of a cheap mining ship Put some accumulated miner captains on each and whatever mining turrets I could find Started 6h-8h "safe mode" mining operations on each Turned off the screen and went to bed After waking up and grabbing a cup of coffee, I turned my screen back on and saw exactly what I expected and was even guaranteed: several hundred thousand iron and titanium conveniently deposited to my account, which was more than I had collected in total so far with my "active" gameplay and enough to satisfy all my early-game material needs for a while without really "doing" anything. --- Contentious statement 1: nothing that gives significant amounts of "stuff" (materials, credits, items) should be fully AFK'able. Operations should be a low-micromanagement way to complement (not replace) active player gameplay and being able to get too much, too quickly, with too little interaction can be demotivating. After my example experience above, if I run out of materials again it's going to be hard to not think "maybe I should just stop playing today and let operations AFK some more," which inevitably disengages me from the game further and further. Contentious suggestion 1: in this spirit, "safe mode" operations with 0 risk (via ambush chance) could be replaced with something like the "rest XP" concept that MMOs pioneered: a way I can passively make the next time I "actually play" yield more rewards for a bit. Rather than being able to do "safe mode" mining operations for 8 hours at half yield, a captain could do an 8-hour "preparation" mining operation (lore: researching asteroid fields, doing maintenance on systems/mining equipment, planning optimal routes, whatever) that would (arbitrary numbers as an example) increase the yields of the next 2 hours of "real" mining operations by 100%. That way, I still get something from this AFK behavior, but it's not a realized gain until I take a risk and actively play more. It doesn't "replace" me playing the game, it can just speed things up when I play later. --- Contentious statement 2: anything fully AFK'able shouldn't require the client to be running. If I can just turn the screen off and go to bed, I should be able to just turn the computer off and go to bed. The game should ideally not feel like a small-scale bitcoin mining operation. Contentious suggestion 2: allow operation simulation to continue while a player is offline and, in the case of single-player, fake it with the system clock. Warn when quitting if any active operations have >0% ambush chance but allow those to continue, too. That way, I can decide if I want to take the risk of a 5% ambush not going well without me able to intervene. --- Contentious statement 3: everything with big, leveraged upsides should have some scary risks I care about. Trade operations have started to get this into a very good place: if my merchant is ambushed after buying all the goods, I could lose the entire trade shipment and its value, which is probably worth a lot more than the ship is. I really care about the safety of the ship on a big trade run and I don't view that ship and captain as expendable. In the same way, miners and scavengers should be able to make me "hurt" if I don't take care of them (lore: ambushed on the way to my big, central depot of resources, which lets the pirates raid my "bank") and I shouldn't feel like the loss ceiling on throwing a miner at things is capped to a tick or two of resource income (adding the crew, this is remarkably even the case with permadestruction!). Contentious suggestion 3: like trade, every operation that "gives me lots of stuff" should have what's effectively a "critical failure" that has bigger consequences than just "the ship blew up, oh well." The risk/reward of sending a miner or scavenger into an area without sufficient escort or armament should make me hesitate when I see a 15-20% ambush chance just like I hesitate a bit when a merchant has a higher ambush chance as it's sent on an operation with a bunch of my credits. That keeps me mentally engaged with the operations and stops them from becoming a "click here every few minutes for more free resources" button. That's super long and thanks for reading if you got through it all--hopefully it makes sense and it's really just some rough ideas to help make operations "part of the game" and not "replacement for the game!"

Claiming asteroids is an enormously useful mechanic that's really important for a smooth early game, but it's never directly introduced or explained to the player even though we're guaranteed there's a claimable asteroid in the starting sector. New players asking questions about how to afford a Captain early on highlights that many people are missing out on this and having a harder start than is likely intended. It'd be great to add a brief segment to the tutorial explaining it. It could happen under the pretense of "The Adventurer" noticing you had no money to build your ship and suggesting you make some. This could also introduce the player economy a bit with something along the lines of "you could even build your own mine here, but that takes money to get going so you should just sell the rights to this for now."

What's the problem? 2.0 changes have done a great job of making material progression feel like a "thing." A lingering issue is that we still aren't encouraged to care about the materials we're progressing through; when it comes to optimal advancement, replacing a few key blocks with the higher efficiency upgrades is all a new tier typically means, with a few rebuilds corresponding to significant processing cap changes. This has a few degenerate things that emerge: There's no good reason to ever build more than a block of two or iron unless you're adding in an early dampener. Titanium is effectively immediately available and better than iron (dramatically better) in every way (except that dampener). Iron doesn't truly exist as a tier. Titanium's the effective real starting tier; nothing that's new (like generators) feels new, given it's the true initial baseline. Naonite is (optimally should be) almost completely ignored: without more processing and more/better shield boosting subsystems, you get better survivability by just building and supporting more hull/armor -- essentially, "naonite is really just bigger titanium ships." Trinium is a fantastic upgrade, but really just a piece-to-piece upgrade of titanium (with shields finally thrown in once you get the subsystems for it). 2.0.2 changes to fighters might make hangars feel more valuable, but you're still just fine doing a "replace all titanium with trinium" step and moving on with "bigger titanium ship (replaced with trinium)." Xanion is just more efficient tech blocks--another in-place replacement. Ogonite... well, ogonite is what it is. You can replace any titanium-but-now-trinium armor with it if you want to deal with scaling replacement, but it's such a marginal upgrade to do so that you're likely best off just ignoring this material entirely outside of replacing what you put your turrets on. Then with Avorion, you replace pretty much everything except for mass-optimization blocks like cargo bays -- which you can stick with trinum on. Meanwhile, there's a lot of unique character and meaning to each of these materials that's overlooked and unintegrated into the progression system. Titanium gives you generators! That's awesome! Naonite gives you shields! Amazing! With Trinium, you can use fighters! Whoa! Xanion lets you use transporters and even clone people! Ogonite... is... um... ogonite is DENSE! Avorion lets you ignore the rifts! Now the idea: what if we used the "cool new stuff" with each material tier as part of the progression system? Spit-balling: where you currently unlock an entire tier and new slot/processing cap, you instead just unlock a single or small subset of "cool new blocks" that you then need to use and interact with to "finish" your material tier advancement, unlocking all other blocks and new processing caps (as well as further progression). E.g.: Titanium first just unlocks the generator block, then you fully unlock the tier once you've used some amount of energy (10 GJ? not sure) that came from generators. This one would understandably be easy and a bit of a gimme, but you'd at least be forced to briefly appreciate how awful an all-iron ship would be. Naonite first just unlocks the shield generator block, then you fully unlock the tier once you've absorbed some amount of damage (200K?) with shields. Trinium just unlocks the hangar at first, then you fully unlock once you've filled half a squad of fighters. Xanion just unlocks the transporter block and full unlock comes once you've done some number of (10?) unique transporter-supported interactions. Ogonite is hard. As is, the best bet would be that it just unlocks armor and you take a certain amount of damage to that armor--but it could use love overall. Maybe move avorion's dampener upgrade to this tier and make that ogonite's "thing?" Avorion would first just unlock its hyperdrive core and you'd get a full unlock after some number of jumps over subspace rifts. The goal here would be that, for each material, you feel like you're actually interacting with that material and doing "the thing that it's all about" as part of the progression. There's plenty of lore-friendly explanation to go along with it, as it "makes sense" that experience with power/shield management, fleet logistics, etc. would translate into the ability to effectively build and manage bigger ships. Potential pitfalls center around people feeling even more "speed-bumped" than they currently are. I don't know that this is any worse than it already is (haters gonna hate), but having yet another progression option ("classic, simple, full") could address that.