More information still needs to be added but I'm making what is written public so people can start learning how to use it.

The MSC (Master Script Controller) is an addon created by [FoRcE]army_guy3 to allow you to load multiple scripts without them conflicting with each other.

It will automatically handle scripts to work along side mutations without conflicts IF you follow guidelines mentioned in this guide. If you stray from this guide you may break functionality of other scripts or the MSC itself.

You can find it here:
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=2203978515

This guide won't go over basics for creating your .nut files.

It also won't cover auto loading into the MSC. You can learn to do that here:
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=2255315135

Making our MSC script is basically the same as other scripts but there is a few rules we should follow.

1. Don't modify the MSC functions. These may be changed in future updates so hijacking them may break your script or the MSC itself.
2. Don't put any other data into the "scriptedmode_addon.nut". This scope will use the same as all the other "scriptedmode_addon.nut" addon files. This is a big no no as scripts with matching variable names will conflict. You may also end up breaking back end functionality of the MSC.
3. Don't modify back end MSC Variables. Some of them are global but this does not mean they should be changed.

After we've created our script we can test it by putting:


into our main script file.

The Main function is a place to safely run init for the execution of your code. You are not required to place it here but here is where your script is safely loaded into the MSC sub scripts.

Note that variables do not need to be placed in Main().

Example:

The MSC will warn if the Main() does not exist in the script but we can easily suppress this warning with:

Example:

The MSC_ScriptInfo will send data back to the MSC on load that gives it special instructions to use with that specific sub script.

The MSC system has been modified to work with default hook functions but in a way that allows all scripts to communicate.

Let's look at an example of the old way of blocking damage.

Normally in a mutation this is how it would look:

In the MSC script it will look a little different:

Keep in mind that currently the "origDamageTable" is blank. I will get around to adding it in later.

This script uses the MSC_ATD_ReturnType.Override_Block type. This means that it will send data back to the MSC saying we should block this damage from happening.

This next script will force allowing the damage to take place.


Both of these are fine but what if we don't want to allow or disallow the damage? Meaning what if we want other scripts to be able to choose this.

We can use the neutral "Normal" type.


The Normal type should be used in most cases unless if your script should force that specific action. Different scripts will conflict with Override_Block and Override_Allow so you should keep this in mind based on what your script does. A conflict won't cause an error but it may cause other scripts from not working properly with yours.

The MSC is designed to automatically connect events to your script.

Example:


This will print I LIKE PIE!!! to your console every time the round starts.

The MSC has a built in admin system for use in script hooking.

Let's do a simple example using the MSC system.


In this example we have two chat commands. "boop" and "givepie". The boop command requires admin in order to work properly. The givepie command does not. Keep this in mind for who should be allowed to use this function. For instance we only want admins to have access to kick.

This is all well and good but what if we want to target players?

The MSC has a built in system to handle this. Let's change our boop command to boop players instead of ourselves.


This example will boop the player found OR if you typed @All you could boop every player at once! Be careful because with great booping comes great responsiblity. o_o

The MSC can also be used with multiple player type arguments. This example pulled from MSC_AG3_AdminScript uses the teleport function. Notice how It includes two seperate playerList variables:


In this example we can see the second PlayerList is being used for who two teleport the players to.

The MSC can do much more but for now I'm going to end with this.

int MSC_GetSubScriptByIndex(int index)

returns the sub scope by index


---------------------------------

bool MSC_IsAdmin(string steamid)

returns if the player is an admin

---------------------------------

table MSC_GetAdminFlags(string steamid)

returns a table containing the players admin flags.

---------------------------------

int MSC_GetAdminImmunity(string steamid)

returns the players immunity level.

---------------------------------

string MSC_AdminFlagsToString(table admin_flags)

returns a string containing the admin flags

---------------------------------

bool MSC_HasAdminFlag(string steamid, string flag)

returns if the player has the admin flag

---------------------------------

array MSC_GetPlayerMatch_Managed(CTerrorPlayer player, string searchString, table commandFlags)

returns an array containing players that met the match conditions

---------------------------------

void MSC_CreateNewFilter(string trigger, table filterScope)

Creates a new chat filter type.

More information on how this works will be added later.

--------------------------------

void MSC_PrintMessageToClientConsole(CTerrorPlayer client, string message)

Prints message to client.

--------------------------------

void MSC_ExecuteClientCommand(CTerrorPlayer client, string executionString)

Executes command on client. This command has heavy restrictions for what can be executed.

--------------------------------

float MSC_PointDistance(Vector vector1, Vector vector2)

returns distance between two points.

--------------------------------

CBaseEntity MSC_GetPlayerAimTarget(CTerrorPlayer player, bool bOnly_players, float dist, bool bRestrictWorldSpawn)

returns entity that the player is looking at.

--------------------------------

table MSC_TraceLineAngles(table traceTable, float dist)

returns result of trace ray starting at start and angles and ending at distance.

--------------------------------

int MSC_Convert_StringToInt(string val, int defVal=-1, table error_out=null)

returns converted value if it didn't fail in conversion process.

--------------------------------

float MSC_Convert_StringToFloat(string val, float defVal=-1, table error_out=null)

returns converted value if it didn't fail in conversion process.

--------------------------------

table MSC_LoadSessionSettings(string subTableName)

returns session table by name.

--------------------------------

void MSC_SaveSessionSettings(string subTableName, table scriptSessionTable)

Saves the session table.

Note: This does not save to file. Once you leave the game.. It's gone.

--------------------------------

-----

MSC_AllowTakeDamage(damageTable, origDamageTable, ATD_Flags)
return MSC_ATD_ReturnType.Normal
return MSC_ATD_ReturnType.Override_Block
return MSC_ATD_ReturnType.Override_Allow

NOT YET ADDED-The origDamageTable will allow you to see what the table looked like before being modified.
-----

MSC_InterceptChat(message, player, nakedMessage, IC_Flags)
MSC_IC_ReturnType.Normal <-
MSC_IC_ReturnType.Override_Block
MSC_IC_ReturnType.Override_Allow

The nakedMessage variable will automatically remove the playername from the message.

-----

MSC_CanPickupObject(entity, CPO_Flags)
MSC_CPO_ReturnType.Override_Block
MSC_CPO_ReturnType.Override_Allow

-----

MSC_UserConsoleCommand(player, arg, UCC_Flags)

-----

MSC_BotQuery(queryflags, entity, defaultvalue, BQ_Flags)
MSC_BQ_ReturnType.Override_Block
MSC_BQ_ReturnType.Override_Allow

-----

MSC_AllowBash(basher, bashee, AB_Flags)
return MSC_AB_ReturnType.Override_Normal
return MSC_AB_ReturnType.Override_Bash_All
return MSC_AB_ReturnType.Override_Bash_None
return MSC_AB_ReturnType.Override_Bash_PushOnly

-----