Data Modding

A lot of the modding features in Software Inc. are completely data driven. Software Inc. loads TyD files found in the "Mods" folder of the root of the game when it launches.

A mod should be placed in its own folder in the "Mods" folder and can optionally contain each of the following folders: "CompanyTypes", "NameGenerators" and "SoftwareTypes".

The root of your mod can additionally include a Personalities.tyd file to add new personalities to the game.

## Debugging console

The debugging console is enabled by binding the console key at the bottom of the key binding menu in the options window.

### Helpful commands

* **INSTA\_DEVELOP\_DESIGN** - Instantly releases whatever is in the design document window, skipping design and dev phases (Only works for modded software)
* **RELOAD\_MOD** X - Reloads mod named X. Note that this does not affect the currently running game, if there is any
* **CHECK\_SPEC\_REP** X - Checks whether all specialization levels are used across all software when mod named X is loaded, which would otherwise make some education worthless
* **TEST\_DEV\_MOD** X Y Z - Prints out balancing information for Software Category Z in Software Y in mod X. This tells you if the player can reach 100% interest with any submarket targeting
* **LIST\_SCOPE\_MEMBERS** X - Prints out all functions and variables available for the type X, to use when making level 3 feature scripts, Read more here.
* **GENERATE\_LOCALIZATION** X - Generates localization files based on the mod named X
* **CHECK\_ADDON\_MARKET** X Y Z - Checks whether all markets are fulfilled by the add-on Z in a software type Y in mod X, which would otherwise make it impossible to sell the add-on to 100% of the market

## In-game content

These are zip files of the software types, company types, name generators and personality types currently in the game:

Alpha 8.6.1 data - 23 KB

Alpha 9.7.6 data - 35 KB

Alpha 10.1.4 data - 23 KB

Alpha 11.4.1 data - 22 KB

Alpha 11.7.1 data - 22 KB

Beta 1.1.1 data - 34 KB

## Alpha 11 changes

If you're coming from pre-Alpha 11 modding, this section will probably be relevant, as the design philosophy of software in Alpha 11 is incompatible with previous versions.

### Feature evolution

Features can no longer depend on each other. You can't design your software in a way that relies on features evolving or deprecating old features. Features are more abstract in Alpha 11 and rely instead on Tech levels to control their evolution. An example would be PC speaker, 8-bit audio and HD audio from Alpha 10. In Alpha 11 you just have "Audio" and its tech level determines its perceived complexity.

### Why?

On a surface level this might seem like a step back in terms of gameplay depth, but it actually opens up a new layer of complexity. The old system wasn't really deep in any meaningful way to begin with, since the player would always end up just pressing "Select all" and none of the intricacies of the feature dependencies were very obvious or satisfying. Some benefits of the new system include:

* The player will never run out of new features
* The player will never run out of things to research and there will always be research available
* The complexity has been moved from obscure interdependencies to several new systems the player can actively engage with
* The tech level system is a steppingstone to adding the updates/expansion mechanic, which would not have been possible with the old feature system

### Moving forward

Features should be a lot more abstract than before. They should represent aspects of a product that appeals to different submarkets to various degrees, rather than very time period specific add-ons. The game is balanced towards the player deciding on which markets they want to target and selecting features that fit that goal. Ideally you would have features that don't always fit in a product, which the player would want to leave out. Features that should always be present, like Audio playback, are represented as "SpecFeatures" or specialization features, which can be specified as mandatory and work as containers for other features with the same specialization.

## 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 TyD file in the "SoftwareTypes" folder.

### Overview

 File:SoftwareTypeOverview.png   File:SoftwareTypeOverviewInGame.png
### Elements

A software type TyD table should contain the following elements:

### Example

Note that this product will have a maximum devtime of 12, but the optimal is set to 25, so the player won't have enough features to reach 100% submarket satisfaction, especially since the features doesn't cover all submarkets properly. You can use the TEST\_DEV\_MOD console command to make sure your software type can satisfying its submarkets.

```
**SoftwareType**
	{
	**Name**			"Test Software"
	**Category**		Testing
	**Description**		"This is part of a test mod. If you develop a perfect version, 50% of the population will want it for about $50, but less than 10% might randomly not want it."
	**Random**			0.1
	**IdealPrice**		50
	**OptimalDevTime**		25
	**OSSupport**		Computer
	**OneClient**		False
	**InHouse**			False
	**SubmarketNames**		[ TestMarket1; TestMarket2; TestMarket3 ]
	**Categories**
		[
			{
			**Name**			"Test category"
			**Description**		"This is a test category"
			**Popularity**		0.5
			**Submarkets**		[ 1; 3; 1 ]#20%, 60%, 20%
			**Retention**		24
			**TimeScale**		1
			**Iterative**		0.75
			**NameGenerator**		testgen
			}
		]
	**Features**
		[
			{
			**Name** 		"Test feat 1"
			**Spec**		System
			**Description**	"This feature represents the system aspect of the product and cannot be deselected"
			**DevTime**		3
			**CodeArt**		1
			**Submarkets**	[ 1; 0; 1 ]#50%, 0%, 50%
			**Features**
				[
					{
					**Name**		"Test subfeat 1"
					**Description**	"This feature requires a level 1 System designer/programmer to be finished"
					**DevTime**		3
					**Level**		1
					**CodeArt**		1
					**Submarkets**	[ 0; 1; 0 ]
					}
					{
					**Name**		"Test subfeat 2"
					**Description**	"This feature will cost the owner $1000 per day when it is released"
					**DevTime**		2
					**Level**		3
					**CodeArt**		1
					**Submarkets**	0 #No submarkets needed for level 3 features
					**Script\_EndOfDay** "Product.DevCompany.MakeTransaction(-1000, Bills, \"Owned\");"
					}
				]
			}
			{
			**Name** 		"Test feat 2"
			**Spec**		Audio
			**Dependencies**	"Audio Tool"
			**Optional**	True
			**Description**	"This feature can be deselected, completely removing Audio features and Audio Tool dependencies from the product"
			**DevTime**		4
			**CodeArt**		1
			**Submarkets**	[ 0; 1; 3 ]#0%, 25%, 75%
			}
		]
	}

```

### 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 (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.

### 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.

#### Values

 Description
 Level
 Unlock
 DevTime
 Submarkets
 CodeArt
 Server
 SoftwareCategories
 Script\_EntryPoint

### 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.

Please note that level 3 features will never be selected by the AI, to avoid unpredictable behaviour and since scripts aren't very performant, it would slow the game down a lot if all products had scripts to execute. So you can think of level 3 features as small bonuses for the player to pick. If you want more advanced behaviour, you should look at writing code mods.

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:

 Script\_AfterSales
 Script\_OnRelease
 Script\_NewCopies
 Script\_WorkItemChange
You can use the **is** keyword to figure out what kind of task you're dealing with, e.g. **if (WorkItem is MarketingPlan)**.

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 use parentheses to get info on specific parameters or generic types, e.g. **LIST\_SCOPE\_MEMBERS CopyScope.Product.RunScripts(0)** will print out info for the first parameter of the function RunScripts, which is **ScriptSystem.EntryPoint**, i.e. the available list of entry points.

You can either write your scripts directly in your 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 last days income if it 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"

```

Finally, all SoftwareProduct's have their own local variables that you can read and write to for your scripts, just use **Product.GetVar(VariableName, DefaultValue)** and **Product.PutVar(VariableName, Value)**.

#### Scope members

These are the variables and methods each scope has access to. Note that you should use the **LIST\_SCOPE\_MEMBERS** console command, as described above, to get details.

**All scopes**

* SDateTime **Now** (Current in-game time)
* int **DaysPerMonth**
* Company **PlayerCompany**
* MarketSimulation **MarketSimulation**
* string **Localize(string input, optional string arguments)** (Localizes a string)
* void **LaunchLawsuit(string subject, float amount, float difficulty)** (subject should be an unlocalized string and the mod should include the localization. Difficulty is float between 0 and 1, 1 being very hard to defeat)
* SDateTime **CreateDate(int year, int month, int day, int hour, int minute)** (Create a new date to use where needed or for date arithmetic, e.g. Now + CreateDate(0,1,0,0,0) to add 1 month to the current date. Note that "year" is defined as years since 1900)
* void **AddPopUp(string text, float importance = 0.5, string icon = "Info", NotificationSound sfx = Neutral)** (Adds a popup message in the top left, input string should be pre-localized, icons include "Exclamation", "Money", "Server", etc. Sfx includes Issue, Warning, Good, Neutral)

**DevScope**

* WorkItem **WorkItem**
* bool **Ended**, **Cancelled** (these will be true if the event was triggered by the workitem being ended or cancelled, otherwise it was triggered by being created)

**SaleScope**

* SDateTime **Time** (Same as Now)
* SoftwareProduct **Product**
* int **PhysicalSales**, **DigitalSales**, **Refunds** (These can be changed to alter the result of the current day's market simulation)

**ProductScope**

* SoftwareProduct **Product**
* SDateTime **Time** (Release date)

**CopyScope**

* SoftwareProduct **Product**
* uint **NewCopies** (How many new copies were added to stock, this is read-only)

#### Script example

This script is used in the microphone surveillance feature of the Operating System SoftwareType:

```
**if** (Product.GetVar("MicMining", true)) //Check if player has been caught
	{
	Product.Bugs = Max(0, Product.Bugs - Product.Userbase * 0.01); //Remove 1 bug from product for each 100th active user
	**if** (Random() * Product.Userbase > 1000000 * Product.Category.Popularity)  //Random chance of getting caught
		{
		LaunchLawsuit("SpyingOnUsers", Product.Sum, 1);  //Create anonymous lawsuit
		Product.DevCompany.AddFans(-Product.Userbase, Product.Category);  //Remove fans and market recognition from player in category
		Product.Userbase = Product.Userbase * 0.05;  //Remove 95% of active users
		Product.KillAwareness();  //Remove all marketing
		Product.PutVar("MicMining", false);  //Mark player as caught for this product
		}
	}

```

You should download the mod data zip and check out examples of other scripts in the other vanilla SoftwareTypes.

### Software categories

Software categories are defined in the Categories list of the SoftwareType table. 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.

#### Values

 Description
 Unlock
 Submarkets
 TimeScale
 Retention
 IdealPrice
 Iterative
 NameGenerator

### Add-ons

Add-ons are defined in the software root table as an **AddOns** node with a list of add-on tables. Add-ons are either software or hardware based, which depends on the categories that support it. Software categories that uses a specific add-on should all either be hardware or software based. Add-ons can be limited to certain categories of the main software type.

Hardware based add-ons are peripherals and function differently than software add-ons in that other companies can make them for each other's hardware and a single customer can buy the same peripheral several times.

### Hardware

To turn a software type into hardware you need to add the value **Hardware True**, which will disable digital sales and make the product easier to sell. When you toggle hardware for a software type, you should also add a manufacturing process, that defines the components that make up a product.

The **Hardware** toggle and **Manufacturing** table can be added directly to the root Softwaretype table to affect all categories, or individually on categories.

#### Manufacturing process

The manufacturing table should include the following items:

 Processes
 FinalTime

#### Components

 Thumbnail
 BuiltInThumbnail
 DependsOn
 DependencyFactor
 Price
 Time

#### Hardware Designs

You can add a **Design** record to reference one or more hardware designs to be used for products of this type. You either specify a single hardware design, a list of designs, a list of designs with an unlock year or anything in between, e.g. **Design [ "CellPhone"; [ "SmartPhone" ; 2000 ] ]**

You can also limit which MeshObjects can be used in a HardwareDesign based on which features the product has. Just add one or more **FeatureBinding** records, containing a list formatted as **[HardwareDesign, MeshObject, Feature]**.

Check out more here: Hardware Design

#### Example

```
**Hardware**	True
**Manufacturing**
	{
	**Components**
		[
			{
			**Name** 			Gyroscope
			**Thumbnail**		"AThumbnail.png"
			**BuiltInThumbnail**	Gyroscope
			**Price**			15
			**Time**			4
			**DependsOn**		"Motion detection"
			}
			{
			**Name** 			"Rumble unit"
			**BuiltInThumbnail**	Vibration
			**Price**			10
			**Time**			2
			**DependsOn**		"Vibration"
			}
			{
			**Name** 			Plastic
			**BuiltInThumbnail**	Plastic
			**Price**			5
			**Time**			2
			}
			{
			**Name** 			Board
			**BuiltInThumbnail**	PCB
			**Price**			5
			**Time**			4
			}
			{
			**Name** 			Joystick
			**BuiltInThumbnail**	Joystick
			**Price**			5
			**Time**			4
			}
			{
			**Name** 			"Drive bay"
			**BuiltInThumbnail**	Harddrive
			**Price**			10
			**Time**			4
			**DependsOn**		"External drive"
			}
			{
			**Name** 			Controller
			**BuiltInThumbnail**	Microchip
			**Price**			100
			**Time**			8
			}
			{
			**Name** 			Console
			**BuiltInThumbnail**	Console
			**Price**			50
			**Time**			8
			}
		]
	**Processes**
		[
			{
			**Inputs**	[ "Gyroscope"; "Rumble unit"; "Plastic" ]
			**Output**	Joystick
			}
			{
			**Inputs**	[ "Board"; "Drive bay"; "Controller" ]
			**Output**	Console
			}
			{
			**Inputs**	[ "Joystick"; "Console" ]
			**Output**	Final
			}
		]
	**FinalTime**	2
	**Design**		[ "CellPhone"; [ "SmartPhone" ; 2000 ] ]
	**FeatureBinding**	[ "CellPhone"; "Antenna"; "Networking" ]
	}

```

## 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.

Writing [REPLACE] as the first line will replace an existing name generator from the game, based on it's file name.

### Example

Here is an example of how a name generator can be structured in the text file:

```
-start(base)
-base(base2,end,stop)
Hello
Hi
-base2(end,stop)
, you
-end(stop)
.
```
This would create a generator that can generate the strings:

1. Hello
2. Hi
3. Hello.
4. Hi.
5. Hello, you
6. Hi, you
7. Hello, you.
8. 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.txt" file in the CompanyTypes folder, with a list of the company types you want to remove, separated by new line, eg.

```
Antivirus
Games
Office

```

### Values

 PerYear
 Min
 Max
 Frameworks
 Types
 Addons
 NameGen

### Examples

```
CompanyType
	{
	Specialization		"Creative tools"
	PerYear			0.2
	Min			4
	Max			8
	Types
		[
			{
			Software	"Audio Tool"
			Chance		1
			}
			{
			Software	"2D Editor"
			Chance		1
			}
			{
			Software	"3D Editor"
			Chance		1
			}
		]
	Addons
		[
			{
			Software	"Operating System"
			Addon		"Joystick"
			Chance		0.05
			}
		]
	}
```

```
CompanyType
 {
 Specialization "Computer Operating Systems"
 PerYear 0.2
 Min 2
 Max 2
 Frameworks False
 Types
 [
 {
 Software "Operating System"
 Category Computer
 Chance 1
 Force True
 }
 ]

	}
```

## Personalities

Personalities control employee traits an inter office relationships. All employees have exactly 2 personality traits. All personalities will be merged with the pre-existing personalities in the game.

### Elements

 Personalities
 Incompatibilities

### Personalities and incompatibilities

Personality values include:

 Traits
 Relationships

The Incompatibilities list should contain a list of personality pairs that are incompatible, meaning they cannot exist in the same person.

### Traits

* **Good traits**: FastLearner, Independant, BigBrain, Humble, Capacitor, WalkItOff, ThisIsFine, Skyscraper, Sunshine, RGBThumb
* **Bad traits**: Stressed, Hypochondriac, SlowEater, NervousBladder, BumLeg, Forgetful, Cupholder, NeatFreak, SilentButDeadly, WalkInstead, UnderTheWeather, OldSole
* **Neutral traits**: NightOwl, BornLeader, FirmwareInc, SuperFocus, Unphased, JustTheFlu, Detached, Watch
* **Traits that also work for the founder**: FastLearner, BigBrain, RGBThumb, BornLeader, FirmwareInc, SuperFocus, BumLeg, Forgetful, Cupholder, Watch, SilentButDeadly, WalkInstead, OldSole, Capacitor, ThisIsFine, Sunshine, Skyscraper, Detached, NeatFreak, UnderTheWeather

### Example

```
PersonalityGraph
	{
	Personalities
		[
			{
			Name		TestPersonality
			Traits		[ WalkItOff ; SlowEater ]
			Relationships
				{
				Extrovert		-0.5
				TestPersonality2	1
				}
			}
			{
			Name		TestPersonality2
			Traits		[ Detached ]
			}
		]
	Incompatibilities
		[
			[ TestPersonality; TestPersonality2 ]
			[ TestPersonality2; Introvert ]
		]
	}
```