BGS Influence calculation: Random thoughts

Jane Turner

Volunteer Moderator
Not for the 1st time I woke up dreaming about the BGS this morning. A thought struck me about the way influence is calculated. Depending on the answer, there are interesting possibilites for finessing state changes.

Hypothesis 1: Continuous Transactions are processed as they are logged and at the tick the outcome is displayed

Hypothesis 2: End of state bucket empty At the tick a calculation is run which assesses the transaction score for each faction and then generates the influence and state changes



Circumstantial Evidence
  • In the bad old days when ticks were missed, the influence changes in systems with maxed out transaction on both days or just one day was one day's worth
  • Systems with a lot of transactions appear to tick through later than those with a few

Both of these support the one big bucket hypothesis

Small variations in tick time presumably account for why one system goes into expansion or retreat before another qualifying system. The intriguing question is: Is the tick time for systems fixed, or can be manipulated. I'll try and test this. It won't be easy!
 
Last edited:
Not for the 1st time I woke up dreaming about the BGS this morning. A thought struck me about the way influence is calculated. Depending on the answer, there are interesting possibilites for finessing state changes.

I am so relieved to hear this happens to someone else too! I woke up at 3am, left the missus in bed and ran a few 5+ missions last Wednesday because I had a nightmare that someone was undermining our systems! Back in bed before I was spotted though :)

No idea how you can test your hypothesis though, it'd be a pain and a half setting it up?
 
If the theory stands then the system with the least traffic should be the system you expand from when you have more then one system over 75%, thats if we assume less traffic means less was done in the system so less transactions.

Not sure if that fits my factions recent expansions. I have a system that has been over 75% for several weeks and hasn't had any influence change for more then 2 weeks now, so no transactions.

I have also never observed a change in expansion system when having several consecutive expansions with the same systems over 75%, but that could just be due to one system always having more/less transactions!

Would love to know other factions observations on this!
 
If the theory stands then the system with the least traffic should be the system you expand from when you have more then one system over 75%, thats if we assume less traffic means less was done in the system so less transactions.
That certainly doesn't seem to be the case, though I don't see why the theory implies that.

I have also never observed a change in expansion system when having several consecutive expansions with the same systems over 75%, but that could just be due to one system always having more/less transactions!
The only time I've seen changes there has been due to the "don't expand again from here if Investment fails to get an expansion" rule.
 
That certainly doesn't seem to be the case, though I don't see why the theory implies that.

Lol had to read it back a few time make sure i posed in the right thread! :D

This bit

Circumstantial Evidence
  • Systems with a lot of transactions appear to tick through later than those with a few
Small variations in tick time presumably account for why one system goes into expansion or retreat before another qualifying system.
 
Last edited:
Ah, I get it.

I suspect the tick time is fixed, and systems are just processed serially in order of addition to the game or something similar. I don't see any particular signs that busier systems tick "later" than less busy ones - looking at the EDDN changes around Colonia on today's tick, the systems that didn't record a change straightaway were a mix of busy and quiet. A system being busy may cause it to appear to tick later due to caching, perhaps.
 
Dreaming about the BGS? Thinking ok, but dreaming would be a bit much even for me.

Great, now you've planted something in my brain, gah!
 
As for what systems are picked? It seems there is a set list they go by. I have one system that always triggers expansion over other systems because its checked before the rest - and that system almost never gets traffic.

So I think they just go down their list generated as they made the galaxy to determine which systems are checked first, and then its first come first served for the states by that.
 
As for what systems are picked? It seems there is a set list they go by. I have one system that always triggers expansion over other systems because its checked before the rest - and that system almost never gets traffic.

So I think they just go down their list generated as they made the galaxy to determine which systems are checked first, and then its first come first served for the states by that.

This was confirmed by DAV on one of his early streams. Paraphrased as 'mainly fixed but apparently random'.
Coders may guess that there is no SORT applied to the select statement, so while order of processing won't change unless they do index changes to the tables, inset a lot of new systems or make meaningful changes to the script, it isn't anything obvious like alphabetic or system id
 
Mainly is the interesting word there.
Throw the english language at Dav's statement (or any FD statement) and you can get it to mean whatever you like. Dav's a coder, and with a coders hat on, it almost certainly means 1 thing. "It is fixed, but he cant guarantee it will always be the same fixed in the future"
 
As for what systems are picked? It seems there is a set list they go by. I have one system that always triggers expansion over other systems because its checked before the rest - and that system almost never gets traffic.

So I think they just go down their list generated as they made the galaxy to determine which systems are checked first, and then its first come first served for the states by that.

Its is looking that way to me too, systems seem to have a set priority
 
Mainly is the interesting word there.
The only thing I can think of that may have shifted things is when new systems are pun into the game.

I don't think they are added at the bottom of the list, but mixed into the coding method they have.

It results in a somewhat randomized systematic way of generating a list - but its still a set list.

How they are checked, is how it will likely be checked for quite some time as Dommarraa noted.
 

Jane Turner

Volunteer Moderator
I am pretty certain I saw an order change - we are attempting a retreat.

Tick 1. System A ticked 1st and the retreat went pending. System B ticked a little later and a war went pending.
Tick 2 System A ticked early and the retreating faction was up to 4.1% - I didn't check system B
Tick 3. We hit sytem A with the kitchen sink and it still hadn't ticked 10 minutes after other systems in the area. To avoid a caching issue I checked with my alt account. When it did tick it was back at 1%
Tick 4. We shall see - but we've hit it with more than the kitchen sink!


I'm starting to think that this sequence (regardless of whether its changeable or not) may be responsible for some weird results around retreat mechanics, specifically the occasions when the influence the day before the tick seems to determine the outcome and where retreating factions have been left on 1% still in the system as the tick terminates.


In a situation where a faction is above 2.5 the day before the tick ends when cut off by a conflict. If the conflict system ticks 1st, then the check on influence in the retreat systen will show >2.5 and it doesn't complete - even when as the system ticks, it drops to 1. Likewise if the faction is at <2.5 on the penultimate day, then even if sufficient BGS work is done to avoid the tick, if the conflict system ticks 1st, then the retreat goes ahead before the increase gets added.




I
 
If correct this should work with conflicts too right?
If two systems can equalise on the same day then the system with less transactions will get the conflict?
Might be able to test that as we're close to conflict in several systems at the moment, happened with our last conflict a few weeks ago but didn't check traffic in the system that got the conflict .... Didnt seem to be the one with the least work done but dont have numbers to confirm
 
Back
Top Bottom