CSM Meeting Minutes 4.004
All this data is potentially out of date, and should be taken with a truckload of salt
See also CSM Meeting Minutes 4.004 raw log
CSM 4 meeting 004, Sun 17th Jan - Meeting Minutes
- 1 Present
- 2 Absent
- 3 Discussion
- 4 Other Business
Meeting started at 15:20
ElvenLord set out the agenda.
1 Overhaul of roles and grantable roles system
2 Kill mails
3 shield bonuses
4 FW - CCP Inaction Towards Bugs/Exploits
5 FW - Lack of Development Part 2
6 Lock Characters to Prevent Theft
7 Scan-able wrecks&containers for the salvager profession(1.2)
ElvenLord indicated that more detail was available if passed. TeaDaze thought it seemed a sensible proposal, following conventional wisdom though questioned of how many groups would be allowed.
Helen Highwater wanted to check how the proposal would work. ElvenLord replied that the CEO would first create user groups with a package of roles attached to them and then add members to them. ElvenLord added that some roles would be predefined and permissions would be given to certain objects.
T'Amber liked the idea though cautioned that the ability to share pre-made user group settings might be open to abuse. ElvenLord stated the proposed system was similar to for example what phpbb forums have or even file systems. T'Amber agreed.
Song Li asked if this would come with a set of pre-packaged role systems available to new player Corps so that every time you create a Corp you wouldn't have to create the basic roles and permissions. Song also wondered if these would be export/importable? T'Amber also wanted to know. ElvenLord answered that it could be done with ease though thought a short tutorial might be needed for a transition phase.
Alekseyev Karrde wondered how it was different from titles, thinking it was the same idea in a different but not necessarily easier to navigate package just expanded to include more options. Mrs Trzzbk agreed it sounded like titles and wanted to focus more on the fact that it shouldn't be a nightmare of the worst proportions to create, hand out and audit said titles.
T'Amber suggested that making some of the current roles more specific and not so broad (such as POS roles) would be a good start and though it seemed similar to what is currently in game but with more control.
TeaDaze thought it would be more flexible if the players could have the option to set the groups so you could for example have a procurement role that has access to a specific wallet as well as hangers etc.
ElvenLord stated the general principle as straightforward where CEO and Directors could create UserGroups with privileges attached and then add/remove members to/from those groups. He continued that each User Group would have attached roles and privileges that every member of the group would enjoy. If you wanted to grant 'special rights' to some members you would just create a suitable group with the extra rights and add those members to it. He continued with more details including suggesting the ability for non directors to allocate roles. Alekseyev Karrde liked the idea that non directors would able to hand out limited amount of roles.
ElvenLord continued with more details, but Song Li stopped him saying everyone had the idea. ElvenLord joked that was just first page and that he would make a PDF of the entire breakdown.
T'Amber asked if the proposal included more options for actual role assignment to allow expanding current roles so that the user groups could be more specific without having to spend lots of programmer time on making the roles mechanically possible. ElvenLord replied the entire system should not require too much programmer work having asked already.
Z0D liked the idea of User / Group type security similar to titles because Eve needed more options of security in parallel as well continuing that at the moment there are "based at", "HQ" and Others whilst there was a need for others such as Station, System, POS or for possible security levels.
TeaDaze thought the general principle was understood but that it would be up to CCP to decide how complex to go and that allowing finer grained permissions for "advanced" users while mirroring the current setup by default would be good. Z0D continued that extra categories should have been there from the start but that at the moment if a player required POS access they get access to all POS. T'Amber and Song Li agreed.
TeaDaze cautioned that care needed to be taken to ensure it isn't too complex to see what groups and people in them can do what if you start allowing nested groups.
Z0D thought the others part needed to have multiple assignable locations for rights per people / groups etc.
Helen Highwater said rather than have 59994593 different roles for variations of the same thing (take from containers in hangar 1, take from containers in hangar 1 at this station) there should just be broad permissions that can be narrowed or defined per user. Helen continued that you could have one Corp Hangar Access role where the scope of could be defined per user for example.
Alekseyev Karrde wanted a blanket option still because setting permissions for each tower hanger and each item therein would get really tired really fast. He added that as CEO he wanted to do less work to establish effective permissions, the bare minimum.
Sokratesz said that people had been asking about the ability to control (for example) hangar and POS access per system rather than all or nothing and asked how this could tie into this proposal. ElvenLord replied that the idea was to tie permissions to objects and not people directly so you could enable one User Group to "control" one object or group of objects but added it would be something for programmers to deal with.
T'Amber agreed with having masking functions to for example allow use of A-Y Hangers but not Z hanger and use B - Z POS but not A POS etc. T'Amber added that manually selecting every POS/hangar/lab would be annoying and using a masking function (as in Boolean selections) would save a lot of time.
Song Li thought the base framework was understood by everyone and that the final details are the kinds of things that discussion with CCP would bring and wanted to call the vote. TeaDaze agreed and ElvenLord called for the vote.
Passed 9 for
ElvenLord wondered if the rest of the CSM had seen the problem where lots of killmails got lost or malformed, adding it was starting to get annoying. Sokratesz wanted to add 'killmails not happening at all to the proposal. Alekseyev Karrde agreed that it happens to him all the time.
TeaDaze stated it was clearly a bug situation and wanted to confirm that people were getting nowhere with bug reports. ElvenLord said pretty much no response.
Helen Highwater suggested that in high lag situations ancillary systems were being turned off on the server and that one of the first to go seems to be killmail generation.
ElvenLord stated that lack of killmails was eve a problem for petitions and reimbursement at both player and GM level.
Alekseyev Karrde thought it was one of the most annoying things day to day in the game adding the sheer volume of mails and the diversity of things they're used for should demand CCP's attention. He also said that the data should be recorded and represented accurately most of the time and not rarely.
T'Amber wanted to include session change problems into this issue.
Sokratesz said they would not mind if CCP made the system a bit different from what it is now such as killmails being delayed for some time when the server is busy doing other things. Sok added that mails just need to be accurate not necessarily on time.
ElvenLord wanted T'Amber to clarify the session change problem to be specific. T'Amber asked if other people had seen the issue where changing systems means you don't show on the killmail. Sokratesz, ElvenLord and TeaDaze said they had. Sokratesz added that if the victim jumps, all damage done prior to session change isn't shown.
TeaDaze cautioned if the aim was to reduce the issues with killmails in high lag situations that adding system change into the mix which would require syncing the nodes would possibly make it worse.
ElvenLord said delayed mode for killmails was fine with him. Mrs Trzzbk didn't mind as long their name gets on to every single killmail ever generated and automatically posted to the GS killboard. Nobody wished to comment on that suggestion.
Song Li seemed to recall that CCP had commented that killmails were created at the moment of the ships destruction with the data currently on the server and that afterwards the data was essentially deleted, meaning that kill mails would still be produced in that way via this proposal even if not sent straight away, which would still require the server load they do now. Song continued that CCP would still be having them cut out to save processor power in high lag and wondered if the trade for killmails should be overruling lag processor support.
TeaDaze thought the killmail generation was done by a separate process which takes a snapshot as the ship is destroyed and that is why you end up with pods on killmails fitted with guns and so on. TeaDaze added that moving from one system to the other that the ship has damage recorded on it, but the server doesn't know how it got there.
T'Amber asked if there was possibly another way to generate killmails and suggested discussing it with CCP. T'Amber added that if it was a choice between killmails and server processing they would rather be able to play.
TeaDaze thought the fundamental issue was how the server holds the transient damage data and assumed that it was only held on the current node and not saved to the database. Tea added that doing so would add more Database calls which might cause more lag but was happy to talk to CCP about it. Tea finished that it wasn't something the CSM could second guess as being easy or difficult and Suggested voting to talk to CCP about buggy killmails and leave details till Iceland. T'Amber and Song Li agreed.
Alekseyev Karrde also wanted to leave the mechanics of this for CCP but that if it could be done without killing the game lag wise it would be a no brainer. He also recalled a time where killmails worked more or less OK and it wasn't a lagpocalypse so it could be done.
Z0D thought this data could be stored temporally on a separate Database and reconciled / synced at downtime to remove the heavier loads from servers used by people playing at critical times.
Song Li also thought the details would have to be discussed with CCP to ensure the actual mechanics were clear and that implementation was defined. Song also wanted to call the vote to get it discussed since CSM couldn't move forward till they had that info.
ElvenLord called for a vote.
Passed 9 for
Sokratesz stated this was a sensitive issue and that a heated discussion about it with Helen had already ensued though everything was summed up in the thread.
TeaDaze wanted to point out that shield and armour tanking are different in many many different places and that trying to align one factor ignoring the others was bad. T'Amber strongly agreed. TeaDaze continued that as long as they remain different but comparable that would be fine even if the fine details are not the same.
Helen Highwater confirmed the discussion with Sokratesz and others in the CSM Public channel and added that in the end the suggestion was a compromise where after changing sessions the bonus would remain for a grace period to allow the gang booster to arrive and keep the bonus running. Helen continued that in this way the benefits are not lost when hotdropping capitals etc. but at the other end of the scale passive tanks wouldn't be overpowered. Helen Highwater also suggested that the two ends of the shield tanking scale are different and need to be approached in different ways and that fixing capital sized tanks as per the proposal would overpower smaller ones.
Alekseyev Karrde reminded that armour doesn't naturally regen and there was no mechanic to handle it other than as-is however shield tanking does. He added that there was many ways it could be argued to balance one or the other but that the gang bonus application was a tiny and
frankly pointless way. T'Amber agreed.
ElvenLord said he didn't fly his Leviathan in combat for those reasons because after two hours of regeneration a session change wipes out 1/3 of the shield.
Sokratesz complained that currently they aren't even comparable adding it takes ages for the bonus to recharge or a lot of capacitor and time to boost it up actively. Sokratesz continued that shield ships essentially enter fights with an inherent disadvantage and the recharge bonus that Helen mentioned does not compensate for it. Sok also thought spanning it across sessions may be prone to
exploits and be difficult to implement at the programming level adding that as it is now it is unfair to shield ships, especially those that greatly depend on hitpoint buffer (HACs, BS and up)
TeaDaze liked the session compromise Helen suggested as long as it also applied to other gang bonuses and not just shield or armour. Tea also wondered if this would apply to active gang links. Helen didn't think that was needed because they take effect as soon as enabled. TeaDaze also wondered if this issue was purely down to the titan shield capacity bonus and not really related to the leadership skills. ElvenLord said it was the most visible problem on capitals and super-capitals. Sokratesz agreed that it was both bonuses but that the effect of the titan bonus is much larger and therefore has much more impact. TeaDaze wanted to check because thought the 15% shield capacity bonus from a mindlinked commander was hardly game breaking and also said the proposal didn't sit right with them suggesting that perhaps the answer was to handle the Leviathan bonus differently and move on.
Helen Highwater pointed out it was a 15% shield bonus as well as the regen bonus which worked out to a free T2 midslot shield recharger which couldn't be ignored. Sokratesz complained that the effect (advantage) of that recharge was so tiny that it wasn't worth counting unless everyone flew drakes. Helen Highwater again stated it was equivalent to a T2 shield recharger for free which was not something that could be glossed over and that it does need to be accounted for. T'Amber and TeaDaze agreed.
Sokratesz asked if the regen made up for up to 37.5% less shield hitpoints to start with, he didn't think so and so thought the recharge bonus took a long time to become an actual advantage. Helen Highwater disagreed saying even if it took a while to benefit from the new maximum Shield capacity that the extra recharge was working straight away meaning that incoming DPS has to be higher to break the tank. T'Amber agreed with Helen and TeaDaze and said the issue with caps needed to be addressed separately if it was an issue and that a vote should be made. Alekseyev Karrde also agreed with Helen.
TeaDaze pointed out that Sok was again arguing based on the Leviathan bonus which was not how 90% of shield tankers with a bonus operate. Tea suggested handling the Leviathan bonus differently such as perhaps giving half the capacity bonus to begin with.
Z0D gave his opinion that if someone has 50% shield left before bonus when the bonus is applied they should still should have 50% left such that if at 5,000 / 10,000 before bonus they would be (for example) 6,000 / 12,000 afterwards.
Sokratesz argued that the gain in regen was absolutely tiny and in situations where you were facing a lot of incoming DPS the recharge doesn't matter at all adding it was the effective hitpoints that counted. Sokratesz finished with titan or normal gang bonus it should be treated the same. Alekseyev Karrde stated that as Shields get both Hit Point and active tank bonus from their leadership buffs it was not unreasonable to have a drawback when talking huge titan inflated numbers.
ElvenLord asked if the proposal should be to add a grace period for all mods/skills when doing session change for shield amount bonus. Sokratesz pointed out that a grace period on session change won't help if you are logging in quickly to jump into a fight. ElvenLord then decided that there was no other option than to vote on the proposal as it stood in the wiki and called a vote.
Failed, 7 against, 2 for (Z0D, Sokratesz)
TeaDaze wondered if this proposal was covering items already raised and passed by the CSM. Z0D answered that he had not seen CCP do anything about it and the issue had lagged for years yet nothing has been done. Z0D added that it was something for CCP to answer as to why they have done nothing about it.
Alekseyev Karrde said that while not a Factional Warfare expert if the proposal was accurate that it was outrageous. Z0D suggested checking the forums about exploits where there was evidence that it has been going on forever even after having exploits demonstrated in front of CCP during previous CSM meetings.
ElvenLord answered TeaDaze saying that some exploits and issues have been mentioned but that this topic covers CCPs attitude/dealings with Factional Warfare not specific problems in FW. Z0D agreed.
TeaDaze didn't think much discussion was needed about this for now and that CSM should talk to CCP about it. Tea also suggested linking this proposal to the Factional Warfare standing exploit topic already passed ( http://wiki.eveonline.com/wiki/FW_Complex_NPCs_and_Standings_%
28CSM%29 ). ElvenLord agreed those could be merged into one topic for CCP discussion.
Alekseyev Karrde thought that on the topic of merging topics that this issue was part of the larger issue of CCP's attitude towards exploits and that was hindering customer service. He wanted to make sure CSM got a chance to talk to them about their internal documentation and not
just Factional Warfare. TeaDaze did not want the issue to become too broad or the Factional Warfare angle might get lost or delayed.
Z0D suggested an issue with customer service in general Factional Warfare being one of the many serious issues.
ElvenLord agreed that Factional Warfare might get lost due to CCP's attention spam not being big and called for a vote.
Passed 9 for
ElvenLord thought this was straightforward.
Z0D said that this was in line with the previous topic, but also covered promises made and not implemented and that even many expansion packs later nothing was being done. He stated that added features were not being finished due to CCP moving to something new and not coming back to the unfinished items leaving them as is.
Alekseyev Karrde thought the proposed permanent team was a bit strong asking if any other game styles have such a resource. He added that perhaps a dedicated team targeted till at least the next major expansion would be a little more realistic, not to mention more focused on deliverables. TeaDaze agreed.
Helen Highwater thought there was lots of editorialising in the proposal and not many actual facts to go on. Helen suggested holding the proposal until it was better fleshed out.
Sokratesz had to go AFK so confirmed T'Amber would take their vote.
ElvenLord asked what facts would be required. He suggested that Factional Warfare has not been touched since deployment and that not many fixes were done to it TeaDaze was happy to take this as a conversation topic as is and discuss it with the relevant team at CCP. Z0D agreed.
ElvenLord stated this was one of the historical problems with CCP and that it had been brought up many times via CSM and still kinda ignored. He linked an example of unfinished items ( http://evajobse.net/csmwiki/index.php/Unfinished_Expansions ).
Helen Highwater suggested the issues were raised rather than just state it was broken and incomplete which doesn't really move the discussion along. Helen added that they could even be in the same issue if they all deal with the same area of gameplay but that at the moment there was
nothing concrete in the proposal to take forward.
TeaDaze thought this would fit into the idea that CCP had to make the CSM look at more big picture stuff. Tea continued that CSM want some answers on the current state of Factional Warfare development because it doesn't seem to be being addressed, at least not publicly.
T'Amber suggested a vote to take it to the meeting and to there find out why it seems like Faction Warfare was on the back-burner, if it was at all. T'Amber also wondered if there might be something CSM were missing and that more concrete examples of the issues might help.
ElvenLord called for a vote.
Passed 7 for 1 against (Helen Highwater)
(Editors note: Zastrow was classed as AFK having not voted on the previous two issues and there were not enough alternates this time to make 9 votes, however the minimum for an issue to be valid is 7 votes)
TeaDaze hoped the updated proposal was clear and pointed out that selling accounts will happen one way or another and supporting a secure way was a good thing. Z0D and Song Li agreed.
ElvenLord asked if anyone wanted to add to the discussion since it was covered in the last meeting. T'Amber said that having traded characters that the proposal covered everything that was discussed.
Alekseyev Karrde was glad this was being addressed and thought for the most part it was solid. However he had an issue with the IP address part because dynamically assigned IPs or people logging in from multiple computers or locations would mess that up. TeaDaze replied that the issue with dynamic IP addresses were well understood and that was why IP address locking would be optional and for advanced users only. T'Amber was happy for it to be optional.
Helen Highwater stated they log in from three or four different locations all with different carriers.
Z0D thought more security implementations should be there to protect users such as for example locking characters properly and requiring credit card security to have them unlocked. TeaDaze countered that they would be locked by default and would require a positive confirmation. Tea also added that some people use GTCs so credit card couldn't be relied on.
Zastrow apologised and returned to the meeting at this point after a minor emergency.
TeaDaze added that people on dynamic accounts could leave the feature turned off. Alekseyev Karrde thought it wasn't optional on the proposal and suggested that was made clearer. TeaDaze stated the section was "Locking account access to known IP addresses (or range of) for advanced users only" and that maybe "for advanced users only" wasn't clear enough and agreed to change the wording.
T'Amber offered to find Chribba's original post obout IP masking which covered most of this. TeaDaze provided the link and added it to the wiki article ( http://www.eveonline.com/ingameboard.asp?a=topic&threadID=781256&page=1#1 )
ElvenLord called for a vote.
Passed 9 for
Song Li confirmed that Ninja salvaging was already a CCP recognised trade and that this proposal makes sense now there is the ability to open your wrecks for all to loot.
Alekseyev Karrde didn't think the second Con in the proposal was a big deal since you could filter the wrecks of the scan results. He thought the biggest issue to look at would be PVP applications/abuse/balance but on the whole he liked it.
Helen Highwater didn't want to give wrecks special protection as per the proposal when nothing else gets masked any more.
Sokratesz rejoined the meeting.
TeaDaze didn't like the the idea of allowing core probes as it could in theory allow scanning out combat ships via wrecks and instead suggested the proposal be amended to require combat probes.
Z0D agreed with the proposal adding that many people who run missions just kill and don't loot.
ElvenLord agreed that the proposal should require combat probes. Song Li agreed and offered to make the change in the wiki.
ElvenLord called for a vote.
Amended proposal Passed 8 for 1 against (Mrs Trzzbk)
ElvenLord confirmed that the next meeting was due on 24th and was meant to prioritize the issues list for the Iceland meeting however agreed that a few new issues could be added. ElvenLord also stated he would try to make a preliminary list by Wednesday so priorities could start to be worked on.
TeaDaze agreed to covering a few new issues raised over the last week, specifically the one for T3 refitting at Pos / Carrier. Song Li agreed with allowing just a few new items.
Zastrow wanted to set aside time to just talk about dominion and the state of the game in general. ElvenLord confirmed he wanted to add those to the meeting agenda separately from issues list.
Sokratesz confirmed absence for the meeting on the 24th and that his new proposal was basically a cry to CCP that something needs to be done about lag but that a few GM's already confirmed that they are 'on it', for what that's worth. TeaDaze linked the issue Sok mentioned (
T'Amber asked if new or amended issues could still be brought up for the next meeting. ElvenLord agreed but added there were still 2 issues that had been set aside for rework and that he would like to see those done by next week.
Alekseyev Karrde wanted a commitment to try to cram as much as possible into the Iceland meeting and added that this CSM has covered a lot of key issues.
Sokratesz noticed an issue was missing from this meeting suggesting it was ( http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1234453 ) because it didn't have a wiki article. Sokratesz promised to make a wiki article and urged people to check it out and discuss on the 24th if possible.
There was some more discussion about topics but TeaDaze stated they didn't need to be discussed now and also suggested a limit of 5 or less topics for the next meeting to allow time for the other pre-Iceland stuff.
The next meeting was set for Jan 24th at 14:00 Eve time.
Meeting ended at 17:27