Skip to content

VSH2-Devs/Vs-Saxton-Hale-2

Repository files navigation

VSH2 Logo by Nergal/Assyrianic

Current STABLE Version: 2.0.5

Master Build Status

Current DEVELOPMENT Version: 2.13.0

Develop Build Status

Current DEVELOPMENT STATUS updated 12/6/23

Transitioning devs, documenting and testing 2.13 for final fixes for release.

VSH2 Addons Repository

NOTICE: This readme will be updated soon. Thank you for your patience!

VSH2 is a rewrite of VSH1. VSH1 and FF2 both had a very bad gamemode framework using shoddy, hacky coding. I could even go as far to say they probably had no framework at all nor any real structure to its code.

VSH2 actually has a structured, event-based framework which combines the best features of both FF2 and VSH1 by not only having multiplayer boss support but also to make it easier to add new bosses and give them truly unique abilities & mechanics through giving the developer full, uninhibited control by code rather than strictly config files.

FF2's purpose was to be very easy to add bosses in a generic, cookie-cutter manner. Of course there's a trade off: FF2 is alot more difficult, if not impossible, to truly customize boss mechanics & abilities without having to recode parts of FF2 itself. VSH2, since it requires at least some experience with SourcePawn, is somewhat more difficult for a newbie to create new bosses than if they were to use FF2 but choosing VSH2 rewards taking the harder route by allowing you to control damn near every individual boss behavior and logic.

If you do require help in setting up the bosses or at least need some info on the API for boss building, then take advantage of VSH2's vast API by having a look at the VSH2 wiki

NB: VSH2 will work perfectly fine as-is out of the box as a VSH1 replacement, but it was designed with capable SourcePawn developers in mind to make the most out of the coded-from-scratch framework!

Why VSH2?

  • VSH2 was created to facilitate easier boss additions to a VSH-esque gamemode while having extensive customisation capabilities, even more so than FF2.
  • VSH2 operates through a series of Event Handling functions across different Boss, non-Boss actions, and clear cut API which allows developers to control boss code at will and with ease.
  • VSH2's game state is controlled through a singleton instance of the VSHGameMode methodmap which allows for easier management of the entire gamemode's state.
  • VSH2 has a vast API to build bosses as wide reaching as your imagination and TF2's limitations!
  • 'ConfigMap' allows you to not only have the power of VSH2's API but have FF2-like configuration for a powerful combination of customization through code and config alike.

How do I get set up?

  • VSH2 uses the same map configurations as FF2 and VSH1 and this is for compatibility reasons.
  • Dependencies: TF2Items, MoreColors, ConfigMap (MoreColors + ConfigMap are part of VSH2 repo).
  • Optional Dependencies: TF2Attributes, SteamTools
  • Compile the VSH2 script code with spcomp or upload the prebuild SMX binaries; which ever method you use, move the SMX binaries to your server's SourceMod 'plugins' directory (addons/sourcemod/plugins).
  • Move the config files into addons/sourcemod/configs. Make sure to keep the folder structure that's in the configs.
  • Move the translations folder into the server translation folder.
  • Read the Wiki to get started making your own boss!
  • If you're moving from FF2 to VSH2, we also have the VSH2-FF2 Compatibility Engine, use this FF2 subplugin library, courtesy of 01Pollux

Credits

Contribution Rules

Code Format:

  • Use New sourcepawn syntax (sourcemod 1.7+).

  • Statements that require parentheses (such as 'if' statements) should have each side of the parentheses spaced out with the beginning parens touching the construct keyword, e.g. construct( code/expression ).

  • Single line comments that convey a message must have 3 slashes: ///.

  • Multi-line comments that convey a message should have an extra beginning star: /**.

  • Properties, functions, & methods smaller than 30 lines of code should have the beginning { brace in K&R C style, for example: ret func() {.

  • Local variable names should be in snake_case.

  • Property names must have a single-letter prefix of their type.

  • Functions, methods, methodmaps, enums, enum values, must be named in PascalCase. Pascal_Case is also acceptable.

  • Enum values used as flags may be upper-case.

  • Named constants rules:

    • Integer constants should be placed in an enum, anonymous enum is fine.
    • Float constants that don't have a fractional part (like: 1.0) should be enum constants that are added with 0.0 at their location(s) of use.
    • Float constants that do have a fraction part (like: 3.14) should be preprocessor defines.
    • string literals should be preprocessor defines.
  • Chained if statements aren't bad but if the data is only ever be one thing at a time, use if-else if statements.

    • if you do if-else if statements on a single piece of data, use a switch statement.
  • Bit fields/flags lets you use a single int as 32 bools. Useful if an element can be multiple aspects at once.

    • 1 << n where n is from 0 to 31.
    • To reverse the above operation. use IntLog2 in int_log.inc: n == IntLog2(1 << n)
  • No pre-increments ++i, i--, Post-Increments only i++, i--