These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Test Server Feedback

 
  • Topic is locked indefinitely.
 

[Crius] Starbase feedback

First post First post
Author
Previous Topic Next Topic
CCP Greyscale
C C P
C C P Alliance
#161 - 2014-06-18 17:34:45 UTC
We're not too worried about coming up with a fix, the only blocker really is the time available. The process of deciding how to fix it will be strongly constrained though by what's technically straightforward and what isn't, and I'm not expecting to find out what that is until I have a sit down with the programmers involved and talk it through.

Also to be clear, the sentiment I was trying to express was that this is not a thing that is going to break industry, because the bonuses available are not likely to be large enough to have serious repercussions. Obviously we want to fix it because it is exploitable, but the exploits it creates are pretty minor in the greater scheme of things :)
Kenneth Feld
Habitual Euthanasia
Pandemic Legion
#162 - 2014-06-18 20:12:38 UTC
Seith Kali wrote:
CCP Greyscale wrote:

Your skillbook suggestion does not address the issue that this bonus is trying to resolve, namely that without it the optimal setup is one of each type of structures and a load of defenses, which is uninteresting.


On that note, how about some way to siege in highsec, allowing dunking large towers without hundreds of man hours? A new flavor of bastion module that couldn't track a stationary bus, for example. Pirate Dunno about you but I'd call that interesting!



Bastion Module perhaps?
Retar Aveymone
GoonWaffe
Goonswarm Federation
#163 - 2014-06-18 20:17:28 UTC
CCP Greyscale wrote:
Obviously we want to fix it because it is exploitable, but the exploits it creates are pretty minor in the greater scheme of things :)

famous last words before the goonswarm economic cabal finds a way to anchor a billion arrays and actually get paid for installing jobs :sun:
Skalle Pande
Teknisk Forlag
#164 - 2014-06-18 22:00:24 UTC
CCP Greyscale wrote:
What exactly about what we've proposed do you find inelegant?

About having to anchor a substantial number of identical modules within a POS, in order to obtain a bonus which has nothing to do with having more facilities? Actually, more facilities ought to require more workers, and therefore a higher installation cost, not lower, if you take the lore arguments at face value - more facilities logically would give more slots, but those are being abolished. And to top it off, this substantial number minus 1 may possibly be offlined when jobs have been installed. It sounds downright silly. And have you considered the visuals here: A POS crowded with offline modules of various kinds, 25 of each, worst case? And only one running? Junkyards are the opposite of elegant solutions...

Minimum requirement would IMHO be that all those modules will function as a group, i.e. that you offline all or nothing, while a job is running. That would take care of the on-off problem. Either your job is running as it was started, or it is not.

A far more elegant solution would be to make arrays behave as PI command centers, which can be upgraded to use much more cap and cpu and provide the bonus in return. No clutter at the starbase, no online-offline shenanigans, better lore integration (more automation = less need for workers = cheaper installation). You might even buy the upgrades in the form of extra modules, if you want the production of such modules to not suffer (and if the code won't allow anything else), but the extra modules should "vanish" into the first upon installation (anchoring) and just leave the one facility which is in operation with better stats. I would actually rather see upgrades getting progressively more expensive, not flat, like in most other cases (skill training, modules, whatever).

Maybe the (24+1) identical modules is the only possible solution presently, because the programming code behind it is old and/or bad and can't be remedied. So be it. But it is very much less than elegant. Acknowledge that, and we can move on. And get a grip on the on-off problem fast.
Skalle Pande
Teknisk Forlag
#165 - 2014-06-18 22:59:16 UTC  |  Edited by: Skalle Pande
xttz wrote:
iskflakes wrote:
Prince Kobol wrote:
mynnna wrote:

(stuff about the need for an overhaul of tower defenses)

Totally agree with mynnna.

PoS defences are joke these days. You can easily take out a fully defended pos in HS these days little more then a small group of BS's with next to no effort.

PoS defensive modules are a poor joke.

+1

A rebalance of POS module stats would not take much work and would sort out a lot of problems with towers.

The cruise missile/torp batteries are useless. The blasters don't have enough optimal range to hit anything. The lock times are too long. The scrams don't actually scram you. The anti-capital weapons don't threaten capitals. The list goes on..

+2

Starbases used to be a real threat to Dreadnoughts and Carriers. Now they struggle to kill cruisers and frigates.

Now, THAT is worrying. If hi-sec POS'es are going to be wardecc'ed and targetted much more frequently for real economic reasons (as opposed to wanton griefing), and if they are not defendable, it will be bad.

I happen to be in a two-man alt corp, which has become the proud owner of a recently anchored POS. It was, as is often the case I think, put up with research in mind, and none of us have any previous experience with POS'es. After Crius, we figured that we could use it for reprocessing and manufacturing as well, on a comparatively very small scale. We're easy prey anyway, but with this in mind I figure we could just as well take it down and not put it back up, once we get the first wardec (we haven't had one yet, incidentally), because there will be no chance whatsoever of putting up even a token resistance. Until then, we can hide as best we can, under a rock in an obscure and remote corner, but as soon as we are found out we will never be allowed to keep it for very long, and it will be an expensive pain in the a*** to pull it down at put it up often.

Please tell me that this is not so? That even if we can't keep our wonderful starbase, we can at least make the attackers bleed? Just a tiny little bit? Please?

Or CCP, you could of course do as mynnna suggested? Give us some means and a reason to defend, when you give people reason to attack? And preferably simultaneously.
xttz
GSF Logistics and Posting Reserves
Goonswarm Federation
#166 - 2014-06-19 07:57:39 UTC
Skalle Pande wrote:
xttz wrote:

Starbases used to be a real threat to Dreadnoughts and Carriers. Now they struggle to kill cruisers and frigates.

Now, THAT is worrying. If hi-sec POS'es are going to be wardecc'ed and targetted much more frequently for real economic reasons (as opposed to wanton griefing), and if they are not defendable, it will be bad.

....

Please tell me that this is not so? That even if we can't keep our wonderful starbase, we can at least make the attackers bleed? Just a tiny little bit? Please?

Or CCP, you could of course do as mynnna suggested? Give us some means and a reason to defend, when you give people reason to attack? And preferably simultaneously.


You can make terrible attackers bleed, no question. However the moment someone shows up with a fleet showing a modicum of organisation, you may as well not login:


  • Ewar modules can't lock Logistics Cruisers fast enough to be effective, and you'll probably need a fair number of ECM modules manually controlled for this anyway.
  • You need several characters worth of controlled medium guns to effectively damage a battleship, while larger guns require most targets to be heavily webbed in order to track it.
  • Non-laser weapons are really vulnerable to having their ammo run down before an attack by an AFK orbiting frigate that can't be tracked.


The less said about missiles and hybrid weapons the better - two entire systems that are less effective than just flying a Rifter out of the shields and taking on a fleet solo. But they serve as a honeytrap to those who don't know any better, and I can see many new towers falling foul of it.

Having said that, CCP will probably also need to look at the balance regarding towers with lots of hardeners in high-sec. That can push 200mil EHP, and without dreads very few people will want to make a serious attempt on these.
CCP Greyscale
C C P
C C P Alliance
#167 - 2014-06-19 10:30:24 UTC
Skalle Pande wrote:
CCP Greyscale wrote:
What exactly about what we've proposed do you find inelegant?

About having to anchor a substantial number of identical modules within a POS, in order to obtain a bonus which has nothing to do with having more facilities? Actually, more facilities ought to require more workers, and therefore a higher installation cost, not lower, if you take the lore arguments at face value - more facilities logically would give more slots, but those are being abolished. And to top it off, this substantial number minus 1 may possibly be offlined when jobs have been installed. It sounds downright silly. And have you considered the visuals here: A POS crowded with offline modules of various kinds, 25 of each, worst case? And only one running? Junkyards are the opposite of elegant solutions...

Minimum requirement would IMHO be that all those modules will function as a group, i.e. that you offline all or nothing, while a job is running. That would take care of the on-off problem. Either your job is running as it was started, or it is not.

A far more elegant solution would be to make arrays behave as PI command centers, which can be upgraded to use much more cap and cpu and provide the bonus in return. No clutter at the starbase, no online-offline shenanigans, better lore integration (more automation = less need for workers = cheaper installation). You might even buy the upgrades in the form of extra modules, if you want the production of such modules to not suffer (and if the code won't allow anything else), but the extra modules should "vanish" into the first upon installation (anchoring) and just leave the one facility which is in operation with better stats. I would actually rather see upgrades getting progressively more expensive, not flat, like in most other cases (skill training, modules, whatever).

Maybe the (24+1) identical modules is the only possible solution presently, because the programming code behind it is old and/or bad and can't be remedied. So be it. But it is very much less than elegant. Acknowledge that, and we can move on. And get a grip on the on-off problem fast.


From a setting perspective, more facilities allow you to spread a given load out across more locations and thus each location can run more efficiently, resulting in less overall costs.

Upgrading a single structure would result in less "stuff" in space, for sure, but I don't see that as necessarily a good thing. Ignoring the hoops you'd have to jump through to keep the current cost structure in place (you'd also probably have to scale HP, capacity etc to maintain parity with current setup), you also end up with much more boring and somewhat less easily scoutable towers. Online/offline shenanigans aside (which, again, we are fully hoping to have fixed before release), I would much rather warp to a research tower and see twenty labs lined up side by side than seeing a tower with a single lonely lab next to it. YMMV, obviously, but that's why we're favoring the current solution.
Bugsy VanHalen
Society of lost Souls
#168 - 2014-06-19 15:21:31 UTC  |  Edited by: Bugsy VanHalen
I have been testing the starbase changes on SiSi.

The character that anchored the POS has not changed corp, is still a director in the corp that he anchored the POS for, but could not get into the shield without the password. It used to be that any corp member of the owning corp could get in without a password. When I logged in the autowarp to last location bounced me off the shield to over 100km away.

In my experience only non corp members need the password to access the POS. This character was not only a director in the owning corp, but also the one who anchored and onlined it.

My question is, is this a bug, or is it an intended change. I hope that it is intended as it would add huge utility to POS management for industrial corps. To be able to lock out other corp members, even directors, by not giving them the password, players could set up personal POSes, without worry of other corp members stealing their stuff. Just only give the password to those you trust.

It is not happening on TQ, corp members still come and go freely, only non corp members need a password to enter the shield. This is repeatable on SISi, as soon as I change my access password, I can not get back in until inputting the correct password. Again, the character is a director in the corp that owns the POS.

I also see the check box that I believe used to say allow alliance usage now says allow corporation usage? This seems to indicate that I can lock out other corp members by leaving this unchecked, and not giving them the password. Is this correct?



On another note,
research time seems way longer, taking my obelisk BPO from ME 9 to ME 10 even with the bonuses from Hyasyoda lab it is saying 167 days in the industry window. 257 days in station. That seems a little excessive for a T1 BPO, even for a freighter. What would it be for a Titan 5 years?? I would have liked to compare it to my T2 capital component BPO's but they are all already at 10. Maybe someone else can check that.


Well back to testing.
Retar Aveymone
GoonWaffe
Goonswarm Federation
#169 - 2014-06-19 16:31:21 UTC
Bugsy VanHalen wrote:
I have been testing the starbase changes on SiSi.

The character that anchored the POS has not changed corp, is still a director in the corp that he anchored the POS for, but could not get into the shield without the password. It used to be that any corp member of the owning corp could get in without a password. When I logged in the autowarp to last location bounced me off the shield to over 100km away.

In my experience only non corp members need the password to access the POS. This character was not only a director in the owning corp, but also the one who anchored and onlined it.

you can set a tower to not allow corp members in without a password and you set your tower up that way by accident, i've done it on tranq a few times

that checkbox has always existed
per
Terpene Conglomerate
#170 - 2014-06-20 11:46:25 UTC  |  Edited by: per
intensive reprocessing array somehow doesnt work for me, im not able to access it (0.4 system)
http://pasteboard.co/VtoJ4un.png


reprocessing array works well though


ninja edit - siphon units not possible to launch in 0,4 systems
Salpad
Carebears with Attitude
#171 - 2014-06-20 12:48:50 UTC
CCP Ytterbium wrote:
Reprocessing Array improvements


I'm mildly concerned about this only having a capacity of 200k m3. It means that if I have a Freighter-load of ore that I want to refine, I'll have to do it in 5 batches. That seems odd. And the Ore Compression array is much larger, with about 100 times more capacity.

Are you sure it's a good idea to not give the Reprocessing Array a lot more internal volume? Like 10 times as much?
JanSVK
Deep Core Mining Inc.
Caldari State
#172 - 2014-06-20 13:09:54 UTC
Did some testing on SISI.

- Production in the POS is cumbersome. Moving blueprints and materials between different arrays results in alot of needless clicking. If possible pls give a share hangar for all Labratories and arrays.

- Tested a hawk manufacturing job in Josameto.

  • Job cost in POS was higher. Building 10 hawk in station = 3 889 864 isk, in POS = 4 190 084 isk. => 300 220 Why is the Job cost in POS higher?
  • Material cost in POS is significantly lower. However there is a strange behaviour because the bonus in the POS seems about 25% BUT does not seem to affect Zydrin, Nocxium, Megacyte.

See images below.

Also I want to adress the security issues coming with POS production. As all POS jobs are corp jobs there is a high risk of corp thieves stealing the manufactured goods or blueprints when multiple corp memebers want t.

Station:
https://plus.google.com/photos/yourphotos?pid=6026976370801855586&oid=112472675286694700491

POS:
https://plus.google.com/photos/yourphotos?pid=6026976368277411074&oid=112472675286694700491
Careby
#173 - 2014-06-20 13:11:32 UTC
Salpad wrote:
I'm mildly concerned about this only having a capacity of 200k m3. It means that if I have a Freighter-load of ore that I want to refine, I'll have to do it in 5 batches. That seems odd. And the Ore Compression array is much larger, with about 100 times more capacity.

Are you sure it's a good idea to not give the Reprocessing Array a lot more internal volume? Like 10 times as much?

I was thinking deliver ore to the compression array, and move compressed ore into the reprocessing array.
Retar Aveymone
GoonWaffe
Goonswarm Federation
#174 - 2014-06-20 17:49:45 UTC
Salpad wrote:
CCP Ytterbium wrote:
Reprocessing Array improvements


I'm mildly concerned about this only having a capacity of 200k m3. It means that if I have a Freighter-load of ore that I want to refine, I'll have to do it in 5 batches. That seems odd. And the Ore Compression array is much larger, with about 100 times more capacity.

Are you sure it's a good idea to not give the Reprocessing Array a lot more internal volume? Like 10 times as much?

unless you're building in that pos, you will have way more minerals to haul on your return trip to the station so it's sort of a moot point
Alain Kinsella
#175 - 2014-06-20 21:18:06 UTC  |  Edited by: Alain Kinsella
Retar Aveymone wrote:
Salpad wrote:


I'm mildly concerned about this only having a capacity of 200k m3. It means that if I have a Freighter-load of ore that I want to refine, I'll have to do it in 5 batches. That seems odd. And the Ore Compression array is much larger, with about 100 times more capacity.

Are you sure it's a good idea to not give the Reprocessing Array a lot more internal volume? Like 10 times as much?

unless you're building in that pos, you will have way more minerals to haul on your return trip to the station so it's sort of a moot point

That's what I started to realize as well.

I believe part of the intent here is to have the compression array not need a Corp Hangar anchored to generally operate. That allows, for example, the ability for a mining leader to 'quick anchor' a small POS at a free moon, compress/store during the mining run, and then haul to your final destination afterward (taking down the POS when done). If a dedicated reprocess character is available (for a High Sec op), he/she can do some work at a Refining Array prior to taking down the POS as well (which gains a nice bonus to the final output, and IIRC avoids the standings-related taxes as well).

That's theory. In practice, if there is a station in-system (or within 1-2 jumps) that will be used instead. The method is still useful in some of the less-used regions however, depending on how 'intense' the mining op was and how far away it was from a station. But it requires knowledge of POS mechanics, and will add at least another hour to the op (for those running it).

EDIT - I just remembered that compressed ore will fit in an ore bay. So another use in high-sec would be to 'pay' a miner in compressed ore (which would end up being the equivalent of 10 normal loads of ore). This option is probably more lucrative to someone like myself, who already has most of the refining skills to a comfortable level (not perfect, but close enough for my needs). Depending on where the miner is, (s)he may also become more of a gank magnet - even in a Skiff.

"The Meta Game does not stop at the game. Ever."

Currently Retired / Semi-Casual (pending changes to RL concerns).
Soldarius
Dreddit
Test Alliance Please Ignore
#176 - 2014-06-20 22:54:10 UTC  |  Edited by: Soldarius
(Please accept apologies. But sometimes I just can't help trolling.)

Wow. Such moons. Many tears. Goons mad.

Your moon goo jew juice empire is (generally) safe. A few extra dozen R64s won't kill your SRP. Besides, I thought you had seen the light with rental scams programs? Aren't they the wave of the future? Or... is PBLRD not the isk-fountain you thought it would be? Renters leaving in droves? Is your PASTA a little too aldente? Predditors killing all your sheep?

https://www.youtube.com/watch?v=3tSLQlV9i4Q

http://youtu.be/YVkUvmDQ3HY
Alexander Lion
Suicidal Actions
#177 - 2014-06-20 23:15:22 UTC  |  Edited by: Alexander Lion
i dont know if this was posted befor.

I played a little on Sisi and wanted to anchor a pos mod and there was not enough CPU to put it online. So i put a Design lab offline, where several jobs were running. the Lab got offlined and i could online the other pos mod. no thing. after realizing there were jobs in the lab i checked the jobs tab in the industry window. I recognized there is a large X infront of the Status bars now where the time is counting down. I wondered my the counter still counts down and what will haben, if it reaches 0. will the jobs be delivered or do they fail?

to check if the job status changes again, i online the Lab again and the x became a arrow like the play button on media players. will this jobs be finshed normal?

Update:

So i checked my jobs today. The ones from the first offlined and then onlined again Design lab were delivered successful.

now i will check what will happen to the jobs if the lab is offline wenn the counter is 0.

Update 2:

So if the POS Mod goes offline while jobs are running in it, the counter keeps counting down and when it reaches 0 the status freezes and you cannot deliver the job. After onlining the Lab again the job gets reset to to the moment the mod was offlines.

so my job took 8 min i offlines the mod at 4 min and the job got reset to 4 min after onlining again.


Is this behaviour correct or should the job be canceled without being completable at all?
Stalence
Caldari Colonial Defense Ministry
Templis CALSF
#178 - 2014-06-21 14:16:48 UTC
CCP Greyscale wrote:
Soldarius wrote:
Blue Harrier wrote:
Thanks for the earlier reply to my other post.

Now a question;
We now have the facility to anchor a POS in high sector space but do I take it we will not be able to harvest moons?

I did try and set up a Moon Harvesting Array but got a long winded message about it had to be in 0.4 or less (I think). The message vanishes far too quickly to read it all and because it has multiple lines it’s very difficult to read all of it in one go.


The tl;dr: You cannot do moon mining in .4 or higher.

That is it. I hope that one day that changes. I've never been a fan of artificial and/or arbitrary limitations. Then again, it would probably completely crash the moongoo market.


0.5 or higher as of Crius. We changed a >= to a > so the code does what the authoring was always assuming it did. I just fixed the display text for the attributes this afternoon to reflect this, but the code should already be in place.



Will this affect drug manufacturing too or just moon mining?

Member of #tweetfleet @stalence // Templis CALSF // YouTube Channel
Alexander Lion
Suicidal Actions
#179 - 2014-06-21 14:27:45 UTC  |  Edited by: Alexander Lion
Moon harvesters are conformed to work in 0.4 by now :) i allready planted one ind a nearby lowsec system.

unfortunatly the big power blocks already send out there scanners to scan all the 0.4 moons for r32 and r64 mats :(

time to build some syphons.


Drug labs can now also be anchored and onlined in 0.4 systems
Retar Aveymone
GoonWaffe
Goonswarm Federation
#180 - 2014-06-21 16:05:27 UTC
Alexander Lion wrote:
Moon harvesters are conformed to work in 0.4 by now :) i allready planted one ind a nearby lowsec system.

unfortunatly the big power blocks already send out there scanners to scan all the 0.4 moons for r32 and r64 mats :(

time to build some syphons.


Drug labs can now also be anchored and onlined in 0.4 systems

i like that not even nulli members consider themselves part of the big power blocks