Shrooblord

This is what the mod Carrier Commander aims to implement. It works surprisingly well. There are a couple of bugs like having to tell the fighter squadrons to perform an Order again if you exit your craft (it tends to cancel Orders for some reason), but other than that, it saves a lot of time and lots of headaches. Check it out if you want functionality like it in your game right now. As for the devs, maybe they can take a look of it and draw some inspiration on how it could be implemented for vanilla. It does everything you've described, except this specific part. When you give an Order to Mine, they will mine the nearest asteroid, and then the next nearest resource asteroid, regardless of its material. But tell you what, two whole Squadrons of Fighters make very short work of a field of asteroids, I can tell you that much. ==== But yeah, definitely. I would love to see the functionality introduced by this mod integrated into the main game code itself. It's a great piece of functionality. It could use a little bit more work (also seeing as people are having considerable trouble installing it for some reason - seriously I'm not sure why that is: when I install it, everything works fine), but otherwise it's one of my favourite mods out there, specifically because it solves all the issues you raised.

Why not? Could you tell me the objections you have for this working in Multiplayer?

I'm just going to dump a load of issues here that we've noticed after a long time of playing online with Alliances: Alliance members do not receive chat messages about Economy changes, like how much a crew was paid or how much money was made in a Trade with an Alliance-owned Station. This makes it very hard to gauge how well specific Stations are doing, rather than the Alliance's Economy as a whole. Alliance members can't teleport to Alliance craft like Players can teleport to their craft with the new teleporting functionality. Captained Alliance ships don't post their messages to chat log. For example, the "Sir, we can't find any more wreckages to salvage!" message never shows up, which means you have to baby-sit your Captained ships to see whether they're still doing their job or not. Alliance ships don't show up as bordered green squares on the Galaxy map like Player ships do. This makes it hard to pinpoint where your ships are currently, and means you have to open up the Alliance window, then select Ships, then check which Sector they're in, then open Galaxy Map, and then find that Sector, instead of one quick glance at the Galaxy Map. While scripting mods, Alliances in general seem to have some issues with Player() functionality. Some scripts fail to select the Player() because certain calls to Player() work while other do not. I believe it's a discrepancy between Player() and Player(Player().index). Because different scripts (also vanilla scripts) can use a wide variety of different behaviour for selecting the player, this can cause issues in some cases, while being fine in others. Consolidating this behaviour into one, specific method of targeting players and/or fixing the bug itself would help with scripts (silently) failing when players are piloting Alliance craft. Missions and other such rewards completed and performed while flying an Alliance craft pay out into your personal inventory instead of into the Alliance's. You can't right click to quick-drop items from your personal inventory to that of the Alliance when opening the Alliance Vault UI. This means you have to click-drag all items from your inventory into the Alliance Vault one item at a time (stacks of the same item don't transfer in one go, for example). Players can be hated by Factions while this same Faction loves the Alliance they're in. While this is OK in general, it can lead to very weird situations where exiting your Alliance craft to pilot your Mining Drone in your strongest ally's Sector can suddenly result in you exiting into your Drone into very hostile territory, which is weird. I propose that all members of the Alliance slowly gain favour with the Factions that favour the Alliance, though at a reduced pace to that of the relations between the Faction and the Alliance itself.

Are you playing in a Galaxy that already existed, or a new one?

Flying an Alliance ship, we've noticed that we see no Damage Number Indicators on our HUD whatsoever. I love the DNIs. It's exciting to see huge numbers whizz off an enemy's ship as it's slowly dying, and it's a good indicator of whether and when your shots are hitting.

Man, me too. I can only try to describe the frustration and cringe at losing my ship at the other end of the galaxy because I forgot that PDS Turrets existed and I still needed to get used to Torpedoes. I love it. This game is now properly kicking my ass once again!

Good tip about the Hologram Blocks. I should experiment more with the different block types we have! Actually no, they're not tricky changes to make. I'm in the finalising stages of the mod's development as we speak. It should appear on the Mods subforum soonish. And boy! It's satisfying to use, if I may say so myself. ;D

I've proposed we talk about this matter in the past, and I wholeheartedly agree with you. Ultimately, a galaxy that feels truly alive would be amazing. But right now, to simulate that while the groundworks for a game like that are still being lain, we'll have to do with timers that chase you around.

I would love a Torpedo Factory for this reason. And yes, constructing Torpedoes on board would be even more amazing, but I can imagine how the devs wouldn't want to add that in for balancing reasons. Torpedoes are crazy powerful. That needs to come at a price (and honestly, they feel like a great money sink - something the game was sorely lacking before the update). If you want, you can already play with Torpedoes by going onto Steam and opting in for the Beta Branch. I highly recommend it. Torpedoes and the other Combat Update additions are fantastic!

That's kind of like how Hangars work, too. They need a clear path in front of them or their exit is considered blocked. It would be nice to have a visual indicator of this same behaviour with Torpedo Launchers, perhaps by making the arrow red when it's blocked or something like that. P.S. Is that... is that a Star Destroyer? ;D

I can confirm: I too have found green blips with reported Energy Signatures to find only an asteroid field.

Whoa! Really? How awesome! Thanks for all your work over the past year, Laserzwei. I have enjoyed this mod very much.

Deadonstick, I like your idea for overheating! I am now also imagining a new weapon type that's focused primarily on cooking your ship from the inside, incapacitating it and perhaps even starting to hurt and kill crew the longer you are exposed to its deadly rays.

I agree. Two different DPS indicators for sustained and burst fire seem like a healthy way to go.

Well the obvious answer is that bigger blocks have more hitpoints, and Torpedo Launchers being one of your primary weapon systems, that's a good thing: you can ensure that your weapon is very hard to take down by making it larger. Other than that, no, no benefit as far as we could tell yesterday. Yes, multiple. For one, you can rapidly fire Torpedoes as each block has a 4 second cooldown or so. Having multiple blocks means you can fire more Torpedoes at a time. Not that you need that many Torpedoes, but... yeah. It's there if you want it. Additionally, Torpedo Launcher blocks have an inventory for (I think) eight Torpedoes each. You have finite storage space by adding Torpedo Storage blocks, and the Torpedo Launcher blocks can extend this space by loading Torpedoes into them, as well as into your storage.

Also, the Persecutors actually jump after you relentlessly and try to kill you every time you return to the Sector you died in. I've just experienced this yesterday. The Galaxy feels dangerous once more. This update is fantastic. My friend and I have played it to death yesterday on our multiplayer server until the wee hours. The combat is so much more interesting now, Torpedoes are glorious, and enemies actually feel like they possess a sort of cunning and tactics. Great work, guys! It's not completely bug-free, though. For one: damage numbers seem to have disappeared altogether, and some of the new enemies behave in silly ways sometimes. I found a shield-buster enemy (shield-breaking icon) just sitting there staring at me like I was some sort of effigy to their god or whatever. He was just sat there doing nothing, even as my friend and I tore his hull to shreds. I also seem to recall it had what looked to be Salvaging Lasers on it?? It may have been Repair Turrets, in which case, I understand that it wasn't attacking us with those. But then the question becomes: why did it chase after us an isolate itself from its peers who could have desperately used its repairing beams? :P

ohmigod YEESSS My body is ready for this update. Let's address things point-wise. Ohhh, yes. I can't wait to see what this is like. Galactic ship-to-ship teleportation? How great. Now I feel like an actual commander rather than a Captain who runs a tugboat. Interesting! I've had ideas of my own for Events that had this theme going for them. I'm excited to see in-game what that's all about. YES! I've been meaning to explore the possibility of modding in a Loot Magnet... and now I don't have to. ;D More great news! I've always found it slightly cumbersome that Stations don't benefit from the same accessibility to Shield Booster and Energy Production SMUs as Ships did. Ah, I wonder, does this address the bug report I made earlier? Sweet, sweet. I hope now that the Invulnerable Fighters have somewhat of a decent counter. Eager to test in-game. I can't express enough how much this excites me. Torpedoes sound awesome. And, finally, some sort of ammunition system to balance in-game combat with. This is gonna be good. One question: in the future, will we be able to design Torpedoes like we can Turrets in Torpedo Factories? I'd love to custom-design the destruction to enact upon my enemies, and outfit specialised ships with specialised torpedoes. Some ideas that come to mind: EMP Torpedoes aimed at disabling ship systems like Engines and Hyperdrive; ionised Torpedoes that are meant for taking down shields; fast Torpedoes with very little damage but high travel speed and rate of fire; nuclear warhead Torpedoes that are slow, deliberate, slightly inaccurate but deal a massive amount of AoE damage upon exploding; laser-guided Torpedoes that are excellent at tracking fast-moving targets and adjusting their course mid-flight; Subspace Rift Torpedoes that simply teleport to their target and 'splode. So, basically, bombs. Aw-hoho YYYESSS that sounds good. I love the idea of bulkier Turrets, and it only makes sense that they would take up more Turret Slots. Excellent! Oh, wowie! All of this sounds intense! I believe a lot of my installed mods are instantly broken, too, though. Hahaha I'm gonna need some time to play in the ballpark and recentre myself with all these changes. A strange change for me to highlight out of all the other cool-sounding changes, but thank you for this. Setting the reconstruction site previously seemed like such a high paywall for something that just improves the QoL of your game experience when death comes knocking. Ah cool. This addresses some of the griefing concerns players have mentioned on PvP servers. Though I think more balancing and changes will be necessary on that front, in time. Heeeyyyy, now stop reading my posts and shamefully adding their content to the game without my prior consent! :P It's like you're reading our prayers! Praise Boxelware! Oh, wow. That's some changes that seem insignificant but may have some rampant implications. All mods that relied on sector.lua before will need to be looked at.(EDIT: derp thought sector.lua was server.lua - my bad.) That's the price of modding an Early Access game, I guess! More callbacks and more documentation about callbacks is much, much appreciated. Thanks folks! JEEBUS THAT'S A LOT OF BUGS FIXED. Good going, you guys!! Specifically, impresses me (of all things); my friend and I haven't heard combat music on our multiplayer server... basically ever. And we were starting to get a little sad about it. ;) I did, thank you for this. ;D

Awesome! Thanks for all your work. ;D I'll give it another swing some point after I'm done with my own two mods (sorry guys, a man has his priorities ;) ). If before then anyone else is hit with inspiration, please, do try, yourself.

Lol duh. I should stop coming here at 4:30 AM and expect to make any sort of sense, much less read a single line of code correctly. xD This is actually what I meant with taking it out of the equation; amount = amount is a moot statement, so commenting it out (or simply deleting it outright) is what I meant. ;) Yeah, sure. The namespaces aren't that hard to get once you've seen it a couple of times and done it yourself. Here, I'll give you an example from one of my mods in the making that communicates between four different scripts: autoDockAI.lua local AutoDockAI = {} AutoDockAI.usedDock = nil AutoDockAI.dockStage = 0 AutoDockAI.printVals = 0 --set to 0 for no debug, 1 for some debug and 2 for extensive debug logging AutoDockAI.numDocks = 0 function AutoDockAI.printUsedDock() if onServer() and AutoDockAI.printVals > 0 then print("AutoDockAI: dock: "..tostring(AutoDockAI.usedDock)) end end (...) -- more such declarations... (...) return AutoDockAI autoDock.lua package.path = package.path .. ";data/scripts/lib/?.lua" package.path = package.path .. ";data/scripts/entity/?.lua" package.path = package.path .. ";data/scripts/?.lua" require("stringutility") require("utility") require("faction") local AutoDockAI = require("mods/AutoDock/scripts/entity/ai/autoDockAI") local PlanGenerator = require("plangenerator") (...) function arbitraryFunction() if AutoDockAI.dockStage == 0 then return 0.2 end end (...) local docked, tractorActive, target = AutoDockAI.autoDock(ship, station) ==== And the inactiveGate.lua example I gave earlier: package.path = package.path .. ";data/scripts/lib/?.lua" require ("randomext") (...) --more requires like this require ("player") local Dialog = require("dialogutility") local SectorSpecifics = require ("sectorspecifics") (...) --more handles like this local ShipUtility = require ("shiputility") -- Don't remove or alter the following comment, it tells the game the namespace this script lives in. If you remove it, the script will break. -- namespace InactiveGate InactiveGate = {} (...) -- this function gets called every time the window is shown on the client, ie. when a player presses F function InactiveGate.onShowWindow(optionIndex, material) local interactingFaction = Faction(Entity(Player().craftIndex).factionIndex) InactiveGate.sendAllGates(Player().index) end ==== There are actually two ways to implement namespaces. One is like the autoDockAI.lua example, and the other is like the inactiveGate.lua example. I'll start with the easier one. In the case of inactiveGate.lua, we set a namespace at the top of the file, after importing all required scripts (making them available in the scope of our current script) and adding handles to other scripts' namespaces by defining them as variables (more on that later as I discuss the other example). Copying the behaviour of the vanilla lua files, it would appear there is also a crucial comment that's included which is part of the declaration, and is necessary. I haven't actually tested not including this comment, so I don't know how true that is. Next, we define functions, again, by declaring them as function namespace. and then call them in the same way whenever we want to call them in-script, even within that same script. Note the InactiveGate.sendAllGates(Player().index) call, which calls a function within the same script's namespace, yet still needs to use the same syntax as if calling a different namespace's function. It's just a syntax you'll get used to. That's it! Namespace created. To call from a different script, simply require it and use its namespace appropriately. ---- Next up, the autoDock.lua example. As you can tell, this one depends on two different script files. One of them, autoDockAI.lua is the script which has a namespace defined, while the other does not. You will note that although autoDock.lua does not have a namespace defined, it will still work. This is important: namespaces are by no means required by the game to run scripts properly. But I have found they make life a lot easier if you want to call functions from different scripts. And they just clear up confusion and make it clear to you the instant you read something: "Ah, this function is from a different script." Anyway, back to the point. autoDockAI.lua has a namespace, and more importantly, notice the return at the end of the script. This script never actually executes on its own. It's almost like an object, or a library of functions and variable definitions. It doesn't do anything until autoDock.lua calls it when calling the function AutoDockAI.autoDock(ship, station). Sure, it initialises and sets some variables when autoDock.lua declares that handler way at the top of the file, but it doesn't execute anything on its own. Of course, this is because there are no automatically triggered functions declared within autoDockAI.lua. There's no ticking functions nor updating properties. So it's a dormant script. However, it has lots of data inside of it. It has all those lovely variables and functions declared within it, which we can access at any time from the main script autoDock.lua by calling AutoDockAI.<OPERATION> whether <OPERATION> is a variable name or a function call. ==== I hope that clears up namespaces for you. They're really not that hard once you've experimented with them a little, and they'll make coding with multiple scripts so, so much easier. ==== I have to admit I'm no expert. I've seen lua scripts include other scripts in their namespace using requires alone. Others use pcall and yet others use namespaces. I'm most comfortable with namespaces right now, so that's what I'm advising you use, not because it's de facto the best approach, but just because I know how they work, and they're relatively easy to get started with (in my opinion). Other options may prove to work better for you. Please do tell. I'm eager to learn more, always.

That's a little contradictory, is it not? DPS assumes that an average is taken, and the cooldowns and whatnot are taken into account there. I think the problem lies not in wrongly assuming an ability to indefinitely sustain the maximum DPS peak, but rather in not accounting for the cooldowns in DPS calculations. I point you to the following mod: Ohm/DPS Calculation Display. It actually does take all these factors into account and gives very accurate numbers that more precisely indicate what you can expect of your Turrets. I propose that these calculations be integrated into the main core code of the game, and used for all DPS calculations. That way, derivative values like the omicron numbers and turret selling price based on DPS should follow suit automatically.

You raise a number of valid points, Deadonstick. Why be a small, zippy craft if you could also be a ginormous Star Destroyer and wipe all your enemies off your windscreen like common bugs? I mean, why other than for style or personal preference, of course? I like your idea of figuring out some trade-off between going big and staying small. To keep with the Star Wars analogy, we need some way in which a tiny X-Wing can reliably take down a Death Star, and vice versa, how a Death Star is supposed to deal with tiny shitty X-Wings. Supposedly, the Death Star has to rely on employing equally shitty craft - let's call them TIE Fighters. But perhaps something else can be thought of, too. And yes, tiny craft should soar and huge giants should be lumbering and sluggish. I like those archetypes and they exist for a reason. They're satisfying, and more importantly, physically accurate. However, bigger size does allow for bigger engines - keep that in mind. At the same time, though, bigger size should need bigger engines, so there's a point of balance there... The game already does all of this. Stations get far, far larger the further you go towards the Core, and larger ships do need larger engines to get going. However, you're right, the scaling is off. It needs tweaking, or outright redesigning. Let's see what this Combat Update brings. Perhaps some of these issues will be addressed in ways we're not thinking of right now. P.S. While on the topic of physics and accuracy, my friend recently noted how you can be travelling at a consistent pace and fire Missiles from your Launcher Turrets, which will then be trailing behind your ship, and how that doesn't make sense. I agree. There's an inexplicable net loss of momentum there. These sorts of issues should also be addressed, in my opinion, but that's rather a different discussion.

Ahaha, indeed, indeed. But if you would see code that I write, you would know that I make it as legible as possible, complete with comments, mostly for my own sake. Here, have a snippet from something I'm working on right now: --By coord (first by X, asc/des, then by Y, asc/des) function InactiveGate.onCoordLabelClick() --X sorting if sortByCoord < 2 then InactiveGate.setSortFunction(InactiveGate.sortByXCoordAsc, InactiveGate.sortByXCoordDes) sortByCoord = sortByCoord + 1 --Y sorting else InactiveGate.setSortFunction(InactiveGate.sortByYCoordDes, InactiveGate.sortByYCoordAsc) --Des first instead of Asc because of how the galaxy coordinates work sortByCoord = sortByCoord + 1 --reset to X sorting if sortByCoord >= 4 then sortByCoord = 0 end end end (...) -- client-sided function InactiveGate.updateGates() if inactiveGatesLBE == nil then return end --if gateData == nil then return end inactiveGatesLBE:clear() table.sort(gateData.gates, sortFunction) for i, pair in pairs(gateData.gates) do local coords = InactiveGate.padCoords(pair.x, pair.y) local timeTC = InactiveGate.formatTime(pair.time) local money = "$"..createMonetaryString(round(pair.cost)) inactiveGatesLBE:addRow( pair.name%_t, coords, tRN(pair.dist), money, timeTC ) end end You'll see the coding style is much different from this mod's original author's. While I am flattered that you seem to suggest I wrote this mod (at least, that's how I read into it - maybe I'm making a fool out of myself right now, but let's say I'm right), I must inform you out of decency that this mod is not my work but Cypher's. I highly doubt that Cypher coded this as it was in its minified state. If they did, then they're even more of a magician than I already hold them for. Good work making the code more easily parsed by human eyes. I've done the same when trying to decipher what it was doing. To be honest, though, the multiple single-line lua operations this code was cram-packed full of has opened my eyes to a new sort of black magicks, and I find that wizardry quite profound. ==== That said, let's talk about bugfixing the issues this mod has in its current state. I'm not sure I understand. How does an index always remain zero? Do you mean it's zero-based, i.e. the first element (index) is "element 0", like with most programming languages' arrays (eg. name[0] = "Fred")? If not, I will ask again: what use is an indexing variable if it always remains the same value (regardless of that being 0, 15 or "Millie Bobby Brown")? I'll put the old vanilla code and your changes side-by-side: 416. for _, item in pairs(required:getItems()) do 446. for _, item in pairs(required:getItems()) do 417. table.insert(items, item.item) 447. table.insert(items, item.item) 418. 448. 419. local amount = itemIndices[item.index] or 0 449. local amount = itemIndices[item.uvalue] or 0 420. amount = amount + 1 450. amount = amount 421. itemIndices[item.index] = amount 451. itemIndices[item.uvalue] = amount 422. end 452. end See, in the original, amount is keeping track of something. For every iteration of the for loop, the amount gets incremented. However, with your changes, amount is no longer changed, ever. It stays the same. In fact, it gets set to its current value (which is in fact a little pointless, but I digress). I'm not trying to reprimand you here or anything - just trying to understand how this change actually solved the buggy behaviour. I'm curious. And this is why I'm curious. I wonder what amount was in charge of keeping track of, if completely taking it out of the equation solves the bug. I also wonder what other, yet unspotted bugs it may have caused. But maybe there are no new bugs. Let's hope, until we do some more testing. Yes, too bad. That's also the snag I hit at some point. I was hoping it would be a simple on/off switch type of deal, but the problem seems more deep-rooted than that. Good find! In my own tests, I found out I had to make several adjustments to the autoresearch.lua script in order to make it compliant with the current version of the game. One of such changes was adding a namespace, implementing proper returns (as you say), and properly calling the functions by their new names. onClickResearch() is not a function that exists in the namespace of autoresearch.lua. That is to say, the script autoresearch.lua doesn't have a function onClickResearch() defined anywhere inside of it. This makes sense, as the original mod's code appears to want to call functions that are inside the vanilla file researchstation.lua. However, it doesn't, because this has not been properly set up (because the way that the code is managed in the current version of Avorion is different to the method employed back when this mod was first created). The debugger in Avorion is really good. It gives precise errors and stacktraces, and manages to catch exceptions like a beast. One problem, however, if I recall correctly, is that function calls that reference non-existent functions, silently fail. Now don't quote me on that: it's been a while since I've tested that, but it could be that that's why we don't catch this behaviour going wrong when autoresearch.lua tries to execute: the debugger (printing to Console) simply doesn't know about the mistake, because no error is raised. So how to fix this? We need to properly include namespaces. I refer back to the code I posted of my own mod project: function InactiveGate.updateGates() See that InactiveGate. in front of the function's name? That's the namespace indicator. It's great, because with it implemented, I can call updateGates() from any script given it's executing in the same scope (Entity, Sector, Server... that kind of thing), by calling InactiveGate.updateGates() from that other script. I've done it several times before in my mod projects by now. So try that. Give researchstation.lua a namespace (look to many, many other scripts in Avorion that already employ this) and make onClickResearch() callable from outside of the script itself by including it in the namespace. Then call it within autoresearch.lua using namespace.onClickResearch() instead of the current onClickResearch() and see if that works. You can run a simple print() command at every step of the way and check Console to see if stuff is behaving as you'd expect. Good luck! Hope you crack this one. Looking forward to updates. :)

We can certainly hope! And if they don't, I sincerely hope the devs or someone in touch with them read suggestions like these. Not just suggestions in Suggestion topics on that subforum, but random suggestions proposed by people in the community talking amongst themselves. That they read them, and that they can make some magic happen on the C++ side of things and say "Hey now, look. We don't have the time or funds to put in those changes you guys want, but here's some new callbacks, here's some exposed variables, here's some properties made writable. If you want it, you can mod it in. Go nuts, guys. Have fun."

Heh. Heh. Heh. I just tried another shot at renaming Sectors. local SectorSpecifics = require("sectorspecifics") function InactiveGate.renameSector() if onServer() then local x,y = Sector():getCoordinates() local specs = SectorSpecifics(x, y, getGameSeed()) specs.name = "Hey There" end end Guess what? The game crashes. Turns out there is a way to trigger the Sector renaming behaviour, but the C++ side of things is ill-equipped with handling the situation (probably because it's supposed to be read-only, yet here we are modifying it), just can't even, and bails. Too bad! We return to the waiting game of hoping that the devs make the Sector name a writable property...

That's a great suggestion, Burnthalo! I'll try that some time. I've also found that Fighters are very effective because you can literally tell them exactly which unit to attack. Sure, it's a little micro-ey, but nothing too bad for an avid RTS player like myself. I guess that's why the Sector is called "Endless Fight Gamma", huh? :P