Citadel docking filters based on the ship's cargo

Right now structure docking rights are only based on standings, not ship type or cargo. Adding such control could be a powerful tool, in the form of blacklists or whitelists - applied globally, or specifically to a standings level or group.

Use cases:

  • Large corps or alliances gain the ability to

    • Enforce staging requirements (e.g. Caps go in THIS citadel)
    • Enforce doctrine requirements (ban shield or armor tank modules, or entire ship types, or only allow specific ships)
    • Deny non-blues with cloaking devices from docking
  • Player tournaments gain the ability to ban specific ships, fits, or modules (e.g. T2, Deadspace, Mutated), or only allow specific ones to dock

  • Small communities could be created around “filtered” citadels to attract like-minded players:

    • Alpha or Newbie Friendly Freeports which only allow pods, corvettes, T1 Frigates and other Alpha-Clone-capable ships to dock

    • or Bomber havens which only allow Bombers to dock

    • or Pacifist stations denying ships with weaponry

    • or HTFU stations denying ships without weaponry

    • etc.

Mechanically speaking:

  • If your ship carries a prohibited item:

    • The overview Dock icon would not be present (or better yet, turn red to indicate a specific denial)
    • A tooltip of “This citadel prohibits docking of [SHIPTYPE] {containing [OBJECT]}” would appear on the station
    • If you try to undock from a station with a prohibited item in your ship, a warning message will appear, to alert you that you will not be able to redock (“are you sure?”)
  • Re.contracts:

    • A delivery cannot be created to a station banning that item.
    • If the station prohibits an item involved in a contract after it has been taken, the contract is canceled.

If you got this far, thank you for reading! \o/

Feel free to constructively build on this; I am aware this idea might introduce problems.

This sounds a lot more difficult and less useful to implement than compression tax and ccp can’t even be bothered with that

This would result in alot of overhead and possible complicated issues.

The list of modules and ships is big, even if you use the groups instead of the items, so it would be very complicated to create and maintain these lists. In addition it might result in unwanted sideeffects (for the tether for example).

The other side would be a big server overhead. If you enter a system you pull the access lists of every station already so it is dicided if you are allowed to dock or not. With your idea you would have to pull the black/white list in addtion, which can become huge. But you would also need to pull this list again everytime you refit, change ship etc. This could result in alot of overhead in your system and create lag.

all you would have to do is connect them with filters you have already created

what makes you think it’s unwanted?

no… you wouldn’t unless you were ■■■■ at coding

for the record i don’t like the idea either but your reasons are just bad

Its not that easy. Current filters are single level filters that only effect ships and items, but not whats inside them. In addition you cant filter pilot related statts with them. So what you would need is a hierarchical structure where you slap different filters for the pilot, the ship and the ships contents together. Depending on what you want to do these filters can become quite complex and complicated, especially when combined into actual rules.

I said it might be unwanted. When creating such a system you need to account for every sideeffect that might cause trouble and create a solution. The tether is just one of them.

You would require additional server events that make sure that your list is always up to date in case it was changed during your visit. Even if you keep a local copy of the filters you would still require syncing with the sever.

Im just pointing out loose ends and possible pitfalls such a system could have if build in, which would add to complexity during developement resulting in high time consumtion and testing requirements.

would only have to push updates if it was updated… something it already does with access lists

this already exists the ones available to players just don’t work that way because they are older

Which still results in more overhead, you can just limit it to a certain degree.

Didnt know that, thx for pointing it out.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.