CSM meeting minutes 3.005

From Backstage Lore Wiki
Jump to: navigation, search


Meeting Minutes: 2009/07/19

Present

Dierdra Vaal, Avalloc, Erik Finnegan, Larkonis Trassler, Mazzilliu, Meissa Anunthiel, Zastrow J, Omber Zombie, Issler Dainze

Apologies

Vuk Lau

Discussion



Dierdra said he had received notification that the CSM emails should be working, however the page to access it seems to still be failing.
Omber Zombie confirmed that he had spoken to CCP Diagoras who confirmed that despite the frontend being broken, the mail access should work correctly.


Account security proposal (maz)


Erik stated he was fine with optional measures and discussing the issue, despite his belief that less frequent changes with better passwords to be better.
Issler said the CCP does not have worse account security than other MMOs and she would not support the idea.
Mazzilliu thought this was still relevant because people lose accounts in stupid ways.
Omber Zombie agreed with the proposal as long as it's optional.
Meissa objected to third party software being installed on his computer, password change reminders and others are not a problem. He said that most compromising happened due to user stupidity that no amount of software will solve.
Zastrow thought it not being a good business policy to make people jump through extra hoops to log in the game.
Mazzilliu agreed, and said that's why everything mentionned is optional.
Avalloc would love a token option. He hoped that one would be able to bind multiple accounts to one lest people who "share accounts" be upset.
Mazz answered that people sharing accounts don't have to use the token.
Meissa put his foot in his mouth and made a comment about mandatory password change that was not in the proposal.
Issler asked if mazz had any data to support the idea it affects a significant number of players.
Mazz said she didn't, but CCP issues warning/devblogs every once in a while, so she assumes it's a problem.
Voting followed.
Motion passed 8 for, 1 against (Issler Dainze)


stuff about character transfers and problems caused by it (maz)


Meissa asked wether it isn't already mandatory to publish a forum thread for every character sale.
Mazz answered it isn't.
DV thought removing all info automatically goes too far and thought asking the user to erase it himself to be better. As well, he prefered this to be optional.
Omber Zombie and Erik agreed with the optionality.
Mazz agreed the mechanics of the change should be worked out by CCP but people aren't notified that the new owners will see petitions
Issler thought there were better things for CCP to spend time on and as such would get no support from her.
Meissa put his other foot in his mouth and made a comment about erasing character history that wasn't in the proposal either. With no space or foot left, he decided to read the next proposals more carefully.
Mazzilliu replied that it was adding another entry in the character info, or requiring a certain NPC corp used only for such purpose.
Omber Zombie reminded that meetings are to discuss the issues, prioritisation is done later.
Issler stated that with the exception of petitions, players can already delete all other information themselves.
Erik and Mazz said petitions could already be deleted by the owner.
Issler thought this was hence a non-issue.
Erik noted that personal notes on other pilot infos are not easily removable.
Voting followed
Motion passed 8 for 1 against (Issler Dainze)


Make guns continue firing at previous target after reload (maz)


Omber Zombie understood, but thought removing one of the few benefits of T1 crystals [over T2 crystals] to be a bit weird.
Mazz said she was looking at it from the perspective of benefit of being amarr vs not being amarr, as lag causes a de-facto reduction in DPS for everyone not amarr.
Omber Zombie answered it was a tactical choice, heading into a fleet fight to choose a normal setup or a "high lag setup".
Larkonis said that considering that T2/faction crystals last practically forever, Oz's point about reloading them is a bit moot.
Zastrow liked the idea because he's lazy as hell and doesn't like reactivating his guns. He noted however that in high lag situations, cycling the guns was more of an issue than reloading.
Erik wasn't sure to understand what were the negative side effects of having guns continuing fire after reload, but high lag should not be a reason to maintain any mechanics.
Larkonis said it removes a bit of the management involved in things, but the benefits would outweigh the downsides, especially for people using multiple caps to shoot POSes.
Erik asked wether the proposal applied to other modules such as cap boosters and other mid slot modules.
Mazz answered the proposal didn't apply to those modules.
Larkonis suggested making it optional in the contextual menu à la "auto reload".
Erik, Mazzilliu and Dierdra Vaal thought that a good idea.
Voting followed.
Motion passed 8 for, 1 against (Omber Zombie)


container idea (maz)


Erik thought cans are intended as cargo buffs, and the division of cargo space in smaller segments throught it was intended. He also though the hassle implied in filling/clearing them adds "role play". He wants to keep things as they are.
Mazz said using cans to expand cargo space seems more like an exploit to her. And freighter pilots currently have no way to create smaller subdivisions without using courrier missions as placeholders.
Omber Zombie wondered if the issue wasn't made void by the introduction of multiple cargoholds. He said a random buff to all cargo holds is unnecessary. He would however be happy to remove the cargo buff one gets from cans.
Mazz asked for clarification as to what the devblog stated.
Omber Zombie said it was the ability to have multiple dedicated bays for fuel, ammo, etc.
Mazz said this was thus the perfect time to raise the issue since they are making the change anyway.
Omber Zombie disagreed, as this proposal was asking for a cargo buff.
Erik said that if the proposal aimed at making partitioning easier, divisioning space with hangar divisions like the orca has would be sufficient.
Mazz said it wasn't a cargo buff, more a convenience buff as all-purpose cargo is more convenient than dedicated separate holds.
Meissa asked how mazz could consider extended space through cans to be an exploit as the devs had to state that the inside of cans was bigger than the outside. He also said cans were extra hassle for which you get extra benefit in the form of additional cargo space. Nobody forces anyone to use cans if they don't want to deal with the hassle. He also didn't see the point of giving everyone 30% extra cargo without any extra effort/cost.
Erik agreed.
Mazz said it wasn't classified as an exploit, but was a nonsensical game mechanic.
Meissa answered it wasn't nonsensical as one got extra hassle and extra capacity as a result. Smaller freight containers would be an answer to the freight container being too large, not this.
Mazz said POS fueler have to use the cans to reduce their trips by 30%
Meissa answered POS fuelers use JFs.
Omber Zombie agreed with Meissa.
Mazzilliu agreed with the POS fueler aspect but not as far as it applied to, say, an iteron. Stating it makes no sense and is annoying for no good reason.
Meissa answered it's annoying for a extra space, and that a lot of aspects of the game were of the form "extra hassle, extra benefit".
Mazz asked what it contributed to the game, adding she doesn't want to play an annoying game.
Meissa answered the contribution was extra space.
Omber Zombie said that basing a wholesale cargo buff based on people fuelling POSes haveing hassle to be ridiculous.
Voting followed
Motion failed 5 against, 3 for (Mazzilliu, Zastrow and Avalloc). Larkonis DC'ed his vote didn't get registered.


Station dock radii (Zastrow)


Larkonis pointed out that many empire stations have the same issue, and being in 0.0, one should be doubly careful. More opportunities for station games is not a good thing.
Zastrow said stations should have windows, but until they do one should at least be able to dock before the session change runs out. He added he doesn't want huge dock radii and that people should still be able to be bumped off.
Omber Zombie agreed dock radius shouldn't be an issue, but questioned the dock/undock practice instead of undocking outside dock range at a random point within x km.
Zastrow answered that randomness would make bubbling undock harder.
Erik didn't have any opinion on undocking inside dock radius or outside, but agree there should be uniformity.
Dierdra agreed.
Avalloc said that station games in 0.0 are to the advantage of the owner of the station. He dismissed the "get a scout" argument as being irrelevant as people can have a logon or dictor trap.
Omber stated the "in or out" question was relevant as the proposed solution was to change all outposts [exit ports] to be within docking range.
Meissa didn't like the idea of requiring scouts, as it favours alts. He thought station windows to be hard to implement, although an overview-style "radar" could be easier. He expressed his support of "all in" until such a tool be developed, and either way the discussion of this matter is a good idea.
Larkonis said if uniformity was applied to outposts, empire dwellers will want it applied to all stations.
Voting followed.
Motion passed 6 for, 3 against (Omber Zombie, Issler Dainze, Larkonis)


Looting from wreck you didn't create = looter flagged to (wreck) killer in Empire (Avalloc)


Dierdra pointed out that this was brought up during CSM 1 and CCP declined it. He asked how Avalloc thought he could convince them this time.
Avalloc stated that the players were still unhappy about it.
Erik didn't see why killing a ship changes the wreck owner. He also opposed the increased reward for piracy it would generate.
Avalloc asked why Erik thought it'd increase rewards for piracy.
Erik answered it had to do with people who didn't participate in the killing stealing from the wreck.
Larkonis said it was something a lot of the player base wants, it being a huge problem in empire wars, and he would like to know why CCP wouldn't want to implement this. He added people would still be able to "steal" from wrecks, but they'd have to be more careful.
Omber Zombie said CCP prefered the current implementation, and that the CSM was free to find an alternate not already suggested (as this proposal was)
Voting started
Motion passed 5 for, 4 against (Omber Zombie, Meissa Anunthiel, Issler Dainze, Erik Finnegan)


Fix rockets (DV)


Omber Zombie asked why going for explosion velocity rather than base damage increase.
Dierdra answered that increasing raw damage might make them overpowered against stationary targets. The objective of the proposal is to make them more valid against their intended targets (small quick ships).
Erik agreed.
Voting started.
Motion passed unanimously.


Corp traitors and neutral support (Erik)


Dierdra said that neutral RR-ing in cases of malicious in-corp pvp seems Extremely rare and as such probably not worth the development effort.
Erik answered he wasn't aware of the exact numbers, but that was up to CCP to investigate.
Larkonis agreed with Dierdra and further pointed out it could be used to grief neutrals.
Erik asked details about said griefing process.
Larkonis explained some of his associates got people CONCORDOKEN'ED by sitting outside stations and saying "hi brosef, i can't afford to repair my ship, can you rep me" and shooting one of them, causing a GCC reaction chain.
Erik said his proposal didn't involve CONCORD.
Larkonis replied the griefing could be done by corp members.
Dierdra agreed this could be used to make neutrals flashy to a corp.
Erik answered this situation would give the victims a choice the current mechanics don't.
Larkonis stated that if someone was setting up to kill a corpmate, he's likely to be well prepared anyway. He furhter stated (with some more affection for the word "brosef") that it could incurr more losses to the corp as they would get flagged to neutrals in addition to the rebelious corpmate.
Voting followed.
Motion failed 8 against, 1 for (Erik)


Fix to logoffski (Lark)


Dierdra asked if he was correct in reading 4 different solutions in the proposal, and said he didn't like the 15 minutes lockout, but the other solutions sounded reasonable.
Larkonis answered that there were inded 4, although not all mutually exclusive.
Mazz asked what happens when someone logs of at a POS that is destroyed before the person logs back in.
Larkonis suggested not logging off at a POS in danger of dying soon.
Avalloc asked if the suggestion is to stop the ability to change the arrival point after a disconnect.
Larkonis answered that it was.
Avalloc said it would be a problem in Mazz' scenario and asked if this was an empire or 0.0 problem
Larkonis answered it was both. Adding that if one were to jump into a bubble and log out, he wouldn't decloak immediately, but after the 60 seconds, which is incidentally the time the ship stays in space.
Avalloc said if a POS was mistimed, it could be gone before the people logged off at it get a chance to get to safety.
Larkonis agreed, but that this was still using game mechanics to avoid getting one's ship killed, that losing a ship due to a POS changing hands was more the responsibility of the person timing it badly.
Voting followed.
Motion passed 5 for, 4 against (Mazzilliu, Issler and Avalloc, Zastrow)


Show info button with chat invite (Avalloc)


Larkonis didn't like going through the effort of searching the name of random plebians who convo'ed him, and expressed support for this issue enhancing his gameplay experience.
Voting followed
Motion passed unanimously


BPO locking changes (DV)


Omber Zombie liked the idea of making locking less painful, but without corp hangar locking, there would be no way to tell who took what.
Dierdra answered this would be useful for moving BPOs.
Omber Zombie said allowing mass unlock without a way to track means something moved may never reappear.
Dierdra agreed it would be less secure, but shareholders would have to vote to disable locking, thereby voting to give the control away.
Erik suggested allowing the unlocking vote to be done on a whole set instead of individual ones.
Dierdra agreed this was part of the issue.
Meissa said the setting as described couldn't be implemented without being made useless (because temporary due to trades movement in cargoholds etc.) if the setting was tied to the BPOs, and useless if it was tied to the corp because it can't leave the hangar without losing the setting.
Dierdra said the option would be tied to the corp as explained in the wiki.
Omber Zombie said the problem was that selecting multiple items to [un]lock generates votes for every individual BPO. He agreed with Erik's suggestion of batch voting without messing with roles.
Dierdra said it was implied in the issue.
Omber disagreed.
Dierdra agreed to clarify the batch voting part
Omber Zombie said that the proposal was thus too complex for the needs. Repeating his statement that batch locking was all that was needed.
Voting followed.
Motion passed 6 for, 3 against( Meissa, Issler, Omber)
Meissa, Issler and Omber Zombie voted no on the basis that the issue was too complex and should be reformulated as simply "batch [un]locking"


RMT Trading & CCP's Policy on it - a request for a discussion with CCP (Oz)


Dierdra asked why specifically Oz wants to bring this up.
Omber replied the issue came with the recent EBank saga where Ricdic had one of his account banned but none of his other accounts, and that this was CCP's current policy.
Issler asked if CCP's RMT policy was currently unclear.
Omber Zombie said it wasn't, that this was a general discussion on the issue.
Omber and Issler discussed a bit about the issue of banning accounts belonging to the same person than the account banned for RMT'ing.
Erik said this could also be used to discuss more means to discourage RMT.
Voting followed.
Motion passed 8 for, 0 against.

Other Business


Dierdra reminded everyone to send their Q&A questions.
Dierdra also said he would like people to send a list of issues discussed in previous CSM meetings to be discussed (again) with CCP, to give CCP time to prepare answers.
Omber Zombie said he had already pointed out that these things were already automatically on the agenda of the CSM-CCP meeting.
Next meeting was agreed to be August 2nd.

Personal tools
Namespaces

Variants
Actions
Navigation
Tools