@Auronio, not really. If a system already has a PMF, even if the system would have only 3 minor factions+1 PMF, it's OUT!
So the rules would be:
- NO PMF in the system
- 6 or less minor factions
(yes, I ignored the "lore/blocked/etc" system rules on purpose)
The opposite is valid as well - say you met all criteria 6 months back but meanwhile other NPC or player factions expanded into your systems and then you are being told - hey, unfortunately you don't meet the criteria today.
We can rant all day and come up with better proposals.
The process is so excruciating intransparent and protracted that the impression hardly can be avoided that a monkey is made out of players = customers.
Doesn't change my impression that ED in general is still one of the best games I played ever but that part sucks.
Regards
The answer I was given was;[TR]
[TD]Sys in use.[/TD]
[TD]Leviathan Scout Regiment[/TD]
[TD]Leviathan Scout Regiment[/TD]
[/TR]
The fact that we are given a reason for our rejection that simply doesn't seem to line up with reality is very disconcerting and is leaving us all very confused about what we can do to ensure that our application is accepted the next time around. This isn't our first rodeo, either. The last time we were denied (on grounds that there were too many NPC factions in system) we buttoned down and solved the issue. Now it stings a little bit more because it's starting to seem like somebody purged the application list and chose reasons for the denial at random from a drop down menu, in order to have something to show for their work at a meeting.
FDev, you are alienating 115 ship kit buying, paintjob loving, dedicated CMDRs. Please look into this.
So, if not in use, or at capacity it is restricted for some reason.Sys in use denotes all given systems applied for are in use, at capacity, or restricted.
Yeah - the "First Come, First Served" rule may be in play.
The answer I was given was;
So, if not in use, or at capacity it is restricted for some reason.
Yeah - the "First Come, First Served" rule may be in play.
oh yeah, I forgot to mention that other criteria: first come first served.
Perhaps he was unlucky enough to choose 3 systems which were already chosen by other PMFs, also waiting to be born![]()
Well first come first serve has more weight than most here think, I've noticed. First come first served applies to everyone in game already as well. If someone moved into your applied systems, they got their first, before you could be processed. That's sad, because if your systems were leaked and someone didn't want you as a neighbor, they can manipulate BGS to do that, or fill the slots. FDev can't be responsible for processing applications at a snapshot in time where you checked way back when and applied. The only way they can really improve is to make the process more efficient(like batch processing mentioned). So first come first serve instances don't come up as often, and people don't have to defend their potential home systems so long.
Yeah ... I think it's the utterly impenetrable nature of it and the lack of transparency of what is and isn't allowable, what requirements have to be settled etc. that is the most frustrating thing.
If I were running this, I'd be doing more checks at player group registration, including stuff like background text checks, lore checks, etc. After that, at submission time the form submission should at least check for whether the systems chosen are suitable at that time. At least that pre-filters a fair amount of stuff. That's not that difficult to do to be fair. I guess the whole PMF thing was a bit of an after-thought initially and now has grown into some kind of unmanageable monster.
It's the not knowing that is the worst thing.
Agreed.
They took submissions via a google form, which can have scripting attached.
It would not be hard to set up a REST endpoint on their server that contains a list of "potential home systems".
EDDB.io tracks about 15 million systems, yet the SQLite database that I created from their data can search those systems (by name, not index) and return all results in about 1 second. Oh and that's with a 'LIKE' search
SELECT * FROM systems WHERE systemName LIKE "param%" ORDER BY systemName
So cache bubble systems in a separate table, and if you don't find the system name in there, switch over to a full table search. If name not found there, then you have either listed an incorrect system name, or that system is not currently valid.
Granted they would have to deal with a lot more traffic than my database... but that's kinda their industry.
EDIT: actually, I may build a tool that does this simply based off of EDDB.io data. Just to show it can be done.
The issue with "at that time" creates massive problems for some regions of space. The BGS moves a LOT in some of the popular parts of space. Especially when injections land on large patches and do not happen often. The system is too fluid from day to day for reservations to occur. That kind of business creates a web of issues for those in and outside of the the BGS currently. First come first serve is just easier & allows more to be involved. Ways to help ensure your canidates best chance is to maintain them. Those rules are clear enough to act on. As I mentioned in my comment, reducing the time spent proccessing requests( as appears to have been done) could help those with applications tremendously by reducing time spent maintaining canidates through BGS.
If that's the case, It would have been real nice to know about it the first time we applied...
It would have saved us from wasting a years' worth of preparatory BGS work, lore building and two more denied PMF applications' worth of disappointment.
Whoever that other PMF would be in our case, is sure taking their sweet time setting up in Diabak...
It should be well noted, this is the first pass results. The scripts used to validate system locations, pmf govt type vs sys govt type has NOT been run yet.
Just to play the nitpicker.
Brett doesn't run the analysis nor is he taking the decisions.
He is the voice communicating whenever one of the people behind think something should be communicated.