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

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

Player Features and Ideas Discussion

 
  • Topic is locked indefinitely.
 

[Rubicon 1.3] Drone Assist change

First post First post First post
Author
Previous Topic Next Topic
Sipphakta en Gravonere
Aliastra
Gallente Federation
#481 - 2014-02-06 19:46:43 UTC
Llyona wrote:
Sipphakta en Gravonere wrote:
Llyona wrote:
Yes. This a limitation in Python and I agree, it's about time CCP started using a big boy language.



Python has multiprocessor support since 2.6, released more than 5 years ago:

This should be pretty straight-forward, but multi-processor is not the same as multi-core.


You might want to read up on http://www.python.org/dev/peps/pep-0371/ - Python is fully capable of using multiple cores and processors.
Ticondrius
Void Regulation
#482 - 2014-02-06 19:46:45 UTC
What about making the limit depend on ship drone control bandwidth?

1. Your own drones use x bandwidth.
2. Drones delegated to you are still controlled from the launching ship, but still requires a quantity of bandwidth from you. Perhaps 1/10th of if you'd launched it yourself?

This keeps drone control more on drone ships, so you don't have Interceptors zipping around with a cloud of drones.
Ransu Asanari
Perkone
Caldari State
#483 - 2014-02-06 19:47:30 UTC  |  Edited by: Ransu Asanari
Quote:
[14:48:37] directorbot: Drone assist is being limited to 50 drones per person. You may now spend the rest of the day posting like maniacs while trolling our various defeated foes. Enjoy yourselves, you've earned it. https://forums.eveonline.com/default.aspx?g=posts&t=319278

Yes, this means we'll have to toss Dominixes into the dustbin and return to using some real goddamned warships once this hits. :toot:

*** This was a broadcast from the_mittani to all-all at 2014-02-06 14:48:34.730289 EVE, replies are not monitored ***

I am here for the Forum Posting CTA. Dear Leader pings, and I obey. But don't call me a drone, because that would be too ironic.

PAP link please?

-edit- actual constructive comments once I get back from class tonight.
Valerius Kavees
Imperial Academy
Amarr Empire
#484 - 2014-02-06 19:48:13 UTC
Rathunterka wrote:
CCP Rise wrote:
Hello, some news:

We've watched the discussion in the community evolve and also kept a close eye on TQ behavior.

As always, leave your feedback and we will do our best to answer any questions.



Well, kill2... no.
The socalled discussion was a number of unhappy whiny players, that were doctrinated to belive theyr own lies after a while, crying out loud because the game didnt allow them to win, despite having more ppl in fleets.
The drone assist carrier was founded and used to counter 250 celestis with 4damps locking beyond 200km in huge fleet fights.
Players addapted... using 100x expensier ships (20m celestis 2b carrier)

Im cool with you and fozzie nerfing everything the second masses start to cry. Its notning new after all... but your reasoning for doing so is just absurd.



Having the biggest toys doesnt mean you have the best performance.

War by any point is decided by numbers...
Sipphakta en Gravonere
Aliastra
Gallente Federation
#485 - 2014-02-06 19:50:23 UTC
Koby Botick wrote:

It would potentially even be possible to "fix Python" to not have this very bad performance behaviour. Because strictly speaking Python does have threads, it's just that there is a global token (the GIL) which forces only one thread from actively working. Since Python itself does no thread scheduling and leaves that to the OS, very weird performance problems follow from that since the OS tries to actively schedule those threads, but only one can run, so the rest get awoken and put to sleep again because they cannot get the GIL very fast and often leading to the perverse situation that Python runs slower on a multicore CPU than on a single core CPU.


Luckily, the multiprocessing module has solved this issue:

http://docs.python.org/2/library/multiprocessing.html wrote:

multiprocessing is a package that supports spawning processes using an API similar to the threading module. The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads. Due to this, the multiprocessing module allows the programmer to fully leverage multiple processors on a given machine. It runs on both Unix and Windows.
Kyalla Mayaki
KarmaFleet
Goonswarm Federation
#486 - 2014-02-06 19:51:45 UTC
Anthar Thebess wrote:
What about Ewar against drones?
Drones assisted to mother ships still will be immune to any form of ewar?


My personal preference here would have been that this is handled as a targeting mechanic for the drone owner - ie, add a hidden target to all drone carrying ships, which doesn't count against that ship's targeting limit, and which is used internally to implement drone assist.

This internal target would still count as targeting by the drone owner's ship - it would be affected by the appropriate EWAR mechanics, safeties, the scan resolution and targeting range, etc. Basically, the drone bunny chooses the targets, but the drone owner's stats are what actually locks them up and fires.

As such, the fitting costs of all those sensor boosters that the drone bunny needed to be able to lock targets would apply to all the drone-carrying ships, EWAR immunities wouldn't propagate to drones unless they were actually attached to an EWAR immune ship, EWAR on individual ships of a drone fleet would affect all the drones connected to that ship, and there would be no perfect alpha strike except with identical ships and identical skill training (of the associated skills anyway).

This approach would have killed drone assist as a viable doctrine for large PvP engagements while leaving the other uses intact - the fitting costs would basically mean drone fleets have to choose between being able to snipe or actually being able to tank - or compromise and do both badly.

This can also solve some of the performance issues - the mechanic can be used at a certain level of server load to just "cheat" and abstract out the drones as weapon systems attached to the ship - nobody will know anyway in 10% tidi with soul crushing lag.
Dave Stark
#487 - 2014-02-06 19:52:02 UTC
Grarr Dexx wrote:
Kranyoldlady wrote:
Incursionsrunner here.

In a hq fleet we normally have vindi's as dronebunny
That said, its 1 vindi for DDD and the rest shoots whatever the need to shoot.

Some numbers:

HQ = 40 people - 10 logi= 30 dps- 1 DDD is 29 dps for the fleet, inportant number when contesting. Effectively using 145 drones for dps.


your idea:

HQ = 40 people-10 logi =30 dps - 3 dps for DDD = 27 dps for the fleet. Again efectively using 145 drones for dps


Imo this does change things alot.
The fc lost 2 dps for the fleet since they get a new role.
The inplementation in the fleet among 40 people is going to be a hassle to put it mildly.



Adapt or die.


nothing to do with adapting, rise said he especially didn't want it to affect incursions yet he sets the limit lower than the number of drones used. it's a complete contradiction that needs an explanation of "i lied" or "oops, yeah that needs looking in to"
Llyona
Lazerhawks
L A Z E R H A W K S
#488 - 2014-02-06 19:52:34 UTC
Sipphakta en Gravonere wrote:
Llyona wrote:
Sipphakta en Gravonere wrote:
Llyona wrote:
Yes. This a limitation in Python and I agree, it's about time CCP started using a big boy language.



Python has multiprocessor support since 2.6, released more than 5 years ago:

This should be pretty straight-forward, but multi-processor is not the same as multi-core.


You might want to read up on http://www.python.org/dev/peps/pep-0371/ - Python is fully capable of using multiple cores and processors.

As I stated, it's quite possible for Python to use multi-threading, however you can only multi-thread OR multiprocess. You CANNOT DO BOTH. The gentleman above us explained quite well why Python can't into multi-threading on a multiprocessing platform.

EVE is an illness, for which there is no cure.
Valerius Kavees
Imperial Academy
Amarr Empire
#489 - 2014-02-06 19:54:36 UTC
Ab'del Abu wrote:
CCP Rise wrote:
Quote:
Please clarify yourself here. What do you mean "if this doesn't work" ?


I can't put a number on it, but currently Dominixes are responsible for somewhere in the ballpark of 5 times the PVP damage dealt of the next most popular fleet battleship, if that's still the case in a few months this will have 'not worked'.


mittens tells his 50k+ minions to abuse some mechanic... cfc adversaries aren't happy about that, ccp isn't, hell even mitten's minions aren't. eventually, ccp comes around and does the cfc's bidding - behaving much like parents who rather shut their little brats up by means of giving them what they want instead of disciplining them. I wonder what's up next - it's not like there are many things left that would give a smaller, better equipped force an advantage over sheer numbers.

if this really was about domis, why design this nerf in a way that would hurt carriers the most? ^^

edit: not like I care. this pattern of ccp is most disturbing though



Rule of Mass applies here


Apply cold water to the burnt area
Akrasjel Lanate
Immemorial Coalescence Administration
Immemorial Coalescence
#490 - 2014-02-06 19:57:43 UTC
So what about nefing power projection CCP Roll

CEO of Lanate Industries

Citizen of Solitude
Pinky Hops
Caldari Provisions
Caldari State
#491 - 2014-02-06 19:58:31 UTC
Akrasjel Lanate wrote:
So what about nefing power projection CCP Roll


That would make the big coalitions cry, which means it is automatically off the table.
Kyalla Mayaki
KarmaFleet
Goonswarm Federation
#492 - 2014-02-06 19:59:28 UTC
Llyona wrote:
Sipphakta en Gravonere wrote:
Llyona wrote:
Yes. This a limitation in Python and I agree, it's about time CCP started using a big boy language.



Python has multiprocessor support since 2.6, released more than 5 years ago: http://docs.python.org/2/whatsnew/2.6.html#pep-371-the-multiprocessing-package

This should be pretty straight-forward, but multi-processor is not the same as multi-core.


Multiple cores are presented to software as multiple processors, so yes, it is the same.
Deckard Stern
Caldari Provisions
Caldari State
#493 - 2014-02-06 20:11:11 UTC
Padanemi wrote:
Seems legit.

Will you also limit the number of people that receive a target broadcast in fleet to 10?


That's such a horrendously awful idea I can't even wrap my head around it.

What is the point of a fleet in the far future whose broadcasts don't go to everyone? What even is that? Are we communicating through cups and string? Morse code with the running lights? I just don't even.
Dave Stark
#494 - 2014-02-06 20:12:17 UTC
Deckard Stern wrote:
Padanemi wrote:
Seems legit.

Will you also limit the number of people that receive a target broadcast in fleet to 10?


That's such a horrendously awful idea I can't even wrap my head around it.

What is the point of a fleet in the far future whose broadcasts don't go to everyone? What even is that? Are we communicating through cups and string? Morse code with the running lights? I just don't even.


so why aren't broadcasts going to all of the drones?

what are we communicating through? cups an string?
Koby Botick
Deep Core Mining Inc.
Caldari State
#495 - 2014-02-06 20:12:18 UTC
Sipphakta en Gravonere wrote:
Koby Botick wrote:

It would potentially even be possible to "fix Python" to not have this very bad performance behaviour. Because strictly speaking Python does have threads, it's just that there is a global token (the GIL) which forces only one thread from actively working. Since Python itself does no thread scheduling and leaves that to the OS, very weird performance problems follow from that since the OS tries to actively schedule those threads, but only one can run, so the rest get awoken and put to sleep again because they cannot get the GIL very fast and often leading to the perverse situation that Python runs slower on a multicore CPU than on a single core CPU.


Luckily, the multiprocessing module has solved this issue:

http://docs.python.org/2/library/multiprocessing.html wrote:

multiprocessing is a package that supports spawning processes using an API similar to the threading module. The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads. Due to this, the multiprocessing module allows the programmer to fully leverage multiple processors on a given machine. It runs on both Unix and Windows.


Erm do you actually use it? Do you know what it does? It basically replaces the "spawn thread" call by a "fork new process" call. Yes the new process then has it's own execution thread on a hardware CPU. However it's completely separated from the original process. The second process then has to somehow synchronize its execution with the original one, because, after all, there isn't suddenly a "mirror solarsystem" aka a second game state; there should be only one. So two separate processes now suddenly need a way to coordinate how they work on the same (memory-based) state. And since they are now separate, they lost many of the tools to actually precent accidental overwriting/corruption of state. The two processes now need to "talk to each other" somehow to synchronize, whereas if you have true threads in a language that actually actively supports multi-threading well, you get these for almost free.

It is possible to use this but you need to artifically recreate correct synchronization which is a non-trivial problem. Languages with proper multi-threading come with those build-in and (more important) tested and used facilities for this kind of work.

Multi-threaded programming is quite a lot more involved and harder than single-threaded as you have to identify and anticipate concurrent conflict-free manipulation of the same data and it's outright a pain in the ass if the language doesn't give you the tools to support you in this. Python does not have the proper tools. It's just not built for it. Your package is an "add on" that tacks on a bit of it, and while I suppose it actually works as described on the webpage you linked, it leaves all the menial and necessary bookkeeping work to the programmer with no help at all.
Leigh Akiga
Kuhri Innovations
#496 - 2014-02-06 20:13:41 UTC
Pinky Hops wrote:
Akrasjel Lanate wrote:
So what about nefing power projection CCP Roll


That would make the big coalitions cry, which means it is automatically off the table.


It wouldnt make anyone cry except the 200 dudes who control 28 regions while being unsubbed.
Joan Greywind
The Lazy Crabs
#497 - 2014-02-06 20:15:54 UTC
Well if the reason for this change is "domis having 5 times the damage of the next ship, making the meta stale", how much damage is proteuses and legions in wh compared to other ships? The meta there is deader (more dead?) than Ghenkis khan's body.
Arthur Aihaken
CODE.d
#498 - 2014-02-06 20:16:00 UTC
Just kill drone assist. Kill it with fire.

I am currently away, traveling through time and will be returning last week.
baltec1
Bat Country
Pandemic Horde
#499 - 2014-02-06 20:17:26 UTC
Joan Greywind wrote:
Well if the reason for this change is "domis having 5 times the damage of the next ship, making the meta stale", how much damage is proteuses and legions in wh compared to other ships? The meta there is deader (more dead?) than Ghenkis khan's body.


T3 have yet to be teircided.
Andrea Keuvo
Rusty Pricks
#500 - 2014-02-06 20:18:59 UTC
Kind of a pointless change now that the new meta for fighting in lag/tidi is blobbing with titans isnt it?