Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [17] 18 19 20 30 40 50 60 .. 61 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 20 post(s) |
Llyona
sleep Deprivation INC. LLC Brothers of Tangra
43
|
Posted - 2014.02.06 19:43:00 -
[481] - Quote
Sipphakta en Gravonere wrote: This should be pretty straight-forward, but multi-processor is not the same as multi-core. EVE is an illness, for which there is no cure. |
Marcel Devereux
Aideron Robotics
332
|
Posted - 2014.02.06 19:44:00 -
[482] - Quote
Make sure that with this change that there is an error message that is displayed to the user trying to assist when they assister is at his/her max drones. |
Seliah
0mega.
0
|
Posted - 2014.02.06 19:44:00 -
[483] - Quote
I like the idea of basing this on bandwidth, it could create interesting mechanics for both small and large scale combat.
I also hope CCP will use this opportunity to fix the existing bugs with drone assign in lowsec, which have been around since, I believe, Crimewatch and the rework of criminal flags. |
Koby Botick
Eighty Joule Brewery Goonswarm Federation
95
|
Posted - 2014.02.06 19:45:00 -
[484] - Quote
Llyona wrote:MeBiatch wrote:Llyona wrote:Kappy Ukap wrote: Server side: Anyhow tbh making the server more powerful would be an option but can CCP do that with how much it could cost?
It's not a matter of cost, but possibility. CCP is already using the best servers money can buy. The "next gen" server platforms just haven't come out yet. and yet still use single core processing... its 2014 not 2003... eve code needs a complete re-write from scratch... it might take several years but should be a priority just like crimewatch rewrite was. Yes. This a limitation in Python and I agree, it's about time CCP started using a big boy language.
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.
For the technically inclined, this is probably the best public documentation about this phenomenon: http://www.dabeaz.com/python/GIL.pdf
Note that CCP actually uses stackless to my knowledge which at least can offload IO processing somewhat more sensibly. The intrinsic problems with Python on mutlithreaded architectures (which ALL servers are today and only get massively more so) is why CCP actually runs one entire Python process per solar system and treats these as single-threaded computation units. This solves the deficency of Python in the normal case, but does obviously not work at all when one such process has a big fleet battle to process.
Divide and conquer by multi-processing is the only winning strategy and it is simply not there. Actually, the brain in the box initiative which we heard first about almost 2 years ago (?) would be a very very tiny step in this direction. But as you can see in the long wait for that getting implemented and looking at the task at hand to get the entire server/fleet action processing properly multithreaded, well it is safe to say it simply won't be done ever. |
Sipphakta en Gravonere
4S Corporation Goonswarm Federation
487
|
Posted - 2014.02.06 19:46:00 -
[485] - Quote
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. I say tomato, you say tomaCCP BAN ALL TOMATOES THEY ARE HARASSING ME I WANT TOMATO FREE HIGHSEC. -- TheGunslinger42 "**** goons, they only kill stuff that can't shoot back, they aren't killing us fast enough, they missed my ****** Ibis so they failed, CCP ban goons they shot my ship." -- Distracted |
Ticondrius
Void Regulation
16
|
Posted - 2014.02.06 19:46:00 -
[486] - Quote
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
Powder and Ball Alchemists Union The Predictables
78
|
Posted - 2014.02.06 19:47:00 -
[487] - Quote
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=319278Yes, 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
Risk Breakers Fidelas Constans
7
|
Posted - 2014.02.06 19:48:00 -
[488] - Quote
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
4S Corporation Goonswarm Federation
487
|
Posted - 2014.02.06 19:50:00 -
[489] - Quote
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.
I say tomato, you say tomaCCP BAN ALL TOMATOES THEY ARE HARASSING ME I WANT TOMATO FREE HIGHSEC. -- TheGunslinger42 "**** goons, they only kill stuff that can't shoot back, they aren't killing us fast enough, they missed my ****** Ibis so they failed, CCP ban goons they shot my ship." -- Distracted |
Kyalla Mayaki
Blue Republic RvB - BLUE Republic
0
|
Posted - 2014.02.06 19:51:00 -
[490] - Quote
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
4329
|
Posted - 2014.02.06 19:52:00 -
[491] - Quote
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
sleep Deprivation INC. LLC Brothers of Tangra
43
|
Posted - 2014.02.06 19:52:00 -
[492] - Quote
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
Risk Breakers Fidelas Constans
7
|
Posted - 2014.02.06 19:54:00 -
[493] - Quote
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
Naquatech Conglomerate Naquatech Syndicate
1475
|
Posted - 2014.02.06 19:57:00 -
[494] - Quote
So what about nefing power projection CCP |
Pinky Hops
Spartan's DNA
434
|
Posted - 2014.02.06 19:58:00 -
[495] - Quote
Akrasjel Lanate wrote:So what about nefing power projection CCP
That would make the big coalitions cry, which means it is automatically off the table. |
Kyalla Mayaki
Blue Republic RvB - BLUE Republic
0
|
Posted - 2014.02.06 19:59:00 -
[496] - Quote
Llyona wrote:Sipphakta en Gravonere wrote: 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
4
|
Posted - 2014.02.06 20:11:00 -
[497] - Quote
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
4330
|
Posted - 2014.02.06 20:12:00 -
[498] - Quote
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
Eighty Joule Brewery Goonswarm Federation
95
|
Posted - 2014.02.06 20:12:00 -
[499] - Quote
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
My Highsec Backbone
555
|
Posted - 2014.02.06 20:13:00 -
[500] - Quote
Pinky Hops wrote:Akrasjel Lanate wrote:So what about nefing power projection CCP 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
Garoun Investment Bank Gallente Federation
321
|
Posted - 2014.02.06 20:15:00 -
[501] - Quote
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
Perkone Caldari State
2884
|
Posted - 2014.02.06 20:16:00 -
[502] - Quote
Just kill drone assist. Kill it with fire. I am currently away, traveling through time and will be returning last week. |
baltec1
Bat Country Goonswarm Federation
10102
|
Posted - 2014.02.06 20:17:00 -
[503] - Quote
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.
Join Bat Country today and defend the Glorious Socialist Dictatorship |
Andrea Keuvo
Science and Trade Institute Caldari State
252
|
Posted - 2014.02.06 20:18:00 -
[504] - Quote
Kind of a pointless change now that the new meta for fighting in lag/tidi is blobbing with titans isnt it? |
Ashrik Tyr
GoonWaffe Goonswarm Federation
19
|
Posted - 2014.02.06 20:19:00 -
[505] - Quote
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'.
I don't get it. How can this be a move to appease goons while at the same time nerfing the main goon fleet doctrine? Hmmmmmmmmmmmm |
Tiberizzle
GoonWaffe Goonswarm Federation
46
|
Posted - 2014.02.06 20:25:00 -
[506] - Quote
If alpha is gamebreaking, why is it okay for artillery alpha or dread alpha to break the game (bypass remote assist mechanics) and not sentry alpha?
How is prefiring F1 and ctrl-clicking the top thing out of the broadcast window more engrossing than assisting drones?
Adjust sentry drone damage projection and in particular revisit the mindboggling double down overbuffs to the Gallente drone hulls.
10 year old game mechanics should not be considered a degree of freedom in realizing whatever autistic fever dream of game balance is inspiring some of the recent changes |
Charadrass
Angry Germans
121
|
Posted - 2014.02.06 20:25:00 -
[507] - Quote
Limiting to the Dronebuddy Bandwidth is NOT a good idea. because many fleets use battleships or different type of ships as a dronebuddy.
Limit it in General to the amount i already posted will solve all Problems and leave the normal fleets untouched. |
Lavayar
Russian SOBR SOLAR FLEET
207
|
Posted - 2014.02.06 20:25:00 -
[508] - Quote
good job |
MeBiatch
GRR GOONS
1711
|
Posted - 2014.02.06 20:26:00 -
[509] - Quote
baltec1 wrote: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.
dont use that term it ended last year with bs rebalance. as only tech I ships had tiers. so any pending changes cannot be construde as tiericide.
the term to use now is just ship rebalance.
thanks There are no stupid Questions... just stupid people... Winter Expansion new ship request |
Sipphakta en Gravonere
4S Corporation Goonswarm Federation
487
|
Posted - 2014.02.06 20:27:00 -
[510] - Quote
Koby Botick wrote: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.
I agree that python places much responsibility on the developer and other languages are better suited for that kind of work. I was just pointing out that python isn't as bad as people make it out to be.
http://www.jeffknupp.com/blog/2013/06/30/pythons-hardest-problem-revisited/ has a (in my opinion) great write up of the problem and possible solutions of utilizing multiple cpu cores/processors.
Of course, Eve's codebase is 10 years old and written for Stackless, so adapting to current python versions and making use of improvements will certainly be a hard task. I say tomato, you say tomaCCP BAN ALL TOMATOES THEY ARE HARASSING ME I WANT TOMATO FREE HIGHSEC. -- TheGunslinger42 "**** goons, they only kill stuff that can't shoot back, they aren't killing us fast enough, they missed my ****** Ibis so they failed, CCP ban goons they shot my ship." -- Distracted |
|
|
|
|
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [17] 18 19 20 30 40 50 60 .. 61 :: one page |
First page | Previous page | Next page | Last page |