Howdy y’all, As the year comes closer to an end and the successful release of our latest DLC, we have had time to really dig in and start chipping away at all the feature requests that we have had internally and of course the holy grail of sweet sweet modder requests. As someone who got into Sins from the modding side of things its very rewarding to finally put some boots on the ground and start ticking off mod requests both small and large. Let me start off by saying that the content below is available in our opt-in build right now. Alright enough yapping let's get into the good stuff.
Traveling Beams
This was a big one for us. Having the beginning and end fade improved readability in large-scale fights, both aesthetically and for gameplay. Given a lot of our most popular mods all have those nice flowing beams, it became a good test bed.
These have been applied to both Vasari, and Advent beams in game via the opt-in build but for those interested in technical information ill list out the functions of how travelling beams work.
Core Control
UseLengthBasedFade Enable traveling phaser bolt effect with smooth fades - This is the main switch to enable the travelling beam behavior
Fade Distance Controls
BackFadeDistance - Length of the trailing fade (back end of the bolt)
FrontFadeDistance - Length of the leading fade (front end of the bolt)
Speed Multipliers
BoltTravelSpeedMultiplier - Speed multiplier for bolt travel. Higher = faster. Default is 1.0
FrontFadeSpeedMultiplier - Speed multiplier for front edge travel. Higher = faster. Default is 1.0
BackFadeSpeedMultiplier - Speed multiplier for back edge travel. Higher = faster. Default is 1.0
Timing Control
BackFadeDelay - Delay in seconds before back edge starts moving. Default is 0.0
Width Modulation
FrontWidthMultiplier - Width multiplier at front of beam. 1.0 = same width, 2.0 = twice as wide at front. Default is 1.0
BackWidthMultiplier - Width multiplier at back of beam. 1.0 = same width, 2.0 = twice as wide at back. Default is 1.0
Specific Launch/Land Hardpoints
This has been a desire of ours since early in development as the Sova was designed around having specific points to launch and land from. It was a relatively simple and straight forward task to work through. Now we like to keep our systems backwards compatible so traditional Hangar.0 array hardpoints are still completely useable if you wish to treat them agnostically. However we know and understand that not only our carriers but the carriers from multiple of our mods need that specific behavior of launching and landing from very specific hardpoints. So we set it up so you can some slightly different naming conventions and control they are such.
hangar_launch - Specific launch point for strikecraft launching
hangar_land - Specific land point for strikecraft landing
Both are arrays so you could technically however many you want.
I duplicated and renamed the Sova's Build point for corvettes to test. As demoed the fighters will launch from their expected location and land exactly at their designated land point. I'm sure you all noticed that the fighters clipped a section of the ship to make their way in. We are currently exploring ways of controlling flight behavior when returning to dock. However, its not to the point of demoing yet. Just know we are looking into the matter for instances like this where their return behavior isn't quite perfect.
Unit_Skin Mesh_Material Override
Now to the uninitiated that might sound like techno babble straight from the mouth of a lippy Starfleet engineer. However, it's one of the easiest and most powerful additions in the list of additions we have done. Before now if you wanted to change the materials on a mesh, you would have to make a duplicate mesh and then change its material reference. Inefficient and not very fun am I right? However, what we did was work in a unit_skin based override for the material file. So, you can still have the base reference to the materials in the mesh file and simply override with the use of the unit_skin file and change the materials on the fly with a unit_skin file. Ill include some technical examples for those interested in using said system.
Basic Override:
{ "material_index": 0, "material": "replacement_material.mesh_material" }
Just a note here to, lets say you have an asset with multiple materials and only want to edit one of the two mesh_materials you have. We got you covered, material_index is the material id for that mesh. You can change both, or just one. Lets say your ship has decals or registry numbers, it would be very inefficient to have duplicate models for all of them. Now you can simply duplicate a text file and take care of the rest. Very efficient.
Multiple Material Override:
{ "material_index": 0, "material": "replacement_material.mesh_material" }, { "material_index": 1, "material": "replacement_material.mesh_material_decals" }
Now here is the best part, lets say your mod has a faction that likes to take ships? After they take those ships they like to do stuff to it, who knows maybe just a fresh coat of paint. Wouldn’t it be nice to have conditions for how those ships are supposed to look when X faction takes them. Well hell yeah it would, and boy howdy do we have you covered.
Race-Specific Override:
{ "material_index": 1, "material": "default_fallback.mesh_material", "materials_by_owner_race": { "trader": "trader_material.mesh_material", "vasari": "vasari_material.mesh_material", "advent": "advent_material.mesh_material" } }
Now your ships can have factional ownership conditions for texture changes, I’m sure we will see some very exciting emergent behavior come out of this, and I look forward to the chaos. This system has only had its initial pass, if there are specific constraints y'all would interested in, please feel free to put them forward. I’m always open to adding constraints.
Mutually Exclusive Techs
Now, branching techs have been a big hot button topic since Sins 1, when the system was present but not utilized outside of mods. I decided to kick it up a notch and really give modders the ability to have fun with this. So, in Sin 1 branching tech was handled by a change in faction ID, without getting into the technical details it was essentially a name change that would lock out techs that required another name. It was also only usable once so the most you could switch was once limiting how much you could actually branch. With Sins 2 I personally made the system infinitely more flexible, instead by using a research modifier that allows 1 tech to lock out another. No faction ID change and no single branch limits.
Corresponding Mutually Exclusive Tech:
{ "version": 0, "domain": "military", "tier": "unlock_tier_1", "field": "advent_military", "field_coord": [0, 2], "research_time": 120.0, "price": { "credits": 500.0, "metal": 50.0, "crystal": 100.0 }, "name": "Energy Weapons Specialization", "description": "Specialize in energy weapon technology. Mutually exclusive with kinetic weapons.", "mutually_exclusive_research_subjects": [ "kinetic_weapons_specialization" ], "player_modifiers": { "weapon_modifiers": [ { "modifier_type": "weapon_damage", "value": 0.15, "tags": \["energy"] } ] } }
Apply the mutually_exclusive_research_subjects to both techs with each of their respective names and when you use one or another it will lock out its counterpart. Simple, repeatable, and flexible for those looking to create some fun, and interesting behavior from their tech trees. When you encounter a tech that has been locked out it will appear as such.
Tech Tree Pre - Req Expansion
Alright so mutually exclusive techs was just the beginning, after touching the system and familiarizing myself with the ins and outs of research I decided it to take a one step further. Allowing for a whole host of options for your tech tree needs. Here is the short list, Alliance, Owned Units, Owned Planets, Unit Items, Owned Structures, Reputation Level, Unity, and Phase Resonance Level.
Required Allied Player Race
"required_allied_player_race": "trader"
Requires alliance with a specific race
Required Owned Unit Types
"required_owned_unit_types": [ "advent_battle_capital_ship", "trader_heavy_cruiser" ]
Player must own at least one unit of ANY of these types to start research
Required Owned Planet Types
"required_owned_planet_types": [ "desert", "ice" ]
Player must own at least one planet of ANY of these types
Required Owned Unit Item Types
"required_owned_unit_item_types": [ "trader_trade_port", "advent_culture_center" ]
Player must own at least one unit item (planet component) of ANY of these types
Required Owned Structure Types
"required_owned_structure_types": [ "trader_starbase", "advent_titan_factory" ]
Player must own at least one structure unit of ANY of these types
Required NPC Reputation Level (line 82-92, 493-495)
"required_npc_reputation_level": { "npc_tag": "traders_guild", "reputation_level": 3 }
Player must have at least this reputation level with the specified NPC
Required Phase Resonance Track Level
"required_phase_resonance_track_level": { "track_type": "movement", "minimum_level": 5 }
Track Types: "movement", "combat", "economic"
Player must have at least this phase resonance track level
If any of you are curious about getting additions to this, please feel free to leave them in the modder request channel in our discord. I can’t promise to get to every single one of them, but they are within scope I’m more than willing to take a look.
AI Attack Type Target Groups Expansion
So this has been a request for a while because part of it controls AI behavior for how a ships AI behavior prioritizes targets. Completely decoupling the system from the code base and completely data driving it was well outside of scope and would have taken far to much time but we took the next best step and made the system a lot more flexible. We currently use 11 (At least until Echo gets his hands on the system) What we have done is add another 20 custom slots that are defined in our code base as user_defined_12 - user_defined_31. These are slots that allow you the end user/modder name them what ever you want. While using those user created names through out your unit files and have that work as if it has been decoupled. We took that 1 step further for those Total conversions you are welcome to name ANY of the AI attack target type names and have the game respect that. We have a fall back for that, and total conversion are completely able to use custom names for everything.
Built-in Types
strikecraft
corvette
light
flak
heavy
lrm
capital
titan
starbase
defense
user_defined_12 through user_defined_31 (20 custom slots)
Exotics Costing Exotics
Well this was a bit a niche one but relatively low hanging fruit, the request being of course to allow for exotics cost other exotics. Allowing for modders to create a tiered exotic system or a network of useful dependencies for resources. Well, now they can. This was pretty straight forward, just allows for exotics as a resource. ill also include an example of how to use it below.
"input_exotic_cost": [ { "exotic_type": "defense", "count": 1 }, { "exotic_type": "offense", "count": 1 }, { "exotic_type": "economic", "count": 1 }],
Its also been properly added to the UI so as to indicate there is a cost and refund via the tooltips.
Single Facility Multiple Exotic Creation
On popular community request was to allow a single exotic facility to produce multiple exotics simultaneously. This took a bit of work but wasn't terrible complicated and when it comes to descriptions its pretty straight forward not a lot to explain.
Right now, exotic production is pegged at 1 per facility. What I have done is allowed for expansion of how much you get per facility based on research. With the value of how much more you get completely defined research side to allow for custom amounts. Right now the default is still 1, if y'all ask nicely I see what I can do about allowing for user control of the beginning amount. It was a bit outside the original work to this system but happy to look again when a moment presents itself.
Modding Quality of Life Improvements
We have heard your impassioned pleas to make the modding interface through the game a bit more user friendly when it comes to knowing how far along your download is and at what stage of installation its at. Credit to Yarlen for working this out. He is the Mod.io wizard. Downloading mods will now have a speed and percentage to indicate how far along you are. Removing the mystery.
We are always looking for new ways to improve the membrane of interaction between the user and mod menu, so stay tuned for more.
Action Value Transform Type Expansion
Added seven new action_value_transform_type enums that enable buffs and abilities to scale dynamically based on current planet development track levels, creating deeper strategic gameplay where planet investment directly impacts unit effectiveness.
per_planet_current_defense_track_level
per_planet_current_logistics_track_level
per_planet_current_commerce_track_level
per_planet_current_mining_track_level
per_planet_current_research_track_level
per_planet_current_focus_track_level
per_planet_current_survey_track_level
Part 2 will bring info on:
Strikecraft Capacity Limits
Individual Selection of Carrier Fighter Construction
Asset Suppression
Particle Mesh Alpha Fade
Mesh Animation
There are a lot more things going on behind the scenes that isn’t at a state to show off yet or is being vigorously tested to ensure its works well with the game and the systems we have. As a modder, this last month has been very rewarding. Getting to help get so many of these systems in has been a reward of its own. As the title suggested I wanted to send this year out on a high note by helping the community that helped me get this job makes some really awesome stuff. Now I don’t want yall to think this is a one and done thing, I will be looking to tick 1-3 mod requests (depending on size and scope of course) every week or two. To continue the momentum we have picked up this last month.