Jump to content

Welcome to the Forum!

The best place to exchange builds and ideas! Vote for the best ideas and suggestions here.

Join the Avorion Discord!

Connect with other passionate players and talk about the latest news.
Discord

DLC Avorion Into the Rift Out Now!

Now available on Steam!
Steam

[MOD][Stations] Yet Another Mine 1.1


NerArth
 Share

Recommended Posts

Download:

1.1

Stable old version:

1.0b

 


 

Readme:

 

Yet Another Mine (YAM), created by NerArth

 

--Description

YAM for short, adds two new commands: "/yam <material>" and "/yamup"

 

The first command allows a player to convert any ship into a station that extracts building materials, i.e. Iron, Titanium, Naonite, Trinium, Xanion, Ogonite and Avorion.

 

The second command allows the player to upgrade a resource extractor to provide a larger amount per cycle. This is a linear increase of 900 per upgrade level, but the cost for each upgrade increases linearly as well.

 

The cost can be configured, the player can choose any of the resources he's found and mined to be extracted, regardless of location in space.

 

 

A config file is provided; you can change the timing, the amount that's given to the station owner, the cost of the station and whether players are notified of receiving resources. Although nobody else should need it, a debug luaout value is present.

 

By default, new station conversions cost 33 million credits, with an increasing cost per material tier and give 900 of a resource every 5 minutes. The idea is that you should build a couple of these and not have to think too much about them. You need to have at least 1 unit of the material you want the mine to extract, this is so you can't skip a material tier without first encountering it.

 

You can upgrade your extractors by using /yamup, with no additional arguments for the command. This will upgrade the extractor at a cost as defined in the config. The cost increases per upgrade level, to keep in-line with vanilla factory upgrade behaviour.

 

 

Files added by this mod:

\mods\YetAnotherMine\yamconfig.lua <- you can change config values here

\mods\YetAnotherMine\yamtransform.lua <- this script transforms ships into stations that will mine a resource

\mods\YetAnotherMine\yammine.lua <- this is the station script that manages the resource payouts

\data\scripts\commands\yam.lua <- this is the script that allows the command to exist and thus provides the entry point to the entire mod

\data\scripts\commands\yamup.lua <- this is the script that allows existing extractors to be upgraded

 

As you can see, none of these files replace default files.

 

 

I created this mod as an alternative for the MineCorp mod made by the forums user NexusNull because while I did try to fix a faulty version of that mod, a crash was occurring that I wasn't being able to solve; I personally didn't like the idea that vanilla code had to be modified, especially in the eventscheduler.lua, so I wanted to try and make something that would be compatible with any other mod and didn't change vanilla files. I did like the random nature of MineCorp mines appearing but I wanted something with more predictability too.

 

--Caveats and points;

* As mentioned above, this mod is 100% compatible with every other mod.

 

* You can receive resources even if you're in a different sector, but the sector with the mining station has to have been loaded and remain loaded. If a mining station is unloaded (i.e. through server shutdown or otherwise) the sector its in must be loaded before the station will produce materials. So for example in single-player you may wish to keep all your resource mining stations in the same sector so that you only need to visit once each time you load the game. This will be difficult for me to change.

 

* Note that about the above point, I made it so that you receive 1/10 of the resource on initial load of the station for 2 reasons; one, it's an instant bonus when you make the station, so it shouldn't be the full sum; two, if a player can exploit a way to unload and reload the station in a reliable manner, it means they won't get the full sum for no reason by means of exploit.

 

* The default costs and resource amounts I have provided in the config have been arbitrarily chosen, but based on the fact that most "function"-type stations cost at least 20million and that building resources are very important for expanding ships.

 

* The linearly increasing cost of the upgrades mean that at some point it will be more economic to create a new station instead of upgrading an existing one, but having a single highly upgraded station may prove more convenient and will be more performance-friendly.

 

* I have tried to leave relevant comments in the code because I can't predict how well I'll keep up with keeping the mod up-to-date and because someone might simply want to learn Lua and Avorion modding from a hands-on approach.

 

As an off-topic note, it took me a few hours over the timespan of around one week to get this mod working in a basic manner.

 

--Version history

1.1.180607

+Added new command yamup.lua for upgrading existing extractors. Usage is simply /yampup.

++New config value that determines the base upgrade cost, which gets multiplied by the material tier.

+Config variable has been made local but will still return itself so it can be used globally.

+Tweaked code more or less everywhere, where it seemed relevant. This is difficult to keep track of, so no list for this.

 

1.0b.180529

+Changed config.lua to yamconfig.lua to avoid generic conflicts. Take note of any values you've changed and delete the old config.lua if you are upgrading from a lower version.

++The above change was partly because of what forum user Laserzwei mentioned. I have not made more changes in this scope yet because I am not certain of how I should go about implementing namespace changes properly. In addition, in the main vanilla script I used as reference, resourcetrader.lua, only a single variable seemed to be declared under its own namespace? (.tax) While the rest were local. I still need to read up more on this topic.

+Made sure that the command will not go ahead unless you are actually in a ship; this means that you can't accidentally screw up an existing station, for example. You can still use /help yam even if not in an actual ship.

+Made sure that the help for the command has explicit info about the costs for each material. The way this gets done in code will get changed in the next version, as it's very messy.

+Made a correction to the description of the /yam command.

+Made the code comments a bit more user-friendly.

 

1.0a.180527

+Fixed a typo that broke the whole mod.

+You must now have at least 1 unit of a material before you're allowed to mine it, so you can't somehow skip over material tiers completely.

+Made base cost lower, down from 50 mill to 33 mill, but cost will increase from this value for each material tier. See the config for changing the multipliers.

 

1.0.180526;

+Finalised version 1.0 for initial release.

 

1.0.180521;

+Created the mod and its structure.

Link to comment
Share on other sites

1.1 has been released. Next versions will likely look at interface and usability changes, so that information about a given station is more readily available, such as its current upgrade level.

 

Screenshots are on the to-do list but there's not much to show with images.

 

Only keeping links for old versions that were stable or mostly bug-free.

 

Just spotted a small typo that breaks things, will upload a fixed version soon that will include changes to the costs and a check for owning the materials before being allowed to use them. Done.

 


 

Reserved post.

 

If you have feedback or find any issues just reply to this thread. I will only update the main post with the readme file, and this one with anything else.

Link to comment
Share on other sites

as english is not my native language, it's not clear to me what materials will be mined. iron/titanium/etc.? or are this mines just like the mines you can build on claimed asteroids?

does this mod have to be installed server-side to work in multiplayer games?

Link to comment
Share on other sites

as english is not my native language, it's not clear to me what materials will be mined. iron/titanium/etc.? or are this mines just like the mines you can build on claimed asteroids?

does this mod have to be installed server-side to work in multiplayer games?

 

Yes, sorry, perhaps I didn't make it clear enough in the readme but this mod is for letting you convert any ship into a station, and the station will "mine" Iron, Titanium, Naonite, Trinium, Xanion, Ogonite or Avorion. There is no progress bar; it's something I wanted to do, but I couldn't see a simple way of doing it, for now anyway. A ship is converted by using, for example;

 

/yam Trinium

 

And note that the material names are case-sensitive; Trinium will work but trinium will not work. You will simply get an error message if the material name doesn't match exactly.

 

As for server-side, I can't say because I don't have the capacity to test it like that and I'm not sure how everything works together, but it probably does need to be installed server-side because it adds scripts that have to be attached to the mining station when it is created via the command. Therefore, if the scripts don't exist on the server, they can't get attached, and nothing or very little would happen. Plus, I think commands need to be registered server-side anyway to even show up in-game for a client, but I might be mistaken.

Link to comment
Share on other sites

Meanwhile, I tried to use your mod whilst playing on a MP server - as expected, it doesn't work.

 

Another thing that came to my mind: maybe you should add having at least 999 of the desired resource as requirement for building it, just to stop people from creating Avorion mines in the starting zone (which is game breaking).

 

//edit: I just recognized that you already did the requirement thing today ... great minds think alike*

 

*this phrase is a translated output from http://dict.leo.org and I hope it means what I had in mind :)

Link to comment
Share on other sites

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")

Link to comment
Share on other sites

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")

 

Thanks for the suggestion, I'll be looking at this for 1.0b, I did consider this might be a potential issue but hadn't found a problem with it with other mods, so I wasn't sure if I needed to do something about it. I don't really know how namespaces work, is there any documentation about how to work with them that you can suggest?

Link to comment
Share on other sites

Thanks for the suggestion, I'll be looking at this for 1.0b, I did consider this might be a potential issue but hadn't found a problem with it with other mods, so I wasn't sure if I needed to do something about it. I don't really know how namespaces work, is there any documentation about how to work with them that you can suggest?

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)

Link to comment
Share on other sites

Thanks for the suggestion, I'll be looking at this for 1.0b, I did consider this might be a potential issue but hadn't found a problem with it with other mods, so I wasn't sure if I needed to do something about it. I don't really know how namespaces work, is there any documentation about how to work with them that you can suggest?

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)

 

Thanks for your reply, that seems to be quite a good explanation and I've been reading the Lua manual on namespaces as well in the mean time, so I will definitely make some changes for the next version.

Link to comment
Share on other sites

  • 2 weeks later...

Did you ever think of making the stations upgradeable, just like vanilla production stations.

 

I'm currently flooding one of the unused sectors in "my" galaxy with extractor stations *cough*

 

Yep, I did consider this and have been thinking about how I want to implement it, so it will probably be in the next version, because I also consider it preferable to have a smaller amount of them but with more "power". Are you using the default config settings by the way?

Link to comment
Share on other sites

BUG REPORT INCOMING !

 

 

what I did using YAM:

 

 

 

what meanwhile happened at the default spawning spot in that zone:

 

 

 

it seems that everytime I build a station, another copy is automatically built at the spawning spot.

what I did was:

1. exit into drone

2. fly to station spot

3. found ship (for proper station naming)

4. /yam

5. attach blueprint

6. hire crew

7. restart from step 1

 

Avorion game version: beta 0.16.7 r11165 as of today (2018-06-06)

Link to comment
Share on other sites

BUG REPORT INCOMING !

 

 

what I did using YAM:

 

 

 

what meanwhile happened at the default spawning spot in that zone:

 

 

 

it seems that everytime I build a station, another copy is automatically built at the spawning spot.

what I did was:

1. exit into drone

2. fly to station spot

3. found ship (for proper station naming)

4. /yam

5. attach blueprint

6. hire crew

7. restart from step 1

 

Avorion game version: beta 0.16.7 r11165 as of today (2018-06-06)

 

Thanks, I'm having a look at it. Nice stations by the way!

 

Edit: Could you also show me your player list of ships? There does exist a duplication thing even with the default vanilla station founders and these show up on the list although they don't physically exist, but disappear after a relog. So far, following your steps, I am unable to replicate exactly what you've got happening.

 

Are you on single-player? If yes, does leaving the galaxy and entering again do anything about this at all?

Link to comment
Share on other sites

I just found out something hopefully helpful about the bug I reported a few hours ago:

 

a new station is spawned everytime that I

* enter one of the existing stations

* found a new ship

* leave a ship/station to fly around with my drone

Link to comment
Share on other sites

I just found out something hopefully helpful about the bug I reported a few hours ago:

 

a new station is spawned everytime that I

* enter one of the existing stations

* found a new ship

* leave a ship/station to fly around with my drone

 

I can't replicate this behaviour at all, could you just give me a list of other mods you are running? It looks like you have a few other mods?

 

Also, please go into the yamconfig and set the luaout as = true instead of = false.

 

Then run the game again and make sure the problem happens and then close the game and go to pastebin.com and paste your client and server logs, and put a link to the logs here. Because I can't replicate the behaviour I need to see if there are any vanilla errors or mod execution errors.

 

 

Edit: Could you also show me your player list of ships? There does exist a duplication thing even with the default vanilla station founders and these show up on the list although they don't physically exist, but disappear after a relog. So far, following your steps, I am unable to replicate exactly what you've got happening.

 

Are you on single-player? If yes, does leaving the galaxy and entering again do anything about this at all?

 

Do try this and show me the list when you can, it might be helpful.

Link to comment
Share on other sites

Other mods: AutoResearch, CarrierCommander + Requirement ShipScriptLoader, Loot Collection for Carrier Command, MoveUI, Regenerative Asteroid Fields

 

luaout = true .... check

 

 

shiplist after I cleared the dupe-stations manually

shiplist after I founded a new ship named "x" - its not visible on the list, because it's a small letter and at last position ...

shiplist after leaving x into drone

shiplist after leaving x a second time

=> logout

client log (includes client log "after relog" (!)

server log so far

=> login

shiplist after relog

additional server log

 

 

I agree with you with that vanilla problem, as I already heard of it and also experienced it, but there must be something that stops the copies from being deleted ...

additional note: after at least one "copy" is spawned, the material output in chat changes from "900" to "90", but more often...

Link to comment
Share on other sites

Thanks, that's very helpful, especially the sequence. Just to make sure, the dupes are always called like Craft 0, Craft 1, Craft 2, etc? Or do the duplicates ever have the same names or similar to what you've actually named?

 

Your in-game clock has actually helped me notice something a bit odd;

 

2018-06-07 16-18-53| Restoring 1's craft Craft 0, type: 3
2018-06-07 16-19-56| Restoring 1's craft Craft 1, type: 3
2018-06-07 16-20-08| Restoring 1's craft Craft 2, type: 3

 

These 3 entries are very close to the times after creating X, and then leaving X into drone the first and second time. And they do repeat themselves at other points, usually they are followed by some of my YAM output like:

 

2018-06-07 16-19-56|   0
2018-06-07 16-19-56| YAM mine entity init, vars defined, station name:  Craft 1
2018-06-07 16-19-56| station values  5  Xanion
2018-06-07 16-19-56| Removing transform script just in case it exists...
2018-06-07 16-19-56| in1,2:  nil  nil
2018-06-07 16-19-56| Setting loaded values.
2018-06-07 16-19-56| Loaded values:  Xanion  5
2018-06-07 16-19-56| index  5  value  Xanion
2018-06-07 16-19-56| yammine Update interval is defined and has previously been set to 300 and resource amount set to 900

 

This collection of log output by YAM indicates that a mine has been initialised, which is probably from one of the duplicate stations, presumably "Craft 1" in this case. Furthermore I know that this specific collection of output indicates that it was a station that was being loaded and not one that was created by the /yam command. To clarify, did you use the /yam command with the craft called "x"? I ask because I understood that you did but don't see any reference to the command being called.

 

In any case, these "2018-06-07 16-20-08| Restoring 1's craft Craft 2, type: 3" outputs aren't from my mod and I've had done a search through the lua files of all the ones you've listed and I can't find the exact source of this log print (I don't think it's a vanilla print, as I haven't seen it before and there's a lot of CarrierCommander log prints around it), so I suspect this is related to CarrierCommander, but I may be mistaken.

 

My suggestion at this point is to make a backup of your galaxy, your scripts, and your mod settings; then disable or remove carrier commander and anything that depends on it, if you can, and repeat your steps and see if it still happens. I've looked through all the logs you gave me and couldn't identify any other recurring patterns, please let me know if you spotted something that I missed that you think may be related.

 

In the future I'm also going to add some more print information about the source of which ship is outputting the YAM stuff to the lua console so that when reading through logs I'll be able to pinpoint better which ship did what.

 

I know this is very long but it seems like we've actually found something a bit complicated. :P

 

Edit: And the code that appears after the YAM output:

2018-06-07 16-18-54| yammine Update interval is defined and has previously been set to 300 and resource amount set to 900
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0
2018-06-07 16-18-54| Flyable Created  1  0  0  0

 

I know that this is CarrierCommander and the first 1 is referring to a station, and it does happen at the exact same timestamp as the YAM output. To me, it seems odd because it all seems to be happening in a pattern and coincides, but I don't know exactly how CC works and I don't really want to bother the author unless we can be sure that the problem isn't something from YAM, though I'm not finding a cause inside YAM and I can't reproduce your bug.

Link to comment
Share on other sites

@NerArth

the duplicates are always named Craft, Craft 1, ....

I did not use the /yam command with "x", at least not in that sequence. a few days ago I accidentally /yam'ed my drone. could that be the crux of the matter ?

 

@Laserzwei

I'm not sure about that. it possibly happened ...

 

 

 

gonna do the galaxy copy & uninstall other mods thing this evening

Link to comment
Share on other sites

@NerArth

the duplicates are always named Craft, Craft 1, ....

I did not use the /yam command with "x", at least not in that sequence. a few days ago I accidentally /yam'ed my drone. could that be the crux of the matter ?

 

@Laserzwei

I'm not sure about that. it possibly happened ...

 

 

 

gonna do the galaxy copy & uninstall other mods thing this evening

 

Ok, thank you for the clarifications. Using YAM on the drone shouldn't have caused the issue, as I tested this and didn't observe duplication, but this shouldn't be possible anymore anyway since 1.0b so I guess that was while you were still on 1.0a?

Link to comment
Share on other sites

correct. I noticed the 1.0b update just as I reported my bug.

 

 

uninstalled CarrierCommand&LootCommand ... bug still present ...

uninstalled ShipScriptLoader (which was my personal main suspect) ... bug still present ...

uninstalled MoveUI ... bug still present ...

uninstalled RegenerativeAsteroidFields ... bug still present ...

only YAM left

uninstalled YAM ... BUG STILL PRESENT ! ... client log - server log 1 - server log 2 pt 1 - server log 2 pt 2

 

I guess we've got to call koonschi or another dev

 

(or we simply leave it as it is now... I tried to reproduce the bug with 1.0b running, with all the other mods, in a "creative" galaxy, and the bug did not show up. maybe it has something to do with laserzwei's hint, or maybe with the use-the-drone-thing - both is no more possible since 1.0b.)

 

Link to comment
Share on other sites

Ok, thanks for the detailed investigation and hopefully it won't happen again in the future. Let me know if it happens again under a new circumstance.

 

I will be releasing 1.1 today by the way. It adds the upgrade feature via a command, /yamup.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...