Laserzwei

You updated from oosp <0.99_5 right? You need to fully reinstall the mod: 1) replace /data/scripts/server/server.lua with the VANILLA file 2) delete /mods/oosp/* 3) continue with the standard installation I updated the installation guide accordingly

I don't know what you did, but you did something very very wrong: In 0.90c, in the function "synchTradingLists", the function " invokeClientFunction" is NOT called. Hence the shown error can not occur. Furthermore line 195 is literally just "end". This can't throw the shown error either.

Highly likely you installed the mod wrong/ with an incompatible other mod. See if /data/scripts/server/server.lua has the following line: player:addScriptOnce("mods/mos/scripts/player/asteroidMover.lua") Also check your logfiles (%Appdata%/Avorion/) When you talk about "faction" I assume you meant Alliance? I tested the behavior in 0.15.8 and as expected I could mave asteroids across sectors in both Alliance-owned and Player ships. Make sure you are close enough to your asteroids (<15km default).

updated for 0.15.8 (0.99_5) - removed oosp not installed detection - removed oosp for all consumers - reworked code for resourcetraders update - removed playerscript handling the (Un-)Loading event - removed the timesystem for accurate out-of-sector calculations - removed oosProdLib since it's not required anymore - remove shipyard oosp update; now here

I'm using (for salvaging): Sector():getEntitiesByType(EntityType.Wreckage) and local resources = wreckage:getMineableResources() if resources ~= nil and resources > 5 then ... I'm using resources > 5, specifically to avoid fighters going after small bits on purpose. Because fighters tend to miss those pieces and try and fail to salvage them, while the big chunks slowly despawn.

commenting out some of the lines in /mods/oosp/scripts/player/oosproduction.lua 257 onward: if (oospConfig.includeFactories and station:hasScript("factory.lua")) then --normal factory if (station:hasScript("turretfactory.lua")) then --factory is a substring of turretfactory, but a turretfactory doesn't produce anything else countF = countF + 1 --calculateOOSProductionForFactory(station, timestamp) end end if (oospConfig.includeConsumers and station:hasScript("consumer.lua")) then --biotope, casino, equip.dock, habitat, militaryoutpost, repairdock, researchstation, resistance outpost, scrapyard, shipyard-trading --consumption(station, timestamp) end if (oospConfig.includeTradingPosts and station:hasScript("planetarytradingpost.lua")) then --calculateOOSProductionForTradingPost(station, timestamp, "scripts/entity/merchants/planetarytradingpost.lua") end if (oospConfig.includeTradingPosts and station:hasScript("tradingpost.lua")) then -- calculateOOSProductionForTradingPost(station, timestamp, "scripts/entity/merchants/tradingpost.lua") end if (oospConfig.includeResourceDepots and station:hasScript("resourcetrader.lua")) then calculateOOSProductionForResourcetrader(station, timestamp) end if (oospConfig.includeShipyards and station:hasScript("shipyard.lua")) then --shipyard-ships debugPrint(3, "update shipyard: "..station.name) calculateOOSProductionForShipyard(station,timestamp) end

I've seen the patch notes, worked through the changes and most of the oosp-mod is implemented in Vanilla (0.15.8+) now. 3 things are missing: 1) update for enqueued ships in a shipyard (if you have a ship that takes 2h and leave the sector for ingame-days, you will still end up having to wait those 2 hours[except if you own other property in that sector]) 2) OOSP currently (<0.15.7) has resource-trader refilling included, vanilla has nothing alike 3) Player stations don't get proper trade events while they are unloaded (Goods are exchanged, but no money)

It's not implemented yet

Are NPC stations loaded?- No, so this mod still has its purpose. There is a config option: config.includePlayerProperty = false Default false; it will ignore all sectors with player property in it. It has a slight disadvantage: When the server allows less loaded sectors/player than they utilize, then some sectors won't get updated (by neither oosp, nor vanilla) Sadly there is no better way to indicate loaded player-sectors than looking for playerproperty. Not at all.

The Dev usually refuses to utilize code provided by the community. Ever wondered why a small box for naming your Mine pops up, when you try to convert an asteroid? It's Dev's version of circumventing a bugfix. The thing is: 1) The window can be clicked away. 2) 1 Line of code would fix the underlaying bug, we (Me & Dirtyredz) told him, but instead of a fix we got that little pop-up. Back to the Gas-Collector: I remember that the fix included here took an unexpected long time to create. The (vanilla-)code was more complicated than is required. In itself th fix wasn't much code though (<10 lines). Edit: Added an updated version for 0.15, including 1) The fix for "The production line you chose doesn't exist.", when selecting a Gas Collector 2) All Factories are now orderd by their name stationfounder.zip

Here is a German video:

This mod was written for 0.14 and is not updated for 0.15. You observed correct that stations like Shipyards/Equip.-Docks are now part of vanilla gameplay! However, there is still a bug, when selecting factories that produce (partially) the same Good (Gas Collectors). It can sometimes tell you that the selected production does not exist even though, it should have. This mod included (past, because its not updated) a fix for it - Vanilla does not!

That really messes up the complex management! Don't do it. Think before you build. You can always attach blocks to an complex. But don't delete the root block or one of the 5x5x5 red Trinium Armor Blocks. (You can delete an armor block, but that will remove the one single factory associated with it. Avoid deleting your rootblock.) Also keep in mind there is a wiki: wiki and it says what to do when an complex gets damaged.

I still had the install instructions for 0.9_91 in the guide. (oosp_0.99_2d.zip is the current version) I've updated the installation guide on the frontpage accordingly. please do a clean reinstallation of the game. Follow the guide afterwards.

I don't have the time to look over it today, but be assured I will have a deeper look at it :)

Sure thing I fixed it on the github page already: oosp You can't know, but you posted some code I've gone through over 100 times. I know it premise, its actions and its pitfalls: It doesn't scale. Remember oosp has to retro-activly calculate past actions. In other words: Everything that could have happen since the last visit has to be calculated within a single gameTick. Now let's see what happens on a less populated server, when a sector has not been visited for 11,5 Days (1Million Seconds) -That is actually a pretty short timeframe! - . TradingManager:useUpBoughtGoods(timeStep) gets called every 5 seconds and on every 6th time it has a 50% chance to consume 1-6 goods. So let's assume we are clever and only use the code after if self.useTimeCounter > 5 then And set timeStep = 30. That reduces the number of calls from 200,000 to 33,333 calls for every factory and habitat and Tradingpost and shipyard and ... . But it's still too f***ing slow. So I took an approach from stochastics and looked how often every good would get it's 50% chance and accumulate it. You can have a look at the old system in oosProductionMod_0.9_91.zip(it's still downloadable on the main page-but for 0.14). where I implemented that exact behaviour. And it sucked big time: It was slow, unreliable and worst of all: If you have goods with small Volume (e.g. Processors) you end up with processor-stocks of 20,000 Units, while everything else is empty. The new system treats every good equally as it looks at the total stock and removes a percentage of it depending on the time that passed. Where config.generationTime is the time after which a full stock is expected to be empty and config.generationTimeVariation is a variaton of that timeframe so you end up with an interval of [config.generationTimeVariation*(1-config.generationTimeVariation), config.generationTimeVariation* (1+config.generationTimeVariation) ] (default +-10%). It is predictable, it's fast, it's easy to understand and easy to mainain. If you really want the vanilla behaviour in oosp, then you have to write code that implements it and is as fast, understandable and maintainable as mine and add pull request for it on github.

Frontpage of the wiki: wiki

For slower good generation in /mods/oosp/config/oosp.lua set config.consumptionTime = 604000 config.generationTime =604000 Could work, I wouldn't try ;)

- reserved

-- 1.10.1 for 0.20.x [2018-12-18] - Fighters will now attack stations again. oopsie - The threshold config slider got its original look back -- 1.9.2b for 0.19.x [2018-12-18] - Fighters will now attack stations again. oopsie

CarrierCommander This mod allows you to automate your fighters in mining, salvaging, attacking enemies and repairing your ships. How to start Click on the fightericon top right and this UI opens up: Click on one of the Buttons to start a command. Click on Dock All to stop all commands and return all Fighters back into your Carrier. Installation instructions 1) Copy the directory `mods` contained in the CarrierCommander .zip file into the game directory `Avorion` 2) additionally place the contents of `data` in /Avorion/data/ From Avorion 0.23 on, this mod will be continued in the workshop Commander (background manager): (https://steamcommunity.com/sharedfiles/filedetails/?id=1741735681) Commands package: (https://steamcommunity.com/sharedfiles/filedetails/?id=1741744976) Since 0.23+ became the main gameversion, there is no download here. Visit the Wiki for more in depth information!

Thank you for updating Hammelpilaw! I reduced the amount of mines by a factor of 100, to make them a special event for a player to find. I choose this, because you can upgrade them now and don't have to fear competition (on multiplayer). (config.probabilityPerAsteroidField = 0.1 -> config.probabilityPerAsteroidField = 0.001) If you want to see if the mod works then I recommend going to /Avorion/mods/Minecorp/config/config.lua, set config.probabilityPerAsteroidField = 1 and start a NEW world (you should see around 10 Mines in your start sector), if not come back with server logs Don't forget to set the settings back!

Make sure to download v. 0.90c. You can only start from build stations, not Mines. And only those build after installation. If your problem still persists, send me your client and server log

If I saw it correctly, the sector background is bound to the sector Seed. The planets however are moddable. Some reference code: \data\scripts\sectorspecifics.lua SectorSpecifics:generatePlanets() SectorSpecifics.generatePlanet(planets, random) SectorSpecifics.generateMoon(random) SectorSpecifics.generateBlackHole(random) SectorSpecifics.getPlanetPosition(random, size) \data\scripts\entity\merchants\planetarytradingpost.lua PlanetaryTradingPost.generatePlanetGoods(planet) \data\scripts\entity\story\wormholeguardian.lua WormholeGuardian.createChannelBeam() code to get you the planets of a secot package.path = package.path .. ";data/scripts/?.lua" local SectorSpecifics = require ("sectorspecifics") local specs = SectorSpecifics(x, y, Server().seed) local planets = {specs:generatePlanets()} API: Planet enum PlanetType PlanetSpecifics

this belongs to the bug section then