Silverstag Source v0.26 - Rev 237

Greetings,

Since my time working with the Floris project I've been a fan of making source files freely available for tweaking, but I've been rather sluggish with getting that done for Silverstag.  One hurdle was making sure I had permission to release everything as OSP that was not already open source or specifically designed by the Silverstag team.  With that having been done the only roadblock was deciding on the level of release I wanted to allow.  I will designate my views below on what I request fellow modders do with the source files supplied.


FREQUENTLY ASKED QUESTIONS:

1. Can I make a completely new mod using Silverstag as a base for it?
YES.  I ask the following things be done though:
[*] The new mod may not use the Silverstag name as part of its name to prevent confusion.
[*] The Silverstag team should be credited for their work.
[*] I'd appreciate being made aware of your mod project.  I'll even help promote it within Silverstag's forum.

2. Can I make a sub-mod / patch for Silverstag and host it within the Silverstag forums?
YES.  I actively encourage this.  Sub-mods may retain the Silverstag name as long as it is clear that it is a sub-mod (example: "Silverstag: <sub-mod name>" or <patch name> (Silverstag v0.23 Patch)).  I'm not as concerned with how you name it such as that it is clear to the community what it is and which version of Silverstag it is compatible with.

3. Can I pull a feature from Silverstag to put in another mod?
YES.  Please note that Silverstag is heavily reliant upon the Warband Script Enhancer (WSE) to function and each of its features are very interrelated which makes it difficult to pull out an individual one.  Any features pulled out that are not specificly created by the Silverstag team have been credited within our download thread on the Taleworlds forum.  Please ensure you're giving credit to the correct folks and if you're unsure I'd be happy to answer questions of this nature.

4. Do you provide technical support for any of the above?
NO.  The source files are well segregated into modmerger kits and generally follow a naming convention that will point you in the right direction of where to look.  If you're unsure where something is after looking I can help you with that, but I'm generally not interested in giving detailed instructions on how to remove / alter a feature within the mod.  It really depends on the number of and nature of the requests.


MODULE SYSTEM SETUP NOTES:
[*] "Build_module" is the main compiling batch file to use.  The build_presentations & build_troops ones are used for quick partial compiles / reloads when only working within those types of files.
[*] Check the "slots" excel file within the documentation folder to see where slot numbers have been used by the various source kits.  This information should be up to date.
[*] When scripts are used from a source not within the main module_scripts or the kit you're currently within it will generally have a comment following stating which file to look into.  A common exception to this are "gpu" scripts which are found in the generic presentation utilities kit for building interfaces.
[*] There are a number of kits that are retained solely for preserving save games and will be removed upon the next save breaking update.  Some of these caused issues while integrated and just have not had their resources / code removed entirely or were left in a disabled state.  Beta Testing Suite, Dynamic Damage and Emoticons are all examples of this and should be left disabled.

Thanks for your interest and I hope you can gain some use out of the materials supplied.  I look forward to seeing what creations you come up with and would love to hear about them for possible inclusion into the Silverstag mod.


Good Luck,
Windyplains

Click to expand...

Caba'drin wrote a great syntax tutorial that might be of interest if you haven't read it.  There's stuff in there I wish someone had told me before I had a ton of trial and error figuring it out on my own.

reg# variables (example: reg1, reg0,...) are for holding integer values independent of a script.  In a sense they're like global integer values that do not have a unique name (other than the reg name).  These are the only way you can express an integer within a script.  By assigning reg1 a value and then displaying it as "{reg1}" within a script that number shows up.  There are up to 66 of these reg values.  I hold to a fairly similar usage for their number ranges that I would recommend, but you don't have to.

Spoiler: My Numbering Scheme

reg0 - reg9 = These are used primarily in scripts for passing information back and forth.  That's why most of my scripts store their information to reg0 or reg1 and only use the higher ones as more are needed.

reg10 - reg19 = These are rarely used and are intended as more of a backup when I want to pass information that isn't likely to get overwritten.

reg20 - reg29 = I use these as "display" values.  If I want a variable stored for display to the player then these are typically where I am going to store them.  This way there is less chance of anything else inadvertently overwriting something I want displayed as I calculate things out since nothing else would use these.

reg30 - reg39 = These are similar to the reg20's, but instead they're used to display debugging information.  This way I can store things at various points in scripts to display as debug info without the information getting overwritten or clashing with data I want to display to the player.

reg40 - 49 = These are kind of like the 10-19 ones and are not often used, but if I want a place to store info to hold for a medium amount of time (across several scripts) this is where I would do it since not much uses this range of variable it isn't likely to clash.

reg50 - 59 = These are where I'd store information used in dialogs to handle showing one bit of dialog or another.  Since no script uses them, no dialog uses them to display information and no debugging code uses them then they're fairly safe for holding longer term info.

reg60 - 66 = I almost never use these and they have specific uses if done so.  s66, for example, holds the title the player should be referred by.

s# variables (example: s1, s2,...) are module system's string variables.  Unlike reg variables that can be stored in a local variable like ":variable", these are the only ones that can hold text strings.  So if you store "@Hi!" in s1 by using (str_store_string, s1, "@Hi!"), then s1 could then be displayed within a string as "{s1}" and would output "Hi!".  If you aren't clear why the @ is in there it is just how the module system designates that what is found within quotes is intended as a string.  You could then copy s1 to s2 by doing something like (str_store_string, s2, s1), or copy it to itself with additional information like (str_store_string, s1, "@{s1}.  Some additional info.").  There are 66 of these as well and they follow the same numbering range as the reg# ones.

When I mentioned why @'s exist as they do it might make more sense to look at it this way:
1.) ":data" would become a local variable called "data" within a script.
2.) "$data" would become a global variable called "data" within the entire module.
3.) "@data" would become a string holding the text "data" and either is immediately displayed as part of an opcode or is stored in a string register like s1.

fp# variables (fp1, fp2, ...) are floating point variables.  They're also available for use throughout the module and are the only way to hold a variable with a decimal point.  Aside from holding a non-integer value they work almost identically to reg# variables.  The one difference is that they need the opcode (set_fixed_point_multiplier, #) to designate how many decimal places you'd like that value to go to.  Typically this is either 100 or 1000 throughout the entire module.  These aren't really needed most of the time as you can simply multiply a reg# variable by 100 or 1000 and then later divide it by that mount to get what you need.  Since you can only set one fixed point value this means that every floating point variable or function is now using that scale until it is set to another scale.  That can make a big difference when doing interfaces which are typically set to 1000 and then having a script run that tries to set it to 100 (now things are 10 times bigger or out of place on your interface).

Click to expand...

Another trick a person might see within strings is something like "@{reg1?Yes:No}".  This simply means that if the value of reg1 is equal to 1 then output "Yes" and if it is not then output "No".  It doesn't matter what reg# variable I use here as the first half of the string following the ? will always be the output on a 1 and the second half will always be the output when our input value is not a 1.

Click to expand...