---

SYSTEM MODDING

This will be a huge tutorial and knowledge-base for system modding. I write this as I learn and "decrypt" more and more parts of system-editing. It should help to learn and speed up modding of systems by giving good examples.
I will also make a template-system to show that all things mentioned here really work.
It will include ALL things that can be modded by me, examples on how to create populated systems like the ones in the game (with missions, bribes,...), also a "gallery" of ALL objects found in the game, sorted by categories like station parts, asteroids, wrecks, ... (maybe in a small extra-system)
This will be published and updated frequently as I make progress.
The replies to this post will handle the numerous parts of system-modding.
Best will be to go through all affected files one by one.
I do all this with notepad. Freelancer Explorer may be a nice tool to create a system, but the result will always be a quick and dirty solution. I want to understand the details of system-modding and FLEx is just a visual tool that hides the details -> just one reason why I don't use it.

------------------------------------------------------------------------------

File organization

I will try to explain which file holds what data and how they are connected or how they interact with each other. All paths are relative to the Freelancer

directory, i.e. I treat it as root.
Some filenames are system- and basename related. I will use < system > and < base > for these.
A detailed description of each file will follow later. (damned, this will be a lot of work... It will hopefully pay back the effort when it is finished and makes system-modding easy)
This only contains files where I exactly know what they do. Will be completed with the time.

------------------

Purchase and sale:
Structure of these files is the same, entries are all in sections (one for each base)

\DATA\EQUIPMENT\market_misc.ini
Contains information about the availability of weapons and equipment on ALL bases.

\DATA\EQUIPMENT\market_ships.ini
Contains information about the availability of ships on ALL bases.

\DATA\EQUIPMENT\market_commodities.ini
Contains information about the availability of commodities on ALL bases.


Objects:
These are the descriptions of all fixed objects that can be found in space. Planets, bases, jumpholes/gates, asteroids, nebulas, stars,...

\DATA\SOLAR\asteroidarch.ini
Archetype references for all asteroids.

\DATA\SOLAR\stararch.ini
Archetype reference for all stars.

\DATA\SOLAR\solararch.ini
This is the "big" one, it holds all planets, bases and all other fixed objects.

\DATA\SOLAR\loadouts.ini
All bases/stations/objects are equipped here (guns, shields, lights,...)

\DATA\SOLAR\ASTEROIDS\< system >_< asteroid field type name >.ini
This defines the visual look and behaviour of the asteroid field used. Minefields are also specified here.

\DATA\SOLAR\NEBULA\< system >_< nebula type name >.ini
Definition of the visual look and behaviour of nebulas.


Universe:
This is the complete universe that you all know in FL. Systems, bases, fields, ... everything.

\DATA\UNIVERSE\universe.ini
A list of all bases and systems. System position on the galaxy map, map scales,... are defined here.

\DATA\UNIVERSE\shortest_illegal_path.ini
Seems to be the place to define paths that cross several systems. This one prefers jumpholes.

\DATA\UNIVERSE\shortest_legal_path.ini
Same as above, just prefers jumpgates.

\DATA\UNIVERSE\SYSTEMS\< system >\< system >.ini
This is the main part of each system. Objects, zones, fields, patrols, their positions, all this is found here. This is where you "shape" your system.

\DATA\UNIVERSE\SYSTEMS\< system >\BASES\< system >_< base >_base.ini
Defines a base with all its rooms.

\DATA\UNIVERSE\SYSTEMS\< system >\BASES\ROOMS\< system >_< base >_< location >.ini
Defines a room inthe base and its connection to other rooms. Also character and ship placement.

\DATA\MISSIONS\mbases.ini
This is probably the largest and most complicated ini-file in FL.
The bases are all listed and populated here with characters (in the bar, traders, shipdealers,..). All missions, rumors and bribes are also defined here. Details are still not completely decrypted.


Allright, this may have confused everyone I guess and i think I lost everyone's attention by now.
Sorry, but this is a very complicated topic and it needs a lot of patience and endurance, but I try to summarize it a bit shorter


Archetype files (these define the objects)
asteroidarch.ini
stararch.ini
solararch.ini
loadouts.ini

System files
Archetypes are used in the system files (all these are nessessary to make a working system with bases and fields):
Code:

SOLAR + ASTEROIDS - mysystem_asteroid_field.ini
/
+ NEBULA - mysystem_nebula.ini
UNIVERSE - universe.ini
+ SYSTEMS + MYSYSTEM + BASES + ROOMS - mysystem_01_base_location1.ini
/ / - mysystem_01_base_location2.ini
/ / - ...
/ - mysystem_01_base.ini
/ - mysystem_02_base.ini
/
- mysystem.ini
MISSIONS - mbases.ini


Purchase and sale
Probably the easiest part of system-modding.
market_misc.ini
market_ships.ini
market_commodities.ini

System framework

This short section will handle the following files in the \DATA\UNIVERSE directory:
universe.ini
shortest_illegal_path.ini
systems_shortest_path.ini

universe.ini
There are two important section types:
[System and [Base. There is a section fro each system and base in the game.

[System
Code:
[system
nickname = Iw03
file = systems\Iw03\Iw03.ini
pos = 5, 10
msg_id_prefix = gcs_refer_system_Iw03
visit = 0
strid_name = 196645
ids_info = 66101
NavMapScale = 2

Explanation:
nickname =
Name of the System in the \UNIVERSE\SYSTEMS directory.

file =
Filename of the system ini.

pos =
This sets the location of the system in the universe map. Coordinates are handled in a similar way as with systems X, Y.
X increases from west to east
Y increases from north to south
values range from 0 to 15 in the builtin maps. center (NY) is 7, 8

msg_id_prefix =
Format: gcs_refer_system_< system >
This is used by NPCs when messaging around.
Probably won't work for custom systems.

visit =
This seems to be a binary flag value.
flag numbers: 8765/4321 ->combined to a binary value
1: System shown on map? NY is the only one with this flag. -> 1
2-7: unknown
8: System never shows up on map. -> 128

visit = 0 is the recommended value (system doesn't show up until found)

strid_name =
Name infocard reference.

ids_info =
Infocard reference for system information.

NavMapScale =
Scale of the system map. Typical entries range from 0 (no entry) to 2


[Base
Code:
[Base
nickname = Iw04_02_Base
system = Iw04
strid_name = 196730
file = Universe\Systems\Iw04\Bases\Iw04_02_Base.ini
BGCS_base_run_by = W02bF36


nickname =
Reference name of the base.

System =
The sytem name where the base is located.

strid_name=
Infocard name reference.

file =
Location of the base ini-file.

BGCS_base_run_by =
??? maybe also a Hex offset for infocard info

other entries
??? unknown

--------------------------------------------------
shortest_illegal_path.ini and systems_shortest_path.ini work the same way, but use different routes to get from one to another system.

there is one section [SystemConnections for each system. The path to ALL other systems will be inserted here in the following format.
example:
Code:
[SystemConnections
Path = Li01, Hi01, Li01, Li03, Iw06, Ku02, Ku03, Bw08, Ew01, Hi01
Path = Li01, Li01, Li01
Path = Li01, Li03, Li01, Li03
Path = Li01, Rh05, Li01, Li04, Iw01, Rh02, Rh01, Rh05
Path = Li01, Rh01, Li01, Li04, Iw01, Rh02, Rh01
Path = Li01, Rh03, Li01, Li04, Iw01, Rh02, Rh01, Rh03
Path = Li01, Br06, Li01, Li02, Iw04, Br02, Br04, Br06
...

Explanation:
Path = < source > , < destination >, < list of systems passed through, including source and destination >

example:
Path = Li01, Rh01, Li01, Li04, Iw01, Rh02, Rh01
source is NY, destination NB.
the path is NY->Texas->Bering->Hamburg->NB

The 2 files also differ in the usage of gates and holes. Its not know how this exactly works. Also inner-system paths(waypoint are still unknown).

I am not sure if this is needed to make a system work and it seems uniportant because waypoint over systems are rare (almost only at missions with a spread group).
Making entries for the connected systems worked for me. (can still be extended later. I need to test what happens when I try this with a path that has no entry here)

EDIT: Path tested without system-entry. It will refuse to set a waypoint by telling "no path" -> works without them, but should be done for a well-made system.

So much to the framework of a system

---

---

Connecting systems

This section handles all finds of jumpgates and jumpholes.
All these entries are in the main ini file of each system:
\DATA\UNIVERSE\SYSTEMS\< system >\< system >.ini

Jumpgates and holes are basically the same, just the look and docking behaviour is different.

Example:
Code:
[zone
nickname = Zone_Li01_to_Li04_hole
pos = 15425, 0, 83760
shape = SPHERE
size = 2000
property_flags = 131072
visit = 128
sort = 99

[Object
nickname = Li01_to_Li04_hole
ids_name = 260916
pos = 15425, 0, 83760
Archetype = jumphole
msg_id_prefix = gcs_refer_system_Li04
ids_info = 66146
jump_effect = jump_effect_hole
visit = 0
goto = Li04, Li04_to_LI01_hole, gate_tunnel_bretonia


Usually, only the [Object entry is needed, as that is our jumphole. The [Zone around it can be useful though. One example is to use this as an exclusion-zone in asteroid fields (more detail on that in later tuts). This makes sure that there are no asteroids near the jumphole.

Explanation of entries (zones will be explained later):
[Object

nickname, ids_name, pos, ids_info
these are very common in most ini-s and should be known by now

Archetype =
This is the model used from the solararch.ini.
Typical entries are jumphole, jumpgate, jumphole_red,...

msg_id_prefix =
Reference for NPC messages.

jump_effect =
The visual effect during the system-change.

visit =
similar flag-system as explained in the system framework under universe.ini
A common value is 0 (visible on map after spotting it)

goto =
This specifies the destination of the jump.
Format is:
goto = < destination system >, < destination object >, < visual effect during jump >
Example:
goto = Li04, Li04_to_LI01_hole, gate_tunnel_bretonia

Important: To make the jump work in both directions you need to set up a similar object in the destination system, just the other way round.

Creating one-way holes or inner-system connections is also possible

Tradelanes

Zooker explained this very well here:
http://www.klngarthur.com/forum/viewtopic.php?t=82

Just a few notes:
Lanes that go straight work in ANY angle.
Lanes that change direction mess up the tunnel-animation. This can be corrected by taking out the visual effcet of the tunnel.
Just comment out the following line in select_equip.ini like this:
Code:
[TradeLane
...
;tl_player_travel = basic_tl_player_travel
...


Please remember that lanes going over edges basically work, but the direction-change is instant and will look strange at this speed when you make turns of over ~10 degrees

---

---

Connecting systems

This section handles all finds of jumpgates and jumpholes.
All these entries are in the main ini file of each system:
\DATA\UNIVERSE\SYSTEMS\< system >\< system >.ini

Jumpgates and holes are basically the same, just the look and docking behaviour is different.

Example:
Code:
[zone
nickname = Zone_Li01_to_Li04_hole
pos = 15425, 0, 83760
shape = SPHERE
size = 2000
property_flags = 131072
visit = 128
sort = 99

[Object
nickname = Li01_to_Li04_hole
ids_name = 260916
pos = 15425, 0, 83760
Archetype = jumphole
msg_id_prefix = gcs_refer_system_Li04
ids_info = 66146
jump_effect = jump_effect_hole
visit = 0
goto = Li04, Li04_to_LI01_hole, gate_tunnel_bretonia


Usually, only the [Object entry is needed, as that is our jumphole. The [Zone around it can be useful though. One example is to use this as an exclusion-zone in asteroid fields (more detail on that in later tuts). This makes sure that there are no asteroids near the jumphole.

Explanation of entries (zones will be explained later):
[Object

nickname, ids_name, pos, ids_info
these are very common in most ini-s and should be known by now

Archetype =
This is the model used from the solararch.ini.
Typical entries are jumphole, jumpgate, jumphole_red,...

msg_id_prefix =
Reference for NPC messages.

jump_effect =
The visual effect during the system-change.

visit =
similar flag-system as explained in the system framework under universe.ini
A common value is 0 (visible on map after spotting it)

goto =
This specifies the destination of the jump.
Format is:
goto = < destination system >, < destination object >, < visual effect during jump >
Example:
goto = Li04, Li04_to_LI01_hole, gate_tunnel_bretonia

Important: To make the jump work in both directions you need to set up a similar object in the destination system, just the other way round.

Creating one-way holes or inner-system connections is also possible

Tradelanes

Zooker explained this very well here:
http://www.klngarthur.com/forum/viewtopic.php?t=82

Just a few notes:
Lanes that go straight work in ANY angle.
Lanes that change direction mess up the tunnel-animation. This can be corrected by taking out the visual effcet of the tunnel.
Just comment out the following line in select_equip.ini like this:
Code:
[TradeLane
...
;tl_player_travel = basic_tl_player_travel
...


Please remember that lanes going over edges basically work, but the direction-change is instant and will look strange at this speed when you make turns of over ~10 degrees

---

---

Populating Bases/Missions

...continued from the "Bases" section...

We have a base that appears in space. It has all the rooms defined, but needs a few character to bring life to the base. Custom missions is connected very closely with this, so I will try to explain as much as I know about them.
This all is about the biggest and maybe most complicted ini-file in FL:
\DATA\MISSIONS\mbases.ini

WARNING: bini (also other ini decompressors) mess a few lines up and corrupt the file. I will put a link here to a corrected version (later)

Again, I will post my "tutorial" base as an example.
To make things shorter, I will comment the simpler entries and explain complicated ones below:
Code:
[MBase
nickname = Tut01_01_Base
local_faction = li_p_grp
diff = 1
msg_id_prefix = gcs_refer_base_Tut01_01_Base

[MVendor
num_offers = 1, 4 ; <---min, max number of missions offered

[BaseFaction ; <--- one section like this for all factions at the base
faction = li_p_grp
weight = 30
offers_missions = true ; <--- this and the line below are messed up by bini
mission_type = DestroyMission, 0.000000, 0.442387, 100 ; <------ type, min_lvl, max_lvl, weight
npc = Tut0101_lpolice_001_m ; <--- NPC declaration (only for additional ones)

[GF_NPC ; <--- a typical bartender
nickname = Tut0101_fix_bartender
body = li_bartender_body
head = rh_bartender_head
lefthand = benchmark_male_hand_left
righthand = benchmark_male_hand_right
individual_name = 244609
affiliation = li_p_grp
voice = rvp101
bribe = fc_lr_grp, 12, 16100

[GF_NPC ; <--- a typical shipdealer
nickname = Tut0101_fix_ship
body = li_commtrader_body
head = ge_male1_head
lefthand = benchmark_male_hand_left
righthand = benchmark_male_hand_right
individual_name = 244612
affiliation = li_p_grp
voice = rvp111

[GF_NPC ; <--- a typical merchant
nickname = Tut0101_fix_trader
body = li_commtrader_body
head = br_brighton_head
lefthand = benchmark_male_hand_left
righthand = benchmark_male_hand_right
individual_name = 244610
affiliation = li_p_grp
voice = rvp101

[GF_NPC ; <--- a typical equipment dealer
nickname = Tut0101_fix_weaponsdealer
body = li_commtrader_body
head = br_sales_head
lefthand = benchmark_male_hand_left
righthand = benchmark_male_hand_right
individual_name = 244611
affiliation = li_p_grp
voice = rvp101

[GF_NPC ; <--- this is the NPC we defined above
nickname = Tut0101_lpolice_001_m
body = li_male_guard_body
head = ge_male3_head
lefthand = benchmark_male_hand_left
righthand = benchmark_male_hand_right
individual_name = 220011
affiliation = li_p_grp
voice = rvp111
misn = DestroyMission, 0.000000, 0.112387 ; <--- mission offered by NPC
room = bar ; <--- location of the NPC
accessory = prop_hat_male_li_grd_visor ; this is to make him look cool

; *** the rooms we defined for our base ***
[MRoom
nickname = bar
character_density = 7 ; <--- ??? probably max number of chars
fixture = Tut0101_fix_bartender, Zs/NPC/Bartender/01/A/Stand, scripts\vendors\li_bartender_fidget.thn, bartender

[MRoom
nickname = trader
character_density = 3
fixture = Tut0101_fix_trader, Zs/NPC/Trader/01/A/Stand, scripts\vendors\li_commtrader_fidget.thn, trader

[MRoom
nickname = ShipDealer
character_density = 2
fixture = Tut0101_fix_ship, Zs/NPC/Shipdealer/01/A/Stand, scripts\vendors\li_shipdealer_fidget.thn, ShipDealer

[MRoom
nickname = Equipment
character_density = 2
fixture = Tut0101_fix_weaponsdealer, Zs/NPC/Equipment/01/A/Stand, scripts\vendors\li_equipdealer_fidget.thn, Equipment


Additional explanations:
Bribes
Our bartender offers a bribe. These are esay to set up, its just this simple line:
bribe = fc_lr_grp, 10000, 16100
format is:
bribe = < faction >, cash factor, < ??? - unknown >
the cash factor is no multiplier, but it can be changed. Lower values make cheaper prices, but not all seem to work.
Here is a link to a few known values.

NPCs: [GF_NPC
This is also self-explaining. You assign a body, head, hands, name, affiliation, voice, accessory and a room.
Also missions offered by NPCs are defined here.

[MRoom
The rooms we defined in the base are populated here. It is possible to place all the "default" NPCs (trader, equipment,...) in the same room. In this case the "virtual_rooms" I meantioned earlier are needed.

-----------------------------------------
Missions

We have already set up the mission and someone who offers it to you.
I recall:
Code:
offers_missions = true
mission_type = DestroyMission, 0.000000, 0.442387, 100


mission_type = < type >, < min lvl >,< max lvl >, weight
min and max level are for the cash, the weight defines the difficulty.

Missions offered by NPCs are a bit different:
Code:
misn = DestroyMission, 0.000000, 0.112387

Format is almost the same, I guess the weight of the NPC's affiliation defines the difficulty.
I recall:
Code:
[BaseFaction
faction = li_p_grp
weight = 30


We still need a destination for the mission. This is placed into the main ini-file of the system and it is a zone. example from NY:
Code:
[zone
nickname = zone_li01_destroy_vignette_1
pos = -23536, 0, -52599
shape = SPHERE
size = 10000
mission_type = unlawful
sort = 99.500000
vignette_type = open


I think the vignette zones are picked at random, there are over 60 of these in NY alone. The size defines the area where the mission takes place. If you leave this, then mission commission will tell you that you failed cause you left the mission area.

Additional loot from missions:
take a look at RMLootInfo.ini, entries are pretty self-explaining.

??? Problems/unsure points ???
- mission types: i could only find destroy missions, maybe also a bini-issue as this entry was messed up. (need to check this back)
- selective mission destination: donno if its even possible...
- the fractional values at the mission-setup (cash, difficulty). can't see a logical connection to NpcRankToDiff.ini and diff2money.ini but there must be one.
- file: VignetteParams.ini many people have tried and failed to get the logic behind this file. It was a script for sure that has been converted to an ini-file.

Planets and Stars

This is also a small and pretty easy section. In FL, a planet and a star are pretty the same and they behave in a very similar way. Both have an athmosphere range where the "burning" effect starts and both have a zone that kills objects who would crash into the planet/star.
Example:
PLANET:
Code:
[Object
nickname = Tut01_Planet_01
ids_name = 0
pos = 10000, 1000, 10000
rotate = 0, 0, 0
ambient_color = 0, 0, 0
Archetype = planet_crater_1000
ids_info = 0
spin = 0, 0.001, 0
atmosphere_range = 1200
burn_color = 160, 222, 245
reputation = li_p_grp
visit = 0

[zone
nickname = Zone_Tut01_Planet_01_death
pos = 10000, 1000, 10000
shape = SPHERE
size = 1100
damage = 10000
sort = 99.500000
density = 0
relief_time = 0
population_additive = false

I think all entries here are self-explaining, I will take a closer look to some of them:

[Object
...
spin = 0, 0.001, 0
This is how the object spins around the 3 axis' values are in radiants per sec i think (i will try 2pi, then it should spin once per sec->poor citicens).
You can also rotate around another axis.
The "spin = " entry can be also used to rotate all other types of objects. Could be nice to have base parts rotating for example solar panels, other modules,...
I have some other fancy ideas here, but will post them when they work.

atmosphere_range = 1200
burn_color = 160, 222, 245
Self-explaining, but good to know
I think these can also be set for all kinds of objects.

Dockable planets need a docking ring and a "base = mybasename" entry.
The dockinring would have the line "dock_with = mybasename".

STAR:
Example:
Code:
[Object
nickname = Sun_Tut01
ids_name = 0
pos = 20000, 2000, 20000
ambient_color = 255, 255, 255
Archetype = sun_2000
ids_info = 0
star = med_white_sun
atmosphere_range = 11000
burn_color = 160, 222, 245

[zone
nickname = Zone_Tut01_sun_death
pos = 20000, 2000, 20000
shape = SPHERE
size = 10000
damage = 10000
sort = 99.500000
density = 0
relief_time = 0
population_additive = false

[LightSource
nickname = Tut01_System_LIGHT
pos = 642, 0, 198
color = 255, 255, 255
range = 120000
type = DIRECTIONAL
atten_curve = DYNAMIC_DIRECTION

I think this is also self-explaining. Only addition is a lightsource.
I will explain lights in another tutorial.

---

---

{zone}
nickname = Zone_Hi02_Malvada_graveyard
pos = 24406, 0, -43335
shape = SPHERE
size = 6000
interference = 0.500000
damage = 100
visit = 128
sort = 99.500000
toughness = 19
density = 16 ;how many ships on the screen-if more spawn than # they vanish
repop_time = 10 ;respawn time
max_battle_size = 16;number of ships that can be on screen again same-density
pop_type = Background
relief_time = 35
faction_weight = fc_n_grp, 10 ;=nomads
encounter = area_nomads, 19, 1.000000 ;4 nomads
faction = fc_n_grp, 1.000000
encounter = area_nomads, 19, 0.890000 ;4 nomads
faction = fc_n_grp, 1.000000
encounter = area_nomads, 19, 0.750000 ;4 nomads
faction = fc_n_grp, 1.000000
encounter = area_nomads, 19, 0.670000 ;4 nomads
faction = fc_n_grp, 1.000000

This example shows how to get imediate battles when you enter the area
we mix two factions that do not play well together. ew03 omega 41

[zone
nickname = zone_ew03_pop_ambient
pos = 360, 0, 3059
shape = ELLIPSOID
size = 40151, 10496, 40429
comment = Ambient Pop
sort = 50
toughness = 16
density = 16
repop_time = 10
max_battle_size = 16
pop_type = nonlootable_ast_field
relief_time = 35
population_additive = false
faction_weight = fc_c_grp, 10
faction_weight = fc_rh_grp, 10
encounter = area_scout, 16, 1.000000
faction = fc_c_grp, 0.500000 ;=corsairs
faction = fc_rh_grp, 0.500000 ;=red hessians
encounter = area_scout, 16, 0.890000
faction = fc_c_grp, 0.500000
faction = fc_rh_grp, 0.500000
encounter = area_scout, 16, 0.760000
faction = fc_c_grp, 0.500000
faction = fc_rh_grp, 0.500000
encounter = area_scout, 16, 0.670000
faction = fc_c_grp, 0.500000
faction = fc_rh_grp, 0.500000

---