Powerplay PowerPlay and the state of the Journal.

Warning - rant.

Some of you know this, many do not. To organize PowerPlay you have to do an enormous amount of data entry. Manual data entry. Manual data entry that is stupefyingly, mind-numbingly stupid, because the data needed isn't available without transcribing the information from the game screen.

There are currently 659 control systems (and 11 headquarters that aren't relevant for this), each of which has nine data points:
Upkeep from last cycles (can change once a week)
Default upkeep cost (never changes)
Cost if fortified (is ALWAYS 0)
Cost if undermined (can change once a week)
Base income (can change once a week)
Fortify total (can change hundreds of times a week)
Fortify trigger (can change once a week)
Undermining total (can change hundreds of times a week)
Undermining trigger (can change once a week)
Once a week, every power that wants to properly manage themselves need to go through every single control system to check and update six data points. That's currently 3,954 data points that have to be manually entered into a spreadsheet or databases. There's no copy-pasting, because the journal doesn't have useful information for this.

Additionally they'll want to update their fortification and undermining totals several times a week as well. If it's just once per day, that's currently 9,226 data points.

If powers want to run an organized offensive campaign, they'll also need to keep track of these things for their target. On the top end, that means each power currently enters 13,180 data points manually every single week. Across 11 powers that's 144,980 data points. If we assume it takes 1 second to enter each data point (lowballing significantly here) that's more than 40 hours wasted on this every single week.

Oh, but it gets better.

There IS PowerPlay data in the journal - but it's borderline useless.

Let's go through some of them.

{ "timestamp": "2016-06-10T14:32:03Z", "event": "PowerplayCollect", "Power": "Li Yong-Rui", "Type": "siriusfranchisepackage", "Count": 10 }

Okay, so CMDR Vectron has picked up 10 fortification merits. So far so good.

{ "timestamp": "2016-06-10T14:32:03Z", "event": "PowerplayDeliver", "Power": "Li Yong-Rui", "Type": "siriusfranchisepackage", "Count": 10 }

And CMDR Vectron has delivered 10 fortification merits. Where? Where did Vectron drop off these merits? Li Yong-Rui picks up merits in their HQ and delivers them to a control system. All we know from this is that Vectron dropped off 10 merits somewhere. We don't know what system, nor do we know the progress for the system.

We can do a bit of snooping and check where Vectron last docked, but that only tells us that Vectron dropped off 10 merits in Dinda. What is the current state for Dinda? Is it 10 merits? 100? 1,000? 10,000?

Oh, but it gets worse.

What if Vectron is pledged to a different power. What if he's pledged to Edmund Mahon? Why does that matter? Because Edmund Mahon picks up fortification merits in the control system and drops them off at the HQ. We can, of course, link the pick-up with where he was docked, but that is a massive pain to do.

There's one more thing in the journal: FSD Jump.
If the player is pledged to a Power in Powerplay, and the star system is involved in powerplay,

Powers: a json array with the names of any powers contesting the system, or the name of the controlling power PowerplayState: the system state – one of ("InPrepareRadius", "Prepared", "Exploited", "Contested", "Controlled", "Turmoil", "HomeSystem")

Now imagine being EDDB, Inara or anyone else trying to keep track of the state of the galaxy. What should you do when a system keeps alternating between having and not having PowerPlay information attached to it, and you get hundreds of updates to it an hour? The sane thing is to ignore the information altogether, which is what both EDDB and Inara does (I'm not even sure if it's in the EDDN feed).

"But Vectron!" I hear you cry. "I just checked EDDB and Inara and they both have PowerPlay information for control systems. How can that be when you just told me they ignore it?"

I know they ignore it, because I'm the one who sends EDDB and Inara the PowerPlay information they use. I am the trusted source for that information, because the game CANNOT be trusted to give them the proper information. And I do this every week, and I've been doing it for almost FIVE YEARS! The first time I sent the data to Inara was the 12th of January 2017. TWO HUNDRED AND FORTY NINE WEEKS of manually gathered and entered data provided to the community because Frontier doesn't care about PowerPlay. I started doing it back in 2016 for EDDB, and EDDB even set up an API for me to do it back in September of 2016.

That is my proof. For more than 249 weeks a community member has had to take more than an hour out of their schedule to ensure that the community has useful and correct data for PowerPlay, because Frontier hasn't updated the journal to include USEFUL PowerPlay data. They "owe" me at least 250 hours of pay for my services, and I will happily take my payment in the form of an updated journal that means I and no one else needs to constantly manually update their databases and spreadsheets. I'd also like a brand new gaming computer, but I suspect getting either is about equally likely.

Back when the journal was introduced, I was VERY quick to suggest JSON arrays that would be great to have (though it could have been better), but nothing ever came of it. That was on the 20th of July 2016. That's MORE than five years ago. Two months later I started talking with EDDB on how to keep it properly updated with PowerPlay data.

There are dozens of ways to improve the journal for PowerPlay, and Frontier has chosen to do none of them. Again, I don't know why - all I can say is that they've done nothing except promise that they'd put a focus on improving PowerPlay "later" and "soon" for more than five years.

Five years of the PowerPlay community asking, begging and pleading with Frontier to just give us the tiniest of table scraps. Five years of Frontier looking the PowerPlay community in the eyes saying "we'll have something nice for you soon" as they dump their leftovers into the dumpster. Five years of the PowerPlay community dumpster diving for the scraps that Frontier threw out, while trying to put together something that even resembles a meal. Yes, that metaphor is now overused.

I'm tired. I can feel it in my bones. I feel like butter spread over far too much bread.

What's the solution? Better journal entries is my main hope. Or just kill the whole thing altogether, as I've publicly suggested multiple times, both on this forum and on reddit.

PowerplayDeliver needs a few updates to cover expansions, expansion opposition, fortification and undermining.

{ "timestamp": "2016-06-10T14:32:03Z", "event": "PowerplayDeliver", "Power": "Li Yong-Rui", "Type": "siriusfranchisepackage", "Count": 10, "System": "Dinda", "Defence": {200, 2588} "Offence": {0, 30850} }

This works for almost all types of merits. Something else is needed for preparations:

{ "timestamp": "2016-06-10T14:32:03Z", "event": "PowerplayPreparation", "Power": "Zemina Torval", "Count": 10, "System": "CD-62 234", "PotentialValue": 1, "Cost": 128, "Totals": {{"Arissa Lavigny-Duval",9700},{"Zemina Torval", 80}} }


The location, FSDJump, CarrierJump and other such events needs updating to be better for PowerPlay as well. Basically, if it includes BGS information, it should include PowerPlay information. Instead of the current mess it should always be present and include something like

"PowerplayState": one of ("Preparing", "Expanding", "InExpansionRadius", "Exploited", "Contested", "Controlled", "Turmoil", "HomeSystem", "None"), "Powers": a json array with the names of any powers contesting the system, or the name of the controlling power, "ExploitedBy": a json array with the control system exploiting it (multiple control systems can be within 15 light years, but only one of them receives the exploited system's CC). When multiple powers contest a system, this should be empty, "ContestedBy": a json array with the control systems that are within 15 light years of the system. When only one power has control systems within 15 light years, this should be empty, "BlockedBy": a json array with the expansion systems that are within 15 light years of the system. Only used when "PowerplayState" is "InExpansionRadius", "Upkeep": an integer value of the current upkeep for the system. Only used when "PowerplayState" is "Controlled", "Turmoil", "HomeSystem". "DefaultUpkeep": an integer value. Only used when "PowerplayState" is "Expanding", "Controlled", "Turmoil", "HomeSystem". "CostIfUndermined": an integer value. Only used when "PowerplayState" is "Controlled", "Turmoil", "HomeSystem". "BaseIncome": an integer value. Only used when "PowerplayState" is "Preparing", "Expanding", "Controlled", "Turmoil", "HomeSystem". "Defence": an integer value array that is either fortification or expansion value {total, trigger}. Only used when "PowerplayState" is "Expanding", "Controlled", "Turmoil", "HomeSystem". "Offence": an integer value array that is either undermining or opposition value {total, trigger}. Only used when "PowerplayState" is "Expanding", "Controlled", "Turmoil", "HomeSystem".HomeSystem". "Preparations": An array of arrays as seen in PowerplayPreparation above {{"Power", merits}} Only used when "PowerplayState" is "Preparing" "Cost": an integer value for preparation cost. Only used when "PowerplayState" is "Preparing" "ExploitationValue": an integer value. Only used when PowerplayState is not "None" or "Preparing". This is the CC generated by an individual system.

There may be a few more things needed, but this is most of it.

Some may argue that this is a lot of data to dump into the journal. My argument is "so what"? We're already dumping a LOT of data into the journal. This little expansion is nothing considering how much easier it will make things.
 
Vectron has for YEARS been regarded as the fount of all wisdom on PowerPlay stats, and put huge work in. I completely agree with everything he says here, and yes this is how much work it takes to run a Power - and that's before you can even start doing the planning - it's just tedious data entry. Journal entries are simple to add, there's already tons of far less vital info in there, it would be so immensely helpful to add this info.
 
Very well said. As a fellow "data guy" for one of the larger PowerPlay groups, this game mode has been neglected in more ways than just bug fixes and UI and graphics. This should be trivial to add into the journal, as it's all critical information that makes PowerPlay tick. You and I both know how valuable the word "should" is in the context of PowerPlay, though. I will hold out hope that Frontier will at least acknowledge this need for development, for the sake of the most reliable long-term player base they have.
 
First Vectron, Thank you for all the hard work you've done for the Powerplay community; I had no idea that you were more than just a guy who said weird Vectron-ism on the Mahon discord.
But on what you said, improvements to the journal like what you suggest sounds like a rather great idea. I play winters and while I'm not even leadership, I do a LOT of data entry just as a normal member; and know for a fact that leadership has to do a lot more. Thanks for offering up the solution, hopefully Frontier is good enough to take you up on it.
 
First Vectron, Thank you for all the hard work you've done for the Powerplay community; I had no idea that you were more than just a guy who said weird Vectron-ism on the Mahon discord.
But on what you said, improvements to the journal like what you suggest sounds like a rather great idea. I play winters and while I'm not even leadership, I do a LOT of data entry just as a normal member; and know for a fact that leadership has to do a lot more. Thanks for offering up the solution, hopefully Frontier is good enough to take you up on it.
The Journal update or the gaming PC? ;)
 
There is a lot of things to change in the powerplay, not just the way data are collected, but also how it's displayed / explained to players.
Example, undermining.
Kill 1 npc in a control system it's not shown anywhere, log, journal, anywhere. But in the game it says "Hey you did 30merits against that power", well ok, but what systems ? If you do 1 kill in 100 systems you have 100 lines saying "Hey nice job you did 30 merits against <powername here>" but WHAT system ?

Well .... I understand that data collecting is hard and all done manually (no api, no journal entry or anything) so having at least some data somewhere would be nice ....

Good suggestion !
 
once upon a time before the log, there was ocr.
up until the log contained the needed info for BGS and soo much more, ocr was still used
to this day my program collects the log info and puts it into a database (it could just as easily transmit to a server, inara, eddb,..etc)
there is still info not in the log and for those ocr is still a great tool
automation of the process is simple enough. a pain in the xxx at first, then eventually easy to update, add changes etc.
deleting the screenshots once everything is done is also automated, so the only thing that gets larger is the database.

no intention of messing with your well deserved rant.

I started doing it all manually in excel, got tired of that repetitive task and tbh only created a program for message notification because there isn't one if you are on a different screen or if the game is minimized.
it became ideas day after day of why type it in, automate it, so I did,
waiting for fdev to fix or implement is not worth the grief for the effort it takes to be accurate and being able to plan effectively.
automate repetitive tasks is what I do at work and because of the BGS, I did/do it for that too, no reason not to.

ocr is even easier now than it was back then.

getting someone to make the code for all this should be easy enough.
many programs similar to mine already exist, pretty sure I am still the only one still using ocr to make it better though, but ocr is not a challenge.

I know the effort many large groups do every day and I know with the right coder it can be even easier on them.

the small wrench in the works is just that, small, being not every PP cmdr cares enough to help or often has not got the time.
but its very little different than anyone running market connector or similar.
so the big issue is where to put the info once collected

if you are already friendly with inara and eddb, there is that.
if it or any of it needs to be 'Group only' then there is that. setting up servers or a server shouldn't be a question either, not for the large groups anyway.
we do it for fun not for profit and many many have spent thousands if not tens of thousands of dollars on our rigs, not to mention the thousands upon thousands of hours invested.

IMO any pc that can play the game is also capable of using a small prg that also uses ocr to get the info required.

either way, best of luck. I know what its like waiting for fdev to do something besides what they have shown us in the past year
 
once upon a time before the log, there was ocr.
And OCR is, depending on how you read the Terms of Service, not allowed. The journal was introduced because Frontier started getting antsy about the tools people were using to get information out of the game. It started with OCR but then it quickly moved to memory scraping, because that is far more reliable, but is also vulnerable to actual exploits. I suspect Frontier turns a blind eye to OCR, but for how long?

But beyond that there are other things to consider - I would much rather fly to every single one of the 659 control system several times a week, because then I am at least interacting with the game in ways other than taking screenshots. Because that's what OCR implies. Take screenshots of 659 control systems, feed the screenshots into an OCR program, then feed the data into a database or spreadsheet. Staring at the PowerPlay data screen for HOURS every single week. Hours that I could instead be using to travel across the galaxy.

And I guarantee you it is easier to find 659 commanders who'd jump to a system to update their journal with PowerPlay data than it is to find 60 commanders who'd do screenshots and OCR.

I don't need to do OCR or manual data entry if I want to start organizing BGS work. I don't need OCR or manual data entry if I want to organize trade routes. I don't need OCR or manual data entry if I want to organize explorations to places I've already been. I don't need OCROCR or manual data entry to organize ANYTHING else in the game - so why should I need to do OCR or manual data entry to start organizing PowerPlay?

so the big issue is where to put the info once collected?

EDDN. "All" it takes is an update to the EDDN protocol, and all listeners can choose to ignore the added data if they don't want it. The ones that do can take it and do with it as they please. And if some groups do not want to send it to EDDN, then they'll have their own versions of EDDN seeders and listeners that handle it for them.

The data is there. It's just sequestered away from easy access because of reasons I shouldn't speculate about. And it's stupid.
 
fwiw ocr and macros are against the eula, yet everyone that uses a flight stick is using macros, same with voice attack. and even people not using sticks use macros.
there are threads here all over that topic.

your take on the bgs is apparently quite thin.
your take on the efforts of others is nothing less than insulting.
The exact opposite of what I was trying to say.

I was assuming you were a bit less angry.
don't take out your impression of what I do with BGS out on me in anger.
belittle the BGS all you want, it is a part of PP and the PP data is just as easly available.

I read your post, I saw what YOU WANT, we all did.

my program does not track trade routes, I am not a trader and if I was eddb is fine for that, so is memory and making notes
No one said you need anything, neither did you.
I even said I get your well deserved rant.

Now I see why, you seem to enjoy the rant and taking shots and really could care less if anyone has a better idea than the ONE you feel should be handed to you from fdev.
Its a game

no-one EXPECTS you to burn your time away recording data that can be gathered easily.

seems to me, you got what your worked for, a rant and no sympathy.


the whole jist of my post was to automate.
you expect fdev to give you the entire PP in one chunk of data? never.
Best you will get is more lines every 3 to 6 months if they even remember, and don't expect it to remain in the same format as you want it.
I've been a part of the log thread since it started, its a joke.

not to mention fdev's hands are quite full recently, trying to prevent total meltdown thanks to EDO.

I fly to 60 systems every morning to collect the INF changes
and every effort put into adjusting that is recorded automatically.

I currently only use OCR to detect the inf diif during elections and other conflicts and if you know how it is locked but the pointers on the status tab or in the missions menu DO change according to effort made or lost.
my program measures that difference and reports the correct security and economy change daily. and funny thing, it is done the instant I take the screenshot. computers execute code quite fast you know...

I can only repeat what I said before its easy to automate and its faster and its accurate.

someone offers an idea and you snap. nice

I know as well as you do the info is there, and as long as in every large group, a few cmdrs fly to all the relevant systems and type up the data and send it in aka via discord usually, then someone enters it into a spreadsheet
usually same thing with PP.

it still requires cmdrs flying to the systems, that will never change

but it can easily be automated so there is no typing aka no errors and faster.

but, you are more than welcome to stay un-automated and do it the hard way. and by the time hades has frost on it I imagine fdev might consider re-considering PP details in the log.
and while you do that, I can imagine some of the people I know in large groups that do PP are already working the problem.
I know that because I have suggested it before, and even though many people don't like new(very old) ideas, if it works and is more accurate and easier, they usually go for it.
 
I think the whole thing about macros and OCR is derailing the discussion a bit. Why should anyone have to resort to tools like that when it's much, much easier to have proper information in the journal? Not to mention these are in a grey area in the EULA, and OCR mostly just makes the process a little faster, but is ultimately the same thing, transcribing things from a screen. I don't mind if you do it, but this shouldn't be expected from anyone.

Powerplayers will want this to be able to properly gather the information that's needed to play this gameplay loop, I mostly do BGS and I would love to have certain things put in the journal, like the station news with the faction summaries, traffic, bounty boards, so on. Powerplay and the BGS can get quite intricate, but more time should be spent actually playing the game instead of gathering the information necessary to even begin playing it correctly. There's no proper API so players have to put hours upon hours of effort into data management and honestly our lives would be a lot easier if this wasn't the case. It's better to actually fly the damned spaceship instead of spending 5 hours a day in a google spreadsheet.
 
fwiw ocr and macros are against the eula, yet everyone that uses a flight stick is using macros, same with voice attack. and even people not using sticks use macros.
there are threads here all over that topic.
[...]
I currently only use OCR to detect the inf diif during elections and other conflicts and if you know how it is locked but the pointers on the status tab or in the missions menu DO change according to effort made or lost.
Not only do you apparently know that OCR is against the EULA, but you're admitting to using tools that are against the EULA and suggesting that others use tools that are against the EULA.
Did I read that correctly?

There's a reason I was dismissive. I'm not dismissive of the work you put in - I'm dismissive of a solution that (as far as I understand it) goes against the EULA.

I'm also dismissive of solutions that aren't available to everyone. I'm part of a very large and well organized group in PowerPlay. There's a reason we've set multiple records in PowerPlay, from most systems, to most systems in turmoil, to losing more systems through turmoil than another power even has, to shrugging off that turmoil and still having far more systems than anyone else has ever had. We've sat on top of the PowerPlay leaderboards for 209 out of 334 weeks. If we wanted to use OCR, we would be able to do so.

We can relatively easily get all the tools we'd want for this type of thing.

But I'm talking about this for ME. Or even Edmund Mahon. I'm talking about it for the betterment of the game and the betterment of the community. Being able to rely on the GAME to give anyone useable data rather than having to rely on external tools that are of questionable EULA legality makes PowerPlay far more accessible to everyone. I WANT an even playing field when it comes to data. I find it silly that I still have to be weary of spilling the beans on some of the inner workings of the PowerPlay rules, just because we have figured out things that other powers apparently haven't, all because the PowerPlay rules are hidden away in some stupid black box. I feel the same way about the BGS.

I want someone who has an interest in the inner workings of PowerPlay to be able to sit down, tinker with the data the game provides on their own, and come up with better strategies and solutions than what are currently hidden away in the various PowerPlay communities behind "operational security". OpSec in PowerPlay shouldn't need to go beyond strategy.

It even gets into bug hunting and bug fixing. The galaxy map has been plagued with bugs for PowerPlay pretty much since the beginning, and everytime it's "fixed" the fix is merely to correct the issues we can show through calculations we've done. And it takes forever to get those ones done. I'm sort of hoping that a proper journal implementation will calculate things like income on the fly, so we can point to discreprencies between the journal output and the galaxy map's claims. It tends to make for far better bug reports when you can say "this part of the game says income for CD-62 208 is 102 CC, this part says it's 107 CC, this third part says it's 102 CC."

We clearly have different philosophies in all of this.
 
Part of me disagrees with ever more information (i.e. in that the game should encourage recon or data gathering as part of a large power) but in another sense it is strange why a power does not know whats going on within itself.

(Spaghetti code aside) it would be good if at the capital systems you had the option to generate or at least see a situation report akin to the automated Powerplay / station repair situation reports for each control system (or that there was a tab in the UI which had this report too). The information is there, its just not in useful places.
 
Can't argue any of that.
It would be nice, but we know how fdev does stuff. so its like wishing the world was at peace.

keep in mind too that every third party web site and app are all outside the game, and for a reason.
Fdev doesn't like that either.
they were never in to hand holding, instructions, or follow through.
and they have proven time and again bug fixing is also beyond them.

I love the game, but less now than before EDO, the king of f-ups.
to me, that they argued for 4 years about massacre missions says a lot, then the release of carriers broke the game and EDO demolished the game.
something as simple as the controller issue that's been ingame since the start, and even though I don't know their coding, I submitted a routine just to show them how easy it is to fix.
bugs are bugs, but not understanding various aspects of the game is never a good sign.
I offered to be a programmer or troubleshooter back then, for free.
I get reasons why, as long as I play too..but really either a person has integrity or they don't
and to troubleshoot or to work on specific things, no-one need the entire code
the log is a great example, it is messages from actions that happened already
modules that react don't really hold any gameplay secrets.

I still am in the game though because of what I already invested, time and effort wise. plus I enjoy my ships a lot.

when I started in 2014 there were only 2 sites in the UK that had info on a few things, mostly market. by then I had already made notes and taken screenshots of all the markets and shipyards I visited.
I played for almost a year before I finally got an X52, that's when I was blown away that it used macros and clearly fdev was more than ok with that.
I also get that many parts of the eula are intended to prevent actual cheaters though. But now I saw macros as ok if it simply made life easier.
The ability to actually cheat is too easy and without some rules aka good guy guide, a game rapidly becomes a waste of time.
as such I saw no reason to make the effort to take it easier a step further. only controlling where my info goes, not playing the game.
the only actual macro I use is just better than the sticks and is only for pips.
I play the game as I always have, but as a programmer I do not like doing the same things over and over when I just want to shoot stuff, etc..

but as time goes on and horizons released = much damage to BGS, 3-6 months to fix.
a 4 year long argument with fdev about massacre missions told me clearly they really did not even understand a lot of things about their own game.
then carriers released and easily 6 months more damage to the BGS

more proof also that they have no concern for our efforts.
EDO takes the cake in all this and I am pretty sure its a 4 year task to get it right.
I predicted this almost as soon as I saw its lack of connectivity. 3 days after release and losing 2 years of effort.

So, Anything that makes that effort less of a pain, which data collection is not so much a pain but so very time consuming which means a lot less actual game play. to me is worth it. as long as its not actual cheating.

I share my BGS knowledge a lot, always have.
I would love to share my program to those that want it, but many already use ones made by others.
many also like to keep secrets, and some should. not the tools but what some things mean and how to of certain things, should be earned.

So even though I agree mostly, I also see fdev as never lifting a finger to help with something as complex as PP or BGS
even though they have released info on both, I don't think there is anyone anymore in fdev that knows as much as many players do and as such makes it pretty hard for them to improve on either without wrecking things.
Current state of a severely damaged BGS is more than enough proof.
And hand wavium they want to do to help some of the anarchy faction supporters is more proof.
The state of EDO seems to have them baffled, or they refuse to admit what really is the case or actually don't see it. not sure which any more.

as for the log there are so many fails still in it and no effort to fix, pretty sure it scares the c__p out of them to look at the code.
EDO seems easy enough because it was an all new code addition, but if anyone at all ever even for a second thought that wiring it into horizons would be fast and or easy, they have no clue, and it shows.

I only suggested what I said because I believe they are drowning in their own mess and if anything at all gets done within the next 4 years for PP or BGS it will be a miracle.
even if you submitted code that could fix or add things, I am sure they would not even glance at it.

so for all that, I decided long ago to take my program that did nothing besides beep at me to tell me someone sent me a message and make it fill in my excel workbook, then I later made it better by converting the code to use ms access instead, faster and easier.
Nowadays all I have to do is play and my program shows me at the click of a button or 3 whats going on in any system I fly into
spending 1 to 4 hours every day collecting and putting in excel and then understanding it all was a severe pain
making excel via my program organize it, color code things and popup warnings and options and suggestions with historic facts(details) made life easier by far and made the game much more enjoyable and about playing instead of record keeping and decision making.

considering what you do, like I was, you are in a unique position. you have history, you have the knowledge. what you do with that can change a lot of things. How you do it is up to you. pretty sure fdev isn't going to contribute much, if at all.
 
Warning - rant.

Some of you know this, many do not. To organize PowerPlay you have to do an enormous amount of data entry. Manual data entry. Manual data entry that is stupefyingly, mind-numbingly stupid, because the data needed isn't available without transcribing the information from the game screen.

There are currently 659 control systems (and 11 headquarters that aren't relevant for this), each of which has nine data points:
Upkeep from last cycles (can change once a week)
Default upkeep cost (never changes)
Cost if fortified (is ALWAYS 0)
Cost if undermined (can change once a week)
Base income (can change once a week)
Fortify total (can change hundreds of times a week)
Fortify trigger (can change once a week)
Undermining total (can change hundreds of times a week)
Undermining trigger (can change once a week)
Once a week, every power that wants to properly manage themselves need to go through every single control system to check and update six data points. That's currently 3,954 data points that have to be manually entered into a spreadsheet or databases. There's no copy-pasting, because the journal doesn't have useful information for this.

Additionally they'll want to update their fortification and undermining totals several times a week as well. If it's just once per day, that's currently 9,226 data points.

If powers want to run an organized offensive campaign, they'll also need to keep track of these things for their target. On the top end, that means each power currently enters 13,180 data points manually every single week. Across 11 powers that's 144,980 data points. If we assume it takes 1 second to enter each data point (lowballing significantly here) that's more than 40 hours wasted on this every single week.

Oh, but it gets better.

There IS PowerPlay data in the journal - but it's borderline useless.

Let's go through some of them.

{ "timestamp": "2016-06-10T14:32:03Z", "event": "PowerplayCollect", "Power": "Li Yong-Rui", "Type": "siriusfranchisepackage", "Count": 10 }

Okay, so CMDR Vectron has picked up 10 fortification merits. So far so good.

{ "timestamp": "2016-06-10T14:32:03Z", "event": "PowerplayDeliver", "Power": "Li Yong-Rui", "Type": "siriusfranchisepackage", "Count": 10 }

And CMDR Vectron has delivered 10 fortification merits. Where? Where did Vectron drop off these merits? Li Yong-Rui picks up merits in their HQ and delivers them to a control system. All we know from this is that Vectron dropped off 10 merits somewhere. We don't know what system, nor do we know the progress for the system.

We can do a bit of snooping and check where Vectron last docked, but that only tells us that Vectron dropped off 10 merits in Dinda. What is the current state for Dinda? Is it 10 merits? 100? 1,000? 10,000?

Oh, but it gets worse.

What if Vectron is pledged to a different power. What if he's pledged to Edmund Mahon? Why does that matter? Because Edmund Mahon picks up fortification merits in the control system and drops them off at the HQ. We can, of course, link the pick-up with where he was docked, but that is a massive pain to do.

There's one more thing in the journal: FSD Jump.
If the player is pledged to a Power in Powerplay, and the star system is involved in powerplay,

Powers: a json array with the names of any powers contesting the system, or the name of the controlling power PowerplayState: the system state – one of ("InPrepareRadius", "Prepared", "Exploited", "Contested", "Controlled", "Turmoil", "HomeSystem")

Now imagine being EDDB, Inara or anyone else trying to keep track of the state of the galaxy. What should you do when a system keeps alternating between having and not having PowerPlay information attached to it, and you get hundreds of updates to it an hour? The sane thing is to ignore the information altogether, which is what both EDDB and Inara does (I'm not even sure if it's in the EDDN feed).

"But Vectron!" I hear you cry. "I just checked EDDB and Inara and they both have PowerPlay information for control systems. How can that be when you just told me they ignore it?"

I know they ignore it, because I'm the one who sends EDDB and Inara the PowerPlay information they use. I am the trusted source for that information, because the game CANNOT be trusted to give them the proper information. And I do this every week, and I've been doing it for almost FIVE YEARS! The first time I sent the data to Inara was the 12th of January 2017. TWO HUNDRED AND FORTY NINE WEEKS of manually gathered and entered data provided to the community because Frontier doesn't care about PowerPlay. I started doing it back in 2016 for EDDB, and EDDB even set up an API for me to do it back in September of 2016.

That is my proof. For more than 249 weeks a community member has had to take more than an hour out of their schedule to ensure that the community has useful and correct data for PowerPlay, because Frontier hasn't updated the journal to include USEFUL PowerPlay data. They "owe" me at least 250 hours of pay for my services, and I will happily take my payment in the form of an updated journal that means I and no one else needs to constantly manually update their databases and spreadsheets. I'd also like a brand new gaming computer, but I suspect getting either is about equally likely.

Back when the journal was introduced, I was VERY quick to suggest JSON arrays that would be great to have (though it could have been better), but nothing ever came of it. That was on the 20th of July 2016. That's MORE than five years ago. Two months later I started talking with EDDB on how to keep it properly updated with PowerPlay data.

There are dozens of ways to improve the journal for PowerPlay, and Frontier has chosen to do none of them. Again, I don't know why - all I can say is that they've done nothing except promise that they'd put a focus on improving PowerPlay "later" and "soon" for more than five years.

Five years of the PowerPlay community asking, begging and pleading with Frontier to just give us the tiniest of table scraps. Five years of Frontier looking the PowerPlay community in the eyes saying "we'll have something nice for you soon" as they dump their leftovers into the dumpster. Five years of the PowerPlay community dumpster diving for the scraps that Frontier threw out, while trying to put together something that even resembles a meal. Yes, that metaphor is now overused.

I'm tired. I can feel it in my bones. I feel like butter spread over far too much bread.

What's the solution? Better journal entries is my main hope. Or just kill the whole thing altogether, as I've publicly suggested multiple times, both on this forum and on reddit.

PowerplayDeliver needs a few updates to cover expansions, expansion opposition, fortification and undermining.
My honest answer despite of being a long term LYR supporter -
Warning - rant.

Some of you know this, many do not. To organize PowerPlay you have to do an enormous amount of data entry. Manual data entry. Manual data entry that is stupefyingly, mind-numbingly stupid, because the data needed isn't available without transcribing the information from the game screen.

There are currently 659 control systems (and 11 headquarters that aren't relevant for this), each of which has nine data points:
Upkeep from last cycles (can change once a week)
Default upkeep cost (never changes)
Cost if fortified (is ALWAYS 0)
Cost if undermined (can change once a week)
Base income (can change once a week)
Fortify total (can change hundreds of times a week)
Fortify trigger (can change once a week)
Undermining total (can change hundreds of times a week)
Undermining trigger (can change once a week)
Once a week, every power that wants to properly manage themselves need to go through every single control system to check and update six data points. That's currently 3,954 data points that have to be manually entered into a spreadsheet or databases. There's no copy-pasting, because the journal doesn't have useful information for this.

Additionally they'll want to update their fortification and undermining totals several times a week as well. If it's just once per day, that's currently 9,226 data points.

If powers want to run an organized offensive campaign, they'll also need to keep track of these things for their target. On the top end, that means each power currently enters 13,180 data points manually every single week. Across 11 powers that's 144,980 data points. If we assume it takes 1 second to enter each data point (lowballing significantly here) that's more than 40 hours wasted on this every single week.

Oh, but it gets better.

There IS PowerPlay data in the journal - but it's borderline useless.

Let's go through some of them.

{ "timestamp": "2016-06-10T14:32:03Z", "event": "PowerplayCollect", "Power": "Li Yong-Rui", "Type": "siriusfranchisepackage", "Count": 10 }

Okay, so CMDR Vectron has picked up 10 fortification merits. So far so good.

{ "timestamp": "2016-06-10T14:32:03Z", "event": "PowerplayDeliver", "Power": "Li Yong-Rui", "Type": "siriusfranchisepackage", "Count": 10 }

And CMDR Vectron has delivered 10 fortification merits. Where? Where did Vectron drop off these merits? Li Yong-Rui picks up merits in their HQ and delivers them to a control system. All we know from this is that Vectron dropped off 10 merits somewhere. We don't know what system, nor do we know the progress for the system.

We can do a bit of snooping and check where Vectron last docked, but that only tells us that Vectron dropped off 10 merits in Dinda. What is the current state for Dinda? Is it 10 merits? 100? 1,000? 10,000?

Oh, but it gets worse.

What if Vectron is pledged to a different power. What if he's pledged to Edmund Mahon? Why does that matter? Because Edmund Mahon picks up fortification merits in the control system and drops them off at the HQ. We can, of course, link the pick-up with where he was docked, but that is a massive pain to do.

There's one more thing in the journal: FSD Jump.
If the player is pledged to a Power in Powerplay, and the star system is involved in powerplay,

Powers: a json array with the names of any powers contesting the system, or the name of the controlling power PowerplayState: the system state – one of ("InPrepareRadius", "Prepared", "Exploited", "Contested", "Controlled", "Turmoil", "HomeSystem")

Now imagine being EDDB, Inara or anyone else trying to keep track of the state of the galaxy. What should you do when a system keeps alternating between having and not having PowerPlay information attached to it, and you get hundreds of updates to it an hour? The sane thing is to ignore the information altogether, which is what both EDDB and Inara does (I'm not even sure if it's in the EDDN feed).

"But Vectron!" I hear you cry. "I just checked EDDB and Inara and they both have PowerPlay information for control systems. How can that be when you just told me they ignore it?"

I know they ignore it, because I'm the one who sends EDDB and Inara the PowerPlay information they use. I am the trusted source for that information, because the game CANNOT be trusted to give them the proper information. And I do this every week, and I've been doing it for almost FIVE YEARS! The first time I sent the data to Inara was the 12th of January 2017. TWO HUNDRED AND FORTY NINE WEEKS of manually gathered and entered data provided to the community because Frontier doesn't care about PowerPlay. I started doing it back in 2016 for EDDB, and EDDB even set up an API for me to do it back in September of 2016.

That is my proof. For more than 249 weeks a community member has had to take more than an hour out of their schedule to ensure that the community has useful and correct data for PowerPlay, because Frontier hasn't updated the journal to include USEFUL PowerPlay data. They "owe" me at least 250 hours of pay for my services, and I will happily take my payment in the form of an updated journal that means I and no one else needs to constantly manually update their databases and spreadsheets. I'd also like a brand new gaming computer, but I suspect getting either is about equally likely.

Back when the journal was introduced, I was VERY quick to suggest JSON arrays that would be great to have (though it could have been better), but nothing ever came of it. That was on the 20th of July 2016. That's MORE than five years ago. Two months later I started talking with EDDB on how to keep it properly updated with PowerPlay data.

There are dozens of ways to improve the journal for PowerPlay, and Frontier has chosen to do none of them. Again, I don't know why - all I can say is that they've done nothing except promise that they'd put a focus on improving PowerPlay "later" and "soon" for more than five years.

Five years of the PowerPlay community asking, begging and pleading with Frontier to just give us the tiniest of table scraps. Five years of Frontier looking the PowerPlay community in the eyes saying "we'll have something nice for you soon" as they dump their leftovers into the dumpster. Five years of the PowerPlay community dumpster diving for the scraps that Frontier threw out, while trying to put together something that even resembles a meal. Yes, that metaphor is now overused.

I'm tired. I can feel it in my bones. I feel like butter spread over far too much bread.

What's the solution? Better journal entries is my main hope. Or just kill the whole thing altogether, as I've publicly suggested multiple times, both on this forum and on reddit.

PowerplayDeliver needs a few updates to cover expansions, expansion opposition, fortification and undermining.

{ "timestamp": "2016-06-10T14:32:03Z", "event": "PowerplayDeliver", "Power": "Li Yong-Rui", "Type": "siriusfranchisepackage", "Count": 10, "System": "Dinda", "Defence": {200, 2588} "Offence": {0, 30850} }

This works for almost all types of merits. Something else is needed for preparations:

{ "timestamp": "2016-06-10T14:32:03Z", "event": "PowerplayPreparation", "Power": "Zemina Torval", "Count": 10, "System": "CD-62 234", "PotentialValue": 1, "Cost": 128, "Totals": {{"Arissa Lavigny-Duval",9700},{"Zemina Torval", 80}} }


The location, FSDJump, CarrierJump and other such events needs updating to be better for PowerPlay as well. Basically, if it includes BGS information, it should include PowerPlay information. Instead of the current mess it should always be present and include something like

"PowerplayState": one of ("Preparing", "Expanding", "InExpansionRadius", "Exploited", "Contested", "Controlled", "Turmoil", "HomeSystem", "None"), "Powers": a json array with the names of any powers contesting the system, or the name of the controlling power, "ExploitedBy": a json array with the control system exploiting it (multiple control systems can be within 15 light years, but only one of them receives the exploited system's CC). When multiple powers contest a system, this should be empty, "ContestedBy": a json array with the control systems that are within 15 light years of the system. When only one power has control systems within 15 light years, this should be empty, "BlockedBy": a json array with the expansion systems that are within 15 light years of the system. Only used when "PowerplayState" is "InExpansionRadius", "Upkeep": an integer value of the current upkeep for the system. Only used when "PowerplayState" is "Controlled", "Turmoil", "HomeSystem". "DefaultUpkeep": an integer value. Only used when "PowerplayState" is "Expanding", "Controlled", "Turmoil", "HomeSystem". "CostIfUndermined": an integer value. Only used when "PowerplayState" is "Controlled", "Turmoil", "HomeSystem". "BaseIncome": an integer value. Only used when "PowerplayState" is "Preparing", "Expanding", "Controlled", "Turmoil", "HomeSystem". "Defence": an integer value array that is either fortification or expansion value {total, trigger}. Only used when "PowerplayState" is "Expanding", "Controlled", "Turmoil", "HomeSystem". "Offence": an integer value array that is either undermining or opposition value {total, trigger}. Only used when "PowerplayState" is "Expanding", "Controlled", "Turmoil", "HomeSystem".HomeSystem". "Preparations": An array of arrays as seen in PowerplayPreparation above {{"Power", merits}} Only used when "PowerplayState" is "Preparing" "Cost": an integer value for preparation cost. Only used when "PowerplayState" is "Preparing" "ExploitationValue": an integer value. Only used when PowerplayState is not "None" or "Preparing". This is the CC generated by an individual system.

There may be a few more things needed, but this is most of it.

Some may argue that this is a lot of data to dump into the journal. My argument is "so what"? We're already dumping a LOT of data into the journal. This little expansion is nothing considering how much easier it will make things.
At this point of time and game status - just shelf powerplay in its entirety.

You are - rightly - mentioning the issues around managing a power.
Like how little in game/tools are provided and how mindless manual and unsupported the administrative side is.

Add on the base utmost boring (over time), repetitive, uninspired, stale and unrewarding powerplay mechanics lacking even the most basic QoL improvements (looking at you in particular dumbest of all dumb fortification merits collection mechanic).

A perfect mixture to wear off ANY player aka client aka human being over time.

I'm saying this as a long term supporter of my own power. Being simply fed up with this unimaginative game part.
Pull the plug.
o7
 
Great post Vectron. As someone who has been apart of PP by either playing in it for many cycles, or just watching from the sidelines for many cycles as well, it is incredibly frustrating watching a company neglect a part of their game that does hold a lot of players as you said. I have been in Winters Leadership from time to time, and the most tedious part was logging spreadsheet values for dozens of systems, including others. I really do not see why they have not just gone and added this critical information into the journal. It is funny that the information that they have given us PPers has actually regressed since PP launched as there was a time where they would actually release weekly information about PP.

Anyways, I hope they can at least add PP info into the journal but knowing them, they'll just ignore this or come in and say "Oh yeah that sounds like a great idea", but then never say a word about it again. I have said this to people in the past involved in PP, but it honestly seems like the devs have a calendar alert that goes off once a year to go on the forums and say "We are totally planning on doing stuff with PP in the future". Would be great if they'd either just spend some dev time for once, or just scrap the system all together.
 
I wholeheartedly agree with the points raised by Vectron and the other folk in there. wrt. OCR: Even if it were compliant with the TOS it is NOT a solution to have an alt sit at a station all week, automatically scanning all control systems of every power and feed it into sheets. It shouldn't be too hard for Fdev to provide us with a somewhat clean solution and I hope, even if they are unable to rework the mechanics of pp, the will be able to make our lives a little bit easier in terms of playing PP.
 
From my point of view - Vectron's work is simply invaluable (and thanks for that!). In the early Powerplay weeks and months, I did the manual checking and adjustments of all PP changes manually for Inara each week and it was boring tiresome work. It was a chore prone to errors and everybody should try it to get at least a glimpse of how it must feel doing so over the years.

About the OCR - if I am correct, the plain OCR isn't against the ToS (it doesn't provide an advantage itself, it just translates the information on the screen to text form. The memory scraping and similar is, though). After all, the OCR was extensively used for getting the commodity market data early on, until Frontier allowed us to use their companion API for that and made several excellent improvements like introducing journals and so on. But, I don't think the OCR is a very sane way how to do things.

At the current state, the PP information in the journal is covering the player actions regarding the Powerplay and I think the records in "player to powerplay" relation are quite sufficient. The problem is that there is complicated to project the individual player actions covered by the journal to the global state of things, to get the general overview of the state of the galaxy as shown in the game. Vectron covered it in the detail, but if I should highlight one thing and the main reason why Inara is using Vectron's (precioussss) service - from the journal, there is easy to get the star systems controlled relatively fast over time, after each cycle ends. But, when you want to know if some star system is no longer controlled, that's where it gets complicated - you must be absolutely certain that the player is pledged and that the information in the journal about "null state" is correct, you cannot use EDDN data due this and it all brings various points where it can go wrong. And we are speaking just about the basic overview of the controlled star systems here, without further details like the star systems value, fortification state and so on, which is not possible to get (which I personally do not need for Inara at the moment, but I can imagine Powerplay-oriented guys will like to have it there).

But to be fair - there may be various technical and design aspects involved and affecting this problem in a way nobody may be aware of. There cannot by simply said: "Frontier does not want to". For example, before the Odyssey release, Howard Chalkley (the guy doing journal stuff) and other Frontier's guys involved did really GREAT work with trying to incorporate all 3rd party tool authors' requests into the journal, they were evaluating all the comments and feedback and improved things even in further update releases. I cannot say a single word of complaint there.

But, yes, I will certainly like to have more Powerplay data in the journals that will help to "reconstruct" the global state of the Powerplay as is displayed in the game than just the player's interactions with it. :)
 
From my point of view - Vectron's work is simply invaluable (and thanks for that!). In the early Powerplay weeks and months, I did the manual checking and adjustments of all PP changes manually for Inara each week and it was boring tiresome work. It was a chore prone to errors and everybody should try it to get at least a glimpse of how it must feel doing so over the years.

About the OCR - if I am correct, the plain OCR isn't against the ToS (it doesn't provide an advantage itself, it just translates the information on the screen to text form. The memory scraping and similar is, though). After all, the OCR was extensively used for getting the commodity market data early on, until Frontier allowed us to use their companion API for that and made several excellent improvements like introducing journals and so on. But, I don't think the OCR is a very sane way how to do things.

At the current state, the PP information in the journal is covering the player actions regarding the Powerplay and I think the records in "player to powerplay" relation are quite sufficient. The problem is that there is complicated to project the individual player actions covered by the journal to the global state of things, to get the general overview of the state of the galaxy as shown in the game. Vectron covered it in the detail, but if I should highlight one thing and the main reason why Inara is using Vectron's (precioussss) service - from the journal, there is easy to get the star systems controlled relatively fast over time, after each cycle ends. But, when you want to know if some star system is no longer controlled, that's where it gets complicated - you must be absolutely certain that the player is pledged and that the information in the journal about "null state" is correct, you cannot use EDDN data due this and it all brings various points where it can go wrong. And we are speaking just about the basic overview of the controlled star systems here, without further details like the star systems value, fortification state and so on, which is not possible to get (which I personally do not need for Inara at the moment, but I can imagine Powerplay-oriented guys will like to have it there).

But to be fair - there may be various technical and design aspects involved and affecting this problem in a way nobody may be aware of. There cannot by simply said: "Frontier does not want to". For example, before the Odyssey release, Howard Chalkley (the guy doing journal stuff) and other Frontier's guys involved did really GREAT work with trying to incorporate all 3rd party tool authors' requests into the journal, they were evaluating all the comments and feedback and improved things even in further update releases. I cannot say a single word of complaint there.

But, yes, I will certainly like to have more Powerplay data in the journals that will help to "reconstruct" the global state of the Powerplay as is displayed in the game than just the player's interactions with it. :)
This issue is probably down to how FD initially saw Powerplay, in that it was a massively decentralized system that averaged out good and bad moves through (the perception of) players always wanting to do 'right' (whatever that was since we were not told!). In such a scenario there is no need for an overview because that (i.e. collation of data) presumes organised groups (which were inevitable really).

If FD massively expanded the information in the autogenerated Powerplay news and / or UI I think that would be enough- the fine line is making a system that requires outside tools to a system that collates it for you in game.
 
Back
Top Bottom