Usage requirements and official guides

[Vornne]

Requirements for use:

Any code left over from the Native module system remains the property of TaleWorlds, with license or usage requirements not specified. The majority of the code is written for this mod, by Vornne (Steven Schwartfeger), with some inspiration from the Native code: the "legal" license used is the "3 clause BSD" (or "BSD simplified"), which seemed the closest well known license to what was wanted. To explain in plainer language the requirements for using the module system in your project:

• The license notice must be kept when redistributing to other people, with explanation of what it applies to if necessary; giving credit to Persistent World or the individual contributors in forum announcements, documentation, or similar.
• The name "Persistent World" or close derivatives or abbreviations must not be used without permission as your module name or part of it, and the forum announcements or similar must not be designed to deceive people into thinking that the project is an official version of Persistent World.
• Using the same module directory name as an official release on a dedicated server would only be permitted for minor bug fixes and enhancements that seem certain not to cause compatibility problems with the corresponding official module (no changes that require players to patch their clients). Server hosters using a module tweaked from an official release should assist in fixing related bugs reported while playing on that server, whether by fixing the scripts, revealing the changed parts, or reverting the changes.

Spoiler: Overview of the changes from Native

The PW module system is an almost complete rewrite from the Native one released by TaleWorlds, with a some files like module_animations, module_meshes, module_particle_systems, module_skills, module_skins, module_sounds, and module_scene_props, being mostly reformatted versions of the Native files, since they are closely linked with the artistic resources that PW uses, but the other module_ files being either emptied or rewritten almost from scratch. The files starting with header_ are mostly just reformatted, since they are mostly constants hard coded into the game engine. The python scripts for building the module system, starting with process_, have been rewritten for speed and better error handling.

The art resources (textures and .brf files) are almost all derived from Native Warband resources, so are available for use under the above conditions with an extra one also: they can only be used for Warband mods (or Napoleonic Wars, since it requires Warband), not mods for the original Mount&Blade, With Fire and Sword, or other games entirely.

Suggestions:

While it is not necessary, open source development using a fork of the Git repository is recommended, and more likely to get assistance from me regarding problems or scripting suggestions. Even when keeping your changes private, the use of Git is strongly encouraged: it allows you to store and visualize exactly what changes you or anyone else made to module system files, allowing easy updating and merging with new official versions (unless you changed the same part of a script, but still it shows both versions for manual merging)

Note that if you decide to keep your module system changes private, once the compiled module is released, it is very easy to convert the module system .txt files back into python based operation lists, especially if the vast majority of the module system is publicly available from the official PW repository. If people seem to have copied code from your module into theirs without permission then released it, you should only complain if the compiled opcode list is substantially identical (likely simple copy and paste): you can't copyright an idea, only the particular implementation; if there is only one or very few possible ways of implementing an idea in the module system, you can't "patent" it - there is no way to tell whether the other person legitimately created it independently.

Spoiler: Some basic principles of the current official design

• Since the Mount&Blade Warband game engine is mainly suited to medieval combat simulation, the PW game mode is also based around it.
• Most other main features are designed to be complementary to the combat system, only adding complexity if the overall game benefits from new situations, motivations, and player immersion. An example could be the crafting system: it would be possible to add many different processing steps and items, replicating actual historical processes more accurately, but if there are no new dynamics caused that affect other parts of the game, it could turn into a boring, repetitive, detached, RSI-from-too-much-clicking mini game.
• The scene terrain and objects (props) are designed to be fairly static within the parameters set by the scene maker: the Warband engine has many limitations and performance problems with spawning or changing scene props as a feature triggered by player interaction.
• Instead, the game is designed so that the players can freely interact and compete with each other as the main "content", within a fair and unbiased framework of game code rules. In other words, instead of playing a preset story line designed to carry the player along as the central hero, each player can be a hero, villain, lackey, or victim for the other players, depending on their own skill, choices, and sometimes luck. Human AI "bots" are intentionally not included for being too unlike real players in behaviour, being inevitably treated like very stupid animals in human shape.
• The game world is totally refreshed from scratch after short periods of time from days to weeks, for multiple reasons: so people can start playing and continue intermittently without large disadvantages compared to players with nothing else to do; to encourage everyone to try different ways of playing all the different parts of the game content, rather than laze around as their ultimate character after a few weeks grinding and power-leveling; and to keep the game world environment consistent with the players in it and their equipment: if a character has a full suit of plate armor, the scene will contain the necessary resources and stockpiles, and the circumstances needed to craft the armor pieces must have happened some time in the unbroken history played out in that mission - otherwise, long term players could have certain equipment with resulting abilities that are not available to anyone else, because the scene (or environment) is different.
• None of the available troop types are sufficient to be totally self reliant but powerful; all have some drawbacks which are significant to some area of normal play: this is because players (of computer games especially) will as a general rule prefer not take risks working with other players unless there are major game play reasons, even though the actual potential for enjoyment can be much higher whether the interaction goes well or badly (being tricked, attacked, or unexpectedly helped can all create interesting challenges or situations to respond to).

If your first idea is to try make a revolutionary new game based on PW with some mix of the following concepts: everlasting character saving, perfectly secure storage of large amounts of game items, entirely optional and consensual combat, a large range of AI monsters to fight, and ever more ridiculously "ultimate" items to loot, stop and think: that sort of game has been done hundreds of times before, so consider just playing your favourite MMO instead, and save yourself the massive amount of work developing that type of game requires.

By removing most ways that players can affect the game world and each other, the requirement shifts from players giving each other enjoyment using simple items and abilities in a sandbox environment, to the development team needing to repeatedly add more content in the form of levels, skills, monsters, items, dungeons, and whatever else, to keep the players interested (you can't hope to compete with WoW and the like in that way). The Warband engine has many aspects which make it unsuitable for that type of game compared to basing on another available engine or game: the multiplayer mission environment is conspicuously designed for fast paced combat, not huge worlds, storing and loading many game objects in a database, complex text based features, fancy user interfaces, etc.

 

[Vornne]

Git repository link:

https://github.com/vornne/pw_module_system

This is where the official repository is hosted: when you "clone" your own local repository all the data is downloaded, so you can store all your changes privately on your local computer. Optionally, you can create a github account and "fork" the main repository, to have a place to upload your changes for others to download.

Official guides:

Installing and setting up Git: using the "Git Extensions" graphical user interface.
Editing and building the module system: set up a text editor, Python, and your new module directory.
Common Git repository operations.

Adding basic items and scene props: simple beginner guides for common changes to a module.

Git command line aliases: for advanced users.

External guides:

An Introduction to Module System Syntax and Usage: a good reference for basic understanding of the module system. Note that parts might not apply to PW or be slightly different.

 

[Vornne]

Reserved.