+- Discovery Gaming Community (https://discoverygc.com/forums)
+-- Forum: Discovery Development (https://discoverygc.com/forums/forumdisplay.php?fid=7)
+--- Forum: Discovery Developers Forum (https://discoverygc.com/forums/forumdisplay.php?fid=183)
+---- Forum: Discovery Unofficial Development (https://discoverygc.com/forums/forumdisplay.php?fid=389)
+----- Forum: Discovery Mod Content Submissions (https://discoverygc.com/forums/forumdisplay.php?fid=33)
+----- Thread: System Submission Guidelines (/showthread.php?tid=2356)
System Submission Guidelines - Igiss - 02-07-2007
This thread contains rules for system submission. To successfully submit a system, all rules should be followed; if you need to violate some to improve your system's design, contact me and we'll see what can be done.
Before submitting a system, you must fill the checklist found here: http://discoveryfl.com/files/dsy_checklist.xls
Include the filled checklist with your submission. Use Microsoft Excel or OpenOffice Calc (latter is free) to fill the list.
These rules should be followed for everyone submitting new systems for Discovery. Please don't think that I'm too restrictive and trying to impose excess limits over your creativity (or laziness). Experience in inclusion Angel's and Dab's systems proved that it is a very lengthy and complicated process that takes more time than most other areas of modding. Please be patient, read the following two posts attentively, and make the life easier for yourself and for me.
Before submitting, include basic information on your system here: http://discoverygc.com/wiki/index.php/New_Systems
This file contains Discovery design information essential for system editing: http://discoveryfl.com/files/dsy_design.xls. This file also contains necessary infocard numbers that should be used for each system.
I will use CAPITALS for all folder names (not meaning that all folder names in your submission must be capital, just for convenience), and EW199 (ew199) as an example system name.
I. Files
DLL and EXE submissions are not accepted.
INI files that are present in original Discovery are not accepted.
Only INI files that were added by you should be included into submission. INI files should be placed in accordance to DATA directory structure (for example, if you are adding a new base, you should place it in DATA/Universe/Systems/SystemName/...).
Ship models, textures or other files should follow same pattern as INI files. Please do not submit modified Discovery models without an important reason. I have a right to use them in the mod, and modify to a certain extent (hardpoints), but I was not granted a right to use those models to create other models.
All other information should be collected into text files, one for each system you are submitting. The file should be named [system name].txt. More details below.
II. System files
System files reside in DATA\UNIVERSE\SYSTEMS\
Main ini file of the system (ew199.ini, for example) and main files for bases (SYSTEMS\BASES).
If you make exact copies of other bases in Freelancer Explorer, DO NOT submit any files from SYSTEM\BASES\ROOMS and DO NOT submit mBases.ini at all! You will find more details on this in the new checklist.
If you are changing mBases.ini and rooms, these files should be submitted too. All the rooms, and part of the mbases.ini you've changed. See how to submit partial files below.
III. INI changes
Usually Freelancer Explorer adds new entries to the end of your ini file. This is not true for main system file, that's why I ask you to submit it whole, not in parts.
For all other files, you can compare Discovery original inis (latest version) and your submission, and copy the part that you've added (or part that FLEx added for you). Copy MUST be precise and contain ALL entries for your submission. If you are not sure about some part, better include extra code than delete what might be needed.
For example, if you are adding a new base, the mBases.ini file that stores all NPC information will be changed. You should copy the part that's added by your base into a separate txt file. The file should be named mBases.txt and should be included in the same place where mBases.ini resides in DATA\...
IV. Infocards
Infocards are names and descriptions identified by a number. Infocards are usually referred to by
ids_name =
and
ids_info =
tags in the INI file.
Text that suits each number is entered in DLL files. I'm entering all DLL entries myself, that's why DLL submissions are not accepted.
Templates for the infocards with full XML synthax are here:
http://discoveryfl.com/files/infocards.zip
Use these to compile your own infocards.
For each new system, 100 infocard numbers are reserved. The first number is the system name (you can find the exact number in universe.ini). Second is description, later come other objects. Names and descriptions must have separate numbers and come with correct XML formatting.
For your system, use the numbers from XXXX11 and later. Numbers before XXXX10 are reserved. For example: you are editing Braunschweig system belonging to Rheinland Military Guard. The name ID of this system is 464000. Therefore, you can use numbers from 464011 to 464099 (preferably from the beginning). Remember, each infocard must have a different number, even if it's only a name.
Each base MUST have three infocards:
550505
name < the name
550506
stats < stats: population, amenities, gravity etc
550507
description < text entry for the base
stats and description are "tied together" with InfocardMap.ini file from DATA\INTERFACE. Part of this file that you've added must be included as well. description (490507) must not be listed in any files except for infocardmap.ini. In the system file, only ids_info = 490506 should be present.
Descriptions are not needed for all non-populated objects. For example, non-populated planets will have stats and description in one entry.
Let's follow our example.
In the EW199.ini file, following code should be included:
[Object]
nickname = EW199_01
ids_name = 550505
...
ids_info = 550506
...
In the ew199.txt, following text should be available:
550505
Name - simple string without any XML
550506
Stats in XML format
550507
Description in XML format
For the InfocardMap.ini, create a new InfocardMap.txt file and add following string:
Map = 550506, 550507
You don't need to add pre-existent infocards (like "Weapon Platform") name and description cause it's part of original DLL files. Freelancer Explorer will usually enter correct number in such situations.
V. How the whole submission should look like
Following files must be present in submission root:
infocards.txt
npcs.txt - optional, if there are NPC names
dsy_checklist.xls
comments.txt - optional, if you have comments
basetemplates.txt - file that lists base templates, in this format:
XX01_01_Base
Sample base name
copy from
Li01_01_Base
Manhattan
Following files must be present in DATA folder:
\DATA\Interface\InfocardMap.txt
\DATA\Universe\Universe.txt
\DATA\Universe\Systems\XX01\XX01.ini
\DATA\Universe\Systems\XX01\Bases\XX01_01_Base.ini
\DATA\Universe\Systems\XX01\Bases\(more bases here)
Following types of files are optional:
\DATA\Equipment\market_*.txt
When you add asteroid fields/nebulas:
\DATA\Solar\ASTEROIDS\
\DATA\Solar\NEBULA\
When you add custom bases:
\DATA\Universe\Systems\XX01\Bases\Rooms\
\DATA\Missions\mBases.txt
Once it's ready, read part V of these Guidelines, zip them all and send to igissmail@gmail.com.
VI. Submission Conditions
1. I cannot review or accept submissions that don't follow the pattern posted here. I'll spend less time adding content myself than trying to extract new content from free-form submissions.
2. I may delete, add, modify whatever I see fit. The only thing I can guarantee is that if a single line of your code will be used, you'll be listed in mod credits.
3. If you do not agree with these conditions, please avoid submitting anything for Discovery mod. Once submitting, you are automatically considered to fully agree with these rules.
System Submission Guidelines - Igiss - 04-04-2007
Design Restrictions
Yes, in red bold, and I'm not going to discuss those unless you provide a very good reason (or your system is not related to any factions, but then you probably shouldn't be creating it at all).
What CAN be added to faction systems:
1) Up to 4 bases, including pre-existent bases.
2) Asteroid fields. Fields should be properly set up for each Sirius region. For example, ice fields are not expected to be anywhere except the Barrier. Stone asteroids might be anywhere. Also, don't use mined asteroid models.
3) Encounters of friendly guardian faction and base NPC faction (Lane Hacker Guard fighters and Lane Hacker traders, for example). In the case of phantoms, nomad encounters (hostile to anyone, including the phantoms, but what else can we do?). Other hostile encounters currently not allowed.
4) Unpopulated planets, quantity might be from 1 to 5.
5) New lights, if some of your objects require additional lighting (realistic).
6) Basic trade, equipment properties.
7) Empty wrecks.
What MUST NOT be added to a faction system:
1) New suns.
2) Populated planets.
3) Nebulas (1 might be allowed if it's not large and there are NO objects inside of it).
4) More than 20 weapon platforms (exception made for Dab's system).
5) Unique objects (Dyson sphere, Arch, etc; exception made for Nightfall's systems only).
6) Wrecks with any valuable equipment (total price more than 5-10 thousand credits).
7) Mineable fields, except for cheap commodities (water, oxygene).
8) Profitable trade routes (some basic trade properties should be set up tho).
9) Exclusive equipment selling points.
10) Bases, planets and nebulas with names that don't have direct relation to real Earth geography.
11) Anything not compatible with Vanilla FL setup and Discovery official history.
12) More than 2 bases that sell ships.
13) Large bases (Newark-type), trade lanes.
14) Objects added by Discovery. Use original models for everything, even for weapon platforms. The last Discovery-added model should be Nightfall's dockable Outcast dreadnought. No more allowed.
15) Any objects/combinations of objects that cause lag, graphical issues, crashes (obviously).
16) Large mine fields/debris fields (unrealistic).
17) Large encounters, nebulas and any zones, if over 40% of their area is out of system borders.
18) Any jump gates, new jump holes.
19) Patrol paths.
What MUST NOT be changed in a faction system:
1) Suns
2) Lights
3) Original base setup
4) Well... generally everything already present in the system.
If anything in your submission contradicts the restrictions and you are absolutely sure that your system will lose something important without it, contact me via PM or igissmail@gmail.com and we'll discuss the issue. Some restrictions might be removed in exceptional cases. Some might not.
The list will be updated from time to time (along with the Rules). Please check them right before you submit.
System Submission Guidelines - Igiss - 04-10-2007
AVOIDING USUAL MISTAKES
Please review this section no less attentively than others. This will help you to avoid mistakes that were made in previous submissions. All examples below are based on mistakes that I had to fix, there's nothing "theoretical" in this post.
0) Necessary software
I assume you already have latest versions of Freelancer Explorer and Freelancer SDK 1.5.
You'll need it many times to compare objects you are adding with those originally present. For example, you are adding a planet in Freelancer Explorer. You should have Freelancer SDK 1.5 in a separate folder for reference, and original Discovery files (unzipped) in another separate folder.
I use Servant Salamander for quick searching inside entries. Link:
http://www.altap.cz/download.html
CSDiff
http://www.componentsoftware.com/Products/CSDiff/index.htm
Absolute must-have. You must compare your files with Discovery files before you submit anything. Compare with this program (it can compare whole folders of documents and separate documents). It will provide a full list of files that were changed, and list of new files that you've created (new bases and rooms, mostly).
When you open "modified" document, it will highlight the part of the ini that you've added. Copy it in a text document, like described in rules.
Make sure that your submission contains ALL files that were changed, and not containing anything you meant to delete.
Always test everything you add in the game. After activating your addon and before playtesting, it's a good idea to test files with FLScan 1.3. You can get it here:
http://lancersreactor.com/t/Download/Download.asp?ID=2126
While testing, keep server console open and track all messages that are yellow or red. Those messages must never appear (except for one generic yellow message) and presence of those messages means that there are bugs in your system that should be fixed prior to submission.
1) System general layout. Zones.
If you are not sure what you are doing, leave the star(s), light(s) and ambience originally present in the system. If you are changing, compare to original systems and make sure that it works.
Don't make zones too large. Exceeding system border is acceptable, but not for too much. Fields (encounters, nebulas, asteroid fields, ...) should be of sensible size.
No objects should be placed outside of system border (seen in FLSO as edges of system display when you first open the system). Not even wrecks or secret objects.
Zones of one type should not overlap. For example, you shouldn't have two asteroid fields overlapping, but you might have an asteroid field inside a nebula.
Exclusion zones for each zone must be unique. If there are two zones from which you want to exclude something, create two similar zones. For example, this should be done if you are excluding a large zone from a nebula and asteroid field at once. Note that you generally don't need to exclude anything from nebulas.
Exclusion zones can be of two types - round (created by Exclusion function in FLEx) and square (created by Lane Access tool in FLEx). Lane Access is the best to create pathways. Normal Exclusion is better for bases and other areas.
Star MUST NOT be within asteroid field! If there's a star within, make an exclusion zone as large as the sun's atmosphere (a bit larger).
2) Planets
Adding non-populated planets is generally a good idea, but avoid using archetypes of populated planets. Leeds has cities on its skin, won't be very logical if your infocard will say it's not populated.
Same for populated planets (when you create non-faction systems). If you add a small moon with craters, players won't understand this to be populated with anything human.
Check atmosphere entries! Size of death zone must be smaller than size of atmosphere, but larger than the planet (size of planet is seen in its archetype, if it's something like redmoon_800, size is 800).
Generally, death zone is planet size plus 100, and atmosphere range is death zone puls 100.
Damage of the death zone is set to 5000 by Freelancer Explorer. This value is incorrect and must be changed to 2000000 (2 mil) for all planets.
If adding a populated planet, make sure you add a mooring fixture in the right location with the same reputation as docking ring.
3) Bases
NPCs
If you want me to set up bases for you, provide basetemplates.txt file listing from which base the template should be copied (more information in the checklist). In this case, do not place any base or room files in your submission.
You may add base and room files yourself, along with mbases.txt chunk. This will save some time, but please make sure that base is set up correctly and does not show any errors while testing.
If you are customizing NPCs, leave all room files where they are, and submit mbases.txt with changes for mbases.ini. However, BEFORE you edit the base in Freelancer Explorer you need to delete all room entries, if there are some (created by me before, for example, and not needed for your needs).
4) Weapon Platforms
These objects are present in large numbers in faction systems (due to their Guard origin).
First of all, use loadouts and archetypes that I use for weapon platforms in same system. If you are making an empty system into a faction sys, refer to other guardian systems for archetypes and loadouts. They are mostly similar, differing only for lawful/unlawful setups.
Don't forget that weapon platforms should be affiliated with the Guard.
Don't use asteroid weapon platforms with no asteroids in nearest vicinity (or inside a nebula).
5) Loadouts for all objects
Loadouts for all objects are based off the hardpoints that are present on the archetype. You cannot use loadout for one base type for another base type, for example, and cannot use loadouts for one weapon platform for another. If you are creating a new loadout, base it off the loadout that's used elsewhere for same object. Search through other systems using Salamander or anything you prefer, find same object, and see what loadout it uses.
Loadouts for bases, static objects and wrecks are placed in SOLAR\loadouts.ini
Loadouts for ships (including battleship stations) are placed in SHIPS\loadouts.ini or SHIPS\loadouts_special.ini
Check all loadouts for wrecks, they tend to cause server crashes. Do not base your wreck loadouts upon ship loadouts, better use other wrecks as templates.
6) Infocards for all objects
All infocards MUST be included in the following format:
497502
Name of your base
497503
Decription of your base in XML format
Make sure you include ids_name and ids_info so that I know what type of entry is it.
All descriptions must use XML encoding, including the rumors. Only exception are the news, but you shouldn't be adding them.
Templates for all XML are in the zip file linked in the 1st post.
Make sure all your descriptions are entered in the text file without line breaks. Make sure you don't delete any XML codes. View all your infocards in-game before submitting the system to me.
System Submission Guidelines - Igiss - 06-29-2008
The posts were updated. However, some information might appear a bit incorrect. Rever to dsy_checklist.xls for correct values.
All reference information was moved to dsy_design.xls.
Links to documents and software are placed in the above posts of this thread. Will re-post here in case you missed.
System checklist essential for submitting:
http://discoveryfl.com/files/dsy_checklist.xls
System design information and reference:
http://discoveryfl.com/files/dsy_design.xls
Infocard templates for systems and ships:
http://discoveryfl.com/files/infocards.zip
System Submission Guidelines - Igiss - 09-12-2008
New versions of dsy_checklist.xls and dsy_design.xls have been posted.
dsy_design.xls simply contains more specific/detailed/fixed information on a number of mod-related things. Most of this info is necessary for editing systems.
dsy_checklist.xls was significantly updated. Summary of updates:
- Added new requirement about "Files": "comments.txt" must be present and must contain all information about removed files/ini sections that should be removed from existing files.
For example, if there was an asteroid field in the system and you delete it, specify matching field file from DATA\Solar\Asteroids. I will delete it from the mod as well.
- Added certain new requirements about infocard numbers ("Infocards" section).
Now, if you are changing name/descriptions for certain base, you must use same numbers for new name and new descriptions.
Also, new test case added that specifically prohibits to use numbers previously used for names to add new info (descriptions), and vice versa.
- For "Design Restrictions" section:
Added a number of new test cases to check that default FL Explorer entries are modified.
Added more checks to fix common code flaws that were found in previous submissions.
Highlighted code portions that need to be searched for and edited in blue, for convenience.
Please download new versions of both documents if you are editing systems. Also, if you are going to submit the files soon and I'm yet unaware of it (know only about Hyperion and Dab), please mail me (igissmail@gmail.com) ASAP to receive more details on how to submit your work during the time that's remaining.
System Submission Guidelines - Igiss - 09-13-2008
One more small update for dsy_checklist.xls.
Added item 3.16 that lists suns that must not be used in new systems (cause bugs):
red_guant_sun
green_giant_sun
sm_red_sun
sm_blue_sun2
St03_sun
St01_yellow_sun
bw05_sun1
bw05_sun2
bw10_sun
ew06_sun2
Added item 3.27 to ensure that casing of system codes is left intact (like HI20 that was changed to Hi20 in a number of places in Hyperion's submission).
Plus a couple of cosmetic fixes.
To clarify certain differences between checklist and forum threads (for example, 20 weapon platforms is the limit according to the thread, but checklist says 30): checklist is updated more frequently and has a priority. If there is any difference between the checklist and any other sources, checklist information is the correct one.
System Submission Guidelines - Igiss - 09-28-2008
I've updated the initial post to reflect link changes and some other changes. Also...
Update for dsy_checklist.xls.
First of all, now, if standard templates are used, neither base files nor room files should be included into your submission. So, the system folder should ontain ONLY the system file.
As an aternative, you may set up all bases yourself and include all base/room files.
1.14 is amended to reflect this:
Following files must be present in DATA folder:
\DATA\Interface\InfocardMap.txt
\DATA\Universe\Universe.txt
\DATA\Universe\Systems\XX01\XX01.ini
"
Do not include base or room files if you want me to set them up using existing base template.
1.20 added:
Check that none of the files and folders in your submission are marked as "Read-only".
2.14 added:
Special description elements (like degrees symbol for planet infocards) and abbreviations are left intact in new infocards.
Check that "A.S." is used, not "A.S".
Added comment about infocards.txt file (it's optional):
For convenience, infocards.txt file may include code for new bases. For example, you may put internal name of the base (LI09_04_Base) next to its name infocard. You can also note if the base template has a shipdealer (meaning that it sells ships).
Special note - please be attentive to this one. I'm receiving submissions with this requirement not followed, although it was added fairly long time ago.
3.27
Check that casing of the system name and other objects is preserved intact in the ini files. If "HI20" is used, it must not be changed into "Hi20" or "hi20" anywhere.
System Submission Guidelines - Igiss - 08-12-2009
Added new versions of:
System submission checklist, with significant changes:
http://discoveryfl.com/files/dsy_checklist.xls
infocards.txt, renewed due to implementing FLDev support. Significant changes, please take note:
http://discoveryfl.com/files/infocards.zip
dsy_design.xls, revewed to contain 4.85 changes:
http://discoveryfl.com/files/dsy_design.xls
System Submission Guidelines - Igiss - 03-22-2010
A warning to all system modders.
For the moment I'm not accepting systems saved in Freelancer Mod Studio. No exceptions are made. This is due to Freelancer Mod Studio changing order of entries in the ini files it saves. This change is irreversible and leads to a number of negative consequences, and, in some cases, to game bugs.
We may use Freelancer Mod Studio for supplementary tasks like setting coordinates, but saving whole system in this tool and submitting it is not possible at the moment. The author of the tool promised to fix this issue to some extent, so this policy may change for the next Mod Studio releases. Also, please note that currently the Mod Studio is in a beta stage. It is not a finalized tool that's 100% reliable to use.
Please check the discussion here:
http://the-starport.net/freelancer/forum/v...74&forum=10
if you have any doubts.