Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Important 0.6 Modding Changes

Discussion in 'Modding' started by Deepflame, Nov 14, 2017.

Thread Status:
Not open for further replies.
This last post in this thread was made more than 31 days old.
  1. Deepflame ME Director Staff

    Messages:
    382
    Hello Modding Engineers!

    With 0.6 drawing closer, it is time we give you guys a heads-up about some of our changes! We cannot yet give you the full list, as some of our changes rely on as-of-yet unrevealed features, however after we release the update we will append this list with the additional information.

    Mod Compatibility
    First and foremost, all mods from 0.4 and older will no longer load. Before 0.5 the new format was not fully integrated yet, so for 0.5 we were still able to load the older mods. From 0.6 onwards, mods more than 1 major revision old will simply not load due to the fact that we no longer support the old definition format.

    Definition Format
    The biggest change to definitions is that we are dropping the old style of formatting. This means we will no longer have definitions nested into tags like <Cubeblocks>. From 0.6 onwards, each definition must use the new definition format. We introduced the new format in 0.5, and we obsoleted the old one, in 0.6 we will remove support.

    The old format looked like this:
    Code:
    <CubeBlocks>
       <Definition>
    	 <Id>
    	   <TypeId>CubeBlock</TypeId>
    	   <SubtypeId>StoneCube</SubtypeId>
    	 </Id>
    	 ...
       </Definition>
    </CubeBlocks>
    
    The new format looks like this:
    Code:
    <Definition xsi:type="MyObjectBuilder_CubeBlockDefinition">
    	<Id Type="CubeBlock" Subtype="CubeStone" />
    	…
    </Definition>
    
    All definitions available in 0.5 already support the new format, with the exception of particles and transparent materials. In 0.6 all of the definitions use the new format. Please be aware that currently there are a few files from us in the game that use the old format, these are there for backwards compatibility with 0.4. Do not use these as an example.

    Transparent Materials
    The transparent materials have had a few tweaks, but mostly they now support the new definition format. We will now explain the settings for the transparent materials so that you guys know how it works and what to expect.

    First, the main settings to care about when trying to make a transparent material such as glass:
    • Color is a multiplier of your texture's color, so if you set it to 0,0,0,0 it gets multiplied to 0 for all values, creating a perfectly transparent panel. If you set it to 1, 1, 1, 1, the result will be exactly your texture.
    • ColorAdd is added on top of whatever is computed by Color.
    • ShadowMultiplier is how much shadows affect the result. It interpolates the computed shadow value from 1 to shadow value.
    • Reflectivity is the basic reflectivity value.
    • Fresnel is added to the Reflectivity value, where a Fresnel value of 0 disables it, and a higher Fresnel value makes the effect stronger. The effect for Fresnel is essentially making it so that when you look straight at a glass panel it will not reflect anything, but if you look at an angle there will be reflections.
    Now it will get a little mathematical as we explain what the values combine to.
    • (Texture * Color * shadow value) + ColorAdd + (ComputedReflectedImage * (Reflectivity + Fresnel))
    Using this formula you should be able to understand how the values work together, but if all else fails:
    • Color generally shouldn’t be be 0,0,0,0. (Default value is 1,1,1,1)
    • ColorAdd is usually 0,0,0,0 unless you are making coloured glass and want to use the same texture. (Default value is 0,0,0,0)
    • ShadowMultiplier is usually 0,0,0,1. (Default value is 0,0,0,1)
    • Reflectivity ranges from 0 to 1, where 0 is no reflection and 1 is a perfect mirror. (Default value is 0.6)
    • Fresnel value shouldn't be lower than 0, 0 disables Fresnel effect, any higher value makes the effect stronger (Default value is 1)
    Please be aware that ShadowMultiplier only works when CanBeAffectedByOtherLights is set to true, and it will permit glass to have a colour (or none) in the dark.

    Particle Format
    The particle effects have a new format too. It is pretty similar to the old format, but the old particle format will no longer load. So for those of you who made custom particle effects, you will have to wait until after we release 0.6 to see what is new.

    One of the main changes we are introducing is support for GPU particles. You have seen them in Space Engineers, and we will have these now as well.

    Texture Format
    Another change, first introduced by Space Engineers, that comes with the updates to the rendering pipeline is that textures should now use BC7 compression. There are tools that are freely available to create BC7 textures, should your software not support it.

    Here is one such tool, including how to use it:
    Texconv: https://github.com/Microsoft/DirectXTex/wiki/Texconv
    Code:
    General usage for making BC7 texture:
    texconv -f BC7_UNORM_SRGB -if TRIANGLE_DITHER_DIFFUSION -sepalpha texture_cm.png
    ((*** try just BC7_UNORM for NG, might make difference for overbrightness ***))
     
    General usage for converting to BC3 (and for adding mipmaps):
    texconv -m 10 -f BC3_UNORM texture_cm.png
    
    Subtype Changes
    We also finally cleaned up all the subtype IDs of many of our items and blocks. For a very, very long time their names had been created ad-hoc without any conventions, consistency, or structure to the names so we created an internal guideline for subtype ID naming, and then renamed all our objects to this format.

    This means that you will have to update your crafting recipe definitions and CubeBlock components to match the new subtype IDs. The naming convention as well as the full list of changes can be found here:
    https://docs.google.com/spreadsheets/d/1wTPmciLOkh1QxJZER_L2vy3fVdvj3OZLme_POEd8dnY/edit#gid=0


    In order to keep this thread clean from discussion so it remains useful as a reference manual, I created a discussion thread here:
    https://forums.keenswh.com/threads/0-6-modding-changes-discussion-thread.7398244/

    Tim
     
    Last edited: Nov 22, 2017
  2. Deepflame ME Director Staff

    Messages:
    382
    As the hype-train continues, I shall continue updating the modding changes!

    Research System
    As announced today, we have radically altered the way research is performed, this provided a lot more interesting gameplay and content, and the good news is, the system is highly moddable, without any programming required!

    First, we now have research tree and research node definitions. These define how the research is unlocked. The way we reasoned about it is that each research tree represents a “specialization”, which provides some variation to gameplay each play through. Plus, it will make it easier to identify who is working on what in a multiplayer game.

    Then, each research tree is made up of research nodes, and each research node specifies which nodes are their parents as well as which research definition they unlock and which research quest they start.

    The way we structured the research is in Data/Research/Treename where each research node has its own file containing the research node definition, the research quest, the research definition, and any additional related elements. Once we release the update, you can take a look at our research to figure out how it works!

    Quest Upgrade
    Originally we planned to make these changes for 0.5, but very early on we realized that to do it properly we would have to make sweeping changes to 0.5 which would make it a difficult transition point in the middle of it all. So we kept the quest changes for 0.6. But here they finally are!

    The old quest session component no longer exists, quest progression is now managed by the Quest Entity Component that is present on each player character. The quest format has been redesigned from the ground up based on our experiences, needs and plans. The old quests are now no longer supported.

    For examples, browse through Data/Quests and Data/Research to look at all our quests. You will see that the format is quite different, but it shouldn’t be too hard to understand from all our quests there.

    Finally, for the programmers amongst you, it is quite easy to introduce custom quest conditions and actions.

    For more information regarding creating custom quests, or customized conditions and actions, look at our wiki article here: http://www.medievalengineerswiki.com/index.php?title=Official_Content/Research_Quests
     
    • Like Like x 2
  3. Deepflame ME Director Staff

    Messages:
    382
    As promised, we are now releasing the next set of changes to 0.6 that will be interesting for you all. There are a couple of really cool new things in 0.6 that we’re sure you guys will love!

    Definition Inheritance/Appending
    One of the coolest changes to our definitions is that it is now possible to append to any definition, or copy from another definition and then only change what you want to change. Through this mechanism you can finally append your new blocks to the existing research, or very quickly create common definitions that are shared by several other definitions.

    For examples of this, you can look at the Data/Research folder and its contents, and observe that the schematic items and crafting recipe definitions for them inherit from a base definition that is defined in unsorted.sbc.

    Another example can be found in Data/Characters and how they use this mechanic to define deer, barbarians and player characters in increasingly deeper definition trees.

    Crafting Changes
    With the introduction of the mechanical blocks we had to make some changes to the crafting component. Since the mechanical blocks are autonomous, and controlled by the toolhead inserted into their toolhead inventory, they needed a specialized crafting component that did not need a queue. So we split the old Crafting Component into pieces, and added two new components, CraftingComponentQueued and AutonomousCraftingComponent.

    The CraftingComponentQueued is identical to the old crafting component, and you should be able to just change your definitions to simply add the word Queued, and everything will work again.

    The AutonomousCraftingComponent is completely new, and it only applies to mechanical blocks. It will require mechanical power to function, as well as a toolhead item to describe what it can craft.

    Additionally, crafting items in Creative Mode now requires resources similar to in Survival mode. This was changed because in Creative Mode, if you just want the item, you can search for it in the new G-Screen and then double-click it to the inventory. This way it is easier to see if the crafting recipes are working as they should be, both for developers and modders alike.

    Finally, we are now changing to a different way we use the crafting categories. Previously, they were a many to many set but this ended up being very confusing, especially with the mechanical blocks, where we wanted toolheads to mostly produce only one or two crafting recipes per toolhead. So we have created one crafting category for each distinct crafting station, and we assign to the crafting recipes where they can be crafted.

    New Search Screen
    The new Search Screen comes with a new interface for searching as well, custom advanced search filters. These are triggered by the first character in a search, for example = only returns cube blocks and allows you to filter to either large or small. @ allows you to search for anything added by mods, # searches by tags, $ by categories, etc. Finally, we removed block positions. This system was very cumbersome to work with and we felt it was no longer necessary for the new screen.

    Audio Modding
    An issue long existent in our game, we finally fixed it properly. It is now possible to add your own audio files to the game and create the appropriate audio definitions, etc. We have made very little changes to the audio format, other than clean-up of some old Space Engineers specific tags and it is no longer necessary to make a <Waves> </Waves> group to add samples.

    For now, we still support the <Waves> </Waves> group, but in 0.7 this may go away.

    Code Changes
    There have been plenty of changes to the code, more than I can enumerate in any thread. But most of them should be relatively easy to adjust to. Amongst them, Vector3D, a double precision variant of Vector3, no longer implicitly casts down to Vector3. Now, in accordance with the C# standards, in order to get a Vector3 out of a Vector3D you will have to explicitly cast it. Secondly, IMyEntity has been removed. Since you have direct access to MyEntity it is no longer necessary to exist, and it was only polluting the codebase. We got rid of it and replaced all calls with appropriate types. A lot of IMy.. interfaces have gone away, since you have access to the main classes, this should not be a problem.

    Known issue:
    You cannot get all blocks in a grid currently, MySlimBlock is not whitelisted yet. We're working on fixing this.

    Removal of MyCharacter
    Last but not least, in 0.6 the MyCharacter class no longer exists. Each character is now a collection of entity components. The result is that player characters and AI characters no longer have to share a full set of functionality. Especially the AI are now significantly less heavy on the game, as they no longer support all the players’ features.

    Since characters are now MyEntity objects, it’s no longer as obvious to identify an entity as a player controlled character. Luckily, there are many ways to identify an entity as a character available to you.

    First, the most optimal situation is that you look for the player character because you wish to interact with them in some meaningful way. Like modifying health, interacting with their inventory, or starting a quest. In these situations, the easiest way is to simply retrieve the appropriate entity component and check for its existence. And then use this entity component to perform your interaction. For example:
    MyCharacterStatComponent statComponent = entity.Components.Get<MyCharacterStatComponent>();
    if (statComponent != null)
    statComponent.DoDamage(10, true);

    Second, another solution is to retrieve the controlling identity. Each player character has a controlling identity connected to it. To get this information you simply call Sandbox.Game.Players.MyPlayers.Static.GetControllingPlayer(entity) and check if the result is not null. Then you have player information, such as their name, available to you.

    Finally, if you do not wish to interact with the entity at all, and you really just want to know if it’s a character or not, you can simply poll the entity’s tag and see if they are tagged as a character, it looks like this:
    bool isCharacter = entity.Definition.Tags.Contains(MyCharacterExtensions.CharacterTag);

    These are all the major changes in 0.6. For questions, the modding forum is available to you, as well as Medieval Engineers’ #modding channel on Discord.

    We’re looking forward to see what you guys come up with next!
     
    Last edited: Nov 22, 2017
    • Like Like x 2
Thread Status:
Not open for further replies.
This last post in this thread was made more than 31 days old.