Directed Expansion in 3.6 (pre-Fleetcarrier-Update) to 9.x (Post-odyssey-world) - A Case Study

[goemon]

"Done seen some [bleep] within my lifetime, my light shine bright/ Protect your energy from poison when the python strike" (Cordae, The Parables)

This is the first post in a series covering a recent directed expansion we played over the last 9 months or so.

i will update the links for the chapters/episodes in the table of content once each goes live (every few days).

Table of Content:

0. kicking it off (this post)
1. The directed expansions basics, a recap.
2. Story of an earlier directed Expansion (Horizon/Engineer Update)
3. a more current directed invasion as expansion - first tries
4. Recap: Expansion priority before ~FC update
5. The curious case of Expansion priority after ~FC update
6. The curious case of Expansion priority by Happiness
7. The first Circle of Happiness Data Hell: how to know which system is the most happy?
8. The second Circle of Happiness Data Hell: where to look for the happiness of a system?
9. Recap: A directed Expansion using Happiness and Invasion
10. What makes a faction in a system happy?
11. How to make a factions system the most happy?
12. Recap: Transaction BGS Game
13. method actions or how to make a system happy
14. Some further Notes on Happiness
15. So we had a Plan, we just needed a Goal
16. So we had a Plan and a Goal, and how we failed that
17. Where we finally manage our directed Expansion
18. Appendix A: I’m not gonna thank all those people
19. Appendix B: Condensed and revised structure to plan a directed Expansion


0. Kicking it off

Since long directed Expansion - getting a minor faction expand to a specific system - is considered to be one of the endgames of the endgame, which is playing the backgroundsimulation for some.

This series of posts is mainly to share an experience - of what did work and didn’t work for us and why. I will not strictly separate between what is known and tested, what is generally agreed upon, the specific case, and what I only believe or speculate to be a mechanic, and why we chose this or that method to achieve it.

Maybe this will inspire either more research ( ;-) ), or inspire someone picking up the challenge that a directed expansion provides.
Or you simply enjoy reading into the story of a long-time BGS player joining a large groups BGS team to finally get that minor faction to its first agriculture system. At the time of posting we made it!

and if you don’t care about the journey, you can jump to the last post of this series "19. Appendix B: Condensed and revised structure to plan a directed Expansion", which reflects my current understanding.

 

[goemon]

1. The directed expansions basics, a recap.

If you have no idea about the general expansion rules, i recommend taking a look here: https://forums.frontier.co.uk/threads/expansions-bgs-guide-best-current-thinking.424895/
once general mechanics of expansions were worked out, the idea of directed expansions looked easy on paper.

assume a galaxy, where there are only systems with only 6 or less factions, so you can expand to all of them.

choose a system you want to expand to.

look at the systems you control. a system over 75% will expand to the closest next one with less than 7 factions (which are all systems in our hypothetical galaxy).

count the expansions you need to get from any of yours to the one system you want, and choose the path with the least expansions needed.

your plan will look like this:

• Bring System A to 75%.
• Expand 3 times until you get to System B. Bring System B to 75% while lowering System A.
• Expand System B 2 times, until you are in System C.

…
- Expand System C 4 times, until you hit your target.

Of course it is not that easy for various reasons, as I will specify…

 

[goemon]

2. A recap of an earlier directed Expansion (Horizon/Engineer Update)

At some point 2016(!) when I returned from an exploration tour to my safe harbour in the middle of my BGS testing area, I found a player group inserted in it.

Spoiler: in case somebody doubts a good story…

in case somebody doubts a good story… here is the first mention of Varati on these forums, a year before player minor factions even became a thing (or BGS was more of a very niche interest):

if you plan to go to or come from the center, varati is a good hub. on the edge of the bubble, independent, corporate, very stabile, first outpost with outfitting is just 26 ls from entry, spaceyard is 800 ls.

Canonn Research had used that system for their minor faction submission and got it handed by fdev.

i was miffed. i was ousted from homesystems by playergroups twice, and i had no intention to move again. i jumped on their thread to vent. luckily for them (and, as it turned out, very much for me) i knew one of them, @patau82 from flipping rare goods systems. he offered me to join their BGS roundtable without being part of the group.

after horizons and its engineers hit, those mad people came up with the idea of expanding Canonn Minor Faction to an engineer system. a directed expansion in over a dozen steps. we basically followed the structure specified in (1.), even if some BGS mechanics were different back then.
there were some obstacles irrc - we had to force a retreat in one system for example to get it to <7 factions - but in december 2017 Canonn Minor Faction got into Khun being the first player groups minor faction controlling an engineer system. it was the most complex BGS gameplay i took part until than, stresstesting in practice a lot of knowledge gathered.
and after that directed expansion i moved on doing other things in game, while Canonn did what they do best. fast forward 3 years …

 

[goemon]

3. a more current directed invasion as expansion - first tries

some time in spring 2020 i was around canonn discord server more regular again, trying to make sense of the weird spawn rules of carbon-dioxide fumaroles. Canonn Minor Faction had grown to over 50 systems in between. there was an open source tool developed by @Dommarraa of Canonn Sciene monitoring Canonn Space by the feeds of third party tools (i’m told, you only need some python knowledge to use it for any faction - not the python ship type though!). there was an invasion-expansion-election happening, a mechanic i had never looked into. furthermore it was an invasion of a controlling faction.

i liked the invasion mechanic for two reasons:
1. you don’t need to force a retreat to expand into a 7 factions system, where you are always on the whim of random traffic or user error.
2. you can gain a lot of assets in one go. no need to retrigger conflicts to gain all stations.

we started scouring the map for juicy targets - non-native factions to invade with many controlled assets. we found one, which would have given an invasion-election. we started to make a project out of it.
would it be possible to trigger an invasion election with a controlling faction to eject them from system and gain all assets in one go?

for that we prepared:

• getting that faction into system control first (daily bread and butter of bgs work, but it took more time than expected as we catched a frenemy on the go, and it took some time till we went to the table. after they understood what we were trying, they gave us free reign)
• identifying expansion source systems to trigger the invasion with as few as possible alternative targets.
• filling all systems in range of that source system with 7 factions.

Known Rules of Invasion were:

• there is no system with <7 factions in range to go to
• in that case your expanding faction will invade any non-native faction in range with the lowest influence of all non-native factions in range and no active conflict in system.

the idea was to block all other options of a system to invade in range by conflicts, or - in case they were controlling - to push those factions above the influence levels of the faction we wanted to invade.

we managed to get the expansion pending. fleetcarrier update happened. the expansion vanished. it wasn’t clear to us whether that was a bug, an error, or something unknown. we found out that invasions after FC update are always war (no invasion elections anymore!), and later we found out that FC update blocked system controlling factions from being invaded. a change that actually made sense, even if it killed some interesting gameplay - but don’t we all love changes to the BGS without patch notes.

so, our little directed invasion project died, but on the go a much larger question came up.

 

[goemon]

4. Recap: Expansion priority before ~FC update
to direct an expansion, you obviously have to get your expansion source system into expansion in time, and none of the others.

easy, just see to it being the only one over 75% after expansion cooldown ends, you say.

but that is not really an option once you manage a faction with many small population and few factions present volatile systems, or systems with a lot of traffic like an engineer system.
Canonn Minor faction usually has at least two dozend systems over 75%.
it has the oddity of being the only not handplaced faction controlling a system at 100% (all other factions retreated).
and permanently working against the faction you back does not inspire enthusiasm, and even if you do, you are again on the whim of random traffic or user error (“i redeemed 70 mio in bounties in that backwater system, as the haz res is visually beautiful. i thought it would help”).

and it also wasn’t really necessary back then, because expansion priority.

first of all (and that is still the case): after two consecutive expansions failed from a system, that system is on “the naughty list” - it will never expand again, and there is no known mechanic to get it from that list. @Ian Doncaster has an impressive example from colonia of a faction being locked out of expansion, as their system failed twice in a row to expand.
so, of all your system over 75% you can cross out those on the naughty list.

and then there was expansion priority. for a long time the tested mechanics were as follows. to quote Jane Turner formulating the state of knowledge in 2018:

[*]Where from: In a situation where more than one of a factions systems is over the expansion threshold, there appears to be something that makes some expansion centres preferred over others. It is not yet obvious what this is (e.g. not time over 75%, % itself or alphabetical order.) The best explanation available is that the tick runs through the galaxy system by system, in a defined order.

or to put it out more simply:
if you had systems A, B, C over 75%, and System A expanded once before B and C, it would always expand first from System A - instead of B or C if over 75%.
So you just had to know your systems Expansion priority.

In case of directed expansion, you did not have to care about systems over 75% being in row behind your source system.

you only had to reduce the influence of the remaining 75% systems being of higher expansion priority than your directed expansion source system. this massively cut down the wetwork required.

only it stopped working that way around the FC update.

 

[goemon]

5. The curious case of Expansion priority after ~FC update

with many Canonn systems over 75% anytime, it became rapidly apparent that the old expansion priority rule didn’t work anymore.
we couldn’t predict anymore which system would expand.
my first thought was fdev having simply changed the order (which rules anyways nobody had worked out).
but then a system which had expanded the last time didn’t expand again before another system, which had not expanded, so should have been of lower expansion priority.
i thought maybe there was some kind of cycling, but then a system expanded twice in a row.
we put it to the test. pushing three systems over 75% - and keeping them there over the full time - one system expanded, then one other, then the second one again.
so we knew and had proof that the old expansion priority rule was gone.
which of course was no step towards what actually makes one system expand above the others.

 

[goemon]

6. The curious case of Expansion priority by Happiness

@Dommarraa was lucky enough to get Community Manager @Paul_Crowther s attention in an AmA, asked what makes one system expand above the others, and got the following answer:

“A faction's eligible for expansion if it's over 75% influence in any given system that doesn't have a conflict active within it. A faction can only have one expansion at once, no matter how many systems its present in. If multiple systems are eligible, then it chooses the one with the highest happiness.” https://forums.frontier.co.uk/goto/post?id=8828199

the one with the highest happiness. i called that bull, as others did.

first of all i had my fair share over the years of fdev employees saying something BGS works in this-and-this way, but not having understood what their developers did. i remember trying to counter rumors from a support mail that no CZ-missions on the mission board “might be down to the faction not having enough money” by looking into the hidden wealth-level of a system (if you don’t know about those hidden numbers, look into FDEVs support fleetcarrier faq: https://forums.frontier.co.uk/threa...led-in-carrier-admin-system-selection.547590/).

second, even if it is someone knowledgeable of fdev talking, there is no guarantee that something actually has the effect intended. example would be “super power bounties” (https://forums.frontier.co.uk/threa...-mechanic-and-bountyhunting-after-2-3.346177/) - intended to boost federal, alliance and imperial factions it created the opposite - for rules of the backgroundsimulation.

third, even if you actually get into communication with a dev, who actually knows what he is doing like @Dominic Corner - who’s input i love every time on this forum - it does not mean it actually works - longrange missions, i’m looking at you! https://forums.frontier.co.uk/threads/rev-enging-mission-boards.543467/page-9

i guess the BGS is for everyone dealing with it a hydra - fdev and players alike.

the fourth reason why I called the statement bull was the very prominent place of a longstanding bug:

Spoiler

if you pledge a squadron to a faction you get an overview page with all systems the faction is present in. one of the systems is marked as the “happiest” system. only that system isn’t the happiest one, it is always the same one no matter its happiness. until at some point you expand to another and another system, and suddenly that new system is marked as the “happiest”. that doesn’t happen every expansion, but once in a while. and now the CM was seriously claiming that the system with the highest happiness will expand …

anyway, we tried to find contradicting data to that statement. to drop a bug report or something and escalate it. if, for example, a “happy” system would be chosen as expansion source over an “elated” system, that would be a contradiction of that statement.

and that put us into the hell that is happiness data …

 

[goemon]

7. the first circle of happiness data hell: how to know which system is the most happy?

there are two aspects to the question, which system is the most happy. one aspect is: game design itself is sparse on feedback about the happiness of a faction.

happiness value can be elated, happy, discontented, unhappy or despondent. that’s it.

with influence and reputation you get numbers (for reputation at least by the journal), and people have done great things with those numbers - for example calculating the influence effect of a 1 mio bounty redeem. you do this, your influence increases that much: https://forums.frontier.co.uk/threads/bountyhunting-and-influence-fc-update-bounty-buff.565678/

with the economy and security “slider-states” you get - well, sliders. @Factabulous of canonn research has investigated them thoroughly here: https://forums.frontier.co.uk/threads/facts-new-theory-of-hatching.477450/
so with the economy and security states you get feedback by a slider where you are moving. okay, we are in boom, almost investment!

with happiness there is no such thing per design. you don’t know whether a system is just happy, very happy, almost elated, elated-but-going down. it is either happy or elated. and as noted above: the only place which could at least tell you which system is the happiest is bugged.

by design playing the bgs game for happiness is a bit like trying to get control in a system without knowing influence levels. you’d see a faction, then another in control. there are states happening, a war for example. and a boom. black box deluxe.

that gamedesign aspect is the gamemasters choice. one can like it or not - but i was playing the bgs before we even knew what triggered a war….

 

[goemon]

8. the second circle of happiness data hell: where to look for the happiness of a system?

the game design thingy doesn’t answer the question where to look, if you actually want to know the actual even-if-very-sparse happiness value of a system. this is the second aspect of the question, which system is the happiest one.

there are four places you can look at:
- right hand panel

Spoiler

- station news

Spoiler

- journal

Spoiler

{ "timestamp":"2022-01-29T10:43:55Z", "event":"FSDJump", "StarSystem":"HR 8133", "SystemAddress":2243843590499, "StarPos":[-133.87500,26.28125,-28.96875], …, "Factions": …, { "Name":"Canonn", "FactionState":"None", "Government":"Cooperative", "Influence":0.116883, "Allegiance":"Independent", "Happiness":"$Faction_HappinessBand2;", "Happiness_Localised":"Happy", "SquadronFaction":true, "MyReputation":100.000000, "RecoveringStates":[ { "State":"Expansion", "Trend":0 } ] }... }

- overview page, if your squadron is pledged to a faction.

Spoiler

here are the things we found out:

1. all of the four sources can have different values at the same time.
your faction might be happy in right hand panel, elated in station news, elated in journal and again happy in overview page. or any other combination you want.

2. happiness can change during a tick multiple times.
… even according to the same source. for example you can jump into the same system, and while no state and influence levels have changed in journal, happiness has. or you dock a second time at the same station during the tick, and your faction isn’t elated but happy now according to the station news.

game design and unreliability of source made it of course problematic (or easy, depending how you look at it) to disprove the community managers statement that “If multiple systems are eligible, then it chooses the one with the highest happiness.”

we decided to settle for the station report as our main source, while @Dommarraa also worked @Garud of elitebgs.app to make their api reporting multiple hapiness changes per tick (i hope i got this right, it sounded very cool).

the main reason to settle for the station news report was
a) it is generally the most reliable, crossplattform and crossmode source.
b) it reports state-changes and influence values first.
c) it is said to be generated everytime when docking at a station, so it isn’t cached.

so, how do you use the station news to disprove the statement, “If multiple systems are eligible [for expansion], then it chooses the one with the highest happiness.”?
Well, by waiting for the expansion to be reported in the station news, while checking station news for happiness in as many systems >75% as you can manage as close to that “tick” as possible. if you'd find a happy system over 75% expanding instead of an elated over 75%, that would contradict the statement.

we found no contradiction.

 

[goemon]

9. recap: a directed expansion using happiness and invasion

if you accept the statement, “If multiple systems are eligible [for expansion], then it chooses the one with the highest happiness.” a directed expansion plan using happiness and invasions would look like this

• fill all systems in expansion range of system A with 7 factions.
• bring system A to >75% and make it the most happy one, so it expands.
• bind all non-native factions in all systems in range you aren’t in and don’t want to go to into a conflict during the time of expansion, so they can’t be invaded. or push all of them above the influence level of the non-native faction in system B you want to invade.
• repeat with system B

…
- repeat with system C
…

so you only need to work out how to make a system the happiest, super-elated, and you actually don’t have to care about all the other >75% systems.

 

[goemon]

10. What makes a faction in a system happy?

you can follow different experiences and ermergent theories and how they got shut down by conflicting data of several BGS players in this thread https://forums.frontier.co.uk/threads/happy-now.559980/, which was @Dommarraa s follow-up to the community managers statement.

i just want to point out that my own pet theory - which was also later revealed to be the community managers opinion https://forums.frontier.co.uk/threads/happy-now.559980/post-8888103 and is also what the wiki says on happiness - was wrong.
happiness is not based on a factions states. states do not increase or decrease happiness. thanks to @Ian Doncaster who one-shotted that idea with a table of colonia happiness data from his brilliant colonia census data base https://cdb.sotl.org.uk/.

while happiness correlates with states, it is neither caused nor depending on them.
what does that mean? well, an elated system will often be in boom, or investment, or civil liberty, but neither a state change causes a change of happiness, nor a change of happiness a state change.
the first can be proven by simply looking at happiness changing during a tick, while a state doesn’t.
the second can be proven by looking at the economy and security slider states.

we can discuss, whether a system for example in civil liberty gets elated more easy (a bit like an short-range blaster cannon deals more damage, if you hit - but you have to hit in the first place) or not (i think not). but in itself a state does nothing for happiness.

on the other hand the pattern emerging was: systems with more activity are more likely to be elated. systems with more activity are also more likely to be in boom though (it is a very good indicator of a no-activity/no-traffic system, if none of the faction has any slider-state). correlation.

but that didn’t bring us towards finding out how to make a system the most happy one for our directed expansion. “be very active” isn’t something you need to tell cmdrs preparing a directed expansion - they are very active anyways.

 

[goemon]

11. How to make a factions system the most happy?

we tried several things. for example: picking up on medicine trade countering outbreak and legal weapon raising security level; we tried shipping large quantities of legal drugs. and tried shipping those commodities high in demand during public holidays. those after an infrastructure failure. and so on. with no apparent effect.
funnily it was a thread of @Ian Doncaster not related to BGS which brought us on the right track. he is publishing squadron season results every cycle, but he never looks at the “political” squadron trophy, because that is easily exploitable. as far as i read into it, to get “political” points, you simply have to sale large quantities of commodities by pressing "sell" most often, 1t at a time, at a market the faction controls … as long as you can stomach, before you get a new load and repeat. i’m pretty sure there are some checks in place to not make it that simple, but anyway - the political trophy is easily exploitable, which is why Ian never includes it in his results. and it for sure does not measure “keep a large and happy faction” as its description says.
but that got me thinking: the exploit to make points to “keep a large and happy faction” was transaction based.

 

[goemon]

12. recap: transaction bgs game

what constitutes a transaction? most basic you can think of it as any time you press a button to create an bgs efect.

handing in a mission is such a transaction, selling a commodity, but also finishing a scenario is a transaction.

until 4 years ago or so, influence effects were massively transaction based.
for example redeeming 4 times bounties of 25k was largely more influential than to redeem 1 bounty of 100k. 4 small transactions bested 1 large sum everytime. this was changed by fdev at some point for good reasons. as of now it doesn’t matter for influence gain, whether you redeem 4 times 25k of bounties or 1 time 100k (https://forums.frontier.co.uk/threads/bountyhunting-and-influence-fc-update-bounty-buff.565678/).
for trade, frontier raised the tonnage-influence effect to levels that selling off 5 different commodities of 20t is less efefctive, than selling 100t of one commodity. and as you are limited by any ships maximum tonnage, you simply cannot create that many transactions by many different commodities with 250t (python) or 720t (t9) with the influence effect reaching its maximum at around 150t. https://forums.frontier.co.uk/threads/trading-for-influence-ii-fc-update.555082/

and so on.

and than there are the checks in place frontier implemented against the famous 1t-trading-exploit to nuke factions influence.
for reputation gain there are maximum gains per docking in place.

so, transactions have been gone as a central category of bgs gameplay for good.
but taking together the political squadron trophy and our previous experience of transaction based bgs gameplay - could it be, that happiness was transaction based?

 

[goemon]

13. method action or how to make a system happy

first of all - nobody needs to panic - no, you don’t sell 1t at a time to make a system elated. we had a player trying this (manually!) with no apparent effect. as said, the checks against the 1t-trading-exploits are still in place.

but once we started racking up positive influence transactions, we got the system we wanted to elated.

this of course also might explain, why happiness correlates both with traffic/activity and favourable economic and security states.

so, how did, after refining, a typical session look for me working a systems happiness?

• load up the python with some salvage goods like occupied escape pods.
• fill the rest with profitable commodities of 20t batches, often 7x20t (the 20t were based on commodities and my bgs pythons cargo space, but i actually think there is a threshold of influence gain per transaction you have to cross)
• jump into the system, scan for USS
• go to a distress call of the faction and fuel up the npc (minor positive security, economy and reputation effect of that scenario)
• go to a weapon fire USS, and get a bounty redeem.

- fly to outpost.

hand in:

• a bounty
• a few escape pods, black boxes and such via search and rescue
• a stacked mission (or more)
• exploration data via Universal Cartographics
• sell off 7x20t of commodities

after that i picked any new missions fitting, especially fetch missions, and repeated.

depending on how you count, and how many different salvage goods i brought, that are 12-16 positive transactions per system visit and docking. on a weekend i could rack up above 100 transactions a day.

many commanders did only some or one of the above - the joy of group play, power of the crowd.

now, i can’t tell you, which of the above is most effective, or if everything of it is effective at all. if somebody would run a test and conclude that for example search and rescue is most effective, but USS scenarios do nothing for happiness i would think it very possible.

but we didn’t run a test - we were trying to get our grip back on how to direct an expansion. and we had found a method to push the right system into elated and keep it there.

 

[goemon]

14. some further notes on hapiness

it looks as if happiness has a decay from elated to happy (its default). mechanically similar to superpower reputation, but in a shorter timeframe. so to make and keep a system elated, you will want to have positive transactions regularly over the full time. happiness is not tick based, so ideally you spread your groups and your own activity over full 24 hours cycles.

it also looks as if you can’t push a system into sustainable high happiness levels fast with a lot of last minute transactions. we weren’t successful when forced to change expansion source in a shorter time frame of 2 days (but that might be down to the numbers we could muster - eventually if you have more commanders doing that you would succeed ).

in the end we settled to start prepping a systems happiness along with its inluence for expansion roughly a week in advance, and racking up transactions in the last 24-48 hours.

 

[goemon]

15. so we had a plan, we just needed a goal

our new directed expansion plan looked very much as written out in 9.
we now knew again how we could bring the game to choose that system over 75% above those others to expand.
@Dommarraa s open source tool to calculate expansion cycles (number of expansions needed to get a faction from a to b) by expansion cube calculation had been upped to include previous retreat awareness, and took number of factions in system into account. we just needed a target.
a directed invasion-election of a controlling faction wasn’t possible anymore with the mechanics.

back when Canonn had gotten control of Khun, the bgs roundtable discussed whether Canonn should get an agriculture system next. we looked at the options, and it just looked as too much work. 4 years and roughly 70 expansions later Canonn Minor faction was still not in any system with a primary economy agriculture orbital. while Canonn was expanding from the edges of inhabited space other player factions looking to be out of powerplay spheres had chosen the agricultural systems around as their home, many of them most likely looking for a system with an earth-like. the options of agricultural systems around where Canonn actually might want to expand to were very limited, and came down to 1 in the end.

we set up a cluster of small population systems as an expansion hub to fill the space around expansion target with 7 factions as to switch between sources. because getting a system back to 75% after expansion tax in the two days of expansion cooldown can be challenging. and on the other hand we didn’t want to retreat the non-native npc factions in our expansion source systems by pushing to 90% or more pre-expansion tax, as to avoid factions to expand to them we didn’t wanted to share a system with (sharing systems can be a lot of work, we learned to avoid that).

 

[goemon]

16. so we had a plan and a goal, and how we failed that

expanding the right systems by making them elated generally worked out. we filled up systems just as required.
but while our plan looked good on paper it failed one time after the other in its last step to target.

the first kind of fails was down to random retreats in range of our expansion source. it is remarkable how hard a retreat feels if you force it, and how often it happens, if you have to monitor 10 systems for potential retreats - all while you try to prep up a systems influence and happiness, get the last system you expanded under control, and should also check on other >75% systems getting elated. we never got the invasion-expansion we wanted, but filled a bunch of systems after unexpected retreats. because systems with <7 factions always take precedent above invasions.

the second kind of fails was down to random traffic pushing other systems to elated and outcompeted our expansion sources hapiness. Khun for example has a traffic of 1000 ships, not even looking at FCs, 400+ mio bounties redeemed each day - it is either over 75%, in investment and elated, or civil unrest and happy. and while it is extreme, it is not the only random traffic high activity system Canonn controls.
so, whenever we had all systems filled, and no random retreat happened in range, and our source was elated, some of the high traffic systens went elated as well and we just never got the right system pending at that point, because some other was even more happy.

 

[goemon]

17. Where we finally manage our directed Expansion

so, what are you doing, if your plan is too complex for you to pull it off? you reduce complexity.
we decided that we had to reduce the number of systems we had to watch, manage and prepare. as you can’t take out systems from the galaxy map, we had to move our expansion target up the expansion priority lane. we decided to force a retreat, so getting any system in range into expansion it would go there if all others in range had at least 7 factions. and if not, it would still go there if our target was the closest system with <7 factions.

we started working our agricultural target system. we made the non-native faction we wanted to retreat taking over an asset to target for negative influence, and than pushed them down. a retreat does not stop an invasion conflict - so if we would have managed our directed expansion-invasion during that time, it would still have happened.

as said before - forcing a retreat puts you on the whim of (random) traffic and user error. but with some pointers from this forum (https://forums.frontier.co.uk/threa...ation-with-negative-influence-actions.596626/) at least we could guesstimate how much work we would have to put in to make it very likely for that factions retreat going through. the high population of our agricultural target system also helped. and so they retreated.

it was early christmas, for both real and fuzzy feelings. we catched an unforeseen retreat in a neighbouring system while everyone was busy forcing retreat and pushing up the right system, delaying our expansion into system another cycle. we got the wrong system into expansion over hollidays when everyone was busy doing other things.
we checked the expansion cycles of all factions “threatening” to expand into our precious to push them down if needed. i compiled a list of all canonn systems going elated more regularly by random traffic.

the forced retreat had massively reduced the number of systems to watch for retreats, and the expansion cycle dates of factions threatening to expand into system gave us timeframes to check for their influence.

than the stars alligned. the canonn comfy cruise expedition ended after almost a year as well as the speedscanning challenge. and a CG for double-engineered FSDs had drawn even more canonneers into the bubble. and our next expansion would go pending early monday: a whole weekend to rack up transactions.

we started saving bounty- and missionredeems for the smaller factions in four or five systems we would have to push under 75%, as they often showed signs of elated by random traffic (while redeeming the Canonn bounties in the system we wanted to expand). we managed to trigger conflicts locking influence up so Canonn couldn't get to 75% in some of the most threatening high traffic systems.
explorers teamed up across timezones to organise a constant redeem of exploration data pages over the weekend.
a bulktrading and a fetch-mission-commodities FC orbited the outpost in our expansion source system.

the system went to elated as expected. the other high random traffic elated systems fell down below 75% on the tick before expansion would go pending. none of the many other systems over 75% showed elated hick-ups. almost there.

i got up early monday morning, and went to the office early (for me), as i wanted to redeem another 20 missions directly before the tick over breakfast, plus some occupied escape pods, plus a full load of cargo, plus a bounty.
after the tick somebody logged into the game, the right system was expanding. my present RL coworker was a bit irritated about me cheering “yes! yes! yes!” during break on a monday morning.

the rest was a bit of admin work. checking that we hadn’t missed a threatening expansion of another faction. no, all was good. checking the systems, where a retreat would still threat our directed expansion until 5 ticks before latest expansion date. all fine. waiting. counting down. preparing the agricultural systems influence levels for take over. Canonn moved in, and in a few days later we had system control election.

the population of that agricultural system are having a free and fair election, whether they want to be governed by a corrupt expansive federal confederacy selling weapons of mass destruction to the highest bidder, or your humble science cooperative, bringing knowledge and a soontill relict to any miner in backwater systems so they have something to ponder while stripping asteroids.
and Canonn will finally take control of their first agricultural orbital. may their stacks of biowaste always be full to dump them in protest against anyone hindering science!

 

[goemon]

18. Appendix A: i’m not going to thank all those people

if you have read until here, you probably expect some kind of thank you - if not to you for reading this much-too-long-posts than to a bunch of other people, as the project of a directed expansion included so many different people in so many different ways.

but i’m not gonna thank fdev to provide me with a game i return to that often, and for thousands of hours, or including the BGS (and keep the detailed bgs patchnotes coming!),
and i’m not going to thank all those people on these subforum sharing their BGS knowledge openly and discuss it,
and i’m not going to thank the commanders flocking to the cause of a directed expansion,
and i’m not going to thank the Council of Canonn and the admins and moderators of their discord server to provide a place, where i’m not the only one being obsessed about a niche of niche of a game (and also give back varati to its natives!),
and i’m not gonna thank @Dommarraa of Canonn Sciene to share the same character traits for grumpiness, laziness, least effort-maximum-effect and him being such a dry humored rock,

because, you know, what comes around goes around.

instead i want to take a moment to thank some people often overlooked in what they do for the game as i play it.

thanks to those third party site database-keepers and programmers, who share their data with each other, and make it available by apis and datadumps (and of course, webinterfaces) to us players. namely:
@themroc of eddb.io (my default option)
@Garud of elitebgs.app (beside its discord bot making monitoring so much easier, it is also the place for a bgs-deepdive by digging into a systems bgs history)
@Spansh of spansh.co.uk (which has a surprisingly powerfull search for weird populated system parameters, and his tourist route plotter with destination imports makes my system-data-update routes so much easier)
and especially @Athan of EDDN and EDMC.

without, let’s say, precise system coordinates databases nobody would have been able to find out about the expansion cube, but it is even more sharing of data between your tools and by api and stream and userface with players, which makes a project like a directed expansion manageable.
even for somebody like me, who stopped dabbling with coding, when cobol and basic were still a thing, and for whom python is a type of ship, or a snake. thank you!

 

[goemon]

19. Appendix B: Condensed and revised structure to plan a directed Expansion in the current game

“I can tell you 'bout the time I had a penny and a plan/…” (Cordae, The Parables)

1. Compile a list of final targets you want to go to of at least 1 system

2. List your controlled systems.

2.1. Cross out all systems on the “naughty list” of systems having failed 2 consecutive expansions. If you don’t know that list, you will assume all of your systems can expand.

3. Calculate the standard range expansions you need from any of your systems to your target if you assume <7 factions in system.

3.1. for that you need to calculate with the expansion cube, not range. @Dommarraa s opensource tool CSN can help with that, if you know some python. otherwise check the coordinate deltas up to the theoretical limit of 34,64 ly.

3.2. you obviously do not need to do that for your systems being on the other side of your space to target, but down to stardensity it isn’t always the closest system from target which needs the least steps.

Your plan should now look like this:

Spoiler

SOURCE 0
TARGET 1/SOURCE 1
TARGET 2/SOURCE 2
TARGET 3/SOURCE 3
…
FINAL TARGET

4. check all systems on your expansion target/source list for number of factions.

4.1. note if a target has less than 7 factions. as that can change, i recommend not relying on it too many steps upfront.
4.1.1. if a target has less than 7 factions
… you need to fill all systems closer to your current source with 7 factions. either by filling it with your faction, or by others.

Your plan should now look like this:

Spoiler

SOURCE 0
- 3 Expansions to fill System A, B, C.
- 4th Expansion to TARGET 1.

TARGET 1/SOURCE 1
- 1 Expansion to fill System D
- Expand NPC faction Z into System E to fill it
- 2nd Expansion to TARGET 2

…

4.1.2. if a target has 7 factions…
4.1.2.1 … you either force a retreat …

Your plan should now look like this:

Spoiler

SOURCE 0
3 Expansions to fill System A, B, C.
- 4th Expansion to TARGET 1.

TARGET 1/SOURCE 1

• 1 Expansion to fill System D
• Expand NPC faction Z into System E to fill it

- Force Retreat of Faction Y in Target 2
- 2nd Expansion to TARGET 2
…

4.1.2.3. … or you go for invasion.
4.1.2.4. for invasion you need to fill all systems in range (cube calculations!) with 7 factions.

Your plan should now look like this:

Spoiler

SOURCE 0
3 Expansions to fill System A, B, C.
- 4th Expansion to TARGET 1.

TARGET 1/SOURCE 1

• 1 Expansion to fill System D
• Expand NPC faction Z into System E to fill it
• Force Retreat of Faction Y in Target 2
• 2nd Expansion to TARGET 2

TARGET 2/SOURCE 2
- 2 Expansions to Systems F, G
- Invasion of TARGET 3

4.1.2.5. you will invade the non-native faction with lowest influence in range (cube calculations!), which has no pending, active or cooldown conflict.
4.1.2.5.1 conflict in its shortest duration blocks invasions 7 days, while expansion length varies for a maximum of 3 ticks.
4.1.2.5.2 compile a list of all non-native factions in systems in range
4.1.2.5.3 cross out the system controlling ones.

Your plan should now look like this:

Spoiler

SOURCE 0
3 Expansions to fill System A, B, C.
- 4th Expansion to TARGET 1.

TARGET 1/SOURCE 1

• 1 Expansion to fill System D
• Expand NPC faction Z into System E to fill it
• Force Retreat of Faction Y in Target 2
• 2nd Expansion to TARGET 2

TARGET 2/SOURCE 2
- 2 Expansions to Systems F, G
- non-native Factions P, Q, R, S, T, U, V in Systems H, I, J need to be above non-native Faction in TARGET 3 or in conflict at latest expansion date.
- Invasion of TARGET 3.

your plan is ready.

5. find out your expansion cycle. cooldown of expansion is always 2 ticks, while pending and active expansion combined have a total duration of 9-11 ticks (10 +/-1). in most cases you will expand every 13 days. calculate with +/- 1.

6. systems which are at 75% at the tick expansion cooldown ends can go pending expansion the following tick.

7. bring your source to >75% latest at the tick before a new expansion can go pending.

8.1. bring all other systems <75% latest at the tick before a new expansion can go pending.​

8.2. if that is no option…
8.2.1. make your source elated.
8.2.2. while bringing all systems <75% which are not your source, but elated - latest at the tick before a new expansion can go pending
8.2.2.1. better safe than sorry. if a system gets elated often without you working it, bring it to <75% in time, as it might get elated on the last tick before expansion gets pending. eventually lock influnce by triggering conflicts if you can't outcompete traffic.

9. Repeat until you expand into your FINAL TARGET

Never surrender- and enjoy!