Xelerus Rules and Standards

See also: api_version

In your Transcendence extension's XML file, you must specify the version of the Transcendence API that your mod is using. Only version=1.0 is compatible with Transcendence 1.01. When you upload a mod onto Xelerus, you should specify the version of Transcendence that your mod was made for.

These standards were created by the community and should be considered before creating a mod. Following these rules should ensure good mods that enhance gameplay.

The Xelerus administrator (Bimbel/bmbl) and all Xelerus moderators (Digdug, Taben) reserve the right to edit, relocate and remove any mod at any time without prior notice. If you have the feeling that any of your mods was edited, relocated or removed by accident, or you want further information on why your mod was modified, please join the IRC channel and discuss it with any of us.

These standards apply to most non-utility, non-source, non-tutorial and non-development mods.

• If your mod overwrites vanilla content, it should clearly say that it does this. If it is not a TC (total conversion), it should say what it overwrites. This will help cut down on conflicting mods, and help people determine if a bug in the game is caused by a mod or by Transcendence itself.
• Please use proper English, grammar and punctuation. If English is not your first language, feel free to add some text in your language to the English one.
• Do not take ships, items, stations, etc. out of the game with the intention of only changing some values and making it your mod.
• Do not upload several godmods onto Xelerus! Taking a weapon and adding 100k damage or the like not only breaks the game, it is also doable by every modder and shouldn't be uploaded.
• Refrain from creating mods that feature a single ship, item, station, etc. taken out of the game to be made playable. Instead, consider making a mod pack that consists of several of these and/or ships, items, stations, etc. of your own.
• Do not upload similar mods! If you have a mod that resembles another one, try collaborating with the creator of the latter to create a mod pack.
• Do not retain old versions of your mods on Xelerus. You should always have only the newest release uploaded to avoid confusion.
• If your mod is not finished, classify it under the Development category (in addition to any other category you would like to classify it under) so that it will not be deleted for being unfinished.
• Do not upload inappropriate content (e.g. things that are NSFW, contain crude language, etc).

Opinion / Reccomendation: If you feel that your mod has serious artistic value despite perhaps straying into inappropriate territory, please talk to us (the community at large) about it, on the forums or IRC. The game already deals with some dark matter like compulsion, drugs, human tradgedy. If you feel you really need a couple harsh words to make a character feel right, we might be able to suggest alternate scifi-ish terms or work out a community-acceptable way to mark for harsh language. Written/oral depictions of violence aren't even usally covered by ratings schemes AFAIK, and there are a few gruesome scenes at least partly described in the base game (eurpoa, the thing relating to volkov). Any sexual content can probably be reduced to implications of the level of primetime TV or say, the succubai in nethack. … Anyway, if you feel there's legitimate cause for content that your reaction is that you should ask about it, please do. It's the constantly swearing wingman whose ship is a d—o with t–s slapped on that's right out … —Weaver

These directory standards should be followed strictly to avoid conflicts with other mods and to keep the mods organized.

• Stand-alone mods should be packaged in their own directory such as: …\<transcendence dir>\extensions\[modname]\[modname].xml
• Subordinate mods should be packaged in a subdirectory of the mod that they modify. An example would be: …\<transcendence dir>\extensions\[primarymodname]\[subordinatemodname]\[subordinatemodname].xml
• Resources (these include image and sound files the mod uses) should be packaged as: …\<transcendence dir>\extensions\[modname]\resources\…

Opinions and Reactions: Hmm … I agree with point one. Some people don't expand zips with directories, so always put your stuff in a directory. It won't /hurt/ people who don't do this, it might just slightly irritate people who organize thier mods directory just so… — Weaver

Point two might make sense for subordinate mods published by the same person, for mod-mods made by third parties I'd probably go with \extensions\[mod]-[submod]\… if it's solely meant to extend the mod, stuff that just requires or optionally works with another mod I'm not sure qualifies for this? —Weaver

Point three, I don't think matters at all. As long as you guarantee a subdirectory, I don't think it matters if you put your images in a further subdirectory of that or not. I also don't think it matters if modname.xml is the same as the directory name. Extensions/myMod is the author's domain, let them organize the contents of it however they like. Of course if you have 100 image files you'll want an images subdir (or more), but if you just have 5-6 images like a playership or 2 images like an item mod might? I just stick those adjacent to the XML. — Weaver

A few basic extension quality standards are required. Not complying with these basic rules will likely result in a request to promptly fix your mod and re upload, and the mod possibly deleted if you don't respond or comply. These standards apply to most non-source, and non-development mods.

• You should have a registered UNID prefix for mods that you produce. If you use an unregistered prefix and doing so causes conflicts down the line, the administration may remove or edit your mod depending on the circumstances at the time, unless you can be reached for prompt updates.
  • The authoritative UNID prefix list is now UNID Database. There are two options for registering your prefix:
    • Go to the OTF UNID registration thread and request it.
    • Go to irc and ask for someone with Wiki editing rights (a fair number of them now) to add it for you.
• You should never use another modders UNID prefix. Doing so will result in prompt deletion. Using an active modder's UNID space is just asking for future conflicts even if you avoid their current used UNIDs.
  • The exception to this is patch mods or compatibility patches included in other mods. These are usually files intended to be used in place of other files, with the intent that a modified version of something in the mod be used. Currently this primarly applies to Playership Drones compatability patches.
  • When updating another modder's old mod to a new game version and/or expanding it — typically only done to mods created by people who have left the community and are no longer available to work with — the new version should be switched to use the upgrader's UNID space unless there's some prevailing reason not to do so.
• The extension must work. All mods that prevent transcendence from launching will be promptly removed from Xelerus, unless they are placed in the bugtesting and/or broken categories by their uploader. Even then, they are likely to be deleted if left unattended for a while and present no apparent value.
• Use legal UNIDs and prefixes only. These are hexadecimal numbers, the digits are 0123456789ABCDEF, other characters are invalid. For prefixes, you get one number in the range 0xD000 to 0XEFFF; for individual UNIDs you have the 65-thousand wide range of 0x<prefix>0000 to 0x<prefix>FFFF,
  • You can use lowercase or mixed case hexadecimal, however. 0xdeadd00d is the same as 0xDEADD00D. Just use what's readable to you.

Some mods have no need for graphics at all — mods that resculpt content the game already has into new variants or a new setting. Some mods don't need graphics but could be made a little more attractive and professional with them; mods that add items or stations where the focus is on what said objects do can get by with stock graphics (and in the case of weapons, pretty particle <Effects> are more important than other graphics).

And some mods nearly require custom — or at a minimum, recolored — graphics. Chief among these is are playership mods, where the coolness of the design is one of the main selling points.

For most mods we merely require that any added graphics not make anyone's eyes bleed. Demonstrations, proofs of concept, tutorials, and such are exempt from needing much in the way of graphical quality, as well. However, mods in the “graphics” category and mods that claim custom graphics as a selling point, we hold to a higher standard.

It's hard to produce 2D Graphics that fit the aesthetic qualities of Transcendence's stock graphics, so they may be judged a little more harshly than other graphics, but they are acceptable when done well. (I'll leave what done well means to someone who has more of a clue about 2D ships —Weaver)

The ships that come with Transcendence were all rendered from 3D models, so doing the same is the easiest way to make ships that look right in the setting. Some guidelines:

• Don't just slap a few primitives together and upload it.
• Don't just use a bland grey-scale. We know, some of the ships in the game are like that, but at least try making a version with a little trim color to help it stand out.
• Don't render in orthographic views (i.e. top, side, front). The full details for George's standard setup can be found here, but in general, you want your view to be above and a little back from your ship (as it faces north) with a shadow-casting light coming from the top-left-forward corner. The exact positions can be fiddled with if it does not look right. Add an extra light (preferably a shadowless soft one like Blender's 'hemi') in the front-right-slightlydown if the ship is too dark, and then add more lights as needed.

• Use 40 facings — especially for 3D ships — unless you have a good reason to do otherwise; small file size is not a valid reason. Ships with less than 40 facings do not look appealling, and the choppiness of turning in large 20 facing NPC ships (even those in the base game) is somewhat annoying.
  • If you give the AI control of a ship with more than 40 facings, make sure you test it extensively, as the AI is known to have issues piloting ships more than 40 facings.
• Make sure the ship rotates cleanly and doesn't wobble or jitter as it spins.
• Do not make a mod just to make a player ship out of a single free-to-use ship graphics resource. Either make a set of playerships out of a set of graphics, or add meat to your mod in another way.

Adding a spiffy new playership to the game is pretty cool, but there are some things you can do to make your ship really shine:

• (Playership drones interoperability note but I want to test something first —Weaver)

• Add NPC versions of your ship to the game. There are several ways to do this (should link to tutorials later —Weaver) and it can really liven up the game. Seeing new ships wandering around whatever stations are appropriate for them or patrolling about randomly adds a lot of new colour to the game even when people don't pick your ship, and generally makes the mod more memorable.

• Other options for robustness including encounters in which the ship attacks the player, or where a pilot of one of the new ship can be gained as a wingman.

These are the most strictly enforced of all standards. Any violations will result in immediate removal of the mod. Recurring violations may result in account removal at the discretion of Bimbel.

• No “stolen” mods. “Stolen” mods are mods that have been blatantly copied and re-uploaded and/or mods that have been incorporated into another mod without the original author's permission.
  • There is a desire in the community to allow for updated versions of mods that have been abandoned by people no longer around to work for them or ask about them, but there is no current consensus on how this should be handled except that all efforts should be made to contact the original author before proceeding.
• No mods that violate the laws of your country of residence.