Laserzwei
-
Posts
399 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Events
Posts posted by Laserzwei
-
-
could not execute function 'synchTradingLists' in '"mods/complexMod/scripts/entity/merchants/complexFactory.lua"':
invalid argument 'nil' at stack position 1, expected 'Player'
stack traceback:
in function invokeClientFunction
data/scripts/lib/complextradingmanager.lua:195: in function ?
Setting state to invalid.
Tried with asteroid stations.
Tried with normal stations.
Checked crew,power,production,storage and did not modify any blocks or delete any blocks.
Dragged and dropped mod into data and mods folders. Avorion/data Avorion/Mods
Version 0.90c
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.
-
just went to new sector found another one, claimed it paid for moving, planned jump, and jumped.
i could not find the asteroid in destination sector so i went back, and it was still there
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/)
Found a bug to squish... If you claim an asteroid and move it while in a faction it creates a dud non claimable asteroid when you go to check it... The workaround is to change the faction status of the asteroid before moving it and then changing back to faction status once moved..
BTW I consider this mod as an essential part of Avorion and hope the devs implement it.
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 curious if there is a way to get the fighters to salvage all parts of wrecks and not just the parts that drop mine-able resources? I get really annoyed seeing all those bits of ships everywhere and my OCD gets triggered playing clean up crew. Another mod that changed the default "Salvage" command from captained ships (The original script is using "getEntitiesByComponent(ComponentType.MineableMaterial)" to find wreckages. This kind of wreckages are not listed there. I've modified this line into "getEntitiesByType(EntityType.Wreckage)") Is this somethingCarrierCommander could possibly implement or is that the method it already uses?
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 -
Hey. Have you read the most recent Beta patch notes? What parts of this mod are still missing from vanilla? At this point? Is it "safe" to run this mod together with the new Beta patch? Will there be duplicated/buggy behaviour?
Basically: should I not install this when running Beta 0.15.8?
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)
-
Thanks for the awesome mod! Quick question, Is there any way to request traders or change price margin like in the default game?
Thanks,
Bob
It's not implemented yet
-
With the current version of Avorion having "keep-alive" enabled on Sectors while the player is not inside them, is this mod still required to have Out-Of-Sector production?
Are NPC stations loaded?- No, so this mod still has its purpose.
Is production exempt from the "keep-alive" functionality(?)
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.
(...) is OOSP now functionality that is incorporated into the base game itself?
Not at all.
-
Ah, cool! You wouldn't happen to know how hard it would be to make that bugfix compatible with 0.15? Sounds like a good one to have. (Or maybe we should just wait until the bugfix gets integrated into the core code, if someone's already done some of the work for the devs to do so. :P )
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
-
Is there a youtube video featuring this mod? This mods seems to a good one. WOuld like to see someone set up a station with this...
Here is a German video:
-
It looks like the functionality added by this mod is now in the base game, correct? Either that, or another mod I have installed is also adding the previously missing stations (like Shipyard, Equipment Dock, etc.).
While I have this mod installed, the only item in the list when clicking "Found Station" is the Crystal Farm, and clicking Transform does nothing.
If I comment out the pcall in stationfounder.lua, effectively deactivating this mod, then all the Stations appear on the UI (and also the icons have changed).
My only question is: could this be because of another mod I have installed, or has this functionality been added to the base game? Is this mod broken?
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!
-
@Sinistrem Yo, I had that problem earlier in Laserzwei's mod and we had hashed it out together discovering that deleting the root block of the ship once it became a station (which translates to deleting the root block of the station itself) is what messes up the way the complex manager recognises the station.
That really messes up the complex management! Don't do it. Think before you build.
So long as you don't delete the root block of the station you can essentially have cube's (Station root blocks) attached to poles (complex station links) as your complex with cargo bays and whatever you want slapped on.
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:
and it says what to do when an complex gets damaged.
-
Question I have installed this mod correctly I believe... but I am receiving this error that is pretty confusing...
any help would be great?
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 :)
-
Hi, your mod is great, thanks for your work.
Found a bug: Trading Post uses "oospConfig.consumptionTime" for both soldGoods and boughtGoods. So basically config variable "generationTime" doesn't affect anything. Version 0.99_2d
Sure thing I fixed it on the github page already: oosp
Is there any chance for a version, that will use current "TradingManager:useUpBoughtGoods" algorithm?
function TradingManager:useUpBoughtGoods(timeStep) if not self.useUpGoodsEnabled then return end self.useTimeCounter = self.useTimeCounter + timeStep if self.useTimeCounter > 5 then self.useTimeCounter = 0 if math.random () < 0.5 then local amount = math.random(1, 6) local good = self.boughtGoods[math.random(1, #self.boughtGoods)] if good ~= nil then self:decreaseGoods(good.name, amount) end end end end
So, basically, this uses 1 to 6 of a 1 random good(that station buys) every 5 seconds with 50% chance.
Why I think that this algorithm is better that current one? Because current one doesn't really care about how many goods can fit in the station. If "config.consumptionTime = 86400" it will eat all goods from Shipyard or Upgrade station regardless of its size in 1 day.
I'm currently in stating sector and I already see that Shipyard has almost 6 times more goods than an Upgrade station and ingame algorithm will use all goods from Upgrade station in 20 hours and from Shipyard in 6 days.
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.
-
Building/Changing the design of the complex can remove functionality.
I now have a very large, very pretty warehouse.
It can no longer make anything.
RIP my billion credits.
Frontpage of the wiki:
-
Hey.
Really like the mod! It makes trading/building your own stations soo much better.
One thing, imo Trading Posts generate goods too fast by default - I'm filthy stinking rich yo.
OOSP needs to be incorporated into the vanilla game imo. Thanks for everything!
For slower good generation in /mods/oosp/config/oosp.lua set
config.consumptionTime = 604000 config.generationTime =604000
Can this be installed serverside only? Or does client need as well?
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
-- 1.10.0 for 0.20.x [2018-12-04]
- now uses vanilla "callable"
-- 1.9.2 for 0.19.x [2018-11-06]
- added Slider to control re-targeting threshold distance (You don't know what that could be? Look in the Wiki!)
- now runs on stations again
- fixed some typos, added some more descriptions
- readme shrinked down to the basic install instructions (advanced Install instructions? Right in the Wiki!)
-- 1.9.1 experimental for 0.19.x [2018-10-28]
- Dropped requirement for ShipScriptLoader. Instead using vanilla /entity/init.lua
- To properly work with alliance ships either overwriting claimalliance.lua or modifying shipdounder 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
-- 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
-- 1.8.5 for 0.18.x and 0.19.x [2018-08-10]
- fixed "stuck" looking UI with dock All
-- 1.7.5 for 0.17.1 (main)[2018-08-10]
- fixed "stuck" looking UI with dock All
-- 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
-- 1.8.3 for 0.18.x (beta) [2018-08-06]
-- 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
-- 1.8.2for 0.18.x (beta) [2018-08-04]
-- 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
-- 1.8.1for 0.18.x (beta) [2018-08-02]
-- 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
-- 1.8.0 for 0.18.x (beta) [2018-07-27]
- 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
-- 0.10.1 for 0.16 [2018-04-05]
- fixed server crashes related to Entity():waitUntilAsyncWorkFinished()
- 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 (only required, when coming from old saves)
--0.10.0 for 0.16 [2018-02-23]
- added GreatWhiteKong's/Cwhizard's Nearest-Neighbor-targeting implementation, which can be turned on in the ingame-config menu
- Salvagers now actively look for new wreckages, hopefully being more reliant in player-less sectors, by Hammelpilaw
- Xsotan fighters should now be properly targeted
- The no Hangar message will now appear, as intented
--0.9.0 for 0.15
initial release
-
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.
With extended configuration options:
And helpful feedback:
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!
-
Updated the mod to work with Avorion 0.15.7. The notifications for receiving material on the right side of the screen are deactivated, but of course you still get material. I do not guarantie anything, this mod may get outdated in future updates.
If you want to overtake this project please contact Laserzwei, we are still looking for someone to keep this alive.
Thank you for updating Hammelpilaw!
So ich habe mir von ihm 1.5b gedownloadet und entpackt und dann, denn 1.5.1 darein entpackt. Nun finde ich garkeine Minen .....
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!
-
Cannot get this mod to work since one of the recent updates, just not getting the option to manage complex to get started. Have tried re-installing everything to no avail
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
[MOD] [OOSP]out of sector Production
in Mods
Posted
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