Link Search Menu Expand Document

Best practices

Mod compatibility

  1. If it can be done in a global script, do it in a global script. Combined with hooks, they are extremely powerful, possibilities ranging from creating new perks to UI scripting to prototype altering on-the-fly. While scripting does take a bit longer to get started, and hacking prototypes directly with GUI programs might look easier at first, consider that:
    • Scripts from different mods modifying the same thing can actually be compatible with each other. Binary files can’t.
    • Scripts can be version controlled and thus are much more easier to maintain.
  2. If you’re using set_sfall_return, always couple it with set_sfall_arg for the corresponding arg(s), unless you have a specific reason not to. Detailed explanation is available here.

  3. Pick yourself a 2-3 character modding prefix. Use it for:
    • global script names
    • global variable names and saved array names
    • debug messages

This will ensure (to some degree), that another mod doesn’t overwrite your scripts, doesn’t mess with your global variables, and that debug messages coming from your scripts can be distinguished easily.

For example, if you pick prefix “a_”, your script could be named, and might look like this:

    #define NAME "gl_a_myscript"
    #define ndebug(message) debug_msg(NAME + ": " + message + "\n")

    procedure start begin
      if game_loaded then begin
        set_sfall_global("a_myvar", 1000);


  1. Do not abuse set_global_script_repeat. Whenever possible, register your script as a hook instead. You can register the same procedure at multiple hook points, if necessary.
    • If you have set_global_script_repeat(300) in your script, you’re probably doing something wrong. That’s an invocation every 3-5 seconds, approximately.
    • If you have set_global_script_repeat(30), you are definitely doing something wrong. Look for suitable hooks harder, think of another way for implementing it, ask fellow modders for help.