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.