Dev Journal: A Very Merry Modder Holiday Pt. 2

[p]We’re back with Part 2 on this long winded breakdown of some modder-friendly features, these are coming soon. Let's dive in:[/p][p][/p][h2]Asset Suppression \[Coming in v1.5][/h2][p]In Sins 1 there used to be a setting to turn off asserts. Mods that like to do whacky stuff ride the line of what the game can do, and thus often run afoul of asserts, even if they’re functionally harmless. With this in mind, we don't want people to turn off asserts for a mod and then go back to stock and get upset when they run into an issue or crash; and the assert doesn't show up to explain what might be the issue. So we massaged the system a bit and created a standalone file that can be included with mods that will suppress asserts as long as that mod is enabled. It’s the best of both worlds; I'll include the example below so you can see how it works.[/p][p] [/p][p][/p][p][/p][p]A simple file with a single entry, it will force asserts off, and when deactivated it will return to the normal behavior. Now for mods, we may consider adding some small entries to this in a future for specific things, but as of now it’s just for asserts.[/p][p][/p][p][/p][p][/p][h2]Strikecraft Capacity Limits[/h2][p]Now if you're a modder and want to make sure every element of your total conversion is as canon as possible, what's one easy way to do that? That's right, forced scarcity. Particularly in this case with strikecraft. This mod request was a fairly straightforward one, if albeit a bit of a pain. (My first time poking around in strikecraft systems.) However, it yielded fruit, that I can now share with you all.[/p][p][/p][p]What this does is allow for is a ‘kind’-based restriction of types of strikecraft. This system is completely optional but allows you to manually restrict the quantities of each on a per ship basis. This allows you that extra level of control when it comes making that perfect, as close as it can be 99.99%, canon mod.[/p][p][/p][h2]Individual Selection of Carrier Fighter Construction[/h2][p]Now one of the biggest holdbacks of the ‘kind’ system for unit construction and construction field propagation is the fact that when you tell a carrier to build a “kind” you're saying ‘build every fighter or bomber’ a faction has. This is a bit restrictive because you can exclude anything. It's hard to make that perfectly canon loadout when you have your hands tied like that; that's why we found a workaround that respects the way things are done currently (for save game compatibility) and a nice little optional override should you want more choice. It works by giving the user a field to override what strikecraft a carrier/hangar can build. Here is how it works:[/p][p][/p][p]Method 1: Strikecraft Kinds (Default)[/p][p][c]"carrier": { "base_max_squadron_capacity": 2, "strikecraft_kinds": \[ "interceptor", "bomber" ] }[/c][/p][p]When using this method, a carrier/hangar's build field with be propagated with these ‘kinds,’ meaning it will automatically place any fighters or bombers registered with that faction.[/p][p] [/p][p]Method 2: Specific Strikecraft Units (Override)[/p][p][c]"carrier": { "base_max_squadron_capacity": 0, "strikecraft_kinds": \[ "interceptor", "bomber" ], "specific_strikecraft_units": \[ "trader_interceptor_strikecraft", "trader_bomber_strikecraft", "vasari_interceptor_strikecraft", "vasari_bomber_strikecraft" ] }[/c][/p][p]This alternate method can be used standalone or in conjunction with the ‘kind’ system. It allows for exact physical overrides of what a carrier/hangar can build. Now the modder can make 10 different types of fighter/bomber/etc. and not have to worry about them showing up on every single screen that builds strikecraft. It can be tailored to your needs.[/p][p] [/p][p] [/p][h2]Particle Mesh Alpha Fade[/h2][p]This one may seem unusual to those who aren’t familiar with what it is, but it's actually very useful in a small handful of niche scenarios. Enough so that it became a bit of a popular modder request. Essentially what this is, is the ability to have variable time-based transparency for particle meshes. A relatively simple thing, it was just a matter of creating enough connective tissue between systems to make it happen. Along with sufficient Solar Forge controls to allow for you to be able to edit and visualize it easily.[/p][previewyoutube][/previewyoutube][p]This one doesn't require a lot of technical data, there are simply 2 simple fields for fade in and fade out. Enter your time in seconds and the system will take care of the rest.[/p][p] [/p][h2]Mesh Animation[/h2][p]I want to preface this is not a full skeleton-bone animation system. This was my biggest endeavor during this last month and it was a critical one. One of the biggest problems with any kind of animation since the Sins 1 days was that it had to be done via the particle system. That was clunky, never quite looked right, and in Sins 2 it straight up doesn't exist with the outline shader. So using it was always a bit of a trade off. You get the motion, but lose out on it being an actual physical model.[/p][p]That is now a bit of a solved problem; we are still double and triple checking it to make sure there are no knock on effects from its use, especially in online or multiplayer games. (Desyncs can be a real pain.) However, we are in a spot to demo it and show you all what that can look like when it finally makes its way into game. Before we get into the super cool videos, let's go over some technical bits so you’re familiar with how the system works. This is a pretty big expansion of the component system (for those unfamiliar with the terminology, the unit items that spawn onto ships - particularly titans or starbases - are components). They are separate meshes that are attached to the ship or structure under certain conditions. Now you can do more than just attach them.[/p][previewyoutube][/previewyoutube][p]This is a demo of [c]in_phase_jump_or_charging[/c]. The Sova pods have all been setup as components. The movement of the pods is completely aesthetic outside of the control you have for restricting fighter launch until the action finishes. As it approaches the edge of the well, the Sova’s engines will begin charging and the flight pods will drop down - just as they do in the intro cinematic. Our ultimate end goal.[/p][p]Here is basic list of the current constraints:[/p][p] [/p][p][c]"child_meshes": \[     {         "mesh_alias_name": "component_flight_pod_0",         "mesh_point": "child.component_flight_pod_0",         "is_weapon_effects_destination": true,         "will_transition_positions": true,         "state_constraint": "in_phase_jump_or_charging",         "default_state_index": 0,         "transition_time": 1.5,         "transition_delay": 1.2,         "position_states": \[         {             "state_name": "pitched_up",             "position_offset": \[0.0, 0.0, 0.0],             "rotation_offset": \[1.0, 0.0, 0.0, 0.0, 0.766044, -0.642788, 0.0, 0.642788, 0.766044]         },         {             "state_name": "folded_down",             "position_offset": \[0.0, 0.0, 0.0],             "rotation_offset": \[1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0]         }]     },[/c][/p][p]Here is a demo of how that would look practically applied. The naming of the states is largely up to the user for this constraint; both state names can be named whatever you want, and the [c]default_state_index[/c] will determine which one is the ship's default. In this instance, default position is 0, which is up and when the constraint is triggered the pods will move to their next position at the defined interval. There are also transition delays for when things need to be staggered. We also included functionality to delay the launch of fighters until the transition completes.[/p][p] [/p][p][c]"block_launch_when_child_meshes_transitioning": true,[/c][/p][p][/p][previewyoutube][/previewyoutube][p]Here is a demo of [c]on_unit_construction_complete[/c]. I reused some doors from elsewhere on the Sova, set them both up as components and when the construction hits 98%, they open. Here is what it looks like expressed in JSON.[/p][p] [/p][p] [/p][p][c]{         "mesh_alias_name": "component_bay_door_0",         "mesh_point": "child.component_bay_door_0",         "is_weapon_effects_destination": true,         "will_transition_positions": true,         "state_constraint": "on_unit_construction_complete",         "default_state_index": 0,         "transition_time": 1.0,         "transition_delay": 0.0,         "construction_progress_threshold": 0.98,         "position_states": \[         {             "state_name": "closed",             "position_offset": \[0.0, 0.0, 0.0],             "rotation_offset": \[1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0]         },         {             "state_name": "open",             "position_offset": \[18.0, 0.0, -10.0],             "rotation_offset": \[0.866025, 0.0, -0.5, 0.0, 1.0, 0.0, 0.5, 0.0, 0.866025]         }]     },     {         "mesh_alias_name": "component_bay_door_1",         "mesh_point": "child.component_bay_door_1",         "is_weapon_effects_destination": true,         "will_transition_positions": true,         "state_constraint": "on_unit_construction_complete",         "default_state_index": 0,         "transition_time": 1.0,         "transition_delay": 0.0,         "construction_progress_threshold": 0.98,         "position_states": \[         {             "state_name": "closed",             "position_offset": \[0.0, 0.0, 0.0],             "rotation_offset": \[1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0]         },         {             "state_name": "open",             "position_offset": \[-18.0, 0.0, -10.0],             "rotation_offset": \[0.866025, 0.0, 0.5, 0.0, 1.0, 0.0, -0.5, 0.0, 0.866025]         }]     }][/c][/p][p]There are controls for how long the transition takes: its time, delay and construction threshold. Again, the state names are completely up to the user.[/p][previewyoutube][/previewyoutube][p]Here is a demo of [c]ability_recoil[/c], tested on the Dunov by animating the side gun as it shoots.[/p][p] [/p][p] [/p][p][c]{         "mesh_alias_name": "component_side_cannon",         "mesh_point": "child.component_side_cannon",         "is_weapon_effects_destination": true,         "will_transition_positions": true,         "state_constraint": "ability_recoil",         "default_state_index": 0,         "transition_time": 0.15,         "transition_delay": 0.0,         "position_states": \[         {             "state_name": "rest",             "position_offset": \[0.0, 0.0, 0.0],             "rotation_offset": \[1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0]         },         {             "state_name": "recoil",             "position_offset": \[0.0, 0.0, -15.0],             "rotation_offset": \[1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0]         }]     },[/c][/p][p]It's a fairly straightforward approach. Users have control over the state name and the transition between states.[/p][previewyoutube][/previewyoutube][p]This is a demo of [c]is_unit_factory_idle[/c] and [c]is_unit_factory_building[/c]. When not constructing anything, the objects will sit at one position; when construction starts, it will move to its next position before starting construction.[/p][p] [/p][p][c]{         "mesh_alias_name": "component_scaffold_0",         "mesh_point": "child.component_scaffold_0",         "is_weapon_effects_destination": true,         "will_transition_positions": true,         "default_state_index": 0,         "transition_time": 0.5,         "transition_delay": 0.0,         "position_states": \[         {             "state_name": "is_unit_factory_idle",             "position_offset": \[0.0, 0.0, -1030.0],             "rotation_offset": \[1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0]         },         {             "state_name": "is_unit_factory_building",[/c][/p]