EVE Search - Big over looked problem with new Sov System

All Channels

Test Server Feedback

Big over looked problem with new Sov System

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: 1 2 [3] 4 5 :: one page
Author	Thread Statistics \| Show CCP posts - 18 post(s)

CCP Incognito	Posted - 2009.10.22 07:57:00 - [61] Originally by: Ihavewindage Can a single corp hold sov in the new setup? Does this mean only Alliances can hold sov? Thanks A corp must be a member of a alliance to online a flag. A lone corp can not claim sovereignty in a system.


CCP Incognito	Posted - 2009.10.22 08:03:00 - [62] Edited by: CCP Incognito on 22/10/2009 08:05:13 Originally by: R Mika Hopefully with the new treaty system coming in this variable will be changed into a 64 bit one. There are quite a few roles missing right now that forces one to make directors of people that simply don't need it (particularly when it comes to diplomacy). And as the original poster pointed out, Sov beacons really have nothing to do with POS management. They should be separate, anyway. Already is, you don't see all the roles in the UI. I believe it is on the long term plans to rework it but not on this release. I guess you could say soon(tm) to soonish(tm)

Caldor Mansi	Posted - 2009.10.22 08:57:00 - [63] Originally by: CCP Incognito Originally by: Waz Weh Edited by: Waz Weh on 21/10/2009 16:14:58 What happens when a corp holding flags leaves the alliance? What happens when a corp holding flags is kicked out of the alliance? When the alliance gets disbanded, do all flags go offline? Is there any effect if the alliance government is changed? Can a malicious corp hold onto flags even though the alliance wants this situation stopped but finds themselves unable to kick the corp? Is there any effect if two corps holding flags in the same alliance online them at the same time, etc? [] The flags offline [] There flags offline [] Yes all the flags go offline [] No [] Yes [] The first one to get to online wins, the other flag will revert back to anchored, "there can be only one" flag online. When a flag goes offline then all structures that depend on them also go offline, IE the Infrastructure Hub, CSAA will pause jobs, Jump bridges will offline,... From this it does not seem to be that difficult to make offlining a Flag submited to corporation voting... Any will to look at it?
Slobodanka	Posted - 2009.10.22 09:42:00 - [64] Originally by: CCP Incognito A corp must be a member of a alliance to online a flag. A lone corp can not claim sovereignty in a system. This is a joke, right? Only alliances can claim sov and corps can't?
Caldor Mansi	Posted - 2009.10.22 09:46:00 - [65] Originally by: Slobodanka This is a joke, right? Only alliances can claim sov and corps can't? It is not. It was this way since sovereignty control was introduced. Only natural step from: Lone player -> Corp and POS -> Alliance and Claimed space. Nothing wrong here, make an alliance with a single corp if you want to claim a space.
HeliosGal	Posted - 2009.10.22 09:57:00 - [66] yes once setup there really is only the 2 mil per corp alliance fee, so thats a good thing alliances now claim sov
Cadde Gallente FireworX	Posted - 2009.10.22 10:11:00 - [67] Edited by: Cadde on 22/10/2009 10:12:42 Originally by: CCP Incognito stuff May i suggest that instead of making more bit-flags or reiterating around the same concept we have today. Each and every "role" rather has a root structure tree? Like this for example: Now, please allow me to explain that image just in case it isn't obvious! If a member have read access to a role this is denoted by a green checked icon as shown in the image. If a member has access to alter/grant a role the read option is ON by default denoted by the gray checked icon. Each role belongs to a parent category. If a pilot or a group of pilots have read/alter/grant access in a parent category the rights will be applied per default to all of it's sub categories/roles. This is denoted by the blue dot in the image. (It is/should be possible to DENY access to a certain sub role or category though) Now why would there be a read option for "Flag anchoring" you might ask... Well, this is just to keep things simple in code and in this specific case it does nothing useful. But as an example, having read access on flag anchoring could allow the pilot to see what pilot is anchoring or unanchoring the flag for authoring purposes. (Find out who the spy/defector is) Furthermore, having read access might let the pilot show WHO has what rights in regards to anchoring flags IF the authoring pilot also have the "Role authoring" read right. (Complex but has it's uses) Having grant access to the category "SOVEREIGNTY ADMIN" but being denied to alter/grant on flag anchoring will deny that pilot from messing with this certain element of SOV administration. In this case, someone who ISN'T denied in this field will have to grant the pilot access to this role for him to ever be able to mess with it. Per default, the CEO of the corp will ALWAYS have ALL rights everywhere, no need to set any rights for the CEO and attempting to deny the CEO a right will just show an error message and even if it did work due to a bug... It would have NO effect! You might have noticed the "Groups" tab, it's just like the pilots tab but instead of pilots you add groups. These groups hold any number of pilots in them and quite simply makes things easier to manage! ------ So how does this work in code? Well, i can't say i know how the eve clusters code looks like or what your database structure is like in regards to the current role management system but instead of checking for a bit-flag for a certain role... The server checks that certain role's "roleID" for a pilot or any group that the pilot is in. It will then find a bit-flag that looks like this: 0 - No access 1 - Read access 3 - Alter access 7 - Grant access 8 - Read by inheritance (Some parent category allows this) 24 - Alter by inheritance (Some parent category allows this) 56 - Grant by inheritance (Some parent category allows this) If the pilot has no rights assigned anywhere then the search will simply return NULL which also means NO access. You might also notice how i per default gave read/alter access to the alter and grant flags. This is assigned when roles are defined by the pilots with grant access. When someone grants access to a certain category or role it will iterate through all child categories and roles and check for a role, if no bit-flag exists (NULL) it will insert that inheritance bit-flag there. The same applies for removing the rights... It iterates downwards checking for inheritance flags that match and NULL's them. You get the idea. Now, performance wise. Assigning roles will have a bigger performance impact than before. Checking for rights will only have the extra overhead of looking up the roleID and checking if the pilot and the groups that the pilot is in has access. I feel it's worth it! EDIT: Broken quote... My opinions belong to me, you can't have them!
HeliosGal	Posted - 2009.10.22 10:30:00 - [68] the last poster makes a lot of sense , the data strucutre would work and the role are acecptible. Thoughts

CCP Incognito	Posted - 2009.10.22 13:42:00 - [69] Originally by: Cadde Edited by: Cadde on 22/10/2009 10:12:42 Originally by: CCP Incognito stuff Lots and Lots of Stuff with pretty pictures Yes what you are describing has been around for ever since there where BIG-IRON mainframes. it is call user access control. We have good idea how we want to do it, But it takes time and we have bigger fish to fry than reworking half the game (the flags are used for allot of things, and hence allot of code would need changing). We will when we are able, we recognize there are bottle necks that are annoying to you, and limiting for us. :( It will be changed in due time, not even going to say soon(tm).... Doh! :)

Draco Argen	Posted - 2009.10.22 13:59:00 - [70] Er I appreciate that people are identifying the bit flag as a bad Idea. There are lots of great replacement ideas. But don't think that CCP haven't had these ideas already. (There likely written on CCP Iceland's bathroom walls) If they can design a meta data email system, they can design an object orientated or relational permissions system. The significance is "legacy" issue. It was a bad first idea when they first came up with it 3 years ago. It saves space and seems logical. But it was non extensible and limiting. It is also THERE, and works. Unless CCP has time to trawl through the code it would affect they can't consider redesigning, for now. It will happen, i'm sure. Just a case of getting your ducks in line and shooting them in the right order. With 6 weeks to go there not going to redesign the Database, handling code, integrity/validation checks (essential for permissions) and the UI. Then QA it all.
Nuts Nougat Sniggerdly Pandemic Legion	Posted - 2009.10.22 14:36:00 - [71] Edited by: Nuts Nougat on 22/10/2009 14:44:40 edit: wrong thread sorry. ---
Jarne Increasing Success by Lowering Expectations	Posted - 2009.10.22 14:47:00 - [72] Originally by: Linianaria Edited by: Linianaria on 21/10/2009 11:33:58 Well i kind of still agree with the fact that a problem still exists. Perhaps its time for CCP to have roles looked at again. Now that you divided POS and Sovr. why dont you create a new role to match this? Sovr. manager role as an example? That would solve the whole "mass sovr. loss by spy" thing and divide POS and sovr. FTW :) This. Surprises me to see that CCP hasn't thought this through. Why should anyone that is allowed to do something completely unrelated to Sov automatically be allowed to affect Sov?! - Success=Achievements/Expectations
Cadde Gallente FireworX	Posted - 2009.10.22 15:17:00 - [73] Originally by: CCP Incognito Originally by: Cadde Edited by: Cadde on 22/10/2009 10:12:42 Originally by: CCP Incognito stuff Lots and Lots of Stuff with pretty pictures Yes what you are describing has been around for ever since there where BIG-IRON mainframes. it is call user access control. We have good idea how we want to do it, But it takes time and we have bigger fish to fry than reworking half the game (the flags are used for allot of things, and hence allot of code would need changing). We will when we are able, we recognize there are bottle necks that are annoying to you, and limiting for us. :( It will be changed in due time, not even going to say soon(tm).... Doh! :) Ok... Ever heard about starting small? I don't know how you guys operate at CCP (either) but why continue adding MORE code that revolves around the problem? Then it will never be fixed because the code just grows and grows and the issue is therefore pushed further and further back the line because of the magnitude of such a change. So may i suggest... Starting to work with "THE" new access system on anything new you implement and let the two work side by side, while OFC gradually reworking the old system. It will be confusing at first for both you guys and us but the means justify the ends. I know this won't happen for Dominion but the next expansion, whatever it may be, better start working on this old system that is so obviously flawed in design. Just to give one example, all the idiots giving director roles because the role system as it is now doesn't work as intended nor is it easy to understand in the first place. And it is too much access to give away just for something small such as doing material efficiency research using a pos. Which requires a host of different permissions that also give access to other stuff the researcher doesn't need access to. Also, while you implement the new permission system we (many players) would love to have, instead of hangars, folders, subfolders and then some ... in our corp hangar where we can define who gets access to what WITHOUT having to use stupid secure cans with passwords and making silly workarounds for everything that isn't working well. Like making holding corporations... It's not only adding more work for the players, it's also very heavy for the servers with all the unlocking items, moving items, locking items, constantly opening several cans (because each container can only hold so much) to see whats in them and so on. There is no limit to how many cubic meters of stuff you can have in a station anyways... So why would we need containers with those limitations? Meh, just do it mmkay? My opinions belong to me, you can't have them!
Caldor Mansi	Posted - 2009.10.22 15:56:00 - [74] Originally by: Cadde Ok... Ever heard about starting small? I don't know how you guys operate at CCP (either) but why continue adding MORE code that revolves around the problem? Then it will never be fixed because the code just grows and grows and the issue is therefore pushed further and further back the line because of the magnitude of such a change. So may i suggest... Starting to work with "THE" new access system on anything new you implement and let the two work side by side, while OFC gradually reworking the old system. It will be confusing at first for both you guys and us but the means justify the ends. I know this won't happen for Dominion but the next expansion, whatever it may be, better start working on this old system that is so obviously flawed in design. Just to give one example, all the idiots giving director roles because the role system as it is now doesn't work as intended nor is it easy to understand in the first place. And it is too much access to give away just for something small such as doing material efficiency research using a pos. Which requires a host of different permissions that also give access to other stuff the researcher doesn't need access to. Also, while you implement the new permission system we (many players) would love to have, instead of hangars, folders, subfolders and then some ... in our corp hangar where we can define who gets access to what WITHOUT having to use stupid secure cans with passwords and making silly workarounds for everything that isn't working well. Like making holding corporations... It's not only adding more work for the players, it's also very heavy for the servers with all the unlocking items, moving items, locking items, constantly opening several cans (because each container can only hold so much) to see whats in them and so on. There is no limit to how many cubic meters of stuff you can have in a station anyways... So why would we need containers with those limitations? Meh, just do it mmkay? Would that mean losing a 4 month beer drinking summer period between expansions? Sorry, not going to happen.

CCP Incognito	Posted - 2009.10.23 07:54:00 - [75] Originally by: Cadde Alt+0153 on the numpad... Ghee all these devs that don't know how stuff is done Thanks, didn't know the number for it.


CCP Incognito	Posted - 2009.10.23 08:05:00 - [76] Originally by: Cadde Ok... Ever heard about starting small? I don't know how you guys operate at CCP (either) but why continue adding MORE code that revolves around the problem? Then it will never be fixed because the code just grows and grows and the issue is therefore pushed further and further back the line because of the magnitude of such a change. So may i suggest... Starting to work with "THE" new access system on anything new you implement and let the two work side by side, while OFC gradually reworking the old system. It will be confusing at first for both you guys and us but the means justify the ends. I know this won't happen for Dominion but the next expansion, whatever it may be, better start working on this old system that is so obviously flawed in design. Just to give one example, all the idiots giving director roles because the role system as it is now doesn't work as intended nor is it easy to understand in the first place. And it is too much access to give away just for something small such as doing material efficiency research using a pos. Which requires a host of different permissions that also give access to other stuff the researcher doesn't need access to. This is a good approach in theory, but they tend to die really slow and for along time you end up maintaining two systems. In my experience it is better to Chain saw out the old and inject the new. This lets the other developers on the team get one email that says "Do it this way from now on" and they can't be lazy and say "well I know how the old works I will just use it, and let someone else change it later" Originally by: Cadde Also, while you implement the new permission system we (many players) would love to have (instead of hangars) folders, subfolders and then some ... in our corp hangar where we can define who gets access to what WITHOUT having to use stupid secure cans with passwords and making silly workarounds for everything that isn't working well. Like making holding corporations... It's not only adding more work for the players, it's also very heavy for the servers with all the unlocking items, moving items, locking items, constantly opening several cans (because each container can only hold so much) to see whats in them and so on. There is no limit to how many cubic meters of stuff you can have in a station anyways... So why would we need containers with those limitations? Yes that would be a nice idea, several reasons why it would not work, but keep dreaming. The reason for limits on the number of items is simply DB performance. I am not a expert on this and this is just how I understand it. If you have 1000 items it take X time but if you have 2000 items it takes X*2.1 time, this is all do to what the DB server keeps in the cache. so we put a in game limit on the containers so that some evil bugger in Jita doesn't take 100m trit and make stacks of 1. Them opens and closes his inventory to lag out every one else in the station. Just remember every time you see a arbitrary limit on something like this there is probably a performance reason behind it. Like having population limits on Jita. I do like the idea of being able to grant someone else access to a hanger, like your alt access to your mains hanger and so on. I will make sure I mention it when we get to redoing it.

HeliosGal	Posted - 2009.10.23 08:06:00 - [77] alt access to a mains hanger is a good idea
Cadde Gallente FireworX	Posted - 2009.10.23 09:43:00 - [78] Originally by: CCP Incognito Really good answers Thanks Incognito, we like this from you fellas. I know about the maintaining two systems at once. My brother used to work for a company that had 12 - 15 of them at the same time, i worked there too but i never had to mess with those systems directly. However, i still had to assist my brother both mentally and in coding from time to time as it was a real mess. It all ended up with my brother (without ever being asked to or getting paid for it) made his very own system, He called it the "Multimanager" and it dealt with EVERY single system and combined them all under one "API" kinda. Maybe you guys at CCP could do that? Just make an API that can communicate with each and every different approach until they are exterminated. This is what DirectX does with graphics card drivers so you guys don't have to. There was this other cool thing that the Multimanager could do. You asked it for a phone number (The company was in the Internet and telephone business) and it would not only reply with what type of hardware was behind that phone number but it would also (Where applicable) connect to the VoIP hardware and gather the most relevant data from it in real time. I am getting to the second thing here, database management. Instead of storing EVERYTHING on one database you can split up the databases into item manager and "the rest" and let ONE server work as a router to channel all these requests so it would seem like one database but in reality the actual reading and writing is done in several places at once, thus splitting up the workload. This also makes it possible to split the JITA database from the rest of the cluster. The "multimanager" knows what is in JITA and whats not in JITA because it can tell the difference by the solarsystemID or even regionID if splitting it up by regions. So how does one deal with requests that would go to all regions? If regionID is missing in the request, meaning ALL regions in the query then the multimanager simply asks all databases and merges the result sets sending them back in one big batch. In essence, one powerful machine handles all the communications with all the (relatively) slower databases thus streamlining the process. The company where my brother worked adopted this system and where reliant on it for their day to day operation as they grew in size faster than ever before. One could say this was because of the work my brother did. However, bad leadership in the company was it's demise and now he works at Tele2 doing the very same thing he did for the other company. Building insane SQL queries that can do more than just one thing. On a final note, the containers are not only limited by the number of stacks you can have but by the amount of M3 you can put in them. One stack of 10,000,000,000 tritanium will fill a station container. But in the database it's just one entry. That is what is wrong with containers! The hangar floor doesn't have a M3 limitation and you can have some five thousand stacks in it before eve complains. I rarely have 5,000 items sitting on my hangar floor, actually i use freight containers and split it up by T1, Meta4, T2, Meta >= 6, Ammo, Drones and so on... But replacing those containers with folders would be far superior. Especially if the folders where listed side by side with the item window. Then we can use those folders for the suggested access system. ♥♥♥ //cadde My opinions belong to me, you can't have them!
Tairon Usaro The X-Trading Company RAZOR Alliance	Posted - 2009.10.23 10:51:00 - [79] well my biggest problem with the proposed sov system is - based on the information i have right now - that it has nothing to do with sovereignty ... the appropriate term is ping-pong-flavor-of-the-day-pwnage /sarcasm_off i understand why CCP wants to make sov more volatile but the proposed mechanism will not promote this. it will just lead to a situation where builders loose interest in building their own empires and move back to empire, while PvPers in the long run will loose their targets after having had some fun in short termed fast paced but completely meaningless gankage. if you can contest ANY system at ANY time within 12 hours sovereignty does not have a meaning nor does it provide the defensive basis for any building activty. it would be a completely different story if the override platforms could only be installed at gates that are linked to systems, which are either unclaimed, high/low sec or claimed by the contesting entity. Thus the conquerer must take the systems one by one from the outer space and can not persue a hit and run strategy on core systems, only causing damage without serious amibitions to take over the space. The restriction to conquering from the borders of the space would give the whole mechanism a strategical depth without rendering it to the static POS warefare we have ..... but so far, i have no indication that this idea is shared by the designers. All i know right now is mechanism that so plain and simple that it has no complexity at all and that renders space claiming to complete meaninglessness. ________________________________________________ Some days i loose, some days the others win ...
Kravek Lamb Federation Navy C0VEN	Posted - 2009.10.23 11:16:00 - [80] Edited by: Kravek on 23/10/2009 11:19:13 Originally by: Tairon Usaro if you can contest ANY system at ANY time within 12 hours sovereignty does not have a meaning nor does it provide the defensive basis for any building activty. Remember that STOPs can`t be placed if Hub is online. So hypothetically if Hub will be pimped taking sov will be not something very easy to do.
Miyamoto Uroki Caldari Black Thorne Corporation	Posted - 2009.10.23 11:36:00 - [81] Originally by: Kravek Edited by: Kravek on 23/10/2009 11:19:13 Originally by: Tairon Usaro if you can contest ANY system at ANY time within 12 hours sovereignty does not have a meaning nor does it provide the defensive basis for any building activty. Remember that STOPs can`t be placed if Hub is online. So hypothetically if Hub will be pimped taking sov will be not something very easy to do. Is this a confirmed fact? you always have to take down the active hub before you can start the onlining of STOPs? Anyone knows if the hub also have reinforced timers, like outposts? Oh, and reinforced timers of POSes are still there, right?
Kravek Lamb Federation Navy C0VEN	Posted - 2009.10.23 11:46:00 - [82] Originally by: Miyamoto Uroki Originally by: Kravek Edited by: Kravek on 23/10/2009 11:19:13 Originally by: Tairon Usaro if you can contest ANY system at ANY time within 12 hours sovereignty does not have a meaning nor does it provide the defensive basis for any building activty. Remember that STOPs can`t be placed if Hub is online. So hypothetically if Hub will be pimped taking sov will be not something very easy to do. Is this a confirmed fact? you always have to take down the active hub before you can start the onlining of STOPs? Anyone knows if the hub also have reinforced timers, like outposts? Oh, and reinforced timers of POSes are still there, right? I personally check that. When Hub of another ally is online in system I was unable to online STOPs. AFAIK have hubs reinforced mode but I'm sure.
Shinma Apollo Shut Up And Play	Posted - 2009.10.23 14:50:00 - [83] Any plan to make Hubs, STOPS, and FLAGS show on directional and probing, or are hubs intended to be a game of hide and go seek? Trying to test the hubs when having no idea where to find them is pretty useless. Sidebar, another smartbomb nerf, you can't smartbomb FLAGS (which isn't bad, because you could hypothetically destroy the new sov system)

CCP Incognito	Posted - 2009.10.23 16:01:00 - [84] Originally by: Shinma Apollo Any plan to make Hubs, STOPS, and FLAGS show on directional and probing, or are hubs intended to be a game of hide and go seek? Trying to test the hubs when having no idea where to find them is pretty useless. Sidebar, another smartbomb nerf, you can't smartbomb FLAGS (which isn't bad, because you could hypothetically destroy the new sov system) Have you logged into SISI? STOPS and FLAGs are global, you can see them from anywhere in the system. Hubs have to be at planets like outposts. I don't think probes are required :)

Rainus Max Fusion Enterprises Ltd	Posted - 2009.10.23 16:53:00 - [85] Edited by: Rainus Max on 23/10/2009 16:54:15 Im curious on this scenario, so Ill put it forward: Alliance A has a constellation with a dead end system, all systems in the constellation have sov. Alliance B drops a STOP in the constellation. If alliance B drops it in the other systems they have to drop STOPs on 51% of gates, is there any special setup within the new system to stop alliances just wandering in and knocking out a dead end? Something along the lines if all neighbouring gates lead to alliance A's claimed space then you cant contest a system.
An Anarchyyt Gallente Battlestars GoonSwarm	Posted - 2009.10.23 17:21:00 - [86] Currently certain things prevent STOPs from being onlined unless other things are gotten rid of first. Originally by: CCP Wrangler Second, a gentile is a non jewish person
Shinma Apollo Shut Up And Play	Posted - 2009.10.23 19:54:00 - [87] Originally by: CCP Incognito Originally by: Shinma Apollo Any plan to make Hubs, STOPS, and FLAGS show on directional and probing, or are hubs intended to be a game of hide and go seek? Trying to test the hubs when having no idea where to find them is pretty useless. Sidebar, another smartbomb nerf, you can't smartbomb FLAGS (which isn't bad, because you could hypothetically destroy the new sov system) Have you logged into SISI? STOPS and FLAGs are global, you can see them from anywhere in the system. Hubs have to be at planets like outposts. I don't think probes are required :) Actually the first post was done with the new browser on sisi :P And yes, it's somewhat important because if you're trying to do recon on a STOP or a FLAG, it's nice to be able to directional scan to see what it is you're warping into, like a bubbled FLAG. More to the point, infrastructure hubs are just covops bait atm, with nothing stopping someone from simply sitting at a planet at a time of invasion with a small bubble, a smartbombing bs, and a small glimmer in their eye, or, like, you know, not having to run 13 planets in a system to find out there is no hub.
DigitalCommunist November Corporation	Posted - 2009.10.23 22:48:00 - [88] Mad props to CCP Incognito for communicating things, instead of the usual "wait for the devblog" response.
Zaethiel D00M. Triumvirate.	Posted - 2009.10.24 03:55:00 - [89] I have to agree that the roles needs to be redone. It is fairly confusing and is not very customized to the various situations where you need give people roles. I also love seeing devs discussing topics such as gameplay with the community and taking our feedback into consideration. Now to get the ability to lock my Aeons corp hanger and ship bay from everyone would be nice. People can still play hot potato with my ships if they are in fleet. -----
An Anarchyyt Gallente Battlestars GoonSwarm	Posted - 2009.10.24 05:18:00 - [90] Edited by: An Anarchyyt on 24/10/2009 05:19:45 Originally by: Shinma Apollo Actually the first post was done with the new browser on sisi :P And yes, it's somewhat important because if you're trying to do recon on a STOP or a FLAG, it's nice to be able to directional scan to see what it is you're warping into, like a bubbled FLAG. Even if for some reason it wasn't on the directional scanner, you can see it from anywhere, and see how far away it is. Therefore, you could obviously figure out what is there regardless. Your other point doesn't even make any sense. Originally by: CCP Wrangler Second, a gentile is a non jewish person

Pages: 1 2 [3] 4 5 :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.