GraXXoR

@Atmosph3rik  I think it’s because this implementation was originally just an afterthought added on as an emergency extra for players caught on Sanctuary or somewhere without any resources but needed to be able to, say, create some fuel in there Nano pack or add an XS container or something.
Surface harvesting really was designed just for picking up those 20 litre rocks in small numbers.
 
But as with everything in DU, NQ thought they could just reuse something that they had already built and re-purpose it beyond its original scope.
 
like the interface for constructs, fine for a dozen, unworkable for 200.
 
Or the dropdown list for the RDMS, fine for adding a player or two to a policy but sucks when you’re trying to choose from 30 odd critical user-rights. 

Or skills interface that takes up over half the screen with a female in a gimp suit - fine if you just have a couple of selection boxes around the edge but stupid when it squeezes the actual skills into a list on the right hand 20% of the screen and allows the list to be 100+ Entries long!
 
these are all inappropriate tools for the jobs and surface mining is no exception.
 
not fit for purpose. 
 
im being critical because these are problems that have existed for months if not years and haven’t ever been addressed and in many cases (skills interface, surface mining) actually became worse. 

You are correct. The intent IS to allow PVP players to know someone is landed and let those PVPers who don't like a challenge to get their seal clubbing action on or those PVPers who do like a challenge know to look elsewhere.
 
It's also apparently designed to lower the server load by reducing the player base since nobody I know of seems to find the system particularly compelling.

You are correct. The intent IS to allow PVP players to know someone is landed and let those PVPers who don't like a challenge to get their seal clubbing action on or those PVPers who do like a challenge know to look elsewhere.
 
It's also apparently designed to lower the server load by reducing the player base since nobody I know of seems to find the system particularly compelling.

I feel that the RDMS and Assets lists hark back to the first days where every player had a maximum of about 17 constructs and an org had a maximum of <300...
its far too clunky for dozen+ or hundred+ cores.
 
RDMS and Assets (Constructs and Territories) lists need to be leveraged here to maximise their benefits.
 
DOCUMENTATION
 
The RDMS policy rights are poorly documented with a single line of text for each. Much better documentation with examples is needed... Game is still in alpha, but we need to start somewhere.  
UI
 
RDMS screen needs to have a clear list of all rights pertaining to the policy on a single, non-scrolling display and use CHECKBOXES to enable and disable the rights. Remove the UNORDERED dropdown list of active policies and replace it with the single screen above. When you check or uncheck a right, it changes colour to show that it is being altered and a simple press of OK or Cancel should determine application or not. Management requires the ability to retrieve information rapidly and clearly All lists need to be filterable by location, type, size etc. so we know how many and where they are. Linking in the RDMS to the system map would be amazing, so we can see our assets on the map and drill down. Allow assets  
ASSETS
 
RDMS Needs to be include POLICY, ACTOR, ASSET, TAG,  where Asset means all constructs and territories. Currently there is somehow NO ASSET TAB in the RDMS and we are still unable to assign or even view our constructs or territories tags from the RDMS manager. NQ might want to allow the RDMS manager to list all the constructs and territories and assign the constructs to policies within the RDMS directly without having to visit the construct manually and add a tag to it.  
TOKENIZED TAGGING
 
Currently there are no Key Cards or Token access right now.  There should be an asset class that when picked up or bought from a dispenser applies a tag to the holder The token times out after a certain period or condition or can be cancelled by the RDMS owner. Player retrieves or buys a token from a dispenser or receives one from an org member. The player then has the tag or tags applied to him for the duration of the token's existence. Removes the need to manually add and remove players from the RDBMs to access assets temporarily. This is perfect for guests, visitor days or test drives etc.  
DATABASE RELATIONSHIPS
 
Leverage the DB. Everything is relationally linked, use those links to help the RDMS manager. Currently, if you click on a policy, it shows what tags and actors apply. Expand this: View a list of all players that have rights in the RDMS. Click on a player to see what Actors they belong to and what policies they are part of. Click on an actor to see what policies they are part of. Click on a tag to see what policies its used in and what assets its tied to Click on an asset to see what tags are assigned and what policies its used in. Click on an asset and reveal it in the map.  
DENIAL / EXCEPTION / INHERITANCE
 
The RDMS has currently no way to deny or create exceptions. This means that additional policies are sometimes needed for subtle differences in access. Add a tag to an element to REMOVE a particular right... for example #NoNoobs We might want to temporarily deny certain rights in one policy without influencing a whole cluster of other policies or recreating groups from the ground up. Exceptions are essential here, like denying ALTs access to certain key assets. This can also be useful in panic situation where a quick response is needed. Just deny first and work out the details later. While constructs have the ability to remove inheritance from their parents, the RDMS does not have this. If you assign a right to a construct, everything ON THAT CONSTRUCT also inherits the right automatically. Setting inheritance to only certain assets on a construct would be useful for example: Public use extends only to furnature types but not combat types or containers.  
FOLDERS, TAGS and ACTORS
 
Tags and to a lesser extent Actor groups have been shown to be more flexible but ultimately harder to manage and more importantly KEEP ORGANISED than simpler folder/directory structures. Give players the ability to group constructs logically in folders and allow application of RDMS to folders and subfolders. Give players the ability to group players logically in folders and allow application of RDMS to folders and subfolders. The RDMS manager can then create folders such as public assets, high security, private etc.  
https://asistdl.onlinelibrary.wiley.com/doi/pdf/10.1002/meet.2008.1450450214#:~:text=Tagging permits a many-to,accessed again later by either. here is an (oldish) research paper discussing the relative merits of folders and tags and came to the conclusion that having both is better than either since we all work and think differently.  
ORG RANKS
 
This is linked to the above ACTORS section: There are only currently three org ranks formally defined. Superlegate, Legate and Member. The Member part needs to be expanded to allow additional, org defined roles with more granularity than just MEMBER. Rank policies assigned by rank.  
TESTING
 
There is currently no method to test any policies RDMS cascading rights viewer is needed Because cascading or inheriting rights from multiple policies is possible, we need to be able to select a construct or player from the RDMS list and view EXACTLY what rights are active or denied. Much like the CSS viewers on any modern browser that show all the applicable CSS attributes from all the cascading rules. Or the Windows active directory permissions viewer which shows actual and inherited rights. Effect Viewer If we change a policy, we need to see exactly what actors and assets will be influenced If we can match a player or actor to an asset and see exactly that that actor/player can or cannot do, it would save a lot of heartache. Construct overview We need to be able to select a construct and see who has what rights and more importantly, VIEW ANY RDMS tags that have been applied to elements on that construct. It's all too easy to overlook a container hub with public rights or a dispenser that is only available to legates. Element rights viewer At a construct level, we need to be able to right click any element and view EXACTLY what rights pertain to that element including inherited rights from the parent construct.  
ADDITIONAL
 
RDMS needs to include asset visibility right to allow non legates to view constructs on their maps.  
 
 
Why is this important? 
NEVER FORGET MARKETPLACE 15!
 

I feel that the RDMS and Assets lists hark back to the first days where every player had a maximum of about 17 constructs and an org had a maximum of <300...
its far too clunky for dozen+ or hundred+ cores.
 
RDMS and Assets (Constructs and Territories) lists need to be leveraged here to maximise their benefits.
 
DOCUMENTATION
 
The RDMS policy rights are poorly documented with a single line of text for each. Much better documentation with examples is needed... Game is still in alpha, but we need to start somewhere.  
UI
 
RDMS screen needs to have a clear list of all rights pertaining to the policy on a single, non-scrolling display and use CHECKBOXES to enable and disable the rights. Remove the UNORDERED dropdown list of active policies and replace it with the single screen above. When you check or uncheck a right, it changes colour to show that it is being altered and a simple press of OK or Cancel should determine application or not. Management requires the ability to retrieve information rapidly and clearly All lists need to be filterable by location, type, size etc. so we know how many and where they are. Linking in the RDMS to the system map would be amazing, so we can see our assets on the map and drill down. Allow assets  
ASSETS
 
RDMS Needs to be include POLICY, ACTOR, ASSET, TAG,  where Asset means all constructs and territories. Currently there is somehow NO ASSET TAB in the RDMS and we are still unable to assign or even view our constructs or territories tags from the RDMS manager. NQ might want to allow the RDMS manager to list all the constructs and territories and assign the constructs to policies within the RDMS directly without having to visit the construct manually and add a tag to it.  
TOKENIZED TAGGING
 
Currently there are no Key Cards or Token access right now.  There should be an asset class that when picked up or bought from a dispenser applies a tag to the holder The token times out after a certain period or condition or can be cancelled by the RDMS owner. Player retrieves or buys a token from a dispenser or receives one from an org member. The player then has the tag or tags applied to him for the duration of the token's existence. Removes the need to manually add and remove players from the RDBMs to access assets temporarily. This is perfect for guests, visitor days or test drives etc.  
DATABASE RELATIONSHIPS
 
Leverage the DB. Everything is relationally linked, use those links to help the RDMS manager. Currently, if you click on a policy, it shows what tags and actors apply. Expand this: View a list of all players that have rights in the RDMS. Click on a player to see what Actors they belong to and what policies they are part of. Click on an actor to see what policies they are part of. Click on a tag to see what policies its used in and what assets its tied to Click on an asset to see what tags are assigned and what policies its used in. Click on an asset and reveal it in the map.  
DENIAL / EXCEPTION / INHERITANCE
 
The RDMS has currently no way to deny or create exceptions. This means that additional policies are sometimes needed for subtle differences in access. Add a tag to an element to REMOVE a particular right... for example #NoNoobs We might want to temporarily deny certain rights in one policy without influencing a whole cluster of other policies or recreating groups from the ground up. Exceptions are essential here, like denying ALTs access to certain key assets. This can also be useful in panic situation where a quick response is needed. Just deny first and work out the details later. While constructs have the ability to remove inheritance from their parents, the RDMS does not have this. If you assign a right to a construct, everything ON THAT CONSTRUCT also inherits the right automatically. Setting inheritance to only certain assets on a construct would be useful for example: Public use extends only to furnature types but not combat types or containers.  
FOLDERS, TAGS and ACTORS
 
Tags and to a lesser extent Actor groups have been shown to be more flexible but ultimately harder to manage and more importantly KEEP ORGANISED than simpler folder/directory structures. Give players the ability to group constructs logically in folders and allow application of RDMS to folders and subfolders. Give players the ability to group players logically in folders and allow application of RDMS to folders and subfolders. The RDMS manager can then create folders such as public assets, high security, private etc.  
https://asistdl.onlinelibrary.wiley.com/doi/pdf/10.1002/meet.2008.1450450214#:~:text=Tagging permits a many-to,accessed again later by either. here is an (oldish) research paper discussing the relative merits of folders and tags and came to the conclusion that having both is better than either since we all work and think differently.  
ORG RANKS
 
This is linked to the above ACTORS section: There are only currently three org ranks formally defined. Superlegate, Legate and Member. The Member part needs to be expanded to allow additional, org defined roles with more granularity than just MEMBER. Rank policies assigned by rank.  
TESTING
 
There is currently no method to test any policies RDMS cascading rights viewer is needed Because cascading or inheriting rights from multiple policies is possible, we need to be able to select a construct or player from the RDMS list and view EXACTLY what rights are active or denied. Much like the CSS viewers on any modern browser that show all the applicable CSS attributes from all the cascading rules. Or the Windows active directory permissions viewer which shows actual and inherited rights. Effect Viewer If we change a policy, we need to see exactly what actors and assets will be influenced If we can match a player or actor to an asset and see exactly that that actor/player can or cannot do, it would save a lot of heartache. Construct overview We need to be able to select a construct and see who has what rights and more importantly, VIEW ANY RDMS tags that have been applied to elements on that construct. It's all too easy to overlook a container hub with public rights or a dispenser that is only available to legates. Element rights viewer At a construct level, we need to be able to right click any element and view EXACTLY what rights pertain to that element including inherited rights from the parent construct.  
ADDITIONAL
 
RDMS needs to include asset visibility right to allow non legates to view constructs on their maps.  
 
 
Why is this important? 
NEVER FORGET MARKETPLACE 15!
 

Yes the slots can exceed the capacity limit, in practice an organization can only have 1625 constructs due to the limit. It can however have say 10000 slots, this allows for an organization to have some buffer for gains and loses over time.
 
 
We are not telling you to tear down your builds, not at all. Quite the opposite, we love seeing players buildings in the game. 
What we are saying is that we need you to find a way to support your builds that exceed what we can grant and support you with as a single contributing member of our community.
 
I wish you all a wonderful weekend, and look forward to reading more feedback on monday.
 
Sincerely,
- Deckard

It would be also cool to have RDMS right that makes constructs visible for the actors. By visible I mean visible in F4 -> Constructs list. Curently, only legates can see the constructs location. So, if you have "use element" right you can control the ship but you can't find it's location other than ask from the owner (or legate) of the ship or if you are registerd at ship's ressurection node. That is also one of the reason why in a small org legates are "assigned quite liberaly".

There are many locations where we need to preserve the great creative work, to be not looted and destroyed. 
My proposal is this: 
To create new status for territory units and constructs. 
It could be something like: CCC (Community Created Content) 
CCC:s could be treated same way as Aphelia owned tiles and constructs. 
CCC status would be assigned by NQ staff only. 
If a dedicated player or group of players wants to continue creating/developing their CCC content NQ could set RDMS to allow it. 
However, if players quit or something else bad happen, CCC tiles and constructs won't disappear, they would stay in Game-world as a public buildings or other common constructs. 
 
Other, maybe even easier solution could be a possibility to tokenize construct and hand it over to “Aphelia”/NQ 
This way we could preserve many great buildings and ships to future generations. 

While this may be off topic for this thread, I believe NQ is missing something here. Many orgs will "promote" members to legate becasue there is NO OTHER rank that would give a member extended options/rights within the org. We really need to have a better org structure as in, have different roles that allow different options in orgs beyond what RDMS can provide.

But this really is a discussion for a different topic.. 

Yes calibration charge optimization and Calibration charge efficiency Improved calibration charge optimization and improved calibration charge efficiency are the first and only 4 skills to not be affected when you VR. 

Instead retain calibration for longer, set three brackets which will add 8, 16 or 24 hours to the time the Mining unit stays at the achieved calibration.
Easy, clean and removes the need to go run around and get the harvestables while giving you roughly the same amount of "bonus ore"
 

Cue the old trope:
—brrrrrrng brrrnnng.
”yes? Uh huh… ok… bye now.”
—click
    “Who was it?”
“It was the 90s. Apparently they want all their modal dialogue boxes back.”

Does anyone get a regular, repeated pause in the game every minute or so? It lasts only about half a second or so but can be deadly if it happens when you come out of warp because you might still be traveling at >20,000kph. I only just managed to stop my ship before hitting atmo. (Because it was empty). 
if you’re coming in to land over MP6 and this happens, we all know how that can end. 

I tested it on two computers of varying vintage and both show the same phenomenon. 

it’s very noticeable in the presence of MUs due to the amount of motion and even when playing the mining mini game. 

Who pissed in your cornflakes? Or were you trying to score points in front of your boy/girlfriend?

a simple. I don’t agree with you would have sufficed. 
 
you’re the embarrassment. 
 
elite dangerous and Star Citizen both touted methods to completely avoid PvP in their kickstarter stages. 
 
elite promised a solo game mode where you don’t encounter other players and Star citizen promised a pvp slider. 
 
Naturally, only one of those games actually delivered a pvp free experience for those uninterested in having their play ruined by basement dwellers who seem to get a thrill and like to rub one out after verbally abusing other players on game forums or in game chat. 
 
I understand the OPs desire but feel that method would be open to abuse by simply and unfairly sidestepping any defenses or attack strategies orgs have put in place. 

Might be that would be too much to handle for some /s  

Flying is character building! It’s Core Gameplay (TM). Much like finding that last voxel before you can pick up a static core or wandering around calibrating MUs by playing the gif animation mini game. 
Or holding your mouse button continuously for a quarter of an hour to pick up surface mats.
or opening, scrolling down and then clicking on a tiny drop down list that closes again 20 odd times to select the correct permissions in an RDMS ACL.

edited — Wtf was a “moisture button” lol. 

Who pissed in your cornflakes? Or were you trying to score points in front of your boy/girlfriend?

a simple. I don’t agree with you would have sufficed. 
 
you’re the embarrassment. 
 
elite dangerous and Star Citizen both touted methods to completely avoid PvP in their kickstarter stages. 
 
elite promised a solo game mode where you don’t encounter other players and Star citizen promised a pvp slider. 
 
Naturally, only one of those games actually delivered a pvp free experience for those uninterested in having their play ruined by basement dwellers who seem to get a thrill and like to rub one out after verbally abusing other players on game forums or in game chat. 
 
I understand the OPs desire but feel that method would be open to abuse by simply and unfairly sidestepping any defenses or attack strategies orgs have put in place. 

You can do something about most of these items yourself.
carry xs core with rez on back of primary vessel  use a clock and slow down before getting close to a planet use archehud with collision detection, have A LOT MORE brakes install an emergency control unit on your ship build small warp ship, go to all planets before hauling, and place a small space station with ressurection equipment and a small shuttle ask other players if you want / need to go to a planet and need help

If they want us to move to space all they need to do is move Market 6 ?
 
But really it would be more fun if they give us player run markets, and let us pick the new market 6. 

Flying is character building! It’s Core Gameplay (TM). Much like finding that last voxel before you can pick up a static core or wandering around calibrating MUs by playing the gif animation mini game. 
Or holding your mouse button continuously for a quarter of an hour to pick up surface mats.
or opening, scrolling down and then clicking on a tiny drop down list that closes again 20 odd times to select the correct permissions in an RDMS ACL.

edited — Wtf was a “moisture button” lol. 

Who pissed in your cornflakes? Or were you trying to score points in front of your boy/girlfriend?

a simple. I don’t agree with you would have sufficed. 
 
you’re the embarrassment. 
 
elite dangerous and Star Citizen both touted methods to completely avoid PvP in their kickstarter stages. 
 
elite promised a solo game mode where you don’t encounter other players and Star citizen promised a pvp slider. 
 
Naturally, only one of those games actually delivered a pvp free experience for those uninterested in having their play ruined by basement dwellers who seem to get a thrill and like to rub one out after verbally abusing other players on game forums or in game chat. 
 
I understand the OPs desire but feel that method would be open to abuse by simply and unfairly sidestepping any defenses or attack strategies orgs have put in place. 

Sorry I really dont see the issue.  I look at donated cores.  Look at who gave ,  I see 200 coming from people that I know/thrust.  I see another 400 from people that are dubious ,  unknown, etc..   I now know that I better not go over 200.  Kind of like a bank that gives you a 500$ overdraft,  it does not mean you should use it,  it's always going to hand up costing you.  Leave within your means applies to the cores.   

Who cares. Focus on the outcome. This is far better then what was proposed and workable. 

Here's an idea on-top of the proposed changes that would make things much smoother with regards to Org cores:

Have a "Slot Exchange Market" where buy/sell orders of "1 slot/mo" can be traded.

That way players can put up their unused Org slots for a nice monthly income, and Orgs can quickly buy emergency slots.

Maybe even allow Org Legates to set a rule to auto-purchase "market slots" @ "set price" if Org is running short on the next core check.

This will be enough cores to satisfy most people's needs. I still don't like the random delete part for org cores if someone removes support  Most recently added cores would be better I think! it would also be better is if Org membership played a part in the total instead of just org slots.