768
edits
Changes
Jump to navigation
Jump to search
Line 192:
Line 192: − + − '''THIS SECTION IS NOT UPDATED TO ALPHA 11 YET!'''+ − Features are defined in the Feature tag of Software types. Optinally a base.xml file can be placed in the "SoftwareTypes" folder with feature definitions, which will then be added to all software. If the root tag of the base.xml file contains the attribute Override = "TRUE", it will remove any base features already defined, this would remove the built-in QA feature for example.+ − + − − {|class="wikitable" − |From − |Use this attribute to specify which other feature this feature supersedes. You can create a tree in this fashion where the features are mutually exclusive. An example could be how 24-bit audio supersedes 8-bit. All dependent features are also backwards compatible in this way. If you select 24-bit audio, all features depending on 8-bit will still work. − |- − |Forced − |Whether this feature is selected by default, the player won't be able to un-tick it, unless it is superseded by another feature. Each piece of software should have at least one forced feature, which will define a lower limit for development time. − |- − |Vital − |Whether this feature is seen as vital in the market. If a feature is vital, software which does not have it implemented upon release will be considered lower quality by consumers, e.g. the 3D feature for operating systems is vital, since you wouldn't expect an operating system to not have it after it has been invented and used. − |- − |Research − |This marks a feature as patentable, its royalty percent will be based around its vital status and development time compared to other researchable features in the same software type. The research attribute should specify which feature this features is part of. Researchable features must have an unlock date and other features in the same software type can not depend on it. − |} − − ==== Tags ==== Line 252:
Line 236: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
→Software types
}
}
=== Features ===
=== SpecFeatures ===
SpecFeatures or Specialization Features are features that map to a specialization (3D, 2D, Audio, etc.), which employees can specialize in. You can only have 1 SpecFeature per specialization, but you don’t need to have one for each specialization. You can make up your own specializations and the game will add them automatically.
SpecFeatures are the foundation that smaller features ([[Modding#SubFeatures|SubFeatures]]) build on. All features have a level which determines employee education requirements. SpecFeatures are level 0, meaning everyone can work on them, but they are not as effective as level 1 or 2 features for satisfying the submarkets.
==== Attributes ====
==== Values ====
{|class="wikitable"
{|class="wikitable"
|Optional tag that limits the feature to a certain software category of its parent software type. You need to specificy an unlock year here, which will override the other unlock tag. You can set the unlock year to 0 to not have an unlock date. You can add multiple of these tags per feature.
|Optional tag that limits the feature to a certain software category of its parent software type. You need to specificy an unlock year here, which will override the other unlock tag. You can set the unlock year to 0 to not have an unlock date. You can add multiple of these tags per feature.
|}
|}
=== SubFeatures ===
SubFeature are addons to the main SpecFeatures, they fit in the same specialization as the SpecFeature they belong to, but they satisfy submarkets more effectively, meaning they need less devtime to add more satisfaction.
=== Level 3 features ===
Level 3 features do not satisfy submarkets at all, but they have custom scripts attached that change how the game works in some way. Scripting works using a programming language developed specifically for Software Inc.
You add scripts to features by adding a Script record, which consists of Script_ and then the name of entry point where you want your script to be executed, and then your script. Each entry point has a different scope, which determines which variables you can interact with. These entry points currently exist:
{|class="wikitable"
|Entry point
|Description
|Scope
|-
|Script_EndOfDay
|Executes after the market has finished simulating every day after the product is released
|ProductScope
|-
|Script_AfterSales
|Executes right after a products sales units have been calculated
|SaleScope
|-
|Script_OnRelease
|Executes when the product has been created, before it is actually registered in the market
|ProductScope
|-
|Script_NewCopies
|Executes when new physical copies have been shipped for a product (i.e. not sold yet)
|CopyScope
|-
|Script_WorkItemChange
|Executed whenever a task has been created or stopped, that is related to the product
|DevScope
|-
|}
To figure out which variables you have access to, you can use the '''LIST_SCOPE_MEMBERS''' console command with the name of the scope you want to check out, e.g. '''LIST_SCOPE_MEMBERS CopyScope'''. Note that you can use dot notation to drill down into a scope, e.g. '''LIST_SCOPE_MEMBERS CopyScope.Product'''.
You can either write your scripts directly in your [[TyD|TyD]] file as such:
Script_EndOfDay "if (Product.GetCashflow(false).Last()>100) {Product.DevCompany.MakeTransaction(-Product.GetCashflow(false).Last()*0.1, Bills);}#Pay 10% of income if income is more than $100"
Or you can put your script in separate files and refer to them relative to your mod root folder, by starting with a forward slash:
Script_EndOfDay "/Scripts/MyScript.txt"
=== Software categories ===
=== Software categories ===