The goal of MagicLib is to create an Open Source, community-driven “library” of useful (and well documented) scripts and plugins that can be leveraged and contributed to by every modder.
If anyone wants to contribute you are more than welcome to do so as it is intended to be a community tool. Do check the Wiki to get a lot of details on the current content.
The magicSettings functions allow modders to easily access a shared data/config/modSettings.json file that can be used as a unified solution to integrate mods with each-others. I will try to provide a thorough blank modSettings.json sample file with each MagicLib update, so modders that will use the shared modSettings.json file and want their mod’s settings to be added to MagicLib’s sample file can post them in this thread. Modders can also document their inter-mod compatibility requirements, regardless of their usage of modSettings or not, on this wiki page.
If you want to integrate your mod to all the ones using the shared modSettings.json solution, you can download a blank sample file here.
Current content:
Functions
MagicSettings
Offers classes to load merged settings and lists from a shared modSettings.json file. Intended to make cross-mod integration and compatibility much easier to manage.
MagicBounty framework
Offers a highly customizable yet easy to implement system to add unique story-driven bounties to a board present in bars.
MagicCampaign
Offers classes to help enrich systems with recoverable hulks holding special cargo, or with stations with custom comm officers, etc.
MagicIndustryItemWrangler
Allows AI colonies to upgrade their installed industry items if a better one is sold to them.
MagicIncompatibleHullmod
A uniform solution for the “incompatible hullmod” issue with vanilla hullmods.
MagicInterference
Adds a cross-mod mechanic to balance very powerful weapons.
MagicAnim
A collection of functions to make smooth animations.
MagicFakeBeam
Creates convincing punctual beams from arbitrary coordinates.
MagicLensFlare
Creates “cinematic” lens flares.
MagicRender
Draw arbitrary sprites on-screen with constraints to entities/camera when needed. (aka “SpriteRenderManager”)
MagicTargeting
Allows “smart” target selection for systems and missiles within distance and search cone parameters, plus it can use ship-class preferences.
MagicTrails
Allows to create missile-style trails anywhere, from ships to bullets, with a lot of customization options. Also includes a CSV based manager that should be able to handle most projectile use cases with negligible overhead.
MagicUI
Draws UI elements such as a system-like charge-bar/tick box next to the normal ship-system for special systems, or an extra status bar above the flux/hull bars.
Loose scripts
Scripts that can be used “as it is” or can be copied to individual mods to personalize the result.
MagicVectorThruster
Manages vectoring or vernier-style attitude thrusters.
MagicMissileAI
A very customizable and lightweight missile AI script usable without any java knowledge.
MagicGuidedProjectileScript
A weapon script that allows regular projectiles to track their target.
Planned / considered content:
MagicRotary
A loose script to make rotary weapons animations with smooth spin up and down.
Wyvern (MagicIndustryItemWrangler)
Wisp, Schaf-Unschaf and Rubi (MagicBounty)
Dark.Revenant (MagicUI)
Deathfly (MagicFakeBeam)
Originem (bugfixes and a lot of optimization work)
jtyotJOTJIPAEFVJ (MagicAnim.cycle)
Kitta Khan (bugfixes)
Nicke (MagicTrails, MagicGuidedProjectileScript)
Snrasha (MagicUI)
Tartiflette
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Any derivative work must also comply with Starsector’s EULA
Why again do we need ANOTHER library? I’d rather not see SS turned into a version of minecraft with every mod having their own required library. This stuff could have been easily put into Graphics Lib…
*Agree with you*
Why again do we need ANOTHER library? I’d rather not see SS turned into a version of minecraft with every mod having their own required library. This stuff could have been easily put into Graphics Lib…
Because we have already several mods using stuf like direct sprite rendering or fake beams (including all of my owns) and incompatibility/versioning issues are already not uncomon. For example, for months all my mods had their visual effects removed due to another mod using an outdated version of the same plugin that overrode mine, leading to a waste of ressources because several instances of the same plugin with different names had to be run at the same time to avoid conflicts. Also this provides a whole bunch of methods that could improve new and existing mods.
And while some of this stuff could have been added to GraphicLib, a whole lot has no place in there. But be reassured: the intent is for this to be a community library, meaning that a-priori if it pickup no other library will ever be necessary. (Plus come on! That’s just one thing to tick in your launcher for a lot of benefits on the modding side)
Is that a bad thing?
I have a suggestion that,if you could provide a method that register the mod at the beginning of game, if there is no mod needs it, turn off all its plugins to prevent the possible waste of memory.
The two plugins currently present start with a check to see if something is using them or not, skipping them if that’s not the case. They shouldn’t have any performance impact if not used.
Why again do we need ANOTHER library? I’d rather not see SS turned into a version of minecraft with every mod having their own required library. This stuff could have been easily put into Graphics Lib…
Because we have already several mods using stuf like direct sprite rendering or fake beams (including all of my owns) and incompatibility/versioning issues are already not uncomon. For example, for months all my mods had their visual effects removed due to another mod using an outdated version of the same plugin that overrode mine, leading to a waste of ressources because several instances of the same plugin with different names had to be run at the same time to avoid conflicts. Also this provides a whole bunch of methods that could improve new and existing mods.
And while some of this stuff could have been added to GraphicLib, a whole lot has no place in there. But be reassured: the intent is for this to be a community library, meaning that a-priori if it pickup no other library will ever be necessary. (Plus come on! That’s just one thing to tick in your launcher for a lot of benefits on the modding side)
Is that a bad thing?
When you put it that way, no it’s not a bad thing, considering the benefits of having a -lib which other modders can contribute to.
This wouldn’t come close to being some sort of Minecraft, mind. If it did, we’d be somewhere near square 1. This lib will, as stated, make it easier on others in the long run if successful.
Download available in the OP.