Astro Empires Database

[Winchester]

Addendum:

1: Replace the two DB permissions noted in the OP with a "Database Administrator" permission - DBA for short.
1a: The DBA can apply the following filters:
1a.1: Guild ID (Fleets) - hides all fleets belonging to that GID.
1a.2: Guild ID (Bases) - hides all bases belonging to that GID.
1a.3: Can apply up to five GID per category simultaneously.
1a.4: Security Level 1, 2, and 3 - applied to each guild member. Players without any permissions cannot access DB info besides their own.
1a.5: Can set the functions of each security level manually, from the following criteria:

• can see guild fleets
• can see guild bases (unlimited view)
• can see guild bases (limited view - can only see owner, coordinates, and JG level)
• can see fleets that 1a.1 hides
• can see fleets that 1a.2 hides

1b: The GM and VGM automatically have DBA permissions.

2: Instead of deleting all data after the time periods noted in the OP, the DB will maintain the coordinates, astro type, base owner, and JG level of all entries. Everything else will be flushed.

3: Non-guild permissions.
3a: Can add player IDs to DB permissions list. This is done by anyone with DBA.
3b: Number of non-guild IDs on permissions list cannot exceed 10% of the number of players in the guild.
3c: If your guild member count drops below the amount needed to keep your current permissions list, the most recently added number is deleted.
3d: The person receives a notification on their end that they have been added, and must click a consent to begin data sharing.
3e: The person can view all guild DB information (with restrictions set by the DBA as seen above).
3f: The guild can view all DB information from the player (with an equivalent set of permissions on the player's end).

4: All players will have the option to hide their DB information from their current guild. Note that anyone with DBA can see that you are hiding it. While hiding, you can still view guild DB information, but only once the DBA has given you the corresponding permissions.



What do you all think?

[Callum]

3: Non-guild permissions.
3a: Can add player IDs to DB permissions list. This is done by anyone with DBA.
3b: Number of non-guild IDs on permissions list cannot exceed 10% of the number of players in the guild.
3c: If your guild member count drops below the amount needed to keep your current permissions list, the most recently added number is deleted.
3d: The person receives a notification on their end that they have been added, and must click a consent to begin data sharing.
3e: The person can view all guild DB information (with restrictions set by the DBA as seen above).
3f: The guild can view all DB information from the player (with an equivalent set of permissions on the player's end).

I'll address the change you suggested for me. Overall, I can see this as sound solution. A guild of 60 can have two players from 3 allied guilds in on it. Which I see as just the right amount, any high number, and you could piggy back on other's data.

On (3f); I don't know whether its necessary for the player not in the guild to have his data uploaded to both his and the other guilds databases. If you want to see what they see, you should have a two way link going on. Such a minor point at this stage, that it doesn't really matter that much.

[CHERUB]

ok, yeah u just pretty much fixed my only problem with this - the permissions. good solution, nice and simple.
Im assuming that the db tab will have an administrator sub-tab where this can be set?

The JGs r nice as well, I was hoping that could be added.

and the inter-guild thing is very good. yeah, Im definately hoping that this gets put in the game.

oh yeah Could I request that this be put in the FR workshop, along with the change to upgrades? Cuase this seems like it is gonna get aproved by pretty much everyone lol

[Lightning1453]

The way I take that is you can select galaxy and if you do you have to select another search item. If you don't select galaxy you could just do a server wide search. Is that correct? If so then I am cool with that because it should be that way. I just wanted to make sure I understood it right.

Incorrect - you have to search by galaxy.

I think that is too restricting. I think you should be able to search a player and find bases in more than just one galaxy. For example, one of my guild members has bases in 5 galaxies and to find all his bases I would have to query 5 times.

I don't think you should just be able to run a SELECT * FROM Database and get everything, but you should be able to do SELECT * FROM AEDatabase WHERE pid=xxxx and it shows all info on that player.

So, I think another search filter you should add would be server and make it have more strict requirements then searching a galaxy. Like if you select server search then you have to select one other option just like with galaxy search, but Player, Astro type, and minimum Jumpgate should be the only three things you could server search.

2: Instead of deleting all data after the time periods noted in the OP, the DB will maintain the coordinates, astro type, base owner, and JG level of all entries. Everything else will be flushed.

I think that is a perfect compromise.

[Winchester]

I'm okay with making the exception be bases of a specific player, but for everything else it should go by galaxy. For one thing, while it does require a bit more in the way of server resources, it encourages people to get the higher level of upgrade, as the lower level of upgrade is limited in how many searches it can run.

[CHERUB]

ok just to make this absolutely clear to everybody, Im gonna describe a search that u can do in the DBs now, u tell me waht I cant do in urs.

I search for guild X and Y in galaxies A20-A30, but only for fleets that are over 5 million in size.

I search for Player Z in galaxies A02-A03, for bases.

im assuming no multiple galaxy search right off the bat.

[Lightning1453]

I'm okay with making the exception be bases of a specific player, but for everything else it should go by galaxy. For one thing, while it does require a bit more in the way of server resources, it encourages people to get the higher level of upgrade, as the lower level of upgrade is limited in how many searches it can run.

I think that would be fine. The main thing to me was the player search. I just put the other two in because I did not see much harm in having them. I forgot about the limited search part.


@CHERUB I am not quite clear what you are asking.

[Wlerin]

I don't see how this can be implemented to the majority's satisfaction (i.e. so it will actually be used) without bending the no hardcoded politics rule.

As long as it isn't bent too far, I think it is worth it.

[CHERUB]

Im asking can I do the above searches in ribbs DB.

Im assuming I cant, but I would like to know what exactly I cant do out of those options.

@Wlerin How so?

[Winchester]

ok just to make this absolutely clear to everybody, Im gonna describe a search that u can do in the DBs now, u tell me waht I cant do in urs.

I search for guild X and Y in galaxies A20-A30, but only for fleets that are over 5 million in size.

I search for Player Z in galaxies A02-A03, for bases.

im assuming no multiple galaxy search right off the bat.

Yes, you can do all of that. You just have to search each galaxy one at a time. ie, search guild X and Y, fleets over 5m, in A20, then in A21, etc.

[CHERUB]

hmmmmmmmmmmm ok. I guess I can live with that. would be better i u could search in small groups of galaxies tho. like say 10 galaxies, or even 5 galaxies. its just that its a LOT of searches if u rsearching an entier server for fleets/bases.

I could live with it tho, if everybody else hates that idea.

[Wlerin]

I don't see how this can be implemented to the majority's satisfaction (i.e. so it will actually be used) without bending the no hardcoded politics rule.

As long as it isn't bent too far, I think it is worth it.

@Wlerin How so?

Addendum:

1: Replace the two DB permissions noted in the OP with a "Database Administrator" permission - DBA for short.
1a: The DBA can apply the following filters:
1a.1: Guild ID (Fleets) - hides all fleets belonging to that GID.
1a.2: Guild ID (Bases) - hides all bases belonging to that GID.
1a.3: Can apply up to five GID per category simultaneously.
...
1a.5: Can set the functions of each security level manually, from the following criteria:

• can see fleets that 1a.1 hides
• can see fleets that 1a.2 hides

These, plus the ability to add non-guild members to the DB, which was suggested as an alternative to Callum's request for combining multiple guilds' DB information.

The problem with these is that a) they are still hardcoding politics, and b) at least in the last instance, they don't solve the problem. Allowing a guild to add <= 10% of its members to its DB permissions will not help guilds that want to share their entire DB with another guild or guilds. They will still be forced to use outside databases, and thus, scripts. I think, in this case, a better solution can be found, though it would require bending the politics rule.

I also think the whole hiding allied fleets thing could be done more elegantly, but that merits a different thread. And a better understanding of exactly what "hardcoding politics" means and why it is anathema.

[Winchester]

My problem with linking DB has nothing to do with hardcoding politics. Allow me to use Ceti as an example:

On Ceti, there are two factions - the SU and the ASU - and a few unaffiliated/independent guilds. The overwhelming majority of the server's players and fleets are in the two factions; if you allow full linking of DB, you essentially have half the server sharing a single database, while the independent guilds either join up and contribute their own scouting, or else are severely disadvantaged. At that point, you have so many people scouting and able to access the DB that there's really no purpose in even making a player-updated database - it will be updated so often that you might as well just remove the fog of war and let everyone search the server carte blanche.

Here's my point. Will linking guilds reduce the reliance on external DB? Yes. Will it make the game so Candyland that the solution becomes its own problem? I think so. I would rather have a few of the hardcore players maintain their own DB, while giving people the option to be legitimate with a very useful tool, than to give everyone access to something that I feel is detrimental to the game.

[Spamhead]

I like it even more than before.

[Hellion]

Addendum:
3: Non-guild permissions.
3a: Can add player IDs to DB permissions list. This is done by anyone with DBA.
3b: Number of non-guild IDs on permissions list cannot exceed 10% of the number of players in the guild.
3c: If your guild member count drops below the amount needed to keep your current permissions list, the most recently added number is deleted.
3d: The person receives a notification on their end that they have been added, and must click a consent to begin data sharing.
3e: The person can view all guild DB information (with restrictions set by the DBA as seen above).
3f: The guild can view all DB information from the player (with an equivalent set of permissions on the player's end).

@3b

I still think its a bad idea to put down this rule. This is mostly going be the case with ops outside of your own guild. Lets say 100 member guild that 50 move over to another guild for jg use primarily which effectively means 45 of them will be cut out from DB access. I know of many ops we just maintained our own information and really didnt ask the hosting guild for their db. Though I do think there should be a limit to the number allowed to use the DB by payment so that way it doesnt result in half the server using one DB. Perhaps even a time frame that the link will also break if outside the guild like a month.