Laserzwei

Said window is not within the scope of the current modding capabilities.

The bottom-right panel always shows the current target. That behaviour is vanilla and not exposed with an API and thus can't be modified.

It was a necessary counter to Avorions auto-naming (you can see that when the ship is still under construction)

Carrier Command is technically not compatible with either 0.17 and 0.18 since in both multiplayer-crashes appear. Also in 0.18 some Avorion-events aren't reliable and thus break the mod. All of these work with 0.17 and 0.18 All Production Chains move Asteroids I updated this one for beta 0.18 and 0.17 advanced shipyard Edit: this should be sticky

updated for beta 0.18 Changelog - 1.8.0 (0.18) - removed the ghost queue (No more enqueing when all parallel slots are taken) - increased parallel slots to 6 (is now a config option) - sanitized the way ordered custom ships get transferred to the customer - added an indicator on custom ships to show their build progress

Ich hab mal probiert deinen "Satz" zu verstehen, indem ich deine Grammatikfehler entferne. Das hat bis zur Hälfte des "Satzes" funktioniert. Danach gab es leider nur noch eine zufällige Hintereinanderreihung von Worten ohne Kontext. Bitte denke daran, dass wir deine Gedanken nicht lesen können und wir deshalb auf eine präzise Verschriftlichung angewiesen sind. Nur so können wir dir helfen! P.S. Die Forumssprache ist Englisch! So you want to do something with the ship-info-panel at the bottom right corner, once you target your own ship?

Edit2: removed attachement to avoid confusion This was an intermediate solution Not in vanilla. It only works for other AI ships. However: I made some changes to the vanilla files, so you can use the mine and salvage command with your own ships. It is attached to this post and works with 0.17 and beta 0.18 Edit: Don't expect too much of it. It has all the flaws the vanilla targetting and viability has. And automated fighting isn't included either...

Edit: This was written before I've updated CC Hence the statements here are outdated! Players and Aliiances are (behing the scenes) just extended Factions. The fighters started from a ship will always be of the same faction as the ship. It doesn't matter, if a player is flying it. Regarding the crashes: These happened already in 0.16, but I still haven't found out why exactly. On top of that Avorion's event system is not reliable anymore (and Carrier Command is literally build on it): Sometimes registered events don't fire, which causes CC to not continue with its current task. This will e.g. show as fighters assigned to mine circle around the mothership despite there being asteroids left to mine. When CC was published the Vanilla ship-commands did not work with fighters and would just let the ship do all the work. But the devs included fighter support. So currently I recommend using the Vanilla tools at hand which have improved ever since.

why did you add the unneccessary brackets "(( ))" in the getName() function?

make sure to check both client- and serverlogfiles for any errors. Since even singleplayer has a build in server. Client: %Appdata%/Roaming/Avorion/clientlog<timestamp>.txt Server: %Appdata%/Roaming/Avorion/galaxies/<YourGalaxyName>/serverlog<timestamp>.txt The functions will be called on client and server side each. And since Entity():addScript/Once() is not avaiable on the clientside, there will be something about it in the clientlog. The solution is to surround the statement with if onSever() then --code end That however is not the error you are looking for.

You don't need "do" in front of your additions. I also recommend using Entity():addScriptOnce("lib/entitydbg.lua") Because having multiple instances of said script has no advantages.

@Kampfkrapfn Is it possible that you converted a ship with the same name as an already build station?

This is a bug in the loot-plugin. From having a glance at the code, I would say that it happens when the script runs on a ship without an Hangar? How common is said error (in the log)?

This is what I was referring to in my first answer (just a little more extreme ;)) With the way cargo-fighters can (not !) be configured currently and under the premise of a realistic delivery service, I also would recommend to keep it at 1 unit of freight per Shuttle If you drop the premise of a realistic delivery service, you could exploit Entity():setValue() to do what you want

You are obviously in the wrong thread

Your Mod has several problems regarding this part: The script buys 1 good from a station, but puts 2 into the cargoshuttle. Basically cheating half the goods in. If the cargo shuttle is supposed to carry goods with a goodsize > 2.5 (Ammunition L, Drill, Drone, ...)m then only one will be loaded and only one can be sold, but two get removed from the cargo bay. If only 1 piece of cargo is available at the station where it gets grabbed, still 2 will be put into the shuttle anyway. Maybe more, that I've either overlooked or are implicated by these

The config thing is LUA, as it will look for any file named config.lua in its package.path scope. And all Namespaced scripts in that Context (e.g. Entity(), Player(), ...) share the package path as well as everything globally declared. So if another mod uses the same code, you might end with the wrong config loaded. You can see all global declarations with _G (which is a list and part of LUA). You will notice that any Namespace of all scripts running in that Context, have their own sublists: e.g.: _G.YetAnotherMine. Non - Namespaced scripts run in their own LUA-VM. Namespaced scripts on let's say the same Entity (,same Sector, etc...) share the same VM and thus lessen resource load. For variables either use "local var = x" or "Namespace.var = x" (in your case: Namespace = YetAnotherMine)

Currently (1.0/1.0a) you use: config = require("config") If any other mod loads a config named "config.lua", only one will be loaded and you can't be sure which one it is. Also as you use Namespaces, every globally declared Variable will be directly accessable and might be overwritten/overwriting something important elsewhere. I would suggest naming your config "yam.lua", maybe place it in its own folder /mods/YetAnotherMine/config/ and make the variable part of your Namespace: YamMine.config = require("mods.YetAnotherMine.config.yam")

Since this is a) still not fixed and b) is also mentioned in this reddit post, I decided to publish the complete fixed file here. (The file is for beta 0.17 , but should work with stable 0.16) stationfounder.zip

A reminder that this hasn't been fixed yet Plus a test script test.zip

Updated for 0.17.x --0.97b for 0.17.1 - EntityDescripters are only used as deep-copy, to prevent unwanted invalidation. Can now jump multiple asteroids at a time again

Thank you very much for providing the extensive bug report ! Notice that "WD End" means that the function returned successful, hence the crash is not (directly) related to it. This is intersting in that I haven't thought about both scripts working on the same Entity at the same time. Could be a hunch You could start by replacing these files on the server side: CarrierCommander_U1.zip just overwrite both scripts (salvageCommand.lua and mineCommand.lua) with the ones provided here and see if it helped. (It most likely won't though) If the crashes continue, you can write me a pm (on the left, the speech bubble below the post counter) with your server details etc.

Soweit ich weiss gibt's da nichts auf einem solchen Niveau. Was es gibt ist die API (im Installationsverzeichnis /Documentation/), das offizielle wiki: https://avorion.gamepedia.com/Script , und dann die ingame Scripte (in /data/scripts/). (As far as I'm aware there are no such tutorials. There is however the Documentation (in your install directory /Documentation/), the official wiki and the ingame scripts (in /data/scripts)) Du kannst mir auch jederzeit Fragen (in deutsch) per pm schicken ;) Was hast du so für Ideen? (You can ask me questions (in german) anytime via pm ;) What extensions do you have planned?)

updated CC to 0.10.1 special thanks to SnowDrakE for helping me to pinpoint causes of notorious server crashes! changelog: -- 0.10.1 for 0.16 - fixed server crashes related to Entity():waitUntilAsyncWorkFinished() [contact me asap, if any other crashes occur] - civil ships will now only be targeted, if configured to do so - added new onJump() and onSectorEntered() events - removed onSectorChanged() event - removed silent uninstall for old (0.14) CC commands

From testing with somebody else from the community, I came to the same suspicion, but he didn't provide the last logs/run the last tests. So I couldn't pin it down. Good job narrowing it down !