Help:Editing guidelines

From LBA File Information
Jump to: navigation, search

This page describes standards, structures and techniques that are utilised in this wiki. It is recommended to conform to these in order to maintain information consistency and accessibility. However, nothing bad will happen if you do not. The standards are not tightly settled nor thoroughly thought, however they were changed many times through the page development, and are still imperfect. This means that they may changed again if there is a need for that. This also means that the rules may be broken whenever it is reasonable. Feel free to discuss the issues and ideas on the discussion pages.

Remember that you can always look at the sources of already existing pages, copy their code and modify it to make new pages. You don't have to know all of this all the time (in fact I don't!). This page exists mainly as a reference of how it should be done.

Also, some solutions used in the LBA File Info wiki are not quite well cooperating with the wiki's native caching mechanism. This may cause some pages not to be refreshed when they should be. If you sumble upon the case (particularly after the edit of a page), you can click the button next to the View history button, and choose Refresh from the menu.

Namespaces[edit]

Currently the FileInfo uses three namespaces (not counting the wiki maintenance namespaces):

  • LBA1 - for LBA 1 contents
  • LBA2 - for LBA 2 stuff
  • Main - for common and other stuff

The rule is simple: everything that belongs to only one LBA version should go to appropriate LBA namespace, everything that belongs to both LBAs or does not belong to any of them should go to the Main namespace. Here are some examples and exceptions:

  • HQR files and entries always go to LBA namespaces, because LBAs do not share files, even if some files have the same names (like ress.hqr, which has different content). This allows some entries to have identical names and still be described in different pages (like Main game palette).
  • Programs always go to the Main namespace, because even if a program supports only one LBA version, it still does not belong to that version (e.g. support for the other version may be added in future).
  • A File type should go to one of the LBA namespaces if it is used by one LBA version only, but it should go to the Main namespace if it is used by both LBAs. If both LBAs use a similar (but not identical) format for the same purpose (like isometric scene), it should be split into two pages with the same name, but each in its own namespace. In this case they may share the specification (that points out differences).

Categories[edit]

FileInfo categories not only organize content, but also, for HQR entries, define belonging to a specific HQR file, that's why in some cases it is important to maintain categories properly.

In automatic HQR presentation model (see below) each HQR file entry, must be in a category named identically as the HQR file it belongs to. For example, and entry (page) named Main game palette that belongs to Ress.hqr file (from LBA 1) must belog to Category:LBA1:Ress.hqr, otherwise it will not show on the LBA1:Ress.hqr page. This does not apply to manual presentation model, but existing entry pages should also follow this rule for consistency (and for easier possible switch to automatic model of that HQR file in future).

The main category structure is following:

  • LBA1 - everything related to LBA 1
  • LBA2 - everything related to LBA 2
  • HQR files - HQR file and entry pages
    • LBA1:Anim.hqr
    • LBA1:Body.hqr
    • LBA2:Anim.hqr
    • LBA2:Body.hqr
    • ... and so on
  • VOX files - same as HQR files
  • ILE files
  • OBL files
  • File formats
  • Programs

In the future there will be categories for images and other files, but there are none for now.

File format pages[edit]

The file format pages describe various file formats - all useful formats that exist in LBA installation directories (though describing some formats, like EXE, is probably pointless), and those that can be extracted from them. Infobox format template exists to provide infobox for the format pages. Example usage:

{{Infobox format
| extension = LSP
| lba1 = true
| lba2 = true
| colour = E0E000
| defaultsort = image
}}
  • extension - is the commonly used extension the files of that format have when stored on a disk. Most of the extracted files extensions are made up by the LBA community.
  • lba1 and lba2 - indicate occurence of files of this format in specific LBA version.
  • colour = colour the extension will have in various lists (like entries list in a HQR page). The colour is in HTML notation, but without the # mark (named colours are not allowed).
  • defaultsort - sets the wiki's {{DEFAULTSORT:xxx}} directive, which is used to change the way the page will be sorted in category listings. In this example, without defaultsort, the page would appear under L (because the page name is LBA image). The defaultsort param makes it appear under I.

Format pages should contain format specification, if it is known.

HQR pages[edit]

Each HQR (VOX, ILE, OBL) file has its own page, which contains description, various information, and list of entries stored inside the file. There are two presentation models possible:

  • Automatic model - works so each HQR entry has its own page, that defines its properties, and HQR page contains only general Semantic Mediawiki query that fetches all appropriate pages automatically. This model highly depends on the Semantic Mediawiki extension features. Entry pages define properties, like index, name, extension, etc. for each entry, and HQR page reads the properties and puts them into the entries table. This model requires all entries of the HQR to have their own pages.
  • Manual model - works so each entry is described manually in the HQR page's source. This makes it easy to create HQR pages containing hundreds of entries, because the entry pages do not have to exist. Disadvantage of this model is that when a described entry page is created (to give more details on that entry), the HQR page will most likely need an update with that entry. Also if the file format of an entry is changed, one will have to manually update the HQR format counters.

For easier creation a special template is present, called hqr page. Below is an example usage (types list is not complete):

{{hqr page
| lba = 1
| providers = [[provider::El Muerte]], [[provider::alexfont]], [[provider::ChaosFish]] and [[provider::Zink]]
| normal = 53
| blank = 1
| type1 = Sprite actor data
| type2 = LBA1:Holomap location file
| type3 = LBA1:Animation
| type4 = In-game font
| text =
This file contains various game resources: the font, textures, some generic models, etc.
}}

The above is an example of the automatic model. The model setting is not present, because it is automatic by default. It takes the following parameters:

  • lba - LBA version (1 or 2)
  • providers - list of people that discovered the information about the HQR file. Each name must be an SMW property set statement. In future this may be used for statistics, and browsing information by providers.
  • normal, blank, repeated, hidden - describe number of entries of each type in the HQR (values of 0 can be omitted). Hidden value is an exception, because it does not have to be a numerical value. For pages like LBA1:xx_005.vox the number of hidden entries may vary between language versions (that page in fact describes three files: en_005.hqr, de_005.hqr and fr_005.hqr), so the hidden field contains range 1 - 3 (hidden entries are not included in the total count).
  • type1, type2... - list of file types that exist inside the HQR, this list is used to build file types table (counts are computed automatically).
  • text - description of the HQR file. It may be long, may contain formatting, wiki text, and templates. The description text should not appear outside of the template, because the template puts entries table and providers list after it. Thus, there is nothing more a HQR page should contain.

The example below describes a manual presentation model (types list is not complete). It uses the same template, but in a different way. Most of the new template parameters apply to both automatic and manual modes.

{{DISPLAYTITLE:LBA2:xx_gam.vox
}}{{hqr page
| ResType = VOX
| mode = manual
| lba = 2
| hqr file = (EN,DE,FR)_gam.vox
| normal = 47
| hidden = 1
| blank = 250
| type1 = LBA2:Wave file | count1 = 48
| text =
This file contains ''item found'' description voices.
}}
  • mode - defines the presentation model (template mode). In this case the mode must be explicitly set to manual.
  • ResType - defines resource file type (HQR, VOX, ILE or OBL). This is used so that breadcrumbs box will display link to the proper resource category.
  • hqr file - defines name of the HQR file the page is for, if the file name is different than the page name. This is also used only for breadcrumbs. This parameter is necessary only if the HQR file name cannot be directly used as a wiki page name, because of the underscore "_"character in the file name. Wiki engine uses the underscore as a replacement for space and vice-versa, so if a page is named with an underscore, it will be displayed with a space instead. If the hqr file is defined, the breadcrumbs will use it instead of the page name. Wiki also always capitalizes the first letter of each article, and this parameter also solves that, if necessary. In connection to that, there is the DISPLAYTITLE magic word before the template, which does the same as hqr file param, but for the shown page title. This one uses the wiki built-in mechanism to allow for overriding default page title display conventions. Note that this can be used for these two issues only - capital first letter, and spaces instead of underscores. It will not work if the desired display title has more differences from original page name (that's why the explicit namespace is required here).
  • count1, count2... - in manual model it is necessary to manually define counts of the file types in addition to type1, and so on.

Note that in the manual model there is no providers parameter. This is because the providers must be described manually at the end of the page. But before that, and after the hqr page template, the actual entries must be defined. For that, the two templates exist: ht and ht auto, which can be mixed on one page.

Template: ht[edit]

Ht template defines one row of the manual entries table (i.e. one entry). Its params are following:

  1. Entry index (always starting with 0)
  2. Entry type (Normal, Hidden, Repeated or Blank)
  3. File type - name of the file type page (e.g. LBA2:Wave file)
  4. Entry function - describes what purpose the entry serves in the game. From this text a link to the possible entry wiki page will be created automatically (thus it is important to keep it unique across HQR files within namespace). If the param is left empty then no link will be created, and in the function table column the word Unknown will be put.
  5. Entry content - should be a short description of what's inside the entry (e.g. Adeline logo). This field does not have to be unique. If empty, the Entry function field will be used (but without linking).

There are also named parameters that can be placed in any position between numbered params:

  • r - for repeated entries only - this param should be set to index (starting with 0) of the entry this one repeats. The index will be shown in the Type column.
  • cl - abbreviation of Content Link, it can be set to 1. If so, the link to the entry page will be created from the Entry function field, but the target page name will be taken from Entry content field.

Example:

{{ht| 35|Normal|LBA1:Animation|Animation  35|cl=1|Twinsen fighting with sword (normal mode) animation}}
      ↑    ↑          ↑             ↑                   ↑
    index type    file type   entry function      entry content

Template: ht_auto[edit]

This template is much simpler to use than ht template, because it is used for entries that have their own pages (so it can take all the information from the page it describes. It takes only one parameter:

  1. Page name - name of the page associated with the entry (including namespace).

Example:

{{ht_auto|LBA1:Twinsen getting hit 2 animation}}

That's all. All necessary information will be taken from the page. The only care must be taken to place the rows in the correct order (they are not sorted in any way upon display).

Table structure[edit]

Defining the entries in manual model does not involve only ht and ht_auto templates. What is also necessary is the proper entries table opening and closing, which can be done with the templates: Hqr entries list header and table footer, which do not take any parameters.

Information providers[edit]

In manual model it is also necessary to manually specify information providers, so that they will appear at the bottom of the page. This can be done with the Providers template, that requires provider specification just like in the automatic hqr page template.

Manual model: full example[edit]

The example below shows all necessary entries and providers definition elements.

{{hqr entries list header}}
{{ht auto|LBA1:Twinsen standing (normal mode) animation}}
{{ht auto|LBA1:Twinsen walking (normal mode) animation}}
{{ht| 2|Normal|LBA1:Animation|Animation  2|cl=1|Twinsen fighting with sword (normal mode) animation}}
{{ht| 3|Normal|LBA1:Animation|Animation  3|cl=1|Twinsen crawling animation}}
{{ht| 4|Normal|LBA1:Animation|Animation  4|cl=1|Twinsen spilling flask animation}}
{{ht auto|LBA1:Twinsen falling animation}}
{{ht| 6|Normal|LBA1:Animation|Animation  6|cl=1|Twinsen standing (athletic mode) animation}}
{{table footer}}

{{providers|[[provider::El Muerte]], [[provider::alexfont]], [[provider::ChaosFish]] and [[provider::Zink]]}}

Entry pages[edit]

Each HQR entry may have its own page, but it is not required. If the page exists, ht auto or automatic model can be used for the owner HQR page, and all necessary properties should be defined. For easy describing the template entry page is available. Here is an example:

{{entry page|1|LBA1:Ress.hqr|0
| content = 
| entry type = Normal
| file type = Colour palette
| size = 768 bytes
| compression = 0
| providers = [[provider::El Muerte]] and [[provider::alexfont]]
| text = 
This is the main game palette which its used for all the sprites, bricks, 3D models and menu background image.

=== Content ===
[[File:PaletaLBA1.png]]
}}

The main and required parameters (right after the template name) are:

  1. LBA version - 1 or 2
  2. Owner HQR file (including the namespace)
  3. entry index - always starting with zero

After that the named parameters may be defined. They are optional, but highly recommended:

  • function - will be shown in the Entry function column in the entries list.
  • content - will be shown in the Entry content column in the entries list.
  • entry type - Normal, Hidden, Repeated or Blank
  • file type - type of the extracted file (name of the file type page)
  • size - original size of the file
  • compression - original compression of the file (0, 1 or 2)
  • providers - list of people that provided information about this entry
  • text - description of the entry. It may be long and may use wiki text formatting. In the above example there is a header and a picture. Picture, sound, and other files may be uploaded to the wiki and attached to the pages. Refer to the Mediawiki help for more information.

For the entry pages there should be no text outside of the entry page template, because it would appear after the providers list, which we don't want. All necessary categorization is done automatically.

Program pages[edit]

Program pages use the infobox program template for infobox definition, and the page content can be written below the template. Example:

{{Infobox program
| author = El Muerte
| homepage = http://magicball.net/
| progpage = http://www.magicball.net/downloads/programs/development/lbadecomp_1_2
| download = http://www.magicball.net/disknode/get/1663/lbadecomp12214.exe?download
| source =
| formats =
* {{supports format|High quality resource}}
* {{supports format|Voice package}}
* {{supports format|LBA2:Island package}}
* {{supports format|LBA2:Island object package}}
* {{supports format|LBA image}}
* {{supports format|Colour palette}}
* {{supports format|LBA1:Dialogs file}}
* {{supports format|LBA2:Dialogs file}}
}}
LBADeCOMP is a LBA DeCompiler. It allows you to extract the data stored in the LBA files. This package includes some viewers to view some of the not so common extracted file formats.

You will need to install [http://www.magicball.net/disknode/get/1662/lbadepak.exe?download LBADePak] first to be able to run LBADeCOMP.

The infobox program template takes the following parameters:

  • author - name/nickname of the program's author.
  • homepage - address of the author's/program's homepage (main page).
  • progpage - address of the program description page (in the author's service). If the program page does not exist, put here a link to the page where the program is listed in the author's service, or just leave this field blank.
  • download - address to download the program directly (if possible). Please do not put the direct download link if the program's author does not allow such links!.
  • source - address of the source code of the program (if available) or a page where source code can be downloaded.
  • formats - list of file formats (this wiki pages) supported by this program (for either viewing or editing). This list should use the supports format template that manages property creation. This way the program will be included in infoboxes for all files of the defined types (and file type pages).