Difference between revisions of "Modding"

From Software Inc.
Jump to navigation Jump to search
 
(122 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
Modding in Software Inc. is completely data driven. Software Inc. loads XML files found in the "Mods" folder of the root of the game when it launches.
+
Mods in Software Inc. can be defined in simple text-based files or using C# and compiling code for the game to load. You can add new software types, furniture, translations and room textures using only the [[TyD|TyD]] file format.  
−
 
 
−
A mod should be placed in its own folder in the "Mods" folder and can optionally contain each of the following folders: "[[Modding#Companies|Companies]]", "[[Modding#Company types|CompanyTypes]]", "[[Modding#Events|Events]]", "[[Modding#Name generators|NameGenerators]]", "[[Modding#Scenarios|Scenarios]]" and "[[Modding#Software types|SoftwareTypes]]".
 
−
 
 
−
The root of your mod can additionally include a Personalities.xml file to add new [[Modding#Personalities|personalities]] to the game.
 
  
 
== Debugging console ==
 
== Debugging console ==
−
The debugging console can be enabled by using the "-debugconsole" launch parameter.
+
You'll need the in-game console to properly test your mods and check if everything is working as it should. The debugging console is enabled by binding the console key at the bottom of the key binding menu in the options window. More information about how to use console can be found on [[Console]].
−
This can be accomplished in Steam by setting it as a launch option for the game, in Windows by making a shortcut to the game and appending the parameter to the end of the path or otherwise launching the game from a terminal/commandline but adding -debugconsole to the end.
 
−
 
 
−
The console can be opened in-game by using the Home button, which you can rebind in the options window.
 
−
 
 
−
== In-game content ==
 
−
This is a zip of the software types, company types, name generators and personality types in the game:
 
−
 
 
−
[http://softwareinc.coredumping.com/wiki/Resources.zip File - 23 KB]
 
−
 
 
−
Updated as of Alpha 8.6.1
 
−
 
 
−
== Alpha 8 changes ==
 
−
 
 
−
Needs are no longer needed, but will be inferred from feature dependencies.
 
−
 
 
−
Feature dependencies should no longer be in a separate tag, and you can completely omit the "Dependencies" tag from features without dependencies.
 
−
 
 
−
You can now have multiple SoftwareCategory tags for features, to limit them to more than one software category, with individual unlock dates, use "0" for no unlock date.
 
−
 
 
−
Example:
 
−
<pre>
 
−
<Feature Vital="TRUE">
 
−
<Name>Multitasking</Name>
 
−
<Category>System</Category>
 
−
<Description>Let your users pretend they can multitask by having several applications open at any one time.</Description>
 
−
<DevTime>6</DevTime>
 
−
<Innovation>1</Innovation>
 
−
<Usability>1</Usability>
 
−
<Stability>0</Stability>
 
−
<CodeArt>1</CodeArt>
 
−
<SoftwareCategory Category="Computer">0</SoftwareCategory>
 
−
<SoftwareCategory Category="Console">2000</SoftwareCategory>
 
−
<SoftwareCategory Category="Phone">2000</SoftwareCategory>
 
−
<Dependency Software="Operating System">Multithreading</Dependency>
 
−
<Dependency Software="Operating System">Example</Dependency>
 
−
</Feature></pre>
 
−
 
 
−
== Software types ==
 
−
Software types are the types of software you can choose to develop in Software Inc. in the design document window. Software types can be added to the game by creating an XML file in the "SoftwareTypes" folder.
 
−
 
 
−
=== Tags ===
 
−
A software type XML file should contain the following tags:
 
−
 
 
−
{|class="wikitable"
 
−
|SoftwareType
 
−
|This is the root tag, which all tags should be a child to. If this tag has the attribute Override="True", all tags are optional and will override the content of a software type by the same name. You can use this to override some values of the built-in software types. Note that if you override the Features tag, you will delete all features from the software type.
 
−
|-
 
−
|Name
 
−
|The name of the software as it will appear in dropdown lists, etc.
 
−
|-
 
−
|Delete
 
−
|Optional tag which deletes the software type from the game, if it is set to TRUE
 
−
|-
 
−
|Category
 
−
|How the field of the software will be referred to in articles, e.g. games are categorized as "Gaming"
 
−
|-
 
−
|Categories
 
−
|The categories for the software type. Can be omitted.
 
−
|-
 
−
|Description
 
−
|The contents of the tooltip that will appear when hovering over the software type in the dropdown menu in the design document window.
 
−
|-
 
−
|Unlock
 
−
|Which year this software type will unlock, e.g. <Unlock>1995</Unlock>
 
−
|-
 
−
|Random
 
−
|How much sales will vary. When a product is released, a random number is chosen and it is weighted using this number, and it will be multiplied for all sales. As an example, for games it is 0.5, since you can't count on good sales for a game, but for operating systems, it is 0, since they are generally in demand and necessary for a computer to work, so sales won't vary that much.
 
−
|-
 
−
|Popularity
 
−
|How popular a software type is, which limits the maximum amount of income. Computer operating systems have 1 and Role Playing Games have 0.6. (Ignored if software type has categories defined)
 
−
|-
 
−
|Retention
 
−
|How long people will use the product, should be between 0 and 1, not including 1. Computer operating systems have 0.9 and Role Playing Games have 0.7. (Ignored if software type has categories defined)
 
−
|-
 
−
|Iterative
 
−
|How likely AI companies are to develop sequels for this type of software, between 0 and 1. (Ignored if software type has categories defined)
 
−
|-
 
−
|OSSpecific
 
−
|Whether you need to choose an operating system for this software.
 
−
|-
 
−
|OneClient
 
−
|Whether this software is for contract work. This does not currently work as expected, so you should probably avoid setting this to TRUE.
 
−
|-
 
−
|InHouse
 
−
|Whether you can lock this software to your own company. This makes sense for game engines, but not for games for example.
 
−
|-
 
−
|NameGenerator
 
−
|The [[Modding#Name generators|name generator]] to use for simulated companies or for when the player clicks the name button in the design document. (Will be used for all software categories which don't have one defined)
 
−
|-
 
−
|OSLimit
 
−
|If this software is OSSpecific, you can use this tag to limit the software to a specific operating system category.
 
−
|-
 
−
|Features
 
−
|All [[Modding#Features|features]] that this software can implement.
 
−
|}
 
−
 
 
−
=== Example ===
 
−
<pre><SoftwareType>
 
−
<Name>Test Software</Name>
 
−
<Category>Testing</Category>
 
−
<Description>This is part of a test mod. If you develop a perfect version, 50% of the population will want it, but 10% might randomly not want it.</Description>
 
−
<Random>0.1</Random>
 
−
<Categories>
 
−
<Category Name="Test category">
 
−
<Description>This is a test category</Description>
 
−
<Popularity>0.5</Popularity>
 
−
<Retention>0.5</Retention>
 
−
<TimeScale>1</TimeScale>
 
−
<Iterative>0.75</Iterative>
 
−
<NameGenerator>testgen</NameGenerator>
 
−
</Category>
 
−
</Categories>
 
−
<OSSpecific>TRUE</OSSpecific>
 
−
<OneClient>FALSE</OneClient>
 
−
<InHouse>FALSE</InHouse>
 
−
<Features>
 
−
<Feature Forced="TRUE">
 
−
<Name>Test feat 1</Name>
 
−
<Description>This feature will always be selected unless superseded by a feature with this as "From".</Description>
 
−
<DevTime>2</DevTime>
 
−
<Innovation>0</Innovation>
 
−
<Usability>1</Usability>
 
−
<Stability>1</Stability>
 
−
<CodeArt>1</CodeArt>
 
−
</Feature>
 
−
<Feature From="Test feat 1">
 
−
<Name>Test feat 2</Name>
 
−
<Description>This feature takes 6 months to make and has 4/6 Usability.</Description>
 
−
<DevTime>6</DevTime>
 
−
<Innovation>1</Innovation>
 
−
<Usability>4</Usability>
 
−
<Stability>1</Stability>
 
−
<CodeArt>1</CodeArt>
 
−
<Dependency Software="Visual Tool">Image viewing</Dependency>
 
−
</Feature>
 
−
<Feature>
 
−
<Name>Test feat 3</Name>
 
−
<Description>This feature takes just as many artists as programmers and offers no stability.</Description>
 
−
<DevTime>5</DevTime>
 
−
<Innovation>1</Innovation>
 
−
<Usability>1</Usability>
 
−
<Stability>0</Stability>
 
−
<CodeArt>0.5</CodeArt>
 
−
<Dependency Software="Test Software">Test feat 2</Dependency>
 
−
<SoftwareCategory Category="Test category">1983</SoftwareCategory>
 
−
</Feature>
 
−
</Features>
 
−
</SoftwareType></pre>
 
−
 
 
−
=== Features ===
 
−
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.
 
−
 
 
−
==== Attributes ====
 
−
 
 
−
{|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 ====
 
−
 
 
−
{|class="wikitable"
 
−
|Feature
 
−
|This is the root tag, which all tags should be a child to. Add any attribute explained above to this tag.
 
−
|-
 
−
|Name
 
−
|The name of the feature as it will appear in feature panel in the design document window
 
−
|-
 
−
|Category
 
−
|An optional tag that controls which specialization a product belongs to. If it is omitted the feature will belong to the base skill level of a field, usually described as "General" in Software Inc. which is controlled by the employees main skill in a role. Otherwise the employees specialization skill will control how well, if at all, they work with this feature. This can be 2D, 3D, Network, etc. You can add new specializations to the game using this tag.
 
−
|-
 
−
|Description
 
−
|The contents of the tooltip that will appear when hovering over the feature in the design document window.
 
−
|-
 
−
|Unlock
 
−
|Which year this feature will unlock, e.g. <Unlock>1995</Unlock>. Specializations will unlock, when the first feature which uses it unlocks.
 
−
|-
 
−
|DevTime
 
−
|How many months it takes to develop this feature
 
−
|-
 
−
|Innovation, Usability, Stability
 
−
|These three tags are normalized, so you can put in any number. 3, 4 and 5 would result in 3/12, 4/12 and 5/12. Innovation controls how long the product will stay interesting to customers. Usability controls how well customers will like the product and in extension, your company. Stability controls bugs and how much skill your employees will gain from working on the feature.
 
−
|-
 
−
|CodeArt
 
−
|The coding to art balancing of the feature. 1 will mean this feature only requires programmers whereas 0 will mean it only requires artists.
 
−
|-
 
−
|Server
 
−
|How many mbps this feature will need per active user. It is scaled with time using the formula 1+log10(year-1969). MMO uses 0.002, which would be around 5 gbps at any given time for a 1 million user game in 2010, which might change in the future.
 
−
|-
 
−
|Dependency
 
−
|What features this feature depends on to be available, this can be features in the current product, features in other products or features in supported operating system. Note that operating system feature dependencies are taken as an intersection, so if a features relies on 3D in an operating system, ALL chosen operating systems must support 3D. A dependency should be defined as &lt;Dependency Software="Operating System"&gt;3D&lt;/Dependency&gt;. You can have multiple of these tags per feature
 
−
|-
 
−
|SoftwareCategory
 
−
|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.
 
−
|}
 
−
 
 
−
=== Software categories ===
 
−
Software categories are defined in the Categories tag of the software type XML file. Categories enable software specialization, e.g. OS/Console/Phone Operating systems. It is completely optional and a "Default" category will be used in case it is omitted from the software definition.
 
−
 
 
−
==== Tags ====
 
−
{|class="wikitable"
 
−
|Category Name="X"
 
−
|This is the root tag, which all tags should be a child to. Use the name attribute to give the category a name.
 
−
|-
 
−
|Description
 
−
|What will be shown when hovering over the category in the design document
 
−
|-
 
−
|Unlock
 
−
|Which year this software category will unlock, e.g. <Unlock>1995</Unlock>
 
−
|-
 
−
|Popularity
 
−
|How popular a software category is, which limits the maximum amount of income. Computer operating systems have 1 and Role Playing Games have 0.6.
 
−
|-
 
−
|TimeScale
 
−
|How long it will take to make a product in this category compared to the base software type, should be between 0 and 1.
 
−
|-
 
−
|Retention
 
−
|How long people will use the product, should be between 0 and 1, not including 1. Computer operating systems have 0.9 and Role Playing Games have 0.7.
 
−
|-
 
−
|Iterative
 
−
|How likely AI companies are to develop sequels for this type of software.
 
−
|-
 
−
|NameGenerator
 
−
|The [[Modding#Name generators|name generator]] to use for simulated companies or for when the player clicks the name button in the design document.
 
−
|-
 
−
|}
 
−
 
 
−
== Name generators ==
 
−
The random name generator uses a tree like structure to generate random strings of words. Generators will be loaded from txt files located in the "NameGenerators" folder and their name will match their file names, minus ".txt". If you name a name generator the same thing as one of the built-in name generators, they will merge their nodes and words, you can use this to expand the words of a built-in name generator.
 
−
 
 
−
=== Example ===
 
−
 
 
−
Here is an example of how a name generator can be structured in the text file:
 
−
 
 
−
<pre>-start(base)
 
−
-base(base2,end,stop)
 
−
Hello
 
−
Hi
 
−
-base2(end,stop)
 
−
, you
 
−
-end(stop)
 
−
.</pre>
 
−
This would create a generator that can generate the strings:
 
−
#Hello
 
−
#Hi
 
−
#Hello.
 
−
#Hi.
 
−
#Hello, you
 
−
#Hi, you
 
−
#Hello, you.
 
−
#Hi, you.
 
−
It works by starting from the first node "start" (nodes are the ones with a hyphen in front of the name), it appends a random string from the list of strings below it (in this case there’s nothing to pick), it then picks a random node from the parenthesis of the current node (which can only be "base" in this case), and then it continues until it reaches the node stop. There is a limit to how far it will go, depending on how many nodes there are, to avoid an infinite loop.
 
−
 
 
−
== Company types ==
 
−
Company types are the types of company that the game will simulate. If you don't define company types for your new software types, the software will not be released by the AI.
 
−
 
 
−
=== Removing companies ===
 
−
You can remove AI company types by adding a "delete.xml" file in the CompanyTypes folder, which includes a root tag containing a tags with the company types you want to remove, eg.
 
−
 
 
−
<pre>
 
−
<CompanyTypes>
 
−
<Type>Web CMS</Type>
 
−
<Type>Financial CMS</Type>
 
−
<Type>Workflow CMS</Type>
 
−
</CompanyTypes>
 
−
</pre>
 
−
 
 
−
=== Tags ===
 
−
 
 
−
{|class="wikitable"
 
−
|CompanyType
 
−
|This is the root tag, which all tags should be a child to.
 
−
|-
 
−
|Specialization
 
−
|The name/tag of the company type. If you pick a name of one of the built-in company types, you can override it. Note that this only works for Alpha 4.5+
 
−
|-
 
−
|Force
 
−
|Whether a company of this type should be created on the first day and be forced to launch software on the first day. It is currently only used to launch a Computer Operating System on day one: <Force>Operating System,Computer</Force>. Just omit the tag if you don't need it.
 
−
|-
 
−
|PerYear
 
−
|The chance of a company of this type being founded every year. All company types in Software Inc. has this set to 0.2, as it seems to work pretty well.
 
−
|-
 
−
|Min
 
−
|The minimum amount of companies of this type there has to be on the market at any given point in time. 1 for computer OS, 2 for games.
 
−
|-
 
−
|Max
 
−
|The maximum amount of companies of this type there has to be on the market at any given point in time. 3 for computer OS, 6 for games.
 
−
|-
 
−
|Types
 
−
|The types of products the company will release and how much effort they take. 1 means they can only work one product of that software type at any given time, 0.25 means they would be able to work on 4 of it at a time. Currently this is set to 1 for all company types in Software Inc. as going lower seems to spam the market. You can define a category for each type, otherwise a random will be chosen from the categories available from the software type.
 
−
|}
 
−
 
 
−
=== Examples ===
 
−
<pre><CompanyType>
 
−
<Specialization>Tools</Specialization>
 
−
<PerYear>0.2</PerYear>
 
−
<Min>1</Min>
 
−
<Max>4</Max>
 
−
<Types>
 
−
<Type Software="Audio Tool">1</Type>
 
−
<Type Software="Visual Tool">1</Type>
 
−
<Type Software="Antivirus">1</Type>
 
−
</Types>
 
−
</CompanyType></pre>
 
−
 
 
−
<pre><CompanyType>
 
−
<Specialization>Computer Operating Systems</Specialization>
 
−
<Force>Operating System,Computer</Force>
 
−
<PerYear>0.2</PerYear>
 
−
<Min>1</Min>
 
−
<Max>3</Max>
 
−
<Types>
 
−
<Type Software="Operating System" Category="Computer">1</Type>
 
−
</Types>
 
−
</CompanyType></pre>
 
−
 
 
−
== Scenarios ==
 
−
Scenarios can define the start conditions, goals and events in-game.
 
−
A scenario type XML file should contain the following tags:
 
−
 
 
−
{|class="wikitable"
 
−
|<b>Tag name</b>
 
−
|<b>Description</b>
 
−
|<b>Example</b>
 
−
|-
 
−
|Scenario
 
−
|This is the root tag, which all tags should be a child to.
 
−
|
 
−
|-
 
−
|Name
 
−
|The name of the scenario as shown in the game.
 
−
|
 
−
|-
 
−
|Money
 
−
|The available amounts of money at the game start.
 
−
|<pre><Money><Amount>1000</Amount><Amount>20000</Amount></Money></pre>
 
−
|-
 
−
|Goals
 
−
|Goals define the "win" condition(s). There can be multiple goals, each defined its own Goal tag. Each goal can also have multiple conditions, separated by commas. Conditions are defined by their name followed by an argument. The only goals available at the moment are Money and Date.
 
−
|<pre><Goals><Goal>Money 200000,Date 6-1980</Goal><Goal>Money 2000000,Date 4-1988</Goal></Goals></pre>
 
−
|-
 
−
|Years
 
−
|The available start years at the start of a new game.
 
−
|<pre><Years><Year>1976</Year><Year>1988</Year></Years></pre>
 
−
|-
 
−
|Events
 
−
|Events are defined separately in the "Events" Folder. You can leave the tag empty to ignore it.
 
−
|<pre><Events><Event>Test</Event><Event>Test2</Event></Events></pre>
 
−
|-
 
−
|Simulation
 
−
|Whether the competition should be simulated. Relevant if you want the competition to be entirely controlled by your own events.
 
−
|<pre><Simulation>TRUE</Simulation></pre>
 
−
|-
 
−
|Trees(Optional)
 
−
|Whether to place trees in the world
 
−
|<pre><Trees>TRUE</Trees></pre>
 
−
|-
 
−
|MinFloor(Optional)
 
−
|The lowest floor the player can build on, between -1 and 9
 
−
|<pre><MinFloor>0</MinFloor></pre>
 
−
|-
 
−
|MaxFloor(Optional)
 
−
|The lowest floor the player can build on, between 0 and 10
 
−
|<pre><MaxFloor>4</MaxFloor></pre>
 
−
|-
 
−
|CanExpand(Optional)
 
−
|Whether the player can buy more plot.
 
−
|<pre><CanExpand>FALSE</CanExpand></pre>
 
−
|-
 
−
|ForceEnvironment(Optional)
 
−
|Whether the player should be forced to play in a specific environment. Between 0 and 3, for forest, city, tundra and desert.
 
−
|<pre><ForceEnvironment>0</ForceEnvironment></pre>
 
−
|-
 
−
|StartingArea(Optional)
 
−
|What the players starting plot should be. Defined as x,y,width,height. Will be clamped to match game limits.
 
−
|<pre><StartingArea>9,128,32,32</StartingArea></pre>
 
−
|-
 
−
|}
 
−
Example of a "scenario" file:
 
−
 
−
<pre><Scenario>
 
−
<Name>Test scenario</Name>
 
−
<Money>
 
−
<Amount>500</Amount>
 
−
<Amount>1000</Amount>
 
−
</Money>
 
−
<Goals>
 
−
<Goal>Money 1337,Date 5-1995</Goal>
 
−
<Goal>Money 1000000,Date 5-2012</Goal>
 
−
</Goals>
 
−
<Years>
 
−
<Year>1980</Year>
 
−
<Year>1985</Year>
 
−
                <Year>2023</Year>
 
−
</Years>
 
−
<Events>
 
−
<Event>Test</Event>
 
−
</Events>
 
−
<Simulation>TRUE</Simulation>
 
−
</Scenario></pre>
 
−
 
−
=== Events ===
 
−
Nothing here yet
 
−
 
 
−
=== Companies ===
 
−
Nothing here yet
 
−
 
 
−
== Personalities ==
 
−
Personalities control employee traits(Leadership, aptitude and diligence) an inter office relationships. All employees have exactly 2 personality traits. All personalities will be merged with the pre-existing personalities in the game.
 
−
 
 
−
=== Tags ===
 
−
{|class="wikitable"
 
−
|PersonalityGraph
 
−
|This is the root tag, which all tags should be a child to.
 
−
|-
 
−
|Personalities
 
−
|This tag should contain the list of personalities
 
−
|-
 
−
|Incompatibilities
 
−
|This tag should contain a list of personalities which cannot be mixed when picking employee personality.
 
−
|-
 
−
|}
 
−
 
 
−
=== Personalities and incompatibilities ===
 
−
 
 
−
Personality tags include:
 
−
{|class="wikitable"
 
−
|Personality
 
−
|This is the root tag, which all tags should be a child to.
 
−
|-
 
−
|Name
 
−
|The personality's name as it appears in the game.
 
−
|-
 
−
|WorkLearn (Replaces Aptitude)
 
−
|Between -1 and 1, where -1 is hard working and 1 is easy learner.
 
−
|-
 
−
|Social (Replaces Leadership
 
−
|Between -1 and 1, where -1 is independent and 1 is social.
 
−
|-
 
−
|LazyStress (Replaces Diligence
 
−
|Between -1 and 1, where -1 is lazy and 1 is stressed.
 
−
|-
 
−
|Relationships
 
−
|This tag should contain a list how people with this personality feels about another personality, between -1 for bad and 1 for great. You only need to define this one-way, so if you already have a relationship with Stubborn defined for Short-tempered, you shouldn't also define it other way around. You can define relationships with personalities already in the game.
 
−
|-
 
−
|}
 
−
 
 
−
The Incompatibilities should contain a list of Incompatible tags, each with two Personality tags naming the two personalities which cannot exist in the same person.
 
−
 
 
−
=== Example ===
 
−
<pre><PersonalityGraph>
 
−
<Personalities>
 
−
<Personality>
 
−
<Name>TestPersonlity</Name>
 
−
<Aptitude>1</Aptitude>
 
−
<Leadership>-1</Leadership>
 
−
<Diligence>0.3</Diligence>
 
−
<Relationships>
 
−
<Relation Name = "Extrovert">-0.5</Relation>
 
−
<Relation Name = "TestPersonlity 2">1</Relation>
 
−
</Relationships>
 
−
</Personality>
 
−
<Personality>
 
−
<Name>TestPersonlity 2</Name>
 
−
<Aptitude>-0.5</Aptitude>
 
−
<Leadership>0</Leadership>
 
−
<Diligence>0.25</Diligence>
 
−
<Relationships>
 
−
</Relationships>
 
−
</Personality>
 
−
</Personalities>
 
−
<Incompatibilities>
 
−
<Incompatible>
 
−
<Personality>TestPersonlity</Personality>
 
−
<Personality>TestPersonlity 2</Personality>
 
−
</Incompatible>
 
−
</Incompatibilities>
 
−
</PersonalityGraph></pre>
 
−
 
 
−
== Furniture modding ==
 
−
Furniture modding is available as of Alpha 8.10.13
 
−
 
 
−
Furniture packages should be located in subfolders in the “Furniture” folder with the game. A furniture package will inherit its name from the folder name.
 
−
 
 
−
You can reload furniture while in-game by bringing up the console and executing the RELOAD_FURNITURE command.
 
−
You can generate thumbnails by bringing up the console in the main menu and executing the FURNITURE_THUMBNAIL command with the name of your furniture as parameter.
 
−
 
 
−
=== The XML and basic tags ===
 
−
Each furniture should be defined in separate XML files.
 
−
 
 
−
The root tag in a furniture xml file should have a Thumbnail attribute with a relative path to a 128x128 thumbnail it should use in-game.
 
−
 
 
−
The root tag can also have a Base attribute to inherit from an existing furniture from the game. If you define the attribute AutoBounds to “True”, the game will auto generate the navigation mesh and building boundary, vertical span, and width and vertical offset for wall furniture based on the furniture meshes, otherwise these can be controlled in the Furniture component by setting the variables BuildBoundary, NavBoundary, Height1 and Height2.
 
−
 
 
−
'''It is highly recommended that you run the command EXPORT_FURNITURE_BOUNDS with your furniture name as parameter if you've used the AutoBounds attribute. This command bakes the bounds information in the XML file so it doesn't have to be recalculated each time the game launches.''' This command has been introduced in alpha 8.10.15.
 
−
 
 
−
If you add an UpgradeTo tag, this furniture will upgrade to the named furniture. If you add an UpgradeFrom tag, the named furniture will upgrade to this furniture.
 
−
 
 
−
=== Meshes and materials ===
 
−
Meshes will be loaded from the Models tag. The Models  tag should contain children tags that define meshes. Each mesh tag should have a File tag, with the relative path to an obj file, a Position, Rotation and Scale. Optionally, the mesh tag can have a Parent tag, to make it a child transform of the ith mesh loaded (Zero index), a ComponentName tag to name the mesh for later reference and a Material tag to give it a material.
 
−
 
 
−
If no material is defined the furniture will use the default material which is much better performance wise and allows the player to colorize the furniture. Meshes using the default material should be UV mapped as shown below.
 
−
 
 
−
[[File:FurnitureMap.png]]
 
−
 
 
−
If you decide to use your own materials, you should have a Materials XML file in your furniture package folder, in which you define your materials. The Materials.xml file should have a root tag with material tags as children. Each material will be named as its tag and should have up to three children: Textures, Floats and Colors. All materials use Unity’s default material. If you want to set the texture you would write <_MainTex>test.png</_MainTex>. All textures will be loaded in 256x256. If you want to see all the colors, floats and textures you can change, refer to Unity’s default shader, which can be downloaded here: http://unity3d.com/get-unity/download/archive . Some variables include:
 
−
* _MainTex
 
−
* _BumpMap
 
−
* _OcclusionMap
 
−
* _Metallic
 
−
* _Glossiness
 
−
* _BumpScale
 
−
* _Color
 
−
 
 
−
=== Interaction points ===
 
−
 
 
−
Interaction points control how employees can interact with a piece of furniture.
 
−
 
 
−
If you have used the Base attribute, the furniture will inherit its interaction points from the base furniture, unless you add the “InteractionPoints” tag.
 
−
 
 
−
Interaction points should define a Name, which at this point in time includes “Use”, “Repair”, “Serve”, “Social” and “Visit” for the base game. They should also have Position and Rotation defined.
 
−
You can define a ComponentName tag to name the interaction points for later reference.
 
−
 
 
−
Interaction points can also define Animation(main animation used when interacting, ignored for some interactions), SubAnimation(used for repairs, 0, 1 or 2 for repair height), MinimumNeeded(how many need to be reachable before the player gets a warning) and ReachCheck(whether we should warn the player at all).
 
−
 
 
−
Finally, it can define a Child, which is the ith interaction point defined (Zero index). If you want a number of interaction points to only be used by one employee at a time you should define children such that they form a dependency loop. When one interaction point gets reserved, the children will recursively get reserved as well.
 
−
 
 
−
=== Snap points ===
 
−
Snap points are points at which certain furniture can be snapped to other furniture, like chairs to tables.
 
−
 
 
−
If you have used the Base attribute, the furniture will inherit its snap points from the base furniture, unless you add the “SnapPoints” tag.
 
−
 
 
−
Snap points should define a Name, which will control which furniture can snap to it, currently in use in the base game is “PCAddon”, “AtTable” and “OnTable”. “Food” is also used in the game for tables which should allow for food but not OnTable furniture, like benches. They should also have Position and Rotation defined.
 
−
 
 
−
You can define a ComponentName tag to name the snap point for later reference.
 
−
 
 
−
Snap points can also have “CheckValid” defined, which controls whether the game should allow for something to be placed no matter if there are collisions. This calculation is heavy, but not needed for stuff like computers and computer add-ons.
 
−
 
 
−
Finally, snap points can define Links, which is a comma separated list of linked snap points, referencing the ith snap point defined (zero index). Links are currently used to link chairs with computers and chairs with food. E.g. for the square table, the OnTable point is linked to all AtTable points around it. The bench does not have chairs and instead the “Use” interaction points are defined in the same order as its “Food” snap points so the game knows where to put the employee’s food and how to save it to a file.
 
−
 
 
−
=== Components ===
 
−
Other than the tags described so far, all tags are interpreted as MonoBehaviour components. If you added a tag called “<BoxCollider>”, the children tags would be interpreted as variables of the BoxCollider component and if the component does not exist, it will be instantiated for the Furniture. All MonoBehaviour variables in a Component will use the ComponentName reference set in the other tags, or alternatively you can add a Transforms tag to define empty objects with a Name, Position and Rotation. Using “self” as a value for a MonoBehaviour variable will find the corresponding component in the furniture object itself. This allows for anything to be added to a furniture, even MonoBehaviors from custom mods.
 
−
 
 
−
If you set the Parent attribute to a ComponentName reference or Transforms reference, the component will be fetched/added to the object instead. This could be used to add a PointLight component to an empty object to make your own lights. Make sure to add a LampScript component to your furniture object if you’re making a custom lamp, so the game can control shadows and lighting.
 
−
 
 
−
Setting a Destroy attribute to “True” for a tag will remove that MonoBehavior from the furniture.
 
−
 
 
−
Note that using MonoBehaviors from other mods requires setting the Namespace attribute and the Assembly attribute so the game knows where to find the classes, e.g. <MyCustomComponent Namespace=”MyMod.Behaviours.” Assembly=”MyMod”>.
 
−
 
 
−
==== Furniture ====
 
−
This component will always be present in a furniture. Common variables to edit would be:
 
−
* Type
 
−
* Category
 
−
* Cost
 
−
* ButtonDescription
 
−
* ComputerPower
 
−
* RoleBuffs
 
−
* Lighting
 
−
* Coffee
 
−
* Wait
 
−
* AuraValues
 
−
* Wattage
 
−
* Water
 
−
* Noisiness
 
−
* Comfort
 
−
* Environment
 
−
* DefaultColorGroup
 
−
* PrimaryColorName
 
−
* SecondaryColorName
 
−
* TertiaryColorName
 
−
* ColorPrimaryEnabled
 
−
* ColorSecondaryEnabled
 
−
* ColorTertiaryEnabled
 
−
* ForceColorSecondary
 
−
* ForceColorTertiary
 
−
* ColorPrimaryDefault
 
−
* ColorSecondaryDefault
 
−
* ColorTertiaryDefault
 
−
* ColorableLights
 
−
* LightPrimary
 
−
* BuildBoundary
 
−
* NavBoundary
 
−
* OnXEdge
 
−
* OnYEdge
 
−
* CanRotate
 
−
* Height1
 
−
* Height2
 
−
* YOffset
 
−
* WallWidth
 
−
* BasementValid
 
−
* OnlyExteriorWalls
 
−
* WallFurn
 
−
* IsSnapping
 
−
* SnapsTo
 
−
* CanAssign
 
−
* ValidIndoors
 
−
* ValidOutdoors
 
−
* ValidOnFence
 
−
* MaxQueue
 
−
* ForceAccessible
 
−
* ITFix
 
−
* UnlockYear
 
−
* TemperatureController
 
−
* HeatCoolPotential
 
−
* EqualizeTemperature
 
−
* AlwaysOn
 
−
* ComputerTransform
 
−
* OriginalOffset
 
−
* PCAddonOffset
 
−
* OriginalRotation
 
−
* PCAddonRotation
 
−
* PokesThroughWall
 
−
* CanLean
 
−
* UseStandardMat
 
−
* TwoFloors
 
−
* OffsetPoints
 
−
* InterPoints
 
−
* UpperFloorFrame
 
−
* HoldablePoints
 
−
* DespawnHoldables
 
−
* DespawnHour
 
  
−
==== Upgradable ====
+
== Folder structure ==
−
This component makes this furniture repairable. Common variables to edit would be:
+
Unless downloaded from the Steam Workshop, mods are placed in the root of the game folder, depending on which type of mod you are making. Each mod should be placed in its own folder within the following folders (Note that these folders might not exist in the first place, so you should create them yourself):
−
* TheScreen
+
* Software types and personalities should be placed in the '''Mods''' folder.
−
* SmokePosition
+
* Furniture should be placed in the '''Furniture''' folder.
−
* TimeToAtrophy
+
* Room, path and roof textures should be placed in the '''Materials''' folder.
−
* UpgradePrice
+
* C# code and dll files should be placed in the '''DLLMods''' folder.
−
* OnMat
+
* Translations should be placed in the '''Localization''' folder.
−
* OffMat
 
−
* DegradeAlways
 
−
* AffectedByTemp
 
  
−
==== TableScript ====
+
== Meta file ==
−
This component handles tables and table grouping for meeting, canteens, etc.  
+
Each mod will take its name from the folder it is in. However, you can customize the '''Name''', '''Description''' and '''Author''' of your mod by adding a meta.tyd file to the root of your mod's folder, containing the specified records. This file will be created automatically when you edit your mod in-game (Not implemented yet as of Alpha 11.4.7).
  
−
==== LampScript ====
+
== Localizations ==
−
This component handles lighting and shadows for lamps.
+
Please go to [https://translate.coredumping.com translate.coredumping.com] to help translate the game.
  
−
==== Server ====
+
== Mod types ==
−
This component makes this furniture a server. It is recommended to inherit from a server furniture, as the server component uses some in-game objects, like a text mesh and a wire mesh. Use the Power variable to change its power in mb.
+
=== Data mod ===
 +
[[Data Modding|Read the documentation here.]]
  
−
== Modding with DLLs ==
+
Data mods can add, change or remove software types, AI company types, name generators and employee personalities. This is all done with [[TyD|TyD]] files, however software can have scripts attached using [[SIPL|SIPL]].
−
As of Alpha 8.10 Software Inc. supports loading assemblies at runtime.
 
  
−
A good grasp of Unity3D programming is required.
+
=== Furniture ===
 +
[[Furniture Modding|Read the documentation here.]]
  
−
To create your own mod start a .NET project targeted at the .NET 3.5 profile.
+
You can add furniture using .obj 3D object files. The furniture modding system, while only using [[TyD|TyD]] files, allows you to change pretty much anything about your furniture that would be possible to change from within the game's engine.
−
Add a reference to the following libraries:
 
  
−
* Software Inc_Data\Managed\UnityEngine.UI.dll
+
=== Materials ===
 +
[[Material Modding|Read the documentation here.]]
  
−
* Software Inc_Data\Managed\UnityEngine.dll
+
Material mods allow you to load textures into the game for interior walls, exterior walls, floors, roofs and paths.
  
−
* Software Inc_Data\Managed\Assembly-CSharp.dll
+
=== Code mod ===
 +
[[Code Modding|Read the documentation here.]]
  
−
Start by creating a class that implements the ModMeta interface, then implement as many classes that inherit from ModBehaviour as you want. Each ModBehaviour implementation will be instantiated once the mod is loaded.
+
If you want to dive even further, you can put .cs files directly with the game, and it will compile and load your scripts on startup. For more control, you can compile your own DLL files for the game to load.
  
−
When you're done, compile your mod and place it in the game's folder, in a subfolder called "DLLMods".
+
=== Localizations ===
 +
To create a localization you can copy the English folder from the Localization folder and fill in your own text in the appropriate fields. Localization files are written entirely in [[TyD|TyD]], to be easily human-readable.
  
−
Here's an example of a mod that let's you change how many floors you can build on, complete with comments:
+
Localizations can also contain '''femalefirstnames.txt''', '''malefirstnames.txt''' and '''lastnames.txt''' files to overwrite the default employee names in the game. These should contain a list of names separated by new lines, ordered by how common the name is.
−
[http://swinc.net/FloorMod.zip Floor Mod]
 
  
−
Here's a list of important entry points you can have a look at:
+
====Helpful console commands====
−
{|class="wikitable"
+
* '''COMPARE_LOCALIZATION''' X Y - Compares what has changed between between localization X and Y, Y should almost always be "English"
−
|GameSettings.Instance
+
* '''CONVERT_LOCALIZATION_TYD''' X - Converts localization named X from XML to TyD
−
|This class contains most of the objects that manage the game
+
* '''RELOAD_LOCALIZATION''' - Reloads all localizations, but does not update UI instantly when in-game
−
|-
 
−
|GameSettings.Instance.MyCompany
 
−
|The player's company
 
−
|-
 
−
|GameSettings.Instance.simulation
 
−
|Manages all companies and products
 
−
|-
 
−
|GameSettings.Instance.sRoomManager
 
−
|Manages rooms, furniture and room segments
 
−
|-
 
−
|GameSettings.Instance.sActorManager
 
−
|Manages employees and teams
 
−
|-
 
−
|SelectorController.Instance
 
−
|Manages selection
 
−
|-
 
−
|TimeOfDay.Instance
 
−
|Manages time
 
−
|-
 
−
|HUD.Instance
 
−
|Manages the main HUD and windows
 
−
|-
 
−
|ObjectDatabase.Instance
 
−
|Contains all furniture and room segments
 
−
|-
 
−
|WindowManager
 
−
|Controls windows and has functions to create windows and GUI elements
 
−
|-
 
−
|}
 

Latest revision as of 18:01, 6 April 2026

Mods in Software Inc. can be defined in simple text-based files or using C# and compiling code for the game to load. You can add new software types, furniture, translations and room textures using only the TyD file format.

Debugging console

You'll need the in-game console to properly test your mods and check if everything is working as it should. The debugging console is enabled by binding the console key at the bottom of the key binding menu in the options window. More information about how to use console can be found on Console.

Folder structure

Unless downloaded from the Steam Workshop, mods are placed in the root of the game folder, depending on which type of mod you are making. Each mod should be placed in its own folder within the following folders (Note that these folders might not exist in the first place, so you should create them yourself):

  • Software types and personalities should be placed in the Mods folder.
  • Furniture should be placed in the Furniture folder.
  • Room, path and roof textures should be placed in the Materials folder.
  • C# code and dll files should be placed in the DLLMods folder.
  • Translations should be placed in the Localization folder.

Meta file

Each mod will take its name from the folder it is in. However, you can customize the Name, Description and Author of your mod by adding a meta.tyd file to the root of your mod's folder, containing the specified records. This file will be created automatically when you edit your mod in-game (Not implemented yet as of Alpha 11.4.7).

Localizations

Please go to translate.coredumping.com to help translate the game.

Mod types

Data mod

Read the documentation here.

Data mods can add, change or remove software types, AI company types, name generators and employee personalities. This is all done with TyD files, however software can have scripts attached using SIPL.

Furniture

Read the documentation here.

You can add furniture using .obj 3D object files. The furniture modding system, while only using TyD files, allows you to change pretty much anything about your furniture that would be possible to change from within the game's engine.

Materials

Read the documentation here.

Material mods allow you to load textures into the game for interior walls, exterior walls, floors, roofs and paths.

Code mod

Read the documentation here.

If you want to dive even further, you can put .cs files directly with the game, and it will compile and load your scripts on startup. For more control, you can compile your own DLL files for the game to load.

Localizations

To create a localization you can copy the English folder from the Localization folder and fill in your own text in the appropriate fields. Localization files are written entirely in TyD, to be easily human-readable.

Localizations can also contain femalefirstnames.txt, malefirstnames.txt and lastnames.txt files to overwrite the default employee names in the game. These should contain a list of names separated by new lines, ordered by how common the name is.

Helpful console commands

  • COMPARE_LOCALIZATION X Y - Compares what has changed between between localization X and Y, Y should almost always be "English"
  • CONVERT_LOCALIZATION_TYD X - Converts localization named X from XML to TyD
  • RELOAD_LOCALIZATION - Reloads all localizations, but does not update UI instantly when in-game
Retrieved from "https://softwareinc.coredumping.com/wiki/index.php?title=Modding&oldid=1374"