Laserzwei

1) LUA (plus an API which is documented in /steam/.../Avorion/documentation/) mainly. See the Avorion/data/ folder for other stuff (sound/graphic/shader...) to modify 2a) LUA doesn't require a compiler 2b) There is currently no modloader. You will always have to modify existing gamefiles 3) Sectors have 3 states: [*]Loaded (player inside) [*]semi-Loaded (no player inside, but player-property inside. Refresh rate is lower than in player sectors) [*]Unloaded (no player(-property) inside or max. active sectors exceeded) There is also an API callback telling when a sector gets loaded back in and how long it was unloaded. This helps with eventual catching up. There is currently no API to force sectors to load

related: https://www.avorion.net/forum/index.php/topic,4635 Thanks for the fix :)

A function to get the started fighters of a specific squad of an specific Entity. It would best reside in FighterController, because it already controls them. Something like this: function Entity... getStartedFightersOfSquad(unsigned int squadIndex) That should be much better than (my) current workaround: local fighters = {Sector():getEntitiesByType(EntityType.Fighter)} for _,fighter in pairs(fighters) do local fAI = FighterAI(fighter) if fAI.mothershipId.number == Entity().index.number and fAI.squad == searchedSquadIndex then --do something end end

Yesterday I had a much more in-depth description -about how the resource System in Avorion is done from a scripting perspective- prepared, but the Auto-Log-Out deleted it, when I pressed preview :-\ So I will deliver it as an appendum: This will Touch the following Classes: Resource information: Entity Material Resource Manipultaion: BlockPlan BlockPlanBlock Box Context: Entity function int... getMineableResources() Returns all resources available for extraction from that Entity as Arguments. If you expect more than 1 resources on that Entity, you will want to put {} around it to catch them. This is not necessary for Vanilla Asteroids. However: Wreckages with different Materials will need it. It does not provide any clue of what Material these resources are. function Material getMineableMaterial() This returns exactly 1 Material. It is only suitable to get a single resource. I haven't tested what it returns in case of multiple resources, but I doubt it holds meaningful Information. function double... getPlanResourceValue() This is pretty much a combination of the above. It returns 7 double Values (One for each Material: Iron->Avorion). Each of them holds the amount of resources build into the Entity. Most of these Values will have 0 in them. They are always given in ascending order, starting with Iron. To catch them in a single Table again use {}. Here is an example code snippet: local resources = {Entity():getPlanResourceValue()} for material, amount in ipairs(resources) do print(Material(material-1).name, amount) end 2 things to metion: 1. I use ipairs to traverse the table. It requires the indices to start with 1 and the next following to be +1. If not, data might be lost! The big pro: It is in order. pairs might traverse randomly. 2. I use material-1 to map the table indices to Material indices. The Material indices start with 0, the LUA-table with 1. This is basically all the information about the resources on an Entity you can get. If you want to manipulate them you have to dig into BlockPlan To get the Blockplan of entity use: Entity:getPlan:get() getPlan() returns a Plan Object, which is basically an extended BlockPlan. the following get() gives the actual BlockPlan. Both have the same -already discussed- getPlanResourceValue() function Context: BlockPlan The resources in an Entity are defined by the Blocks which make it up. So to manipulate the resources on an Entity (mainly, but not limited to Asteroids or wreckages) you have to modify the underlaying BlockPlanBlocks. You can get these blocks by traversing through the BlockPlan. Either use the tree-like traversing starting with the given BlockPlanBlock attribute root and root:getChildren(). Followed with the BlockPlan function BlockPlanBlock getBlock(int index). Traversing it in this manner allows to get information about the structual properties (to destroy a root-Block you need to inflict enough damage to destroy all of its children as well) Or use function int... getBlockIndices() with function BlockPlanBlock getBlock(int index). Don't forget to get them into a table with {...}. Context: BlockPlanBlock To manipulate the material-type, you can modify it with the BlockPlanBlock attribute material. It requires to be a Material object. To Manipulate the amount, you have to change the volume of the block. Much like it costs proportionally more to build a Block, you also gain more resources back from it. The Volume of a Block is defined by it's size. As every (building-)Block is actually a cuboid, you have to change its size. It is stored in the box property. You can test which sizes you want in the building mode (it also allows to add resource-stones)- the build-cost and the resource-amount are the same. You will probaly have to fiddle around with the Box's attributes, to get the desired results. This completes the information and manipulation of resources in Entities - available for modding.

since nobody answered: function Material getMineableMaterial()

I've got a relatively small request: add something like function Entity, ... getEnemies(var relationThreshold) to shipAI. The Intention is to have quick access to all Enemy Entities, in cases where "getNearestEnemy()" does not return the most reasonable target. (E.g. it selects a fighter close by, but the Big Mainship might be a better target...)

I won't be updating it. If you find someone who wants to, I will gladly support him with code snippets and the concepts of how CC-plugins are supposed to work. Also: Updated CC to 1.9.0 experimental changelog: -- 1.9.0 experimental for 0.19.x [2018-10-19] - halved calculation times for targeting enemies by changing the order of if-statements - discarded the seperate Xsotan-enemy detection code and used Vanilla ShipAi. As a result Xsotan aren't seen as neutral by the ship (and only the ship CC is running on) anymore - added Unsupervised targeting-option to enable Vanilla-targeting behavior against enemies(which overrites Attack Civils, Attack Stations, Aggressive Targetting). It's also one magnitude faster than the beforehand mentioned speed increase. - added config option to enforce Unsupervised targeting serverwide There is no apparent reason to update from 1.18.5 as it will work just fine with Avorion 0.19. I've just spend some time improving the code Edit [2018-10-24]: With the announced changes to Salvage- and MineAI it is to assume that it will take some time before they get integrated ino Carrier Commander Edit [2018-10-28]: Updated CC to 1.9.1 experimental: -- 1.9.1 experimental for 0.19.x [2018-10-28] - Dropped requirement for ShipScriptLoader. Instead I'm using vanilla /entity/init.lua - To properly work with alliance ships either overwriting claimalliance.lua or modifying shipfounder line 140 to use addScriptOnce is mandatory. See: readme/install instructions - Guardian gets its proper priority assigned now (Thanks to Hammelpilaw) - fighters will always prefer higher priority targets - with multiple same-priority targets fighters will prefer its current target, but only if it is 15km closer than the next closest target (effectively avoiding them to chase enemies to far off and getting into crossfire) - changed default priorities: fighter > ship > guardian > station Again: The install procedure has changed! with 1.9.1 and up. Follow the instructions in the readme file(s).

I'm also interested. There is a "ParentEntity"- Component (Enums -> ComponentType -> ParentEntity), but it's not surfaced to the LUA API. There is also the possibility of going through the ships of the same faction and search for that specific turret: function MyMod.onSomeoneFired(turretId) local turret = Entity(turretId) local parent local possibleParents = {getEntitiesByFaction(turret.factionIndex)} for _,p in pairs(possibleParents) do if (p.isShip or p.isStation) then local pTurrets = {p:getTurrets()} for _,t in pairs(pTurrets) do if t.index.number == turret.index.number then parent = p end end end if parent then print("parent found", parent.name) else print("no parent found, weird!") end end I didn't try the code but it should work ;D

This was vanilla related, but it's fixed now Update: 1.8.2 (0.18) - now using, in 0.18.3 introduced, createSavedDesignsSelection

You didn't follow the install instructions, no wonder bad things happen Go here: https://discord.gg/ZJYYxrZ . I might be able to still help you

update -- 1.8.5 for 0.18.x (beta) [2018-08-10] -- 1.7.5 for 0.17.1 (main) - fixed "stuck" looking UI with dock All Edit: If you are updating, make sure all fighters are docked.

You've observed that right! (and it affected miners and attackers as well) Update -- 1.8.4 for 0.18.x (beta) [2018-08-09] -- 1.7.4 for 0.17.1 (main) - switched from nearest old target to nearest of squad - dock-all now forcefully stops carrier-commands

CarrierCommander_xxx.zip/CarrierCommander/mods/CCBasicCommands/scripts/entity/ai/

This mod is currently not compatible with Carrier Command 1.7.x or 1.8.x There is a difference in can do and will do

wish granted: -- 1.8.3 for 0.18.x (beta) -- 1.7.3 for 0.17.1 (main) - added repair command - fixed typo in mine command - fixed a typo in readme.md - added readme.txt without the formatting characters of readme.md - removed uneccessary data-saving in salvage command

The 15s delay when starting a command comes from the way the timed calls in scripts are done in Avorion. In short every CarrierCommander command is its own script. Avorion offers a function called getUpdateInterval() to grab the timing when a Script's update() gets called. I programmed it to return 15(s), if currently there is no target (1-5(s) else). The target gets selected in update(). It's not called immediately after adding the script, but only after the time specified in getUpdateInterval(). And because update() hasn't run, no target has been selected, yet. And therefore getUpdateInterval() says to wait 15s. Edit: update -- 1.8.2 for 0.18.x (beta) -- 1.7.2 for 0.17.1 (main) - Removed the Assign All command (did nothing special anymore) - xsotan fighters target name fix - reduced time for attack fighters to switch targets, after their previous target died - Founding a ship as alliance ship, would break the mod. This was due to claimalliance.lua using namespace (no idea why it caused it though). I've included a namespace-less version for now

(A) stands for: Click this and the command Activates (D) stands for: Click this and the command Deactivates

Updated Changelog: -- 1.8.1 for 0.18.x (beta) -- 1.7.1 for 0.17.1 (main) - fixed a crash in aggressiveCommand.lua that could halt action on that ship - fixed attack-fighters switching targets - renamed aggressive to attack command - Auto Assign now properly sets button actions

There is currently a 15s delay before the command starts to get fighters off. Maybe that's what you've experienced?

There is no `return` icon. Only docking (orange/yellow) or idle (blue), active (green), something went wrong (red). I can't decipher the 4th sentence, please elaborate further. Q1: probably Q2: Yes this mod is useable with 1.7.1 (current default/main version) and beta 1.8.2. Avoid using Vanilla commands and CC on the same ship at the same time though

updated CC to Avorion 0.17.1 and 0.18.1(beta) Changelog -- 1.8.0 for 0.18.x (beta) - update from 1.7.0 to 0.18 -- 1.7.0 for 0.17.1 (main) - rewrote code base - moved from (buggy) Event-based system to Busy-waiting-based system - mining/salvaging/attacking are now their own addons that are hold within its own modfolder (If you still have an CC installation make sure to delete it before updating from 0.10.1) - changed license to QPL-1.0 Please note: There is a delay of ~20s after you activate a command until it starts operation. (It will show a blue "idle" icon beforehand though)

Making it compatible with the newest version of Avorion isn't the challange. The challange is to have it running without any unexpected behavior. And currently there a many things keeping me from releasing a satisfying update: reducing transmission overhead when a production cycle finishes. (Causes massive lags on multiplayer) prevent the complex from breaking, when the repair button gets used avoid data-loss, when the LUA-VM crashes. "That's a nice mutli-billion Credits complex you have there. It would be a shame, if it got voided by a VM crash ::)" integration of fighters (like casual factories do) have onRestoredFromDisk(timeSinceLastSimulation) simulate the time passed to name a few. There's a lot of utility and convenience stuff that I want to add as well. Edit: You have the permission to release a functioning fork of the complex mod, if you provide a link to the original forum thread (here: https://www.avorion.net/forum/index.php/topic,3268.msg17943.html#msg17943)

pretty easy: 1) You need the BlockPlan of the design you want to apply to your drone. 2) You need to get it to the serverside and execute the following code: Entity():setPlan(blockPlan) In a script running on your drone.

You wouldn't ...

make sure you are using 1.7.0, if you are on the main brancch. or 1.8.1, if you aree on the beta branch. If that doesn't help, send your logfile.