I said I would post it… here it is:

===========================================
Complete Guide to creating missions against the Nomads
…Covering: New faction, Ship, Encounters, Missions…

---

Tutorial written by ‘Psy’ on 17-02-09

Contact: [email protected]

Best Read at 1024x768 or higher with wordwrap on

Tutorial Structure/Contents

Getting Started:

• -) Intro
• 1. Preparation

Creating a new faction:

• 2a) Reputations
• 2b) Faction Specifics
• 3. Testing the work so far (Adding encounters)

Working with missions:

• 4a) ‘Prepping’ the system (Zones)
• 4b) Base setup

Closing out:

• 5. Outro

Intro

I decided to type up this guide as I believe it will help a great many people when they are trying to get missions against the Nomads in their own mods, or even just to get Nomads flying about in space. I have put a lot of info into this tutorial, that covers the whole process of implementing the Nomads right from scratch, so anyone should be able to learn something new from this. I hope so anyway. If this tutorial goes down particularly well, if someone wishes to make a better quality .pdf document or something, then by all means go ahead. So long as the original credit goes to me, and the content is left unaltered, then by all means go ahead and stick your mark on too!

This tutorial assumes you have a basic editing knowledge of freelancer game files. How to open ini files, the use of various tools (especially IDS & resource editing) and basic system/universe editing is pretty much what’s required here. It’s not a big ask, and you could pick all of this up in a day or two at very most. At which point come back to this tutorial then by all means.

I won’t put a load of pointless legal stuff here, as rippers will rip at the end of the day, and we are powerless to stop it. All I will say is, you may publish/upload this tutorial to any site/forum/host so long as the document is kept in it’s original form. And if you do have to break this up in some way and post snippets/excerpts from this tutorial, I just ask that you give credits where it’s due. By doing this with any tutorial, everyone is happy. Now on to business…

1. Preparation

I said in the intro (if you read it), that I would cover this process from the very fundamentals, so we will start by creating a new Nomad faction. Some may be reading this now and thinking “this is pointless, as there is already a Nomad faction in place”. This is true, but unless you are comfortable performing some limit-breaking (which is basically modifying data in the game binaries to break certain ‘hard-coded’ limits) it is better to do it this way. It may save a lot of headache in the long run. And besides, I want this to be a good reference for as large an audience as possible. I assume you have a clean and error-free mod-base to start working on. I would recommend everyone start with either the decoded and bug-fixed Freelancer SDK or the Quickfix pack by Leuva-Deus. Running error-checkers frequently is also advised. FLScan, FLIA and FLEC are all excellent tools for a serious modder.

2a) Creating a new faction
Reputations

Creating a new faction is covered in other tutorials, but I will put my own method of doing this and keep all of this together. We will be editing the following files at this stage (* denotes non-essential edit):

Data\initialworld.ini – This file contains factions’ attitudes towards one another, and base info about factions, such as name.
Data\Missions\empathy.ini – This file contains info that determines how reputation changes based upon certain events.
Data\Missions\M13* – This contains mission data for mission 13 of singleplayer. Only relevant if you use OpenSP.
Exe\newplayer.fl* – This file contains information used when creating a new Singleplayer character.
Exe\mpnewcharacter.fl – As above, this file contains the same info, but is used on Multiplayer character creation instead.
Data\Missions\faction_prop.ini – Faction Properties file containing detailed info about all the factions’ behaviour and characteristics.
Data\Missions\npcships.ini – This file contains info about what ships a faction uses, their difficulty level(s) for encounters, loadouts etc.
Data\Equipment\commodities_per_faction.ini* – This file tells Freelancer what commodities the various factions carry (if any).
Data\RandomMissions\VignetteParams.ini – This tells Freelancer what types of missions the factions can be involved with.

Starting with initialworld.ini then, you will see quite a large file with all of the existing game factions and their attitude towards each other. Copy the existing existing nomad faction (fc_n_grp) to the bottom of the file and give it an intuitive name, such as “new_no_grp”. Notice I am keeping the same style when I type this. Strictly speaking this isn’t necessary. Factions will work regardless, but it’s always best to keep things as close to the original freelancer as possible. So go ahead and replace the existing name there with your own. Because we have taken the existing Nomad faction as our own, we do not need to bother with typing new IDS entries, so we can leave the next 3 lines alone (you could always alter these later with a better description).

Now this is where it really gets exciting! Or not. You need to set the reputation of each of the following faction entries. I assume you are keeping the existing Nomad-hates-all scheme, so go ahead an replace each numeric value with -0.65. This will ensure the Nomads hate each other faction and will lead them to attack everyone (well, they will later anyway). As you might have guessed -0.65 is a low value and so represents a more ‘hostile’ standing towards the given faction. Conversely, a value of ‘0.65’ would make them friendly towards that given faction. The number is a float (recognizable by the decimal point; IE. it isn’t a ‘whole’ number/integer), and the scale runs between -1 and 1. However, although there appears to be flexibility here, don’t go mad with it. Try and keep any new entries here to the values the game uses by default. Besides, these values are more than sufficient.

Before we move on, add a new line at the bottom of this file for the new faction. Yes, each faction has a reputation towards itself. Why this was done this way is a mystery, but a factions entry for itself should always read 0.91, which basically gives it affiliation to itself. It’s crazy. A new faction wouldn’t be another faction would it? But anyway, on we press. When editing in this file, start as you mean to go on. All of your entries should be what you intend to use indefinately, meaning you won’t be running back here to alter your faction. This is asking for problems. And i’ll go on now and explain the next bit, which will (hopefully) illustrate what I mean. We have just set our new factions attitude towards each other faction, but what we haven’t done is entered a new line for our faction under every one of the existing factions. This needs to be done for every single faction in this list, and the values need to match exactly. So for example, say you entered a reputation if -0.65 against the Liberty Police, then under Liberty Police you need to add a reputation of -0.65 against this new nomad group. Here is an example entry which should look something like yours:

;--------------------------------------
;----------New Faction Entry----------
;--------------------------------------
[Group]
nickname = new_no_grp
ids_name = 196891
ids_info = 66205
ids_short_name = 196939
rep = -0.65, li_n_grp
rep = -0.65, li_lsf_grp
rep = -0.65, li_p_grp
rep = -0.65, br_n_grp
rep = -0.65, br_p_grp
rep = -0.65, ku_n_grp
rep = -0.65, ku_p_grp
rep = -0.65, rh_n_grp
rep = -0.65, rh_p_grp
rep = -0.65, co_alg_grp
rep = -0.65, co_be_grp
rep = -0.65, br_m_grp
rep = -0.65, co_nws_grp
rep = -0.65, co_hsp_grp
rep = -0.65, co_ic_grp
rep = -0.65, co_khc_grp
rep = -0.65, co_kt_grp
rep = -0.65, rh_m_grp
rep = -0.65, co_me_grp
rep = -0.65, co_ni_grp
rep = -0.65, co_os_grp
rep = -0.65, co_rs_grp
rep = -0.65, co_shi_grp
rep = -0.65, co_ss_grp
rep = -0.65, co_ti_grp
rep = -0.65, co_vr_grp
rep = -0.65, fc_bd_grp
rep = -0.65, fc_b_grp
rep = -0.65, fc_c_grp
rep = -0.65, fc_fa_grp
rep = -0.65, fc_g_grp
rep = -0.65, fc_gc_grp
rep = -0.65, fc_h_grp
rep = -0.65, fc_j_grp
rep = -0.65, fc_lh_grp
rep = -0.65, fc_lr_grp
rep = -0.65, fc_lwb_grp
rep = -0.65, fc_m_grp
rep = -0.65, fc_ou_grp
rep = -0.65, fc_rh_grp
rep = -0.65, fc_or_grp
rep = -0.65, fc_u_grp
rep = -0.65, fc_x_grp
rep = -0.65, gd_gm_grp
rep = -0.65, fc_uk_grp
rep = 0.65, fc_n_grp ;*
rep = 0.65, fc_ln_grp ;*
rep = 0.65, fc_kn_grp ;*
rep = 0.65, fc_rn_grp ;*
rep = -0.65, fc_ouk_grp
rep = -0.65, fc_q_grp
rep = -0.65, fc_f_grp
rep = -0.65, gd_im_grp
rep = -0.65, gd_z_grp
rep = -0.65, gd_bh_grp
rep = 0.91, new_no_grp
;–------------------------------------

Notice where I have put asterisks in this code. These are used only in the main storyline, and represent the Nomad-controlled house factions in the singleplayer storyline. As they are essentially ‘Nomad’ themselves, I did the only logical thing which was to at least set a friendly rep towards them. This isn’t really necessary though and won’t show any effect in multiplayer, unless you utilize these ‘unique’ factions in your mod. There are others in there too which aren’t necessary. By necessary, I mean it doesn’t matter what their value is set to. I don’t mean, it’s not needed so scrap it. The game parses all of these entries, and if just one is missing or mismatched you are facing potential crashes. Be very careful here and do it very slowly and accurately. Those of you thinking of using your ‘super-duper-text-editor-search-n-replace-program-feature’, this is great, but be careful to do the search and replace process properly. Recheck it manually.

And before we move on to the next step, I will display a snippet of another existing factions’ code, to show where our factions fits in there:

;-----------------------------------------
;----------Existing Faction Entry----------
;-----------------------------------------
[Group]
nickname = li_p_grp
ids_name = 196848
ids_info = 66201
ids_short_name = 196897
rep = 0.91, li_n_grp
rep = 0.91, li_lsf_grp
rep = 0.91, li_p_grp
rep = 0.65, br_n_grp
rep = 0.65, br_p_grp
rep = 0, ku_n_grp
rep = 0, ku_p_grp
rep = 0, rh_n_grp
rep = 0, rh_p_grp
rep = 0.65, co_alg_grp
rep = 0.65, co_be_grp
rep = 0.65, br_m_grp
rep = 0.65, co_nws_grp
rep = 0.91, co_hsp_grp
rep = 0.65, co_ic_grp
rep = 0, co_khc_grp
rep = 0.65, co_kt_grp
rep = 0, rh_m_grp
rep = 0.65, co_me_grp
rep = 0.91, co_ni_grp
rep = 0.91, co_os_grp
rep = 0.65, co_rs_grp
rep = 0.65, co_shi_grp
rep = 0.91, co_ss_grp
rep = 0.65, co_ti_grp
rep = 0.91, co_vr_grp
rep = 0, fc_bd_grp
rep = 0, fc_b_grp
rep = -0.65, fc_c_grp
rep = 0, fc_fa_grp
rep = 0, fc_g_grp
rep = 0, fc_gc_grp
rep = 0, fc_h_grp
rep = 0, fc_j_grp
rep = -0.65, fc_lh_grp
rep = -0.65, fc_lr_grp
rep = 0, fc_lwb_grp
rep = 0, fc_m_grp
rep = -0.65, fc_ou_grp
rep = 0, fc_rh_grp
rep = 0, fc_or_grp
rep = -0.65, fc_u_grp
rep = -0.65, fc_x_grp
rep = 0, gd_gm_grp
rep = 0, fc_uk_grp
rep = -0.65, fc_n_grp
rep = 0.91, fc_ln_grp
rep = 0, fc_kn_grp
rep = 0, fc_rn_grp
rep = 0, fc_ouk_grp
rep = 0, fc_q_grp
rep = 0, fc_f_grp
rep = 0, gd_im_grp
rep = 0, gd_z_grp
rep = 0, gd_bh_grp
rep = -0.65, new_no_grp
;–---------------------------------------

The bottom line is the one to look out for here. This line needs to be placed into every faction like I said before, with the matching reputation. Two factions in this game ‘like’ each other the same way. One can’t want to batter the other, while the other loves the first (not initially in this file anyway).

Now this is done, we can move on to the second file, empathy.ini. You will notice a similar structure. All of the factions are listed (minus our new one), along with numerical values just as before. However, rather than controlling attitude towards other factions, this file controls how a factions reputation changes based on certain events in-game. The first line, under faction nickname in one of these entries, is object destruction. This is how this factions rep will alter if you blow up one of their bases, ships or other solar object. A minus indicates the rep will change negatively, which is pretty obvious. In theory these could be set to ‘give’ rep on destruction, but whether this actually works in practice is unknown to me, and is pointless really. The next three lines control what happens to this factions rep when you either complete, fail or abort a mission taken from them. Again, it’s pretty obvious what happens. Success should always be positive, and the other two should always be negative, however this differs depending on the faction you are looking at (some are more forgiving than others).

The rest of the section deals with what happens to reputation when you destroy another factions’ ships. Friendly/Allied ship destruction will cause a decrease in rep, while obliterating enemies of the given faction will cause an increase in rep. These should generally be kept to low amounts across the board, so that it doesn’t take a handful of kills to adversely affect your rep with various factions. Unlike the initialworld.ini file though, each faction doesn’t have an entry for itself, so make sure you don’t add one in the next bit.

What you should do here is take the existing Nomad faction from here, and modify it to suit your needs. Just tweak the values until you are happy, and that’s all there is to that part. Now a slightly more time-consuming task again, is to add a line for your new faction into every other faction, so that the game knows what to do with reputation when your new faction is involved. Again a sample follows below so you can check your work:

;--------------------------------------
;----------New Faction Entry----------
;--------------------------------------
[RepChangeEffects] ; new nomad group
group = new_no_grp
event = object_destruction, -0.030000
event = random_mission_success, 0.025000
event = random_mission_failure, -0.045000
event = random_mission_abortion, -0.067500
empathy_rate = li_n_grp, -0.025
empathy_rate = li_lsf_grp, -0.025
empathy_rate = li_p_grp, -0.025
empathy_rate = br_n_grp, -0.025
empathy_rate = br_p_grp, -0.025
empathy_rate = ku_n_grp, -0.025
empathy_rate = ku_p_grp, -0.025
empathy_rate = rh_n_grp, -0.025
empathy_rate = rh_p_grp, -0.025
empathy_rate = co_shi_grp, -0.025
empathy_rate = co_khc_grp, -0.025
empathy_rate = co_kt_grp, -0.025
empathy_rate = br_m_grp, -0.025
empathy_rate = co_me_grp, -0.025
empathy_rate = co_be_grp, -0.025
empathy_rate = co_rs_grp, -0.025
empathy_rate = co_vr_grp, -0.025
empathy_rate = co_ni_grp, -0.025
empathy_rate = rh_m_grp, -0.025
empathy_rate = co_ti_grp, -0.025
empathy_rate = co_ic_grp, -0.025
empathy_rate = co_ss_grp, -0.025
empathy_rate = co_hsp_grp, -0.025
empathy_rate = co_alg_grp, -0.025
empathy_rate = co_os_grp, -0.025
empathy_rate = co_nws_grp, -0.025
empathy_rate = fc_c_grp, -0.025
empathy_rate = fc_ou_grp, -0.025
empathy_rate = fc_rh_grp, -0.025
empathy_rate = fc_bd_grp, -0.025
empathy_rate = fc_j_grp, -0.025
empathy_rate = fc_h_grp, -0.025
empathy_rate = fc_m_grp, -0.025
empathy_rate = fc_x_grp, -0.025
empathy_rate = fc_b_grp, -0.025
empathy_rate = fc_g_grp, -0.025
empathy_rate = fc_lh_grp, -0.025
empathy_rate = fc_u_grp, -0.025
empathy_rate = fc_gc_grp, -0.025
empathy_rate = fc_lwb_grp, -0.025
empathy_rate = fc_fa_grp, -0.025
empathy_rate = fc_lr_grp, -0.025
empathy_rate = fc_or_grp, -0.05
empathy_rate = gd_gm_grp, -0.025
empathy_rate = fc_uk_grp, -0.025
empathy_rate = fc_n_grp, 1
empathy_rate = fc_ln_grp, 1
empathy_rate = fc_kn_grp, 1
empathy_rate = fc_rn_grp, 1
empathy_rate = fc_ouk_grp, -0.025
empathy_rate = fc_q_grp, -0.025
empathy_rate = fc_f_grp, -0.025
empathy_rate = gd_im_grp, -0.025
empathy_rate = gd_z_grp, -0.025
empathy_rate = gd_bh_grp, -0.025
;–------------------------------------

;-----------------------------------------
;----------Existing Faction Entry----------
;-----------------------------------------
[RepChangeEffects]
group = li_p_grp
event = object_destruction, -0.030000
event = random_mission_success, 0.089600
event = random_mission_failure, -0.045000
event = random_mission_abortion, -0.067500
empathy_rate = li_n_grp, 0.350000
empathy_rate = li_lsf_grp, 0.400000
empathy_rate = br_n_grp, 0
empathy_rate = br_p_grp, 0
empathy_rate = ku_n_grp, 0
empathy_rate = ku_p_grp, 0
empathy_rate = rh_n_grp, 0
empathy_rate = rh_p_grp, 0
empathy_rate = co_shi_grp, 0.050000
empathy_rate = co_khc_grp, 0
empathy_rate = co_kt_grp, 0.050000
empathy_rate = br_m_grp, 0
empathy_rate = co_me_grp, 0.250000
empathy_rate = co_be_grp, 0.050000
empathy_rate = co_rs_grp, 0.050000
empathy_rate = co_vr_grp, 0.250000
empathy_rate = co_ni_grp, 0.250000
empathy_rate = rh_m_grp, 0
empathy_rate = co_ti_grp, 0.050000
empathy_rate = co_ic_grp, 0.250000
empathy_rate = co_ss_grp, 0.250000
empathy_rate = co_hsp_grp, 0.250000
empathy_rate = co_alg_grp, 0.050000
empathy_rate = co_os_grp, 0.250000
empathy_rate = co_nws_grp, 0.050000
empathy_rate = fc_c_grp, 0
empathy_rate = fc_ou_grp, -0.400000
empathy_rate = fc_rh_grp, 0
empathy_rate = fc_bd_grp, 0
empathy_rate = fc_j_grp, -0.100000
empathy_rate = fc_h_grp, 0
empathy_rate = fc_m_grp, 0
empathy_rate = fc_x_grp, -0.450000
empathy_rate = fc_b_grp, 0
empathy_rate = fc_g_grp, 0
empathy_rate = fc_lh_grp, -0.350000
empathy_rate = fc_u_grp, 0
empathy_rate = fc_gc_grp, 0
empathy_rate = fc_lwb_grp, 0
empathy_rate = fc_fa_grp, 0
empathy_rate = fc_lr_grp, -0.250000
empathy_rate = fc_or_grp, 0
empathy_rate = gd_gm_grp, 0
empathy_rate = fc_uk_grp, 0
empathy_rate = fc_n_grp, 0
empathy_rate = fc_ln_grp, 0
empathy_rate = fc_kn_grp, 0
empathy_rate = fc_rn_grp, 0
empathy_rate = fc_ouk_grp, 0
empathy_rate = fc_q_grp, 0
empathy_rate = fc_f_grp, 0
empathy_rate = gd_im_grp, 0
empathy_rate = gd_z_grp, 0
empathy_rate = gd_bh_grp, 0.050000
empathy_rate = new_no_grp, -0.05
;–---------------------------------------

Next up, is the optional M13 file. Open this up and scroll down until you find the section with reputations in. This file basically deals with what happens when you complete the story. What reputations to set, what jumpholes to unlock and so on. We are only interested in adding our new faction in here for completeness sake. The relevant section should look the like the following when you’re done:

;---------------------------------
;----------M13 Factions----------
;---------------------------------
Act_SetRep = Player, li_n_grp, 0
Act_SetRep = Player, li_lsf_grp, 0
Act_SetRep = Player, li_p_grp, 0
Act_SetRep = Player, br_n_grp, 0
Act_SetRep = Player, br_p_grp, 0
Act_SetRep = Player, ku_n_grp, 0
Act_SetRep = Player, ku_p_grp, 0
Act_SetRep = Player, rh_n_grp, 0
Act_SetRep = Player, rh_p_grp, 0
Act_SetRep = Player, co_alg_grp, 0
Act_SetRep = Player, co_be_grp, 0
Act_SetRep = Player, br_m_grp, 0
Act_SetRep = Player, co_nws_grp, 0
Act_SetRep = Player, co_hsp_grp, 0
Act_SetRep = Player, co_ic_grp, 0
Act_SetRep = Player, co_khc_grp, 0
Act_SetRep = Player, co_kt_grp, 0
Act_SetRep = Player, rh_m_grp, 0
Act_SetRep = Player, co_me_grp, 0
Act_SetRep = Player, co_ni_grp, 0
Act_SetRep = Player, co_os_grp, 0
Act_SetRep = Player, co_rs_grp, 0
Act_SetRep = Player, co_shi_grp, 0
Act_SetRep = Player, co_ss_grp, 0
Act_SetRep = Player, co_ti_grp, 0
Act_SetRep = Player, co_vr_grp, 0
Act_SetRep = Player, fc_bd_grp, 0
Act_SetRep = Player, fc_b_grp, 0
Act_SetRep = Player, fc_c_grp, 0
Act_SetRep = Player, fc_fa_grp, 0
Act_SetRep = Player, fc_g_grp, 0
Act_SetRep = Player, fc_gc_grp, 0
Act_SetRep = Player, fc_h_grp, 0
Act_SetRep = Player, fc_j_grp, 0
Act_SetRep = Player, fc_lh_grp, 0
Act_SetRep = Player, fc_lr_grp, 0
Act_SetRep = Player, fc_lwb_grp, 0
Act_SetRep = Player, fc_m_grp, 0
Act_SetRep = Player, fc_ou_grp, 0
Act_SetRep = Player, fc_rh_grp, 0
Act_SetRep = Player, fc_or_grp, 0
Act_SetRep = Player, fc_u_grp, 0
Act_SetRep = Player, fc_x_grp, 0
Act_SetRep = Player, gd_gm_grp, 0
Act_SetRep = Player, gd_im_grp, 0
Act_SetRep = Player, gd_z_grp, 0
Act_SetRep = Player, gd_bh_grp, 0
Act_SetRep = Player, new_no_grp, -0.65
;---------------------------------

Mine makes the player neutral to all except the Nomads. Nothing special involved here; it’s just a case of tweaking the values to your liking. Unless you use OpenSP in your mod (most tend not to bother) then you can safely skip this section, unless you’re a nerd like me of course.

Only a couple of more files to go now on this reputation-editing spree. Back out of the Data folder for a second now and move into the Exe folder. In here you need to fire up mpnewplayer.fl. This file is plain-text just as the ini’s are (well, as the ini’s are after been previously decoded). So you can just open this in notepad or your favourite text-editor (you may have to go through the windows ‘open-with’ process to do this, as .fl will most likely not be a recognized file-extension. When this is open you will see a familiar rep listing again, with each line preceeded with the word ‘house’. This is what the starting rep of a freshly-created MP character will be. Add you new faction under the last existing entry, keeping the same format, and then choose your rep. Here is an example again:

;-----------------------------------
;----------New Player Rep----------
;-----------------------------------
house = 0, li_n_grp
house = 0, li_lsf_grp
house = 0, li_p_grp
house = 0, br_n_grp
house = 0, br_p_grp
house = 0, ku_n_grp
house = 0, ku_p_grp
house = 0, rh_n_grp
house = 0, rh_p_grp
house = 0, co_alg_grp
house = 0, co_be_grp
house = 0, br_m_grp
house = 0, co_nws_grp
house = 0, co_hsp_grp
house = 0, co_ic_grp
house = 0, co_khc_grp
house = 0, co_kt_grp
house = 0, rh_m_grp
house = 0, co_me_grp
house = 0, co_ni_grp
house = 0, co_os_grp
house = 0, co_rs_grp
house = 0, co_shi_grp
house = 0, co_ss_grp
house = 0, co_ti_grp
house = 0, co_vr_grp
house = 0, fc_bd_grp
house = 0, fc_b_grp
house = 0, fc_c_grp
house = 0, fc_fa_grp
house = 0, fc_g_grp
house = 0, fc_gc_grp
house = 0, fc_h_grp
house = 0, fc_j_grp
house = 0, fc_lh_grp
house = 0, fc_lr_grp
house = 0, fc_lwb_grp
house = 0, fc_m_grp
house = 0, fc_ou_grp
house = 0, fc_rh_grp
house = 0, fc_or_grp
house = 0, fc_u_grp
house = 0, fc_x_grp
house = 0, gd_gm_grp
house = 0, fc_uk_grp
house = -0.65, fc_n_grp
house = -0.65, fc_ln_grp
house = -0.65, fc_kn_grp
house = -0.65, fc_rn_grp
house = 0, fc_ouk_grp
house = 0, fc_q_grp
house = 0, fc_f_grp
house = 0, gd_im_grp
house = 0, gd_z_grp
house = 0, gd_bh_grp
house = -0.65, new_no_grp
;-----------------------------------

Now we need to open the newplayer.fl file, also in this directory. However, a simple text-edit won’t do here. The file is Freelancer encrypted, and so we need to make use of a little tool to decode this for us before we can make changes. The tool I used was ‘Simple Save Editor 1.0’, (to quote the window title) by ‘TheJkWhoSaysNi’. This makes use of flcodec to decode the file into a readable and editable form. The changes to make are the same as the above file. Find the last entry and add your new faction in there. Then you can hit save, and it will re-encode it for you back to it’s original state.

*Just a note about these two .fl files if anyone is interested. I tested both of these in the game, in both encoded and plain-text format, and both work fine. So perhaps you might keep the last file in it’s editable state for easy modification later, or perhaps some of you might just want to encrypt everything as much as possible. The bottom-line is that it gets read fine either way, with no noticeable problems, so it’s your call.

2b) Creating a new faction
Faction Specifics

You need to head back into the Data folder again and down into the Missions sub-directory. Open up the faction_prop.ini file. You will see sections for each faction along with various characteristics. What you need to do, is copy the existing Nomad faction section and paste it to the bottom of this file. Then alter the affiliation to match your new factions nickname. I will post an example below again, and comment each line to tell you what each one is responsible for:

;-------------------------------------
;----------Faction Properties----------
;-------------------------------------
[FactionProps]
affiliation = new_no_grp
legality = unlawful ;Are they lawful (good) or unlawful (bad). They should probably be unlawful in your mod.
nickname_plurality = plural ;Is a pilot of this faction referred to as been singular or rather as plural.
msg_id_prefix = ignore ;Prefix to the pilots’ voices. Should be ignore for Nomads as they don’t actually speak.
jump_preference = any ;Does this faction favour jumpgates or jumpholes (or either) for inter-system travel.
npc_ship = new_no_fighter ;The npc_ship lines ‘choose’ what ships they fly around in. They need at least one.
mc_costume = mc_fc ;Pilot costume in space (seen when you hail them). Not a big deal when they are hostile.
firstname_male = 229608, 229608 ;Range of names to use for male Pilots’ first names. For example, ‘John’, or ‘Chris’.
firstname_female = 229608, 229608 ;Range of names to use for female Pilots’ first names. For example, ‘Helen’, or ‘Alice’.
lastname = 229608, 229608 ;Range of names to use as surnames/lastnames. You get the idea for names.
rank_desig = 197140, 197140, 197140, 10, 15 ;Names for the pilot’s rank (such as ‘Ace’). Nomads are blank though by default (which is fine).
formation_desig = 197808, 197820 ;Names for wings of ships. These run from Alpha to Omega by default (from the greek alphabet).
formation = fighters, fighter_guild ;Ship formations used for the various ships they fly. I use capital ships as well as fighters.
formation = gunboats, gunboat_wall ; ^
formation = battleships, battleship_wall ; ^
;–-----------------------------------

There is another line(s) that you may notice other factions use, and that is ‘voice’. This is to set up what voice the pilots’ use when hailed in space. Just as the msg_id_prefix line, this is unused with the Nomads, as they don’t speak in vanilla. You can alter this by all means, if you want to liven them up a little. The msg_id_prefix, just the elaborate a little more, is basically what faction gets stated in the conversation if you hail them in space. The structure is: “This is <faction><formation><#>, we are…”, the last bit varying depending on what they are currently doing. Is it a patrol mission, trading run and so on. There are some more too, pertaining to cargo scanning. Will this faction scan ships for certain cargo? And if so, what are they looking for? Along with priority values and so on. All unecessary for the Nomads, and for us.

As this tutorial isn’t a complete guide on faction behaviour, we won’t be covering any of this in detail here. We just need to implement the necessary to get Nomads in. So, let’s move on to the next file, npcships.ini. This code defines ships that the given faction will use. We saw above, in the faction_prop file, entries for NPC ships. The file we are in now is what these lines reference. Continue what we have done for the previous files, and copy an existing Nomad ship entry (search for ‘fc_n’ to narrow it down fast), and then paste that to the bottom of the file. Now, there is a very important change we need to make that only effects the Nomads. Every other ship in Freelancer has the ‘npc_class’ line showing ‘class_fighter’ as opposed to just ‘fighter’ (which is what the Nomad ships have by default). Here is what I mean (ignore all of the comments except on the last line for now):

[NPCShipArch]
nickname = fc_n_no_fighter_d19 ;Make this unique, and update faction_prop.ini with this new ship.
loadout = no_fighter_loadout02 ;This is the armament of the ship. What weaponry, equipment, cargo, lights etc that it carries.
level = d19 ;The difficulty level of the ship (used internally, just leave this at 19 for simplicity)
ship_archetype = no_fighter ;The ship architecture, referencing a ship entry from ‘shiparch.ini’. This is the vanilla Nomad fighter.
pilot = MSN13_Nomad_Fighter ;The NPC pilot. It defines behavioural characteristics. How well they fly, evade, their accuracy and so on.
state_graph = FIGHTER ;Tells the game what AI state to use. This should always be set to FIGHTER for fighters.
npc_class = unlawful, FIGHTER, d19 ;<– Notice ‘FIGHTER’ in here, this needs changing to ‘class_fighter’.

This needs to be altered to read ‘class_fighter’. There are other classes in the game that will work also, but they are of no importance for us. This can always be altered later once you know it is all up and working. Remember to alter the nickname too, to make it something unique, otherwise we will have a duplicate which is not good. Now refer back up to the snippet above and check my other comments for the other lines. This will give you an idea of what else is going on in this file.

Notice in my comments, next to nickname, I said you will need to update the faction_prop entry we made earlier. This is so the game knows to load our new NPC ship rather than the one that was already in there (which if you copied my snipped above would be wrong anyway, as that isn’t a vanilla NPC ship). There are a lot of lines like this, which reference other files all over the place, and can confuse easily. As such, we will leave the others as they are. We won’t touch loadout; we will leave this at it’s default setup for now which will work fine. We won’t touch the pilot either; this will be left using the mission 13 pilot, which again should suffice. The ship archetype will most likely not need to be altered unless you wish to introduce a new ship design into the game for the Nomads. If you do this, remember to create/update the loadout too, so that the equipment ‘fits’ the new ship. I would recommend you leave any unecessary editing for now, until you know it all works.

Now you should have something that looks like this:

[NPCShipArch]
nickname = new_no_fighter_d19
loadout = no_fighter_loadout02
level = d19
ship_archetype = no_fighter
pilot = MSN13_Nomad_Fighter
state_graph = FIGHTER
npc_class = unlawful, class_fighter, d19

Save and close out of that file, as we won’t need that anymore. We are close to the meat and potatoes of mission editing now, but before I go on to discuss that, we should edit another two optional files. I prefer to do this to be on the safe side, as what harm can it do? Definately no more than leaving it out altogether. So, you need to back out of the Missions folder and go into the Equipment folder. Now fire up commodities_per_faction.ini. As the name implies, this tells the game what cargo/commodities each faction carries when flying around in space. The Nomads won’t be carrying anything (unless of course you want to give them something), and so we will just create a new section for them, but leave it blank. The game will parse the file, see that we do indeed have an entry for them, but no go any further. This could help to prevent potential game errors later on.

The structure of this file is extremely simple, so just create a new entry for your faction and save and exit. It should look as basic as this, unless you added something to them (which is fine):

[FactionGood]
faction = new_no_grp

This last one has always been previously overlooked. Either that, or just ignored because of no understanding of what it actually does. Go back into your Data folder, and then move into the Interface folder. Open up ‘KnowledgeMap.ini’. This file has a fair bit of info in it, and it mainly pertains to singleplayer elements and various mission resources. Right at the top, you will see a list of factions and their corresponding IDS numbers, followed by a value of ‘65’. It is unknown to me what this value actually does, and what ‘levels’ if any could be set here, but none-the-less we will mod this file. Go to the bottom and add your new faction. Make sure you use the entry you used before when we first added the faction and set reputations. A quick trip into an IDS/resource editor will reveal what that number is if you forgot. For the Nomads it should be 196891, assuming you used the vanilla faction as a base. That’s it. Save and close this one.

Almost there now. There is one last file to alter before we can move on to implementing the Nomads, and this file is particularly important. Go back up a level into the Data directory, and then drill on down into the RandomMissions folder. This folder contains files relating to Random Missions, suprisingly enough. The one we need to update with our new faction is VignetteParams.ini. So open this up. If you have a quick skim through, you will see various mission ‘nodes’, each followed by a series of factions. Each of these nodes pertains to a certain Mission type. For example, ‘Tractor in the loot’, 'assasinate the target or ‘destroy the base’. Until we decide which of these our faction is to be involved with, they won’t be able to receive missions. So, lets get to work.

The general rule here, is to add your faction next to an existing faction with a similar ‘stance’. So, an unlawful/criminal faction should be added next to an existing unlawful/criminal faction. And suppose we added a new mining or trading faction, this could be added next to another existing faction that takes on a similar role. As Nomads are criminals (at least thats the way I am playing things here), we should add them in as unlawful. If you scroll down a bit, you should start to see various nodes that end with fc_x_grp as the last faction. This is the Xenos, and as you probably know, these are criminals. I have picked these because they are at the very end of the lines, so it is easy to see our new additions when we add them in, rather than having them ‘nested’ in the middle somewhere. I would recommend a good text editor here with a search and replace function. Replacing: ‘fc_x_grp’ with ‘fc_x_grp, new_no_grp’ (or whatever your new faction’s nickname is). You should be replacing about 20 entries with this. Save and close when done.

This file will be referenced by the game later on when we come to working with ‘Vignette Zones’. Without it, we would get no missions.

3. Testing the work so far

Now that all of the most time-consuming and boring parts are over, we can test our changes. This is as simple as creating a new encounter zone in a system, and then flying through it, to see if our new faction shows up in space. There are a few ways to do this. You could place it in an existing system (backup the original first though), or you could do it in a fresh system. My preference is the latter. This is because it is a clean-slate. There aren’t any other existing zones that could cause a problem, or ‘lessen’ the chance of your new faction showing up. This isn’t a system coding tutorial, and so I won’t be going into much detail here. Suffice to say, just create a new system (if you wish) and then add in the following encounter zone, unless you did it already (I will comment this again):

[Zone]
nickname = Zone_Ew09_pop_ambient_01 ;A unique name for the zone (the system name is a convention, not a requisite).
pos = -178, 0, 178 ;The position of the zone in space, relative to the system center (you may wish to adjust this).
rotate = 0, 0, 0 ;Rotation of the zone. As this is a sphere, this will have no effect if altered anyway.
shape = SPHERE ;Shape of the zone. Sphere, Box, Ellipse etc. Spheres are usually sufficient.
size = 44707 ;Defines the zone size. This is the radius (IE. from the center to the edge).
comment = Nomad Pop ;A useful comment. This is only for us humans to reference, and not for the game itself.
sort = 51 ;Appears to have no effect, but set to a low amount for ambient pop zones to be safe.
toughness = 19 ;Appears to have no effect on NPC difficulty, but leave at 19 to be safe.
density = 10 ;The absolute max concentration of NPC ships in the area at once. Should be higher than MBS.
repop_time = 25 ;How fast can the zone be re-populated with NPCs after the relief time expires.
max_battle_size = 6 ;The highest number of NPC ships that can be attacking at any one time.
pop_type = Background ;Type of the zone. Appears to have no effect like the sort parameter. Leave it in anyway.
relief_time = 35 ;How long it takes after a battle/encounter before NPCs can start spawning again. A safe time.
population_additive = false ;Can this zone interact with other overlapping zone spawns. Leave this at false to be safe.
faction_weight = new_no_grp, 20 ;How likely is it for a certain faction to appear. Only Nomads here, so leave this at 20 (max).
encounter = area_nomads, 19, 1.000000 ;The encounter type, difficulty, and chance (we only have the one, so these values are fine).
faction = new_no_grp, 1.000000 ;What faction(s) is to be involved with this encounter, and their chance (again, these are fine).

You should alter the faction nickname to match your own if it is different to mine above. Otherwise an incorrect faction will be called, potentially crashing the game. One last thing you need to add though before this will work, is an encounter statement right at the top of the system file (just under the system info will be fine). This just tells the game what ‘area_nomads’ means in our encounter zones that follow. It links it with an encounter .ini file, so it knows where to look for info when the spawns occur. This is what you need:

[EncounterParameters]
nickname = area_nomads
filename = missions\encounters\area_nomads.ini

I am using an already existing encounter file, ‘area_nomads’ for this. If you feel you are up to it, you may create a new one, using a similar encounter file as a template. To be safe though, I would suggest you stick along with what I am proposing initially, until you are confortable with it, and know what everything does. Save and close this file. Remember earlier when we had to edit a line in npcships.ini? The line had ‘FIGHTER’, and we needed to alter it to ‘class_fighter’. We need to repeat this again in a similar way for our encounter. I didn’t explain why this needs to be done, so i’ll do that now. If you used the default entries of ‘FIGHTER’, our encounters would show up in space, but not in missions. There is a file named shipclasses.ini, which contains ship classifications. Basically, ‘class_fighter’ belongs to the category ‘sc_fighters’, which is recognized for missions, whereas ‘FIGHTER’ is a member of ‘fighters’ which is not recognized in this way. This is a hardcoded limitation of freelancer, and there is no way around this except by using a different class.

When you have done the necessary to that file, save it up, you know the drill by now (and should be flying through these ini files). Start a local test server, or OpenSP, however you prefer to do it, and fly into that system. Go into the area where you set up this zone and see what happens. If you’re previous coding is correct you should see your new (or not so new) faction flying in space along with their ships. At this point you might want to give them a once-over, by checking their infocard text, radar text (their ship/pilot names) and checking their loadouts to make sure everything is present and correct. You can check an NPC’s level easily in-game too, and this is something many people still do not know how to do. Change the radar mode (in the bottom-left of the HUD) to show the wireframe structure of the targeted ship. You will see the level directly underneath that, and that’s all there is to that. If, on the other hand, you crash when entering this area/when these ships spawn, or even when jumping/undocking into the system to start with, then you need to revisit the earlier parts of this tutorial to go back over everything. Running some error-checkers for common-mistakes though (such as typo’s; I bet you made one) is not a bad idea, and can quickly remedy an issue without having to trawl back through everything you did.

When you’re ready, let’s move on to the next bit. Missions. How they work, how to add them in, troubleshooting and all the rest of it. Grab a drink or something so you don’t dehydrate. I won’t be held responsible for anyone passing out as a result of reading this essay of a tutorial, just as a little side-note here, you do understand that right?!

4a) ‘Prepping’ the system

Now we are ready to begin. This section won’t actually be longer than the work we have done so far. All the previous preparation work takes the longest, and is probably the most time-consuming to get right. So, well done for getting to this point, and good job on getting it all working. Feels good doesn’t it. More of that to come. Just wait till you’ve finished! You need to now open up your system ini (for whatever systen you wish to add missions in). Make sure this mission has a friendly faction and populated base too. This is so we can make this base the ‘mission-offering’ base. An empty system is no good.

Now, personally, I use freelancer explorer for object positioning, as it is very quick to use for placing new items. Alternatively, you can add everything manually, but there isn’t any good way of knowing where in the system you are adding things, so it involves a long process of adding, loading and checking, then readjusting etc. So, I would grab this program if you don’t already have it (you should). I can’t tell you how to use every part of the app, so refer to it’s own help and online on forums and so on for this. You need to go into your system and add some vignette zones. You will see these on the left pane along with other objects and zone choices. Place these within 40k of your base. This value is important as the vignettes will be ignored if they are out of range of the base we will be using to offer the missions. Use the ruler feature if you are unsure about the distances. No more than about 25k usually works good.

A good (and almost mandatory) practice when using FLE is to check your changes. And do this continually. FLE has a nasty habit of altering/resetting things which you never want to happen. So, if you don’t already do this, take that under advisement. Close FLE (remeber to go to ‘update files’ in the menu. It will prompt you if you haven’t saved, so make sure you click to do it if you haven’t already. Manually fire up your system ini and scroll down to the bottom. You will see our new additions at the bottom. They should all be uniquely numbered and ideally follow one-after-another. The actual placement and order doesn’t matter, it’s just a helpful organization for us humans when looking at it later.

I will list a sample vignette from a fictional system of my own, and then explain each entry as usual. Check yours against this:

[Zone]
nickname = Zone_New01_destroy_vignette_01 ;Name of the zone, nothing more. The system name (ew05) is just a convention.
pos = 25500, 0, -7500 ;Position of this zone within the current system. Use FLE for quick placement/moving.
shape = SPHERE ;Shape of the zone. Sphere/Box/Ellipse etc. Spheres are quite sufficient.
size = 10000 ;Size of the zone. This is the radius from the middle to an edge.
sort = 99.500000 ;A seemingly unused parameter, left-over from old coding ideas. Leave as default.
vignette_type = open ;Type of vignette, of which there are 3. I will cover these in detail below.
mission_type = unlawful, lawful ;Is this a lawful or unlawful mission? I will explain this in detail below too.

If your vignettes all check out, and are in the right positions, then we are ready to go on. Make sure you have a decent number of vignettes though. A minimum of 4 for one base will be sufficient for now. They are allowed to overlap, so if you are forced into doing that, then it is fine. I would recommend you add as much diversity as possible though to your missions by placing them in different areas.

I said above that both the vignette_type and mission_type entries needed further clarification, so here it comes. There are 3 types of mission vignettes. ‘Open’, ‘Field’ & ‘Exclusion’. Open can be used anywhere in a system, and doesn’t have any special properties associated with it, other than electing that area to be used in a mission. This is the most common type by far and can be used quite freely. I would suggest you create your first missions with these zone types and at a later stage come back and experiment with the other types. Field is used to offer missions that tell you to go to a certain field, rather than just stating go to sector xx. It’s just aesthetical at the end of the day. It requires a couple of extra entries in some other files before you will get this up and running in a new system, and is beyond the scope of this tutorial (i’ve gone on enough anyway). Refer to the web for more info on this. Perhaps I will add it in the future, as free time presents itself. Finally then, exclusion is used to create a clearing for battle. If you use this type and head out on a mission to an area that uses this vignette type, you will that your nebula or asteroids aren’t in the way. You need to add an exclusion into your existing nebula and/or asteroid file(s) though if you wish for this to work properly. Again, for more info on zones and system editing in general, please see the web. Sorry for not covering it here, but as I said, I don’t wish to digress too much.

On to mission types. There are 3 main types as above. They are better thought of as combinations though rather than one single entry. Look at this snippet:

mission_type = unlawful, lawful

This is what the values mean depending on their position in that line:

mission_type = <against>, <for>Breaking it out further, this means the first entry we use will be the target for the mission (the one we are fighting against). The second value then, is the the side we are representing (the one we are fighting for). Pretty simply isn’t it. The mission type in my above example is a typical lawful mission. Meaning when we take that mission we are fighting for the good guys. This line isn’t actually needed at all in this type of mission, but I recommend you add it in anyway. It is better for learning purposes, and it is easier to see and change later. You do however need this line for the other types. Here are the following types you can have, and when they should be used:

mission_type = unlawful, lawful ;As we saw above, this is to be used for standard ‘kill bad guy/criminal’ missions.
mission_type = lawful, unlawful ;This is the opposite to the last one, to be used for setting up ‘kill good guy’ missions.
mission_type = unlawful, unlawful ;This is a more unique type, and is used to allow criminals to fight each other.

Lawfuls don’t kill each other. That wouldn’t be typical ‘good guy’ behaviour, and so we don’t see such an occurence reflected in the mission types above. Now we are clear on that, and it is setup how we like it, we can move on to another requirement.

You need to check whether this system you are working in has encounters. If it is the same system you used earlier when we did the encounter tests then you might be good to go, but we should re-check it all anyway. You should have at least one ambient pop zones that covers the vignettes you placed. You can have any number of these. For example, you could have a seperate population zone covering each vignette, or one serving many, or just one large one covering most of the system The latter is what I would recommend to you for simplicity at this stage. The vignettes do not have to be fully surrounded by a pop zone, but it should be a good towards it. This is the so the game knows to associate the mission vignette with factions from that zone. If it isn’t touching, it will be disregarded and we won’t get missions for that area, which we need to avoid. Again, I would use FLE for adding one in quickly. It can always be moved, resized and tweaked later on as you get more familiar with the process.

Once you are happy you have a population zone containing ‘working’ encounters, for ‘both’ a lawful and unlawful faction (yes, please do test this first), then we can proceed. You can have more than one type of faction, so long as you have at least one of each. After all, our mission_type declaration states that it is a lawful mission vs. unlawfuls. The game will choose a faction at random when we end up taking the mission. It will choose a lawful faction we can fight for, and an unlawful faction to fight against from the factions listed in one of the pop zones. See the web for more detailed information about encounters and troubleshooting if you find yourself having issues you can’t resolve. There can be many causes and as such, trying to cover any here is pointless. Just referring back to what I said about the mission_type declaration; It isn’t strictly necessary to have a lawful or ‘allied’ faction in the encounter zone, so long as you have a target of course. But this will cause problems, because you won’t receive any backup in missions, in the form of allied ships coming to your aid. It might send one, but that’s all it will send, so make sure you remember to have at least one faction of each type. Excellent.

4b) Base setup

Now that is done, we only really have one more step to do in this whole mission-making process, then we can move on to the final test. We need to configure our chosen base to provide missions. Assuming you have a base up-and-running in the current system, we can move straight on into the file we need to edit. If not, check out one of the many base/station creation tutorials that are around the web. It’s quite simple and shouldn’t take you long. Just make sure all elements of this are working. This is so if you get problems later on, you will know whether it’s your mission work or a leftover issue from your base implementation. This confusion crops up all the time, trust me.

Ok, so, the file we need to edit is ‘MBases.ini’ and this lives in the Mission folder we visited earlier in the tutorial. Scroll down this ginourmous file until you find your base. You might want to use the ‘find’ button here to grab it quickly by nickname. If you have a quick look down here for the length of this base entry, you will see several distinct sections. The first is the basic info about your base, the next is a very brief one about the mission vendor, the one after that covers the layout of your base with regards to what factions and NPCs are present there, and following that we have a list of each of those NPCs and their info, and lastly one for each room that resides on the base. We only need to touch a handful of these. Before we do though, I cannot stress enough the importance of been careful in this file. Because it is so big, it is easy to lose track of where you are and start editing or removing parts you should. So, perhaps start to make seperate backups of this file, or create very easy to see markers in this file that are commented out. You might think this sounds a little overkill, but you’ll wish you had listened if and when you screw it up.

Right, the first bit to edit is the MVendor. This controls how many missions are available for the taking at the mission vendor screen in-game. The first value is the minimum amount that will always be present there, and the second value is the maximum number of missions that can appear. Bear in mind, you will need enough mission vignettes defined in your system to be able to increase this value. If you only added 4 earlier, than obviously this last value can’t exceed 4. 2 and 4 though, is the combination of choice for bases. At least, this is the most common occurence with vanilla freelancer. Planets tend to have a little more, with about 3, 5. But you can go higher even still if you really need to. It’s not really necessary, but a possibility none-the-less. So alter these values to appropriate ones. If you don’t even have an MVendor entry present then add one (refer to the below excerpt of a sample base).

The second item to edit is the basefaction section(s). If you have just the one faction on your base, then you will only see the one basefaction section. If you have more however, then you will see a seperate section for each, with each one listing it’s own NPCs that are on the base. What you need to add, if it is not already there, is a new line telling the game that this faction will offer missions. This step is actually optional, becase you can have the base itself offering missions (through MVendor) and no NPCs offering them. But I like to give the base more activity by allowing specific faction NPCs to hand out missions. So go ahead a “offers_missions = true” line in there just under the ‘weight’ declaration. If you are wondering why that line wasn’t there before, but with a ‘false’ entry, well, that’s because that isn’t a valid command. It’s either present and ‘true’ or it’s not there at all. If you ever want to remove missions then, just strip that line out altogether. See the below excerpt for a visual of this.

The third thing to edit is the “mission_type” line. Again, as above this may not be present for you if you haven’t previously offered some type of mission on this base, so you may need to add this in. This should be placed under the previous “offers_missions = true” entry ideally. It looks like this:

mission_type = DestroyMission, 36.983860, 71.051361, 100

And works like this. The first paramenter is mission type, but as there is only the one type available in freelancer, this will always be DestroyMission. The only thing that could go wrong here then is a typo. The next 2 parameters control mission difficulty and along with that mission payout. Technically, it’s difficulty decided by the payout. Where are these values from? Back in the RandomMissions folder there is a file called called diff2money.ini, and as it implies, this governs payouts in relation to difficulty. So if you go into this folder and open up this file in a new window, you can now see it’s structure. The scale on the left and the cash payout to the right of these values. You need to choose a ‘minimum’ value for our MBase entry, along with a ‘maximum’ value. This will introduce a variance in mission difficulty and payout, and as a result will make the mission random each time. In theory you can choose any value between 0 and 100 for these two, so long as the second is greater than the first and lies within a seperate price ‘band’, but looking through many vanilla freelancer bases suggests otherwise. Usually the second value resides about 2 places down in the diff2money file relative to the first one. It is best to keep this similar to vanilla freelancer to avoid any potential problems, although i’m inclined to think it will work fine either way. Check some other bases for yourself to see this.

These values do not have to be exact, so long as they are between 0 and 100. They will fall into a payout category and all will be fine so long as you followed my considerations. Besides, you may have modified your diff2money.ini file to modify mission payouts (vanilla ones are far too low huh!) so this is not a problem. I’ll just quickly mention FLE again too. If you have used FLE since doing out an mbase entry and you have altered anything in the base using FLE, then it will most likely have altered these mission_type parameters. Pay particular attention to the second ‘max’ value. It has a nasty habit of resetting this to 0, which isn’t how it’s supposed to be. If this is the case, set it back. And continually check too, as MBases.ini is a prime file to get messed up by FLE usage. The program is great, it’s pretty much the only one of it’s kind, and hats off to to Colin Sanby for coding it. Just an important thing to remember, as it happens all too often that’s all.

The last value which I haven’t covered yet is the ‘100’ at the end. Because this mission_type line resides under the BaseFaction section, we need to set a ‘weighting’ up that will decide what the chance is of that faction providing missions on the MVendor screen. This only applies to the mission dealer system and not to individual NPCs that may be offering missions at this base. Also, if you just have the one faction, then this can be left at 100. If you have other factions on the base that you want to offer missions then you will need to split up this weighting between each on of them. Remember, there is a BaseFaction section for each faction on the base, and they may or may not offer missions. You should make sure they all have entries present and correct if you want them to offer missions. It all seems like a lot of work, but after doing it a few times you’ll get the hang of it, and learn faster ways of doing it. So don’t be discouraged.

The final bit to edit, is the “mission_type” entries for NPCs. This is the same as the above entry, apart from it doesn’t have the weight on the end. This is because, that NPC will either offer that mission or he/she won’t. There isn’t a ‘chance’ setting for them in terms of missions. The first parameter is mission type, of which there is only one type as explained above, and the final values are the min & max difficulty of the missions and subsequently the payout. Set these up the same as the above for now for simplicity and speed. You can always alter them alter. You might also want to tweak your mission payouts too. I know I did once I started offering harder missions. All that work for a few thousand? Now that just won’t do will it! Here is a full base entry for your reference:

;–----------------------------
;----------Base Entry----------
;------------------------------
[MBase]
nickname = new01_01_Base
local_faction = new_no_grp ;Faction that own the base.
diff = 19 ;Ignore it; not related to missions.
msg_id_prefix = gcs_refer_base_St01_01_Base ;Used in voices, such as when you hail nearby NPCs.
;Can be left if you haven’t implemented new voices.
[MVendor]
num_offers = 2, 4 ;Min/Max mission offers at the mission vendor.

[BaseFaction] ;I have one faction only, so just one such section here.
faction = new_no_grp ;Who this base faction is.
weight = 100 ;Weighting (chance) of this faction’s NPC(s) showing in bar.
offers_missions = true ;If this line is present, this faction can offer missions.
mission_type = DestroyMission, 28.478239, 53.365002, 100 ;Difficulty & weighting at MVendor.
npc = new0101_001_m ;List of this base faction’s NPCs.
npc = new0101_002_m
npc = new0101_003_m
npc = new0101_004_m

[GF_NPC]
nickname = new0101_fix_bartender
body = pi_orillion_body
head = ge_male3_head
lefthand = benchmark_male_hand_left
righthand = benchmark_male_hand_right
individual_name = 245154
affiliation = new_no_grp
voice = rvp111

[GF_NPC]
nickname = new0101_fix_ship
body = pi_orillion_body
head = ge_male2_head
lefthand = benchmark_male_hand_left
righthand = benchmark_male_hand_right
individual_name = 245157
affilia</for></against></formation></faction>

I’ll pass that info on Gibbon. Psy doesn’t seem to be registered on starport I believe the offerbribes wasn’t mentioned though because he was using the existing nomad entries, so that would be unecessary. It was a tut for nomads after all

Like I said though. The existing entries are fine. It’ll show ‘Nomads’ or just ‘Nomad Pilot’ (whatever the name(s) is set to) in the text. Looks fine for me after I followed it. A new faction though… yeh… would need an edit for sure ;D

Yeah…. I just have a feeling I misunderstood what he meant though MK, lol