Yesterday CCP announced the first wave of planned changes to address stagnation in nullsec. There is a 220 page (and growing) threadnaught in the EVE-O forums. Whilst CCP Greyscale has to dedicate the time to read all the posts in that thread I have no desire to. Instead I restricted myself to dev posts answering valid and useful points and then I did a random sample of a handful of pages to get a more general feel for how people are reacting. Not scientific but who cares. The mood of the posters is not entirely predictable, however.
Of course there are the posts from idiots who announce they will stop playing (hint: bye bye). There are the other posts from people who say nullsec is impossible to handle without caps jumping (hint: caps haven't always been in EVE). There have been a fair few posts from people who totally don't understand the point of this change and want to know how their alliance is meant to rapidly defend territory spread far and wide across New Eden (hint: you don't). Yes it makes force projection harder but that is exactly the bloody point. Space is big yet in New Eden it has been shrunk so much by jump drives that large alliances think nothing of crossing the whole map for a fight then back home for kippers.
The other half of the posts seem to recognise this shake up for the good thing it is. Force projection for the largest alliances will be reduced. People will have to think carefully about where they live as their 'big blue doughnut' won't be as effective any more. What's the point of being in a large coalition if they can't really help you? Maybe it's better to have neutrals to shoot in close proximity to home? Hopefully super-massive alliances start to shrink back on themselves and new alliances are able to get a foothold in nullsec.
There have been valid points about Black Ops ships receiving the same penalty as Carriers and Supers. Black Ops should be fast in and out guerilla style ships as opposed to caps which are meant to be deployed in more protracted battles. Maybe CCP should link jump fatigue to ship mass? There has also been the valid point about new characters joining corps deep in nullsec and how they join their new space friends out there. These issues can all be dealt with for the good of EVE. More issues will no doubt rear their heads but either the players will figure out clever new ways to handle those or CCP will make more balancing passes if it is
deemed necessary.
With the last expansion wormholes were nerfed with what is possibly the exact opposite of the proposed changes to nullsec. We have been forced into massively large chains of systems, all of which we have to scan and map in order to find people to shoot at or go run sleeper sites to make ISK when no targets are around. We have been forced into larger space and had our ability to control our environment reduced with the hole rolling nerf. We have survived by adapting and figuring out how to do so has been more engaging than much of what I'd been doing for some time prior to these changes. Sensible people play games to be challenged. I am fairly confident that the existing nullsec alliances will adapt equally well. Some will fall by the wayside and make space for new, more enduring corps to make their mark on New Eden. I look forward to watching how these changes pan out, but in the meantime I'm also enjoying the tasty nullbear tears.
Showing posts with label mechanics. Show all posts
Showing posts with label mechanics. Show all posts
2 October 2014
7 May 2014
API NPC Changes
I rarely venture into the eve-o forums. I find them to be a wasteland of bitterness which sucks the soul and removes my desire to play EVE. The only time I go there is when some other, tougher soul tells me there is something worth reading. Right now the 'something worth reading' is a threadnaught initiated by CCP SoxFoxFour on an intended change to the data available to pull from the EVE API.
I see there being two problems here which are not entirely unrelated. Problem one is the existence of this information in the API which shouldn't be there. The people pointing out that wormholes are meant to be mysterious areas with no intel not gathered with your own eyes are 100% correct. We already had wormhole system jumps removed many moons ago for this very reason. The NPC kill data should also have been removed at that point. We should not know anything about wormholes which wasn't learnt from d-scan or other in-game intel gathering means. If my corp scans out a long chain then it is up to us to station scouts in each link to wait for activity, or actually patrol the chain to find someone to shoot. The key concept here is we need to be active to find things.
The mildly related second problem was introduced with the Odyssey expansion. In Odyssey we were lumped with the wonderful new scanner. No more did we have to actively probe systems to see what was out there. No more did we have to proactively scan our own systems during operations to see if any new signatures were present in our home system or where ever we happened to be operating. No more did we have to be surprised when ships appeared from nowhere to gank us when we thought we have all our exits covered. See where I'm going with this? Ostensibly the reason for this change was to bring more people into exploration. While a laudably intention we rarely find anyone else in our chains at all. When we do we have to be really quick to catch them if they are running sites, or they have to be really dumb and not notice the new signature auto-populate in their signature scanner. The balance of risk has shifted too far and the new proposal shifts this even further in favour of carebears. I'm sure this in unintended by CCP...
I agree with both sides but the fix is not to do nothing. I fully support removing this information from the API. Wormholes are big spaces where intel comes at a premium. You should have to work hard to get your kills. The first part is scanning, the second part is keeping the intel current, the final part is the kill. The real problem here happened with Odyssey and should be removed. Get rid of the signature scanner autopopulating. Force people running sites to have probes in the air actively scanning for new sigs. Take us back to pre-Odyssey scanning. If passive intel for the hunter is removed then so too should passive intel for the prey.
"as a heads up as soon as I can find the time I will be removing WH systems map/kills endpoint. This is data that exists in the API but not the client and is incredibly powerful. As with everything I am open to discussing this, but I will admit that you will have a damn hard time convincing me of not doing it."The resulting thread which followed this was at 23 pages when I last looked with a fairly even split of people who welcome the change and people who absolutely hate the idea of this information going away. Those in favour cite the reason that wormholes exist is to be mysterious with no way of knowing what is out there, particularly not from external tools pulling from the API. Those against raise the point that it is already hard to find people in wormholes and this information is the only way they can find people to kill in a long, pre-scanned chain.
I see there being two problems here which are not entirely unrelated. Problem one is the existence of this information in the API which shouldn't be there. The people pointing out that wormholes are meant to be mysterious areas with no intel not gathered with your own eyes are 100% correct. We already had wormhole system jumps removed many moons ago for this very reason. The NPC kill data should also have been removed at that point. We should not know anything about wormholes which wasn't learnt from d-scan or other in-game intel gathering means. If my corp scans out a long chain then it is up to us to station scouts in each link to wait for activity, or actually patrol the chain to find someone to shoot. The key concept here is we need to be active to find things.
The mildly related second problem was introduced with the Odyssey expansion. In Odyssey we were lumped with the wonderful new scanner. No more did we have to actively probe systems to see what was out there. No more did we have to proactively scan our own systems during operations to see if any new signatures were present in our home system or where ever we happened to be operating. No more did we have to be surprised when ships appeared from nowhere to gank us when we thought we have all our exits covered. See where I'm going with this? Ostensibly the reason for this change was to bring more people into exploration. While a laudably intention we rarely find anyone else in our chains at all. When we do we have to be really quick to catch them if they are running sites, or they have to be really dumb and not notice the new signature auto-populate in their signature scanner. The balance of risk has shifted too far and the new proposal shifts this even further in favour of carebears. I'm sure this in unintended by CCP...
I agree with both sides but the fix is not to do nothing. I fully support removing this information from the API. Wormholes are big spaces where intel comes at a premium. You should have to work hard to get your kills. The first part is scanning, the second part is keeping the intel current, the final part is the kill. The real problem here happened with Odyssey and should be removed. Get rid of the signature scanner autopopulating. Force people running sites to have probes in the air actively scanning for new sigs. Take us back to pre-Odyssey scanning. If passive intel for the hunter is removed then so too should passive intel for the prey.
30 November 2012
Goodbye Annoying Hangers
I read about the impending demise of corporate hangers in ship ages ago, so I was somewhat surprised to see a devblog only just appearing now. CCP tell us they are making this change to remove more unnecessary complexity from the system, which is something I fully support. As an added bonus, as I sometimes move stuff around in an Orca, I really like this change.
I never understood the reasons behind splitting up the Orca into so many different compartments when the Orca pilot is able to do what he wants with the contents of any of them. For me it has only ever meant I look through several tabs before finding what I'm actually looking for. Whenever I've dealt with accessing other peoples' Orcas they generally tell me what I'm looking for is 'probably in tab X but just rake around'.
For the few cases where access restrictions are required CCP have put more cargo containers sizes into New Eden. An Orca corporate hanger space is 40,000 m3 and CCP have conveniently added 10,000 m3 and 5,000 m3 containers. If you do want to restrict access simply put in three of the 10k m3 containers and one 5k m3 container to hold everything in. Doing it this way leaves 5k m3 of space where you can move stuff you want people to access. Simples.
Now, dear CCP, there are a handful of other places the breakdown into corporate hanger tabs needs removed. Whilst these corp tabs are essential in many POS modules, there are others where they are not needed. Eliminate these from mobile laboratories and their ilk and suddenly it becomes possible for alliance members to use labs for copying or invention. Eliminate them from other POS modules and suddenly reverse engineering and even manufacturing could be opened up.
If it was possible to remove the corp hangers from the Orca it could just be as doable to remove them from a handful more places.
I never understood the reasons behind splitting up the Orca into so many different compartments when the Orca pilot is able to do what he wants with the contents of any of them. For me it has only ever meant I look through several tabs before finding what I'm actually looking for. Whenever I've dealt with accessing other peoples' Orcas they generally tell me what I'm looking for is 'probably in tab X but just rake around'.
For the few cases where access restrictions are required CCP have put more cargo containers sizes into New Eden. An Orca corporate hanger space is 40,000 m3 and CCP have conveniently added 10,000 m3 and 5,000 m3 containers. If you do want to restrict access simply put in three of the 10k m3 containers and one 5k m3 container to hold everything in. Doing it this way leaves 5k m3 of space where you can move stuff you want people to access. Simples.
Now, dear CCP, there are a handful of other places the breakdown into corporate hanger tabs needs removed. Whilst these corp tabs are essential in many POS modules, there are others where they are not needed. Eliminate these from mobile laboratories and their ilk and suddenly it becomes possible for alliance members to use labs for copying or invention. Eliminate them from other POS modules and suddenly reverse engineering and even manufacturing could be opened up.
If it was possible to remove the corp hangers from the Orca it could just be as doable to remove them from a handful more places.
16 May 2012
Stealing POSs
It's an accepted defence mechanism in wormhole space to anchor POSs at all the moons in your home system. Obviously this is a more appealing defence in systems with a small number of moons, but even in systems with 20 moons it's still a viable defence. At the risk of stating the obvious, the defence aspect is that anyone wanting to obtain a foothold in your wormhole system would first have to blow up an offline POS before they could anchor their own.
This is a sucky situation to have in EVE and is a result of the game mechanics not providing a mechanism by which to unanchor POSs belonging to others. This is a topic that comes up from time to time in my corp and my answer is always the same: It should be possible to using hacking modules to force an offline POS into an unanchored state. This could be either with the Codebreaker I and II modules or with a brand new module and/or skill.
Personally I would go with a requirement of a Codebreaker II and a new skill of Advanced Hacking to trigger the offlining process. There should be some alert provided to the POS owners in order to allow them to arrange a defensive fleet. There should also be a longer timescale for the unanchoring following a successful hack attack compared to the owner unanchoring the tower. Maybe a base unanchoring time of 10 hours with a bonus of 1 hour reduction per skill level in Advanced Hacking.
Such an attack should be viable in all securities of space. It would be comparable to stealing from a jetcan or looting someone else's wreck with the applicable shootable state persistent for the entire time of the unanchoring process. Cancelling the unanchoring should not be possible by any party.
The resulting situation would allow people to make ISK salvaging abandoned POSs without requiring wardecs in hisec. This would also free up many moons which are currently 'reserved' by people who may not even play any more. The defensive aspect becomes less appealing in wormholes but not entirely gone, just more risky. I can't see any downside to this plan. Can you?
This is a sucky situation to have in EVE and is a result of the game mechanics not providing a mechanism by which to unanchor POSs belonging to others. This is a topic that comes up from time to time in my corp and my answer is always the same: It should be possible to using hacking modules to force an offline POS into an unanchored state. This could be either with the Codebreaker I and II modules or with a brand new module and/or skill.
Personally I would go with a requirement of a Codebreaker II and a new skill of Advanced Hacking to trigger the offlining process. There should be some alert provided to the POS owners in order to allow them to arrange a defensive fleet. There should also be a longer timescale for the unanchoring following a successful hack attack compared to the owner unanchoring the tower. Maybe a base unanchoring time of 10 hours with a bonus of 1 hour reduction per skill level in Advanced Hacking.
Such an attack should be viable in all securities of space. It would be comparable to stealing from a jetcan or looting someone else's wreck with the applicable shootable state persistent for the entire time of the unanchoring process. Cancelling the unanchoring should not be possible by any party.
The resulting situation would allow people to make ISK salvaging abandoned POSs without requiring wardecs in hisec. This would also free up many moons which are currently 'reserved' by people who may not even play any more. The defensive aspect becomes less appealing in wormholes but not entirely gone, just more risky. I can't see any downside to this plan. Can you?
25 January 2012
Random Rats
If there is one thing that mystifies me, it is the incredible predictability with which Sleepers in an anomoly or signature will attack. This is not an unusual think to encounter around New Eden, but the increased ferocity with which Sleepers organise themselves would seem to lend itself nicely to some unpredictability in the tactics them employ.
To illustrate, if I find myself in a class two wormhole system running a Perimeter Checkpoint I know I will find a couple of sentry guns, a couple of cruisers and a couple of frigates. I also know killing the final cruiser will result in reinforcements arriving. I also know the reinforcements will be two classes of cruiser and which class will be the trigger.
It seems to me there is something artificial about this situation. I would have expected a more random variability in the composition of sleeper fleets and arrival times of reinforcements. Don't get me wrong, this predictability is great from a capsuleer point of view. As long as I am able to withstand the onslaught of damage coming from the initial forces, I have the information to control the field. Life is good.
But still, it almost seems like the attacks follow some predetermined template and not any form of sentient logic and intellect which is capable of analysis and learning.
To illustrate, if I find myself in a class two wormhole system running a Perimeter Checkpoint I know I will find a couple of sentry guns, a couple of cruisers and a couple of frigates. I also know killing the final cruiser will result in reinforcements arriving. I also know the reinforcements will be two classes of cruiser and which class will be the trigger.
It seems to me there is something artificial about this situation. I would have expected a more random variability in the composition of sleeper fleets and arrival times of reinforcements. Don't get me wrong, this predictability is great from a capsuleer point of view. As long as I am able to withstand the onslaught of damage coming from the initial forces, I have the information to control the field. Life is good.
But still, it almost seems like the attacks follow some predetermined template and not any form of sentient logic and intellect which is capable of analysis and learning.
23 January 2012
Wormhole Stabilisers
So the CSM think wormhole stabilisers should be added to the game to make invading wormhole systems easier? Rather than follow my instinct to jump up and down and complain about this being a terrible idea I decided to think how this should actually work. This thinking lead to a discussion with my friend splatus over at A journey through the mind. The resulting thoughts were something like this.
Stabilising Effect
To create a stabilising effect there should be a requirement for a presence at both the entry and exit points of the wormhole. The idea being to create awareness from anyone watching d-scan that a stabilisation effort was in operation. This creates a flash point for conflict if so desired.
Achieving the effect would involve anchoring and bringing online a destroyable structure on one side of the wormhole. The time required to bring this online should not be particularly long, say three minutes. This structure then enables the other side of the wormhole to be targeted by one or more of a new high-slot ship module. It is this module which provides the actual stabilisation effect.
The stabilisation effect would be something similar to the vamp modules used to drain cap from ships. In this instance it would be draining 'mass input' from the wormhole at a set rate. Applying additional stabilisation modules to a single wormhole would increase the rate mass input was drained from the wormhole but should be subject to similar diminishing returns as stacking modules in a ship. Basically this creates an increase in the maximum mass which can travel through a wormhole, but beyond the initial mass limits there will be a time-based 'repair' effect which needs to be taken into account. Should there be a point where the total mass traversed through the hole minus the 'repair' effect is greater than the initial maximum mass supported by the wormhole then the wormhole will close.
The time a wormhole can stay open should not be increase. Possibly the stabilisation effect should have a side-effect of reducing wormhole lifetime. It should never be possible to hold a wormhole open indefinitely. Finally, when a wormhole eventually closes, the anchorable structure will be destroyed unless already removed.
Destabilising Effect
If we are to have a ship module and anchorable which can increase the stability of a wormhole then there should also be a sister module which has the opposite effect. Currently a wormhole corp will collapse a wormhole by running calculations on a spreadsheet while jumping plate-fit battleships or Orcas through. Having a module to simplify this task would be a massive improvement in the game experience while not particularly changing the actual dynamic involved.
As with the stabiliser effect, the destabiliser should be a two part process. Part one is anchoring and bringing online the structure on one side of the wormhole. This could even be the same anchorable used in the stabilising effect to keep outside parties guessing if the wormhole is being closed or held open. Part two is running one or more of another new high-slot ship module. This time the effect is to inject mass to the wormhole. Think shield transfer this time. Again there should be a stacking penalty to prevent instant closing of a wormhole.
The maths for this modules is easier than for stabilising. You add mass using this module and also by pushing ships through the wormhole if you want. Eventually the wormhole will close, destroying the anchorable if it is still in place.
Summary
Two new ship modules and a new anchorable to give capsuleer a little more control over wormhole life. The first may make invasion easier but slightly more visible to the observant occupier of a wormhole; the second will make life easier for wormhole residents but at a slightly increased risk of being noticed while closing an unwanted wormhole connection.
Thoughts?
Stabilising Effect
To create a stabilising effect there should be a requirement for a presence at both the entry and exit points of the wormhole. The idea being to create awareness from anyone watching d-scan that a stabilisation effort was in operation. This creates a flash point for conflict if so desired.
Achieving the effect would involve anchoring and bringing online a destroyable structure on one side of the wormhole. The time required to bring this online should not be particularly long, say three minutes. This structure then enables the other side of the wormhole to be targeted by one or more of a new high-slot ship module. It is this module which provides the actual stabilisation effect.
The stabilisation effect would be something similar to the vamp modules used to drain cap from ships. In this instance it would be draining 'mass input' from the wormhole at a set rate. Applying additional stabilisation modules to a single wormhole would increase the rate mass input was drained from the wormhole but should be subject to similar diminishing returns as stacking modules in a ship. Basically this creates an increase in the maximum mass which can travel through a wormhole, but beyond the initial mass limits there will be a time-based 'repair' effect which needs to be taken into account. Should there be a point where the total mass traversed through the hole minus the 'repair' effect is greater than the initial maximum mass supported by the wormhole then the wormhole will close.
The time a wormhole can stay open should not be increase. Possibly the stabilisation effect should have a side-effect of reducing wormhole lifetime. It should never be possible to hold a wormhole open indefinitely. Finally, when a wormhole eventually closes, the anchorable structure will be destroyed unless already removed.
Destabilising Effect
If we are to have a ship module and anchorable which can increase the stability of a wormhole then there should also be a sister module which has the opposite effect. Currently a wormhole corp will collapse a wormhole by running calculations on a spreadsheet while jumping plate-fit battleships or Orcas through. Having a module to simplify this task would be a massive improvement in the game experience while not particularly changing the actual dynamic involved.
As with the stabiliser effect, the destabiliser should be a two part process. Part one is anchoring and bringing online the structure on one side of the wormhole. This could even be the same anchorable used in the stabilising effect to keep outside parties guessing if the wormhole is being closed or held open. Part two is running one or more of another new high-slot ship module. This time the effect is to inject mass to the wormhole. Think shield transfer this time. Again there should be a stacking penalty to prevent instant closing of a wormhole.
The maths for this modules is easier than for stabilising. You add mass using this module and also by pushing ships through the wormhole if you want. Eventually the wormhole will close, destroying the anchorable if it is still in place.
Summary
Two new ship modules and a new anchorable to give capsuleer a little more control over wormhole life. The first may make invasion easier but slightly more visible to the observant occupier of a wormhole; the second will make life easier for wormhole residents but at a slightly increased risk of being noticed while closing an unwanted wormhole connection.
Thoughts?
Subscribe to:
Posts (Atom)

