Shrooblord

Except Einstein is quick to enact his revengeance and he killed the game as soon as it got there...?

Not if they were not in the Hangar at the time. It may be worth consoling your worrying heart to have them out on "Defend" command while flying around a Sector. I mean, you'll still lose the Blueprints, but not the 120 Fighters that you made from them.

Hm, still intriguing given that I didn't need to do that to get it to work on my end. I really am curious what is causing this discrepancy. Also, Lestat9, thank you for your effort and solving the issue - but could you please use the EDIT button instead of posting 4 times in a row? Thank you - just makes for a cleaner read on the forum. ;)

BUG REPORT Noticed unexpected behaviour due to the implementation of Ship Script Loader as the only hook for entities into using this mod: you cannot long-distance rename ships you own. This is confusing since once you've piloted these ships, the script has been added to them, and then, you can long-distance rename them. This is intentional to how Ship Script Loader works, but an oversight on my end. I will work out a solution soon / today that incorporates the ease-of-use of using Ship Script Loader to install the mod, but allows long-distance renaming of ships you own / in your Alliance (given the proper privileges etc. etc.) without having to pilot them first. Stay tuned.

Is there a way you can integrate the behaviour of the manual difficulty change into your mod? Manually adjusting the server INI every time I jump from "belt to belt" sounds both a little cumbersome and immersion-breaking. Mostly just asking, since you say you've found how to do it manually, whether that's a change that can be made in-code as well.

I have a bug report. Not entirely sure what triggers it, but I'll tell you the outcome. Sometimes Goods Haulers try to do one or both of the following problematic things: Buy more goods than the Cargo Hauler has stock for, usually as simple as 1 over the total amount they could carry. Push more goods to the receiving Station than that Station has space for. Whenever they decide they want to do either, they don't let up and continue to try and perform this behaviour somewhere between 5 and 10 times in a row, which spams both the Console and the main game screen itself full of error messages (Console says something along the lines of "Expected to buy 5 goods but bought only 4", while the game screen shows an error in the typical red "You can't do that" message with a red cross, on the right) every second or so. With multiple Goods Haulers at work in one Sector, this gets very spammy very quickly, but more importantly, your Goods Haulers aren't doing anything, because they load up their Cargo Bays with goods they can now no longer push, because the receiving Station doesn't accept more goods of that type anymore. Is there anything you can do to include some sort of check that wouldn't trigger this behaviour anymore? It's made me steer clear of giving my craft the Goods Hauler orders inside my own Sector, because they keep trying to push Aluminium from my Alu Mine to my Shipyard, which doesn't want it anymore, instead of acting as my handy cargo shuttle between production chains as I intended for them to do. Furthermore, Goods Haulers with cargo already with them will never try and push these items for profit, which I think isn't in the spirit of how this mod operates.

I think yes! This is possible, and I've added similar tooltip in the last update v1.02. ;) Ah, that looks fantastico. Thanks!

Owh! So good! I recently ran into this issue in my own savegames and it was... confusing more than annoying. Thanks for a fix!

I'm here to report a bug. Se my post on the bugs subforum for repro steps. The script FactionNotifier.lua spazzes out when a ship being built by a Shipyard is loaded into memory after a game has been shut down while the ship was still being built. Line 180 is failing because faction.name does not exist. Seems like the ship doesn't belong to any Faction while it is being built (or at least, when it gets loaded while being built, which, as you can read in my bug report, is already super buggy), and so FactionData can't return accurate data to work with. Consider implementing a clause to check whether the data is nil. EDIT: In fact, forget the repro steps I mentioned. The repro steps are: Start building a Ship at a Shipyard. Open Console. EDITII: I made a hotfix: from if #FactionData.OtherFactions > 0 and LoadedOptions.PF then drawTextRect('Factions in Sector:', HSplit:partition(2), -1, 0,ColorRGB(1,1,1), FontSize-2, 0, 0, 0) local i = 3 for _,factionData in pairs(FactionData.OtherFactions) do local faction = Faction(factionData.index) local MainVSplit = UIVerticalSplitter(HSplit:partition(i), 5, 5, 0.80) local Name = faction.name:gsub("%/*This refers to factions, such as 'The Xsotan'.", "") Name = Name:gsub("%/*", "") Name = Name:gsub("%*", "") drawTextRect(Name, MainVSplit.left,1, 0,ColorRGB(GetRelationColor(factionData.relation)), FontSize-2, 0, 0, 0) drawTextRect(factionData.License, MainVSplit.right,-1, 0,factionData.Color, FontSize-2, 0, 0, 0) i = i + 1 end end to if #FactionData.OtherFactions > 0 and LoadedOptions.PF then drawTextRect('Factions in Sector:', HSplit:partition(2), -1, 0,ColorRGB(1,1,1), FontSize-2, 0, 0, 0) local i = 3 for _,factionData in pairs(FactionData.OtherFactions) do local faction = Faction(factionData.index) local MainVSplit = UIVerticalSplitter(HSplit:partition(i), 5, 5, 0.80) local Name = nil if faction then Name = faction.name:gsub("%/*This refers to factions, such as 'The Xsotan'.", "") else Name = "???" end Name = Name:gsub("%/*", "") Name = Name:gsub("%*", "") drawTextRect(Name, MainVSplit.left,1, 0,ColorRGB(GetRelationColor(factionData.relation)), FontSize-2, 0, 0, 0) drawTextRect(factionData.License, MainVSplit.right,-1, 0,factionData.Color, FontSize-2, 0, 0, 0) i = i + 1 end end But do please look at it yourself, too. I may not have covered all grounds with this one fix.

Hey, I had a problem when building a Ship at a Shipyard. The particular build I requested from the Shipyard would take 40 minutes to complete, and at the time I wanted to go to bed, so I closed the game and would return to it later (now). However, when I returned, the ship wasn't being built by the Shipyard anymore (no blue progress bar on the Shipyard). I decided to try and use the /destroy command to get rid of it and request it being built again, but that command didn't succeed on killing the object. It left it with 1 hull and no amount of damage would destroy the ship, nor blow any of its blocks off. I tried using /destroy on the Shipyard to see if it was keeping the ship alive somehow, but that didn't help. I'm now stuck with an immortal, immobile object that I can't get rid of. Work-Around: Change entitydbg.lua's onOwnButtonPressed() function to this: function onOwnButtonPressed(arg) if onClient() then invokeServerFunction("onOwnButtonPressed", Player().index) return end Entity().selectedObject.factionIndex = arg end That way, you can take ownership of objects that are your selected object, rather than only objects that you are currently piloting (how would that even work, by the way... whatever). You now have ownership of the broken object. Fly to it in your Mining Drone. Pilot it. Summon the Entity Debugger once more. Now hit Toggle Invincibility. The Immortal Object is no longer invincible. /suicide, /destroy or ramming your ship into anything at all will now be able to destroy it.

I'm not sure. The secure function is called every time a server save is triggered, which stores data so that in the event of a load, all the data can be restored (via the restore function). Many scripts have these functions, as you'll know if you look at a couple of scripts yourself. There seems to be an issue storing the variable currentProductions, whatever that means. It may have to do with some kind of restocking mechanic that Resource Depots have? I'm not an expert on RDs. It shouldn't affect the trading functionality of RDs, but who knows how bugs multiply throughout the functionality of code if left unchecked.

Question: does this affect Traders who come into Stations to buy goods, too? I have seen all my economy crippled to about 5-10% effectiveness in relation to previously - was this your mod, or the balance changes introduced by the Beta patch?

You can request goods from the Factory interface (use the third tab on Trade Goods when you Interact with the Factory; only accessible if you own the Factory), which should request Cargo Shuttles from the selected Station. I'm not sure if you can request goods from Stations you don't own. I assume not, since this would be a very easy way to game the system and steal assets from Factories you don't own, crippling productions chains. But I don't know, because I haven't tried it myself. Give it a swing! Note though that Cargo Shuttles can only be supplied by Stations that have a Fighter Bay, and Fighters that are Cargo Shuttles.

Sorry for the double-post, but I just had an idea. (And you know how I get when I have an idea.) I know this is outside of the original scope of your mod, but do you think it would be possible to display the total amount of bonuses your ship is receiving because of all the System Module Upgrades? So instead of having to go by each SMU manually and adding up the totals to percentages and whatnot, you could have all the bonuses displayed somewhere, maybe only as a tooltip when you hover over something in the UI. Could also help clear up some confusion on whether percentages are additive or multiplicative (they're additive, for the record). What do you say?

That's hilarious. I think the problem stems from the fact that an Alliance is technically another Faction, so you can interact with it and sell things to it as if it were just an NPC, but because you are that Faction, you get money two ways. That's bad, and you explained perfectly well why!

TheGoodDoctor, thank you for posting instructions on how to modify the file. Do you think you could post a diff using DiffChecker, though? That way, also users in the future will be able to make the modifications you propose, as line numbers alone are subject to change during the process of development.

Update 1.1.1 BUGFIX: The UI window now closes when you press OK.

And stabilisation means reduced risk of being Hyperspace Jammed? Nice. I inherently like the idea of more System Module Upgrades. Right now, there's just a couple of good ones that fit their task really well, but you can get away with choosing one or two specialised SMUs like a Shield Booster and Energy-producing SMU, and then cram it full of, I don't know, Turrets, or Hyperspace-related SMUs, but adding more SMUs that add a meaningful difference in your chances of survival, means you'll have to start making decisions that balance combat prowess and utility - which gives ample room for strategising.

Ooooooooh the hasPilot call checks for player pilots. You learn something new every day. I don't know what I was thinking it checked for, but I assumed they were a different type of Captain. Silly Shroobie!

Have you checked what its braking speed is? This heavily influences the top speed at which AI ships go. I have an AI ship with a braking speed of 1500 m/s2 (yeah I know: lots of Inertial Dampeners and front-facing Directional Thrusters), which uses its top speed of 1500 m/s to zoom around Sectors. AI ships take into account how long it would take for them to brake to get to their destination and match their speed accordingly. To test this: put a Velocity Security Control Bypass on a Captained ship, and in Tactical Mode scroll way the way the way out there. I'm talking hundreds upon hundreds of kilometers out. Send it there, and select it. You'll see it constantly accelerating, because it's nowhere near reaching its destination within any reasonable time frame. Once it gets to a point where it will need to start braking, you'll see it drop in speed. So my tip: if you want your Captained craft to go fast, given them sufficient braking thrust. They can't turn 180 degrees and use Boost to go the other way and force-brake like our player craft can, so they play it safe and go slow.

I just thought about Feather's suggestions again. In the case of the cola-can assault, how about the fact that although only 8/9 boarders of yours fit on the cola-can, you still have 100 times those amounts ready to go? You could make it so that, indeed, the target ship has a higher defence rating of sorts than expected given its crew size, but is explained by the fact that this smaller ship bottlenecks your assault force; but also so that your assault force has way more assets to "throw at them", i.e. Zerg rush style / covered in swarming ants approach. You could effectively whittle away their crew over time, if you're willing to use your own boarders as meat grinder cannon fodder. But if that's the approach you want to go for, you should be allowed to. Hm this gives me so many more ideas. How about robot boarders? Tiny nanobot swarms? Cloning vats so you don't need to hire so many boarders all the time but are passively creating more... er... well... "exalted honorary warriors with a win-or-die philosophy".

Oh, wow, imagine being able to build something like that! Wow! Yeah, okay, I'm on board. 45 degree angles, pls devs!

I guess you've got a point there. But perhaps you offer a solution right there: if there were to be a Hyperspace Blocker (which is functionality that is actually exposed to us modders, so someone could go out there and make a "Hyperspace Jammer within X km of this Ship" System Module Upgrade, or perhaps even a Hyperspace Jamming Turret of sorts), I propose that it would also block access to modifying System Module Upgrades. Basically, deadlock and cripple a ship, as is the intent of an offensive system like this. But then a new problem arises: how to properly balance this so that it has valuable counterplay? If someone can have an offensive system like this, or maybe even more than one, we need some way to counteract that, or all combat just devolves into "who can have the most or best Hyperspace Jammers equipped". Perhaps Hyperspace Jammers need to work on some kind of cooldown, or only be able to detain a ship for an amount of time dependent on the target ship's size and/or processing power (trying to reroute power to computers to counteract the "hack", or similar explanations as to how this can be countered), or maybe targets need to have an ability to "reverse the polarity", and counter-Jam their opponent with their own weapons?? I don't know. You raise an interesting set of problems, though. It would be nice to try and see how to design for and around those problems.

As you have, I'm curious, what change in the code caused this behaviour to be fixed? Could you post a diff?

Yes please. Script indeces would be incredibly handy for not a small amount of use cases.