SCP Additions

WARNING: THIS PAGE IS BEING DESIGNED

This section is just now being built and designed. Please wait a little before real posting inside it or its linked pages and subsections.

Introduction

The main thing the Source Code Project do is adding features to the retail game engine. BLA, BLA, BLA

SCP Additions: List by Date

SCP Additions: List by Category

Posting Rules

Please follow the rules. Even if you don't agree with some of them, follow them. This section can grow huge and it can become a damn hell. So we need one and only set of rules. And we all must follow it.

No discussion here, please.

1. 1st. GOLDEN RULE: Be extremely brief.
   • Do not make long explanations within the lists.
   • In each entry Description section write a brief explanation.
   • If you need a deeper explanation for that feature put a link, (or links), in See section. Even create new pages if needed.
2. 2nd. GOLDEN RULE: Be extremely tidy.
   • As you can imagine, this Wiki section can become a mess quite easily.
   • Always put each new feature in both lists SCP Additions: List by Date and SCP Additions: List by Category.
   • Always check that each entry in SCP Additions: List by Date has a working link to SCP Additions: List by Category entry.
   • Always check that all the links in SCP Additions: List by Category work.
3. SCP Additions: List by Date posting rules.
   1. As they should be quite intuitive, please follow any other example you find here.
   2. This list is actually two lists:
      • Features that belong only to HEAD experimental builds.
      • Features that belong also to stable builds. This kind of features are also present in HEAD builds. These builds are the seed for official SCP releases (like 3.6.9).
   3. Be sure you know if the feature must go to HEAD Branch or Stable Branch.
   4. Be extremely tidy in the place and date you post. The list should be always kept sorted in descending date order (the most recent additions should go in the upper part of each section).
   5. If the CVS date for your feature doesn't exist, create a new one. Use Japanese YYYY-MM-DD format. So January 27th in 2007 should be 2007-01-27. (In this way the number of the date always grows when a day advances).
   6. Once you have located or created your date, post the feature as a sublist entry on that date:
      • Always start it with the link to the SCP Additions: List by Category entry.
      • If you want, you can also add a brief description to the entry.
4. If your feature is upgraded from the HEAD to the stable branch, please move it to that section, update the dates and also update SCP Additions: List by Category added date.
5. SCP Additions: List by Category posting rules.
   1. Please follow any other example you find here.
   2. Each feature here is a sub-sub-sub section. Ie., each new feature entry goes between ==== and ==== to make it appear in the Contents box at the top of the page.
   3. Each entry has four sections:
      • Description: A brief description of the feature.
      • Added in: Post the build or the date if known. If it is experimental write HEAD only. Examples:
        • Added in: 2006-12-28
        • Added in: 3.6.9.
        • Added in: 2006-12-28 HEAD only
      • See: Put the links here to related pages with deeper info about that feature. If you want to post a lot of info about your feature, create your own page and put the link here.
      • Usage Tips: In the future, creating a tips page somewhere in the Wiki is intended. In this section you could explain useful tricks. Put here the links to the tips this feature is useful for here.
        If you feel like it, you can even start that tricks page ;) . Some discussion can be found here.
   4. Please try to put every feature in the category you think that suits better. Even you can put it in two or more categories if you feel like it. But in this situation follow the next steps:
      • Only fill the four sections (Description, Added in, See and Usage Tips) in one of them. This would be the main one.
      • In the others, you will use the same name but ending with "(repeated)", "(repeated 2)" and so on. The main reason to do this is avoiding conflictive entries with exactly the same name.
      • In these secondary entries, just put a See section with a link to the main entry.
      • A "fake" example:
        • Mission features
          ...
          • Feature AA. (This would be the main one)
            • Description: Whatever...
              ...
            • Usage Tips:
          • Feature BB
            ...
        • Graphics
          ...
          • Feature AA (repeated). (This would be the secondary one)
            • See: Here you'd have a link to Feature AA
          • Feature XX.
            ...
   5. If you want you can use the next colour code to tell the addition importance:
      • Critical update. (This would be an extremely important update over retail behaviour).
        • Description: Whatever...
          ...
        • Usage Tips:
      • Common update. (Normal updates).
        • Description: Whatever...
          ...
        • Usage Tips:
      • Just a tweak. (This would be just a tweak over retail Freespace2).
        • Description: Whatever...
          ...
        • Usage Tips: