Pages: 1 2 3 4 5 6 7 :: [one page] |
|
Author |
Thread Statistics | Show CCP posts - 26 post(s) |
|
CCP Fallout
|
Posted - 2010.08.23 14:45:00 -
[1]
We've all experienced this at one time or another: hit an F key, say an F word while waiting. What's that all about? CCP Veritas gives us the skinny in his new dev blog.
Fallout Associate Community Manager CCP Hf, EVE Online Contact us |
|
ivo
Drunken Pilots
|
Posted - 2010.08.23 14:54:00 -
[2]
Its nice to know that this all powerful bug is finally getting squished.
Also, First, wow my first first
|
Yuki Kulotsuki
|
Posted - 2010.08.23 14:57:00 -
[3]
Nice face. Nothing like encountering "rare" exceptions regularly. This certainly sounds like a problem though. Finding the right balance of processing. I do not envy ya that job.
Originally by: CCP Lemur THIS IS GOD: ... IF YOU HAVE ANY MORE REQUESTS I'M AVAILABLE SUNDAY FROM 10:30 TO 12:00 TO RECEIVE YOUR PRAYERS.
|
Zendoren
Aktaeon Industries
|
Posted - 2010.08.23 15:03:00 -
[4]
Nice follow up on the mod lag guys.....
If you keep this level of blog reporting.... I think you will gain many friends in the eve community!
|
Force Kon
|
Posted - 2010.08.23 15:10:00 -
[5]
I hope this will finally show people that CCP are making steps to fix lag and not focusing all their efforts elsewhere.
|
TeaDaze
|
Posted - 2010.08.23 15:15:00 -
[6]
Thanks for the work in tracking this down. We look forward to seeing the fix in action
TeaDaze.net Blog | CSM Database |
Qujulome
Amarr
|
Posted - 2010.08.23 15:15:00 -
[7]
+1 for pictures
|
Evelgrivion
Ignatium.
|
Posted - 2010.08.23 15:16:00 -
[8]
Edited by: Evelgrivion on 23/08/2010 15:16:47 Unless I misread the blog, the means for actually fixing the issues aren't mentioned. Ive heard before that Dogma was written in Python, and that its the single largest bottleneck in EVE. What do you guys have in mind to bring Dogma up to speed? Will the relevant bits be refactored in C++ or are we going to be waiting for the Stackless Python Just In Time Compiler project to finish up, perhaps with some "minor" refactoring of the existing Stackless code?
|
Zirse
Minmatar Brutor tribe
|
Posted - 2010.08.23 15:22:00 -
[9]
Thank you sir, for the read.
|
Jorend Dohag
|
Posted - 2010.08.23 15:22:00 -
[10]
You should look into GPGPU! It pays off.
|
|
Levitikon
Destructive Influence IT Alliance
|
Posted - 2010.08.23 15:25:00 -
[11]
Oh, wow. So basically, great pre-dominion server performance had NOTHING TO DO WITH CCP, it was byproduct of bug that made your guns stuck, thereby lessening load on node system.
You really cannot, under no circumstances, yield Dogma subsystem - that will end up with warp scramblers not activating, guns not firing when they should and in effect totally ****ed up battles, where people can warp out/survive when they shouldn't, or where they die when they should lie (case: warpout command was issued 10 seconds after you got out of warp range, but since Domga was yelded, warp scrambling effect was never activated).
Yes, while you are reading it dear devs - there exists another CONFIRMED layer of this bug: With good enough lag, you can keep your target warpscrambled regardless of state of your module or DISTANCE.
You could* fit 7 warp scramblers on your ship, MWD to enemies (cool thing - module won't cycle, you will keep your MWD speed infinitively without using cap), activate scramblers on 7 enemy capital ships, fly 100KM away and enjoy perma-scrambled 7 with no risk for you.
I wonder if you could pull something like that with focused HIC and titan... I hope, dear developers, that you can see why no one wants to commit Titans into big laggy fights anymore.
|
Lin Xiao
Ars ex Discordia Test Alliance Please Ignore
|
Posted - 2010.08.23 15:28:00 -
[12]
Thanks for the update CCP Veritas.
This is an example of how to communicate and interact with your players. Keep it up.
|
Shamblingform
Gallente
|
Posted - 2010.08.23 15:29:00 -
[13]
Easily first page!
German Giggles! R
|
|
CCP Veritas
|
Posted - 2010.08.23 15:29:00 -
[14]
Originally by: Evelgrivion What do you guys have in mind to bring Dogma up to speed? Will the relevant bits be refactored in C++ or are we going to be waiting for the Stackless Python Just In Time Compiler project to finish up, perhaps with some "minor" refactoring of the existing Stackless code?
I've been busy profiling it under some basic scenarios and there's some low hanging fruit to be plucked in there. There's significant algorithmic optimizations to be made as well, and those follow you around regardless of what language you're in. Language/platform shift isn't on the table until the algorithms are sound.
In other words, I believe Dogma is doing stupid things, and I intend to beat the stupid out of it before considering giving it rocket boots.
|
|
Jorend Dohag
|
Posted - 2010.08.23 15:29:00 -
[15]
http://developer.download.nvidia.com/compute/cuda/3_1/toolkit/docs/NVIDIA_CUDA_C_ProgrammingGuide_3.1.pdf
|
Mashie Saldana
BFG Tech
|
Posted - 2010.08.23 15:30:00 -
[16]
Originally by: Jorend Dohag http://developer.download.nvidia.com/compute/cuda/3_1/toolkit/docs/NVIDIA_CUDA_C_ProgrammingGuide_3.1.pdf
Wrong tool for the job.
18 months |
Levitikon
Destructive Influence IT Alliance
|
Posted - 2010.08.23 15:34:00 -
[17]
Another useful tidbit of information - please include killing ships into your thin client simulations.
Shooting single titan is all fun and giddy, but in real battles people's ships go boom!. Associated with it - a lot of changing targets, loosing targeting locks, getting out of range, WARPING OUT AND IN (kind of important, as it's only real 'tank' players have against being primaried by enemy fleet and only tactical tool FCs have for implementing battle strategy).
|
Vuk Lau
|
Posted - 2010.08.23 15:34:00 -
[18]
Edited by: Vuk Lau on 23/08/2010 15:34:29 BTW Video mentioned in this devblog CSM presented to CCP can be found on following link Youtube link Btw this is something called "manual gun cycling" and is used in fleet fights when node starts to die.
Thanx for keeping us in the loop about your progress.
|
Kikki Di'je
Lay Low
|
Posted - 2010.08.23 15:35:00 -
[19]
I love you.
No, seriously, I love you.
I love you man. No, really.....I love you.
|
Hemmo Paskiainen
Gallente Silver Snake Enterprise
|
Posted - 2010.08.23 15:36:00 -
[20]
Edited by: Hemmo Paskiainen on 23/08/2010 15:36:38 Nice blog, module lag is one of the things that annoyed me im fleet fights
I love u too
|
|
|
CCP Veritas
|
Posted - 2010.08.23 15:39:00 -
[21]
Originally by: Levitikon Another useful tidbit of information - please include killing ships into your thin client simulations.
When doing this sort of analysis, it's best to start out by isolating exactly what you want to look at to remove any external influence. In the cases pictured, I wanted to observe module and drone behaviors, so that's exactly what I had going on - and little else.
I have done tests involving blowing up many ships (and little else). They were as fun as they were informative~
|
|
|
CCP Fallout
|
Posted - 2010.08.23 15:50:00 -
[22]
Originally by: Vuk Lau Edited by: Vuk Lau on 23/08/2010 15:34:29 BTW Video mentioned in this devblog CSM presented to CCP can be found on following link Youtube link Btw this is something called "manual gun cycling" and is used in fleet fights when node starts to die.
Thanx for keeping us in the loop about your progress.
Thanks. I ninja edited the link in :D
Fallout Associate Community Manager CCP Hf, EVE Online Contact us |
|
Vuk Lau
|
Posted - 2010.08.23 15:56:00 -
[23]
Originally by: CCP Fallout
Originally by: Vuk Lau Edited by: Vuk Lau on 23/08/2010 15:34:29 BTW Video mentioned in this devblog CSM presented to CCP can be found on following link Youtube link Btw this is something called "manual gun cycling" and is used in fleet fights when node starts to die.
Thanx for keeping us in the loop about your progress.
Thanks. I ninja edited the link in :D
Thank YOU :D
|
Indeterminacy
THORN Syndicate Controlled Chaos
|
Posted - 2010.08.23 15:57:00 -
[24]
"we're tweaking the parameters of our existing infrastructure to improve performance."
That's basically the story amirite? Some specifics about the longer term solution would be useful.
Of course we all know why the devblog spam now. In the end they're good and of course it's good problems are being addressed. On the other hand, this seems elementary enough that it could have been tackled at any point in the last 6 months for little if any cost on CCPs part.
That's a bit depressing.
|
Lumy
Minmatar eXceed Inc. HYDRA RELOADED
|
Posted - 2010.08.23 15:58:00 -
[25]
Originally by: Indeterminacy "we're tweaking the parameters of our existing infrastructure to improve performance."
That's basically the story amirite? Some specifics about the longer term solution would be useful.
Of course we all know why the devblog spam now. In the end they're good and of course it's good problems are being addressed. On the other hand, this seems elementary enough that it could have been tackled at any point in the last 6 months for little if any cost on CCPs part.
That's a bit depressing.
This reading thing, you aren't really good at it, right mate? |
Ix Forres
Caldari Righteous Chaps
|
Posted - 2010.08.23 16:04:00 -
[26]
Great facial expression, good dev blog. How many major fixes have come about since the introduction of the thin client platform, and when was this made internally available? What were your methods of debugging EVE before it was available?
Originally by: Mashie Saldana
Originally by: Jorend Dohag http://developer.download.nvidia.com/compute/cuda/3_1/toolkit/docs/NVIDIA_CUDA_C_ProgrammingGuide_3.1.pdf
Wrong tool for the job.
This. Whenever people go "ZOMG CUDA! OpenCL! GPU processing!" I just cry.
Yes, GPUs are fast at some tasks. However, for the majority of tasks (including the majority of EVE Online's server tasks) they are not suitable. They are applicable to very, very narrow fields- graphics rendering, massive processing of embarrassingly parallel (it's a technical term, fyi) tasks, and so on. None of which covers EVE's server side. And let's not forget the fact that TQ runs on blade servers; adding GPUs would require a shift to traditional server form factors which would require a massive investment to migrate, along with an increase in running costs, probably increases in other costs like maintenance, a requirement to reinvest in huge amounts of networking gear... and you're still using the wrong tool for the job. -- Ix Forres - 3rd Party Application Developer - EVE Metrics - accVIEW
|
Dierdra Vaal
|
Posted - 2010.08.23 16:08:00 -
[27]
Quote: Essentially what we have to do is re-introduce yielding in the effect processing queue, only under our control instead of at the whim of some defect.
Does this mean the module lag will get better, or will it stay the same?
* * * Director of Education :: EVE University * * * CSM1 delegate, CSM3 chairman and CSM5 vice-chairman
|
Aranial
Gallente Empyrean Warriors Lux Caelestia
|
Posted - 2010.08.23 16:09:00 -
[28]
ah ha! MOAR Brain NOM NOM
|
Rakshasa Taisab
Caldari Sane Industries Inc. Initiative Mercenaries
|
Posted - 2010.08.23 16:10:00 -
[29]
Originally by: Ix Forres This. Whenever people go "ZOMG CUDA! OpenCL! GPU processing!" I just cry.
And the specialized code that needs to go in to make it all work makes developers cry.
|
Dante Edmundo
|
Posted - 2010.08.23 16:18:00 -
[30]
Edited by: Dante Edmundo on 23/08/2010 16:21:23
Excellent and insightful report.
Having written code myself for many years, I was often surprised how little emphasis would be placed by project management on "thin testing clients" or even "automated testing". They simply didn't want to spend the time up front to develop these valuable bug hunting tools.
Automated testing is especially powerful as it saves a good amount of developer time in the long run, and re-checks older features automatically on each build - to make sure the code doesn't break something old while fixing something new. It also is a good method of making sure your test itself is solid - since an ad-hoc testing process can be buggy as well.
Good luck with your efforts. I think it benefits the community and CSM being able to read BLOG posts of this detail. And shows you guys are sincerely attempting to work on issues that dog players today - not just expansions for the future of Eve.
Dante
|
|
|
CCP Veritas
|
Posted - 2010.08.23 16:23:00 -
[31]
Originally by: Ix Forres Great facial expression, good dev blog. How many major fixes have come about since the introduction of the thin client platform, and when was this made internally available? What were your methods of debugging EVE before it was available?
Thanks~
The thin clients matured enough for usage roughly a month ago, and while it took a fair bit of time to get them to do useful things, much has come from them already. It's hard to say how many major fixes have come from their usage so far, since that's dependent on your definition of major. Certainly most of what I talk about in this blog was made possible in the timeframe it happened via thin clients, and there are some nice optimizations coming down the pipe as well that originated in controlled thin client setups.
Before the thin clients we did load testing by getting as many warm bodies to log in to test servers, both internally and with the public mass tests. This type of testing is fantastic for finding things you didn't think to test, but not very useful for the kind of specific drill-down testing that I've been talking about above. Removing the need to use mass tests for that purpose has been very liberating, both in that we can do more of it and that we can focus on higher level information during mass tests.
|
|
Peter Tjordenskiold
The Executives IT Alliance
|
Posted - 2010.08.23 16:25:00 -
[32]
Wouldn't it be easy to slow down all cylic times in a heavy load situation, like
real_cyclic_time = cyclic_time * load_factor ?
The paradigma of real time is great, but a cyclic time based on load could help a little bit.
|
|
CCP Veritas
|
Posted - 2010.08.23 16:25:00 -
[33]
Originally by: Dierdra Vaal
Quote: Essentially what we have to do is re-introduce yielding in the effect processing queue, only under our control instead of at the whim of some defect.
Does this mean the module lag will get better, or will it stay the same?
I'm not really sure. At the very least it should be more consistent. I did play around a bit with how much yielding is done during the last mass test, and I think I found a good value where the amount of module lag is less while still maintaining reasonable responsiveness of other systems.
|
|
Ander
Gallente Sniggerdly Pandemic Legion
|
Posted - 2010.08.23 16:34:00 -
[34]
The problems you describe in the blog are basic multitasking / multithread issues covered in even the basic university operating system courses.
Stuff like resource starvation is an interesting but very common problem if your devs dont know exactly what they are doing.
EVE PIRATE BattleDB.com |
Liang Nuren
Parsec Flux War.Pigs.
|
Posted - 2010.08.23 16:35:00 -
[35]
Originally by: CCP Veritas
I've been busy profiling it under some basic scenarios and there's some low hanging fruit to be plucked in there. There's significant algorithmic optimizations to be made as well, and those follow you around regardless of what language you're in. Language/platform shift isn't on the table until the algorithms are sound.
Smart man.
Quote: In other words, I believe Dogma is doing stupid things, and I intend to beat the stupid out of it before considering giving it rocket boots.
You'd think that rockets would be someone else's job anyway. At least, I hope so! Marvelous job on the dev blog and sleuthing!
-Liang -- Eve Forum ***** Extraordinaire On Twitter Blog
|
Obsidian Hawk
RONA Legion
|
Posted - 2010.08.23 16:35:00 -
[36]
CCP Veritas - Great read, great blog, epic picture lol. If I could offer a suggestion for future tests using the thin client. Add on 1 smartbomb to all the ships and have that going off at the same time. While the tests do prove impressive, the damage is all one sided, you need to receive as much as you give.
Well anyway it's just a thought. Seeing all damage being given and only 1 target receiving and the target isnt trying to shoot back, seems to make the load unbalanced, if that makes any sense.
|
Genya Arikaido
|
Posted - 2010.08.23 16:38:00 -
[37]
Veritas, that face and the context in which is was made had my sides bursting for 15 minutes.
Know that it will soon become the new "face" (pardon the pun) of future forum picture posts in the context of captions ranging from "OMG!" to "FACEMELT!" and even the dreaded "WHAT HAS BEEN SEEN CANNOT BE UNSEEN!".
Originally by: CCP Tuxford my bad.
Rest assured I'm being ridiculed by my co-workers.
|
Axemaster
|
Posted - 2010.08.23 16:47:00 -
[38]
Edited by: Axemaster on 23/08/2010 16:51:45 Some questions:
You say the system was actually getting overloaded. So where was the bottleneck happening, in the CPU?
If so, isn't this exactly the sort of problem that would benefit most from parallel computing? You are basically running a bunch of identical timing processes. Why not split them into groups and assign each group to a separate cpu core? It seems straightforward enough. It would even allow you to separate them from the location servers, speeding them up.
Actually, why not use a gpu to process this? They seem tailor-made for these kinds of massive parallel computing problems. All you'd have to do is get a specialized driver (not so hard since they are already used for this by many scientists). The cpu could send the processes over to the gpu, which would run the timers for the list of active modules. The cpu would keep track of the positions and velocities of the ships since it's a location node, and I assume that info is all stored in the RAM. The GPU, having access to the same resources, could also run the hit/miss/damage calculations.
This is hardly a spiderweb issue - guns cycling and firing only need to know the relative speed and distance of the target. It seems very easy to split this up.
Am I in the ballpark here?
Edit: The fact that you describe the processes lining up in a queue makes me feel even more that parallel computing is needed here.
|
Charles37
|
Posted - 2010.08.23 16:49:00 -
[39]
Great blog (fantastic picture!); it's very nice to be kept in the loop on what's happening with some of these issues, and I sincerely hope that the dev team continues to do so even after this 'lag blog marathon' has ended.
|
Mynxee
|
Posted - 2010.08.23 16:50:00 -
[40]
Edited by: Mynxee on 23/08/2010 16:51:28 Very interesting read from a process point of view (since I lack the tech savvy to comment on the technical stuff). This is quite possibly my favorite of the Dev Blogapalooza offerings so far--I really enjoyed the "how we figured stuff out" detective novel approach. And that first picture was great!
Thanks to CCP Veritas and all the other dev bloggers for acknowledging the CSM's contributions. ♥
Life In Low Sec |
|
Taudia
Gallente Sane Industries Inc. Initiative Mercenaries
|
Posted - 2010.08.23 16:53:00 -
[41]
Originally by: Liang Nuren Simply put: the differences in scale and complexity between what's covered in University OS courses and what happens in the real world is staggering.
Confirming this. As a student current trying to get into the gaming industry, the difference between what is used in the industry and what is considered academically worthwhile is staggering. The thing is, strange as it sounds, academic theory doesn't actually have to work in practice for academics to be happy about it. I am pretty sure that the sleeper AI, while it is great and very complex relative to the ordinary AI and even what is implemented in most games, is pretty trivial from an academical viewpoint. In short, when things have to work, you do something you know you can make work in reasonable time and with reasonable performance, which means that cutting edge theory stuff is a bad choice.
|
Gnulpie
Minmatar Miner Tech
|
Posted - 2010.08.23 16:54:00 -
[42]
Great blog.
Thanks for all that really nice and detailed information. This is exactly what was missing the last (couple) month(s). Excellent to see that you are back on the right track with communication again. Even though those blogs are certainly a strain on the devs (who likes writing all that stuff? ), it is certainly good and helpful for everyone.
Thanks! |
Hawk TT
Caldari Bulgarian Experienced Crackers Circle-Of-Two
|
Posted - 2010.08.23 16:54:00 -
[43]
Edited by: Hawk TT on 23/08/2010 16:55:18 Great Blog! Nice screenshots
For those interested in the Python GIL (Global Interpetter Lock) drawbacks and in Python cooperative-multitasking: David Beazley's - Understanding Python GIL - PyCon 2010
This is David Beazley's presentation @ PyCon 2010...who the f**k is David Beazley?!?! - OK, Google him The presentation is fun, it's informative, it shows how Python behaves on multiple-CPU cores (BAAAAD!) etc. The presentaiton also covers the issues when threads release control prematurely And there is some hope - a new GIL is being developed, unfortunately for Python 3.2+, but still it could be ported to Stackless 2.7...More or less, it seems that GIL will survive for the time being and will not be "killed" any time soon...
Hopefully CCP is working on something on their own...GIL in Python = No Benefits form Multicore Processing ___________________________________ Science & Diplomacy Manager @ BECKS Circle-of-Two |
Cedori
Shiva Morsus Mihi
|
Posted - 2010.08.23 17:00:00 -
[44]
Edited by: Cedori on 23/08/2010 17:00:55 Since you noted that drones seemed to push the server over the edge, wouldn't it be a possible optimization step to "group" drones as guns are grouped?
I know that has some complex issues with drones taking damage/etc, but with most ships fielding 5 drones, it seems that doing this could cut down on the number of calculations Dogma needs to perform by a large margin. Instead of 6 calculations per character involved in a fleetfight, you'd have 2, or a decrease of ~200% (less real effect of course, but still).
This post represents the views of me, myself, and I. Nothing said should be attributed to my corp or alliance, otherwise I might be whipped with a strand of wet-spaghetti! |
P'eon
|
Posted - 2010.08.23 17:02:00 -
[45]
Originally by: devblog And then there was lag! The server I was running against was positively unhappy. But still, modules were reasonably fine - the error was not to be seen. (Remember what I said above about there being many manifestations of lag? Well this was a different sort, but not what we needed to reproduce the æstuck module' symptom) Some fantastic sleuthing by my teammate CCP Masterplan lead us to some simple steps that could be done to induce this error. Module delays quickly followed.
out of curiosity, what did you have to do to induce module lag?
|
Darth Vapour
|
Posted - 2010.08.23 17:05:00 -
[46]
June 25th, 2010:
Quote: EVE is now, from a technical standpoint, in a better state than it has ever been.
And now this:
Quote: The "rare" error happened 1.5 million times in the month of June, 2010 on TQ.
Does this mean the error occurred even more before the server came to be in the best state it ever was or was the statement in the minutes the nonense everyone thinks it is ?
|
Korerin Mayul
Amarr hirr
|
Posted - 2010.08.23 17:08:00 -
[47]
Originally by: Ix Forres embarrassingly parallel tasks
hahahahhaaa! thats my new favorite buzzword ever.
|
|
CCP Veritas
|
Posted - 2010.08.23 17:08:00 -
[48]
Originally by: Axemaster You say the system was actually getting overloaded. So where was the bottleneck happening, in the CPU?
Yup.
Originally by: Axemaster If so, isn't this exactly the sort of problem that would benefit most from parallel computing?
This goes back to something I said earlier in regards to language/platform shift. Going wide on a poor algorithm won't gain you as much as switching to a good algorithm, so that's where we're going to attack first. It's possible that some day making Dogma parallel will make sense as the primary approach, but today is not that day.
Originally by: Axemaster Actually, why not use a gpu to process this?
Well, for starters our servers haven't got GPUs Past that, GPU processing is good for the true extreme of execution to memory ratios - it takes a lot of time to shovel information into the GPU and get it back out relative to the speed of execution, so you need a problem that has heavy execution per memory to make sense to go to the GPU. I believe it's unlikely that this particular system will fit that profile.
|
|
|
CCP Veritas
|
Posted - 2010.08.23 17:12:00 -
[49]
Originally by: Cedori Since you noted that drones seemed to push the server over the edge, wouldn't it be a possible optimization step to "group" drones as guns are grouped?
Just because they pushed load over the edge doesn't mean they're a lot of load themselves. Think of it this way, if drones add 10% CPU and player modules add 95% CPU, having folks start all modules and then launch drones would make it feel like drones are a lot of load, since having them out pushed the server over 100% CPU. However, any time spent addressing their 10% would be considerably better spent addressing the 95% elsewhere.
|
|
Marlenus
Ironfleet Towing And Salvage
|
Posted - 2010.08.23 17:13:00 -
[50]
Originally by: CCP Veritas I believe Dogma is doing stupid things, and I intend to beat the stupid out of it before considering giving it rocket boots.
I am not a programmer, but this made me LOL. A vivid metaphor I can understand. ------------------ Ironfleet.com |
|
Vuk Lau
|
Posted - 2010.08.23 17:26:00 -
[51]
Originally by: Darth Vapour Edited by: Darth Vapour on 23/08/2010 17:06:38 June 25th, 2010:
Quote: EVE is now, from a technical standpoint, in a better state than it has ever been.
And now this:
Quote: The "rare" error happened 1.5 million times in the month of June, 2010 on TQ.
Does this mean the error occurred even more before the server came to be in the best state it ever was or is the statement in the minutes the nonsense everyone thinks it is ?
I will have liberty to say that I almost pooped all over Socratesz when I heard the famous "EVE is now, from a technical standpoint, in a better state than it has ever been." so my bet is that was pure example of nonsense
|
Nareg Maxence
Gallente
|
Posted - 2010.08.23 17:29:00 -
[52]
I enjoyed this devblog. Looks like the thin client is going to be cornerstone in sorting out load related issues for you.
|
Keiko Kobayashi
Amarr Celestial Janissaries Curatores Veritatis Alliance
|
Posted - 2010.08.23 17:33:00 -
[53]
Edited by: Keiko Kobayashi on 23/08/2010 17:33:53 So this æfixÆ, will it make it so that I donÆt have to manually unstuck and fire guns anymore? IÆm fine with a bit of module lag (that is equally shared by everyone) as long as I donÆt have to turn off auto-repeat, ungroup guns and click target icons in order to do damage.
Especially for fleets less experienced with large scale battles, this gun bug currently puts them at a serious disadvantage, basically reducing their damage output to near 0. Currently if you donÆt recognise that the gun bug is in effect in time, you may have lost say, all of your logistics already.
|
darius mclever
|
Posted - 2010.08.23 17:49:00 -
[54]
nice dev blog and keep up the good work.
one note though ... i dont share your observation from the last mass test. as soon as drones were allowed the lag became horrible. before them it was quite playable.
|
Elsa Nietzsche
|
Posted - 2010.08.23 17:51:00 -
[55]
Could you explain what 'processing effects' are?
|
Axemaster
|
Posted - 2010.08.23 17:54:00 -
[56]
Ok, since you were nice enough to answer my previous question, I'll ask a new one:
How are position/velocity/acceleration vectors handled and updated by the location server? Are they simply updated 100 times per second? Or does the server use some sort of predictive calculus to calculate where the ship should be when something queries it (i.e. it doesn't have a position until it's asked, like in quantum mechanics)?
If it isn't using predictive calculus, surely it would benefit MASSIVELY from switching to it? In fact, I can think of exactly how you would do it, it wouldn't even be hard to figure out. You could essentially remove all nonessential updating from the server, and probably cut cpu usage by 75% or more.
Also, I don't want to sound like a broken record, but all those vector sets cry out for parallel computing...
|
|
CCP Warlock
|
Posted - 2010.08.23 17:54:00 -
[57]
Originally by: Darth Vapour Edited by: Darth Vapour on 23/08/2010 17:06:38 June 25th, 2010:
Quote: EVE is now, from a technical standpoint, in a better state than it has ever been.
And now this:
Quote: The "rare" error happened 1.5 million times in the month of June, 2010 on TQ.
Does this mean the error occurred even more before the server came to be in the best state it ever was or is the statement in the minutes the nonsense everyone thinks it is ?
Well, technical perfection is like everything else in life, you can always do better.
But let's just say, that there's a little samizdat activity in CCP at the moment to provide an appropriately inappropriate t-shirt in order to properly memorialise that particular entry into the great list of "They can't hit an elephant from ther...." remarks.
Onwards. Upwards. To the stars!
|
|
Kesper North
Caldari Reliables Inc Majesta Empire
|
Posted - 2010.08.23 18:00:00 -
[58]
Can you explain why you are using Maelstroms as a laser platform? -- Killed me? Read about it in my blog! Northern Lights: Solo PVP in EVE Online
|
Evelgrivion
Ignatium.
|
Posted - 2010.08.23 18:01:00 -
[59]
Edited by: Evelgrivion on 23/08/2010 18:01:14
Originally by: CCP Warlock
Originally by: Darth Vapour Edited by: Darth Vapour on 23/08/2010 17:06:38 June 25th, 2010:
Quote: EVE is now, from a technical standpoint, in a better state than it has ever been.
And now this:
Quote: The "rare" error happened 1.5 million times in the month of June, 2010 on TQ.
Does this mean the error occurred even more before the server came to be in the best state it ever was or is the statement in the minutes the nonsense everyone thinks it is ?
Well, technical perfection is like everything else in life, you can always do better.
But let's just say, that there's a little samizdat activity in CCP at the moment to provide an appropriately inappropriate t-shirt in order to properly memorialise that particular entry into the great list of "They can't hit an elephant from ther...." remarks.
Onwards. Upwards. To the stars!
Heres an idea for a shirt quote
"From a technical standpoint, the game has never been in ҉҉̡̢̡̢̛̛̖̗̘̙̜̝̞̟̠̖̗̘̙̜̝̞̟̠̊̋̌̍̎̏̐̑̒̓̔̊̋ ͡҉҉a better҉҉̡̢̡̢̛̛̖̗̘̙̜̝̞̟̠̖̗̘̙̜̝̞̟̠̊̋̌̍̎̏̐̑̒̓̔̊̋̌̍̎̏̐̑ ͡҉҉ sta͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿̿ ҉҉̡̢̡̢̛̛̖̗̘̙̜̝̞̟̠̖̗̘̙̜̝̞̟̠̊̋̌̍̎̏̐̑̒̓̔̊̋̌̍̎̏̐͡҉)-"
|
Lumy
Minmatar eXceed Inc. HYDRA RELOADED
|
Posted - 2010.08.23 18:01:00 -
[60]
Edited by: Lumy on 23/08/2010 18:02:09
Originally by: CCP Warlock Well, technical perfection is like everything else in life, you can always do better.
But let's just say, that there's a little samizdat activity in CCP at the moment to provide an appropriately inappropriate t-shirt in order to properly memorialise that particular entry into the great list of "They can't hit an elephant from ther...." remarks.
Onwards. Upwards. To the stars!
The public demands photos.
Joomla! in EVE - IGB compatible CMS. |
|
Luke S
Zeta Corp.
|
Posted - 2010.08.23 18:05:00 -
[61]
Stupid question: Does module lag happen to all types of mods? Such as mining lasers? ---
|
DmitryEKT
Atlas Alliance
|
Posted - 2010.08.23 18:25:00 -
[62]
Originally by: Kesper North Can you explain why you are using Maelstroms as a laser platform?
because, even after the projectile buff, a maelstrom with tachyons does more dps than a maelstrom with 1400mm's.
also, he said he was shooting for hours, so he probably didnt want something ammo-dependant. and matari ships are cool. so there ya go. i'd have taken abaddons myself...
|
Helios Black
Wraith.Wing Wildly Inappropriate.
|
Posted - 2010.08.23 18:30:00 -
[63]
Gotta say that I love the amount of blogs dedicated to informing us what's going on with fixing lag. Nice to hear about the technical aspects of things and know there's actually people out there who care about the issue and are working on it.
Thanks CCP!
Originally by: Helicity Boson Maybe you should go play Uno with your mom so you can be "second winner" again.
|
Dubyou Bush
|
Posted - 2010.08.23 18:32:00 -
[64]
STFU ***** and fix lag quit talkin
|
Helios Black
Wraith.Wing Wildly Inappropriate.
|
Posted - 2010.08.23 18:36:00 -
[65]
Originally by: Dubyou Bush STFU ***** and fix lag quit talkin
**** off.
Originally by: Helicity Boson Maybe you should go play Uno with your mom so you can be "second winner" again.
|
Master Akira
Child Head Injury and Laceration Doctors
|
Posted - 2010.08.23 18:38:00 -
[66]
Originally by: Dubyou Bush STFU ***** and fix lag quit talkin
You are an awesome poaster
|
Hykke
Free Imperial Vikings
|
Posted - 2010.08.23 18:39:00 -
[67]
Great series of dev blogs recently, this one in particular impressed me.
Being a developer myself I can appreciate the efforts you guys are doing to hunt down those illusive bugs and performance issues causing lag.
My guess is that sometime in the far far past there was a bug caused by the effect system not agreeing that a module should be cycled. The developer who got this bug report, then looked over the code and decided that this bug was so rare that he would just write a quick workaround. After this workaround was implemented the bug disappeared, and the problem was "solved" ... only to reappear 1.5 million times later :-)
Experience has taught me that a quick workaround is often the wrong solution to a problem
Great to see that you are not trying to implement a quick fix, but are trying to get to the root of the issue.
|
Ki Rathos
Minmatar Urban Mining Corp Swords Of Athena
|
Posted - 2010.08.23 18:47:00 -
[68]
I too was curious if there was a way to offload the effects processing to another node. If it is sounds like that might do the trick.
Think it would be cool too if you guys could develop some kind of tool that allows the thin client to say run on my comp and take requests from your central server, maybe have it connect into sisi.
Would leave it on while I am working, you guys would then have a veritable army of PC's ready to put tons of automated pew pew ships onto a node. Maybe once you guys add in some diagnostic tools. A system like that would allow you to mass test whenever you needed from actual client machines, sort of the end to end way to check on things.
|
Vaerah Vahrokha
Minmatar Vahrokh Consulting
|
Posted - 2010.08.23 19:25:00 -
[69]
The developer facial expression... almost repaid for all of the months worth of effort spent in asking for lag fixes. - Auditing & consulting
When looking for investors, please read http://tinyurl.com/n5ys4h + http://tinyurl.com/lrg4oz
|
|
CCP Shadow
C C P C C P Alliance
|
Posted - 2010.08.23 19:43:00 -
[70]
Off-topic posts removed. Stay classy.
|
|
|
Grez
Empire Assault Corp Dead Terrorists
|
Posted - 2010.08.23 20:03:00 -
[71]
Originally by: CCP Shadow Off-topic posts removed. Stay classy.
*grabs a glass of whiskey*
Will do, Sparky!
Thanks for the awesome dev blog! ---
|
Trebor Daehdoow
|
Posted - 2010.08.23 20:12:00 -
[72]
Originally by: Vuk Lau I will have liberty to say that I almost pooped all over Socratesz when I heard the famous "EVE is now, from a technical standpoint, in a better state than it has ever been." so my bet is that was pure example of nonsense
NDA or NDA, this is TMI IMHO.
Originally by: CCP Warlock But let's just say, that there's a little samizdat activity in CCP at the moment to provide an appropriately inappropriate t-shirt in order to properly memorialise that particular entry into the great list of "They can't hit an elephant from ther...." remarks.
Remember to print extras for the CSM. I take an XL.
Seriously now, excellent blog, it gives a good view of how the debugging process really works. And kudos to Vuk Lau for bringing the video to the meeting.
Confessions of a Noob Starship Politician Spending Hours blogging the Minutes
|
Selnix
Gallente North Eastern Swat Pandemic Legion
|
Posted - 2010.08.23 20:23:00 -
[73]
Originally by: CCP Veritas In other words, I believe Dogma is doing stupid things, and I intend to beat the stupid out of it before considering giving it rocket boots.
Given the current state of Rockets, only a stupid Dogma would try to use such boots.
Thx for a nice blog tho.
|
Amy Garzan
Gallente The Warp Rats Intrepid Crossing
|
Posted - 2010.08.23 20:39:00 -
[74]
Yay! Keep up the good work and techie blogs. I love reading them. -------------------------------------------------- 101010 The Answer to Life, The Universe, and Everything |
Mashie Saldana
BFG Tech
|
Posted - 2010.08.23 20:52:00 -
[75]
Originally by: Kesper North Can you explain why you are using Maelstroms as a laser platform?
I think it was mentioned elsewhere that it was civilian lasers.
18 months |
Glyken Touchon
Gallente Independent Alchemists
|
Posted - 2010.08.23 21:13:00 -
[76]
Originally by: Mashie Saldana
Originally by: Kesper North Can you explain why you are using Maelstroms as a laser platform?
I think it was mentioned elsewhere that it was civilian lasers.
Probably because it has 8 turrets & they didn't want to risk hurting the titan
|
Rage Spear
Minmatar Republic Military School
|
Posted - 2010.08.23 21:51:00 -
[77]
Best blog for a long, long time.
Thanks for writing this and good luck with finding some way to let us cycle our guns AND do everything else instead of just one or the other.
|
wizard87
|
Posted - 2010.08.23 21:57:00 -
[78]
Good blog, great pictures.
You're a good communicator CCP Veritas - you're analogies seem to make sense for the less technically inclined.
Hope you get a good appraisal as you appear to be one of the good eggs at CCP.
|
Brigitte Helm
Minmatar Native Freshfood
|
Posted - 2010.08.23 22:34:00 -
[79]
Thank you for a well thought out dev blog that explains not only the problem but how you find what the true problem is. Plus great photo
One minor correction the actual quote is "They couldn't hit an elephant at this dist..." General John Sedgwick's final words Hug a Carebear, Kill a pirate, squish a Rat, and tickle a dev.
Make Eve fun.... |
Xianthar
Vanishing Point. The Initiative.
|
Posted - 2010.08.23 22:43:00 -
[80]
surprised your using cooperative scheduling given the very dynamic workload, i figure you'd used preemptive scheduling or tasklets with some sort of tasklet priority assignment.
|
|
|
CCP Atropos
|
Posted - 2010.08.23 22:43:00 -
[81]
Originally by: Hawk TT Edited by: Hawk TT on 23/08/2010 16:55:18 Great Blog! Nice screenshots
For those interested in the Python GIL (Global Interpetter Lock) drawbacks and in Python cooperative-multitasking: David Beazley's - Understanding Python GIL - PyCon 2010
This is David Beazley's presentation @ PyCon 2010...who the f**k is David Beazley?!?! - OK, Google him The presentation is fun, it's informative, it shows how Python behaves on multiple-CPU cores (BAAAAD!) etc. The presentaiton also covers the issues when threads release control prematurely And there is some hope - a new GIL is being developed, unfortunately for Python 3.2+, but still it could be ported to Stackless 2.7...More or less, it seems that GIL will survive for the time being and will not be "killed" any time soon...
Hopefully CCP is working on something on their own...GIL in Python = No Benefits form Multicore Processing
I watched this since I was unable to attend PyCon this year and I have to agree; a very informative and not too technical view of life with the GIL.
Software Engineer Core Engineering |
|
Zendoren
Aktaeon Industries
|
Posted - 2010.08.24 00:57:00 -
[82]
That presentation goes to show you that, more often then not, laziness is the cause of most problems in life.
Sort answer is, the python Dev's are lazy and do not want to make a proper interpreter for its code, and CCP does not want to get into the programing language inventing business!
Looks like CCP is stuck between a rock and a hard place on the threading front!
So, how is that code refactoring project coming? Was the 3rd time the charm?
|
Jinli mei
Test Alliance Please Ignore
|
Posted - 2010.08.24 02:31:00 -
[83]
Is CCP doing anything fancy and magical like replacing the GIL for Python with something less suck?
|
OmegaTwig
THORN Syndicate Controlled Chaos
|
Posted - 2010.08.24 02:47:00 -
[84]
Originally by: Luke S Stupid question: Does module lag happen to all types of mods? Such as mining lasers?
If you can get everyone in Jita into one belt with enough Veldspar so that everyone can be mining at once, with drones and everything then yes i believe this will happen with ANYTHING that cycles and produces an effect...
BTW: Love the Devblog, +1 for pics... Gonna have to check more regularly for them because they are coming out more frequently!
FakeEdit: Found the RSS Feed, YAY!
|
Blazde
4S Corporation Morsus Mihi
|
Posted - 2010.08.24 03:31:00 -
[85]
Originally by: CCP Veritas I've been busy profiling it under some basic scenarios and there's some low hanging fruit to be plucked in there. There's significant algorithmic optimizations to be made as well, and those follow you around regardless of what language you're in
This single line answers all my frustrations with the feedback we've had so far about lag because any mention of basic low-level code optimisations has been glaringly absent before now. Please, please crack on with this. I spend a lot of time optimising code and it's really not uncommon to get 10-20 even 100 times speedup in code that hasn't been agressively optimised before, even if it was written fairly well in the first place. I have something I call the '10x rule': if giving your code ten times more time to run gives some significant benefit (removes a bottleneck, gives results previously unreachable, puts it acceptably inside a performance limit, cures lag!, etc) then optimise the hell out of it before even considering any costly high-level redesigns. In Python (or any other high level language) this applies more than ever because the language makes it very easy for a coder to do very costly things without realising it, if they don't fully understand what's happening underneath the hood.
In this case it sounds like the Dogma code is *the* fleet-fight bottleneck (makes perfect sense, activating modules/applying effects in very large numbers is pretty much the definition of a fleet fight), and it hasn't been agressively optimised in the past - resisting temption to ask why - so this should yield great results. (Hell just send me the Dogma sources and I'll send em back with all no-brainer optimisations done )
Regarding the Dogma yielding bug, was this introduced around October 2008? Ie. the exact time lag seemed to get much better. This was when fleet fight lag changed very dramatically from: - Not being able to lock - Warping/basic movement commands taking forever to initiate. You could 'queue up' warp commands, and often spent entire battles warping to the place you wanted to be at an hour earlier - Modules taking forever to active
to: - Warping/moving being extremely responsive - Locking often being pretty good - Ghost wrecks - Modules activating but not cycling, and getting stuck
There were theories at the time that devs had purposely changed the priorities of various commands, and it was seen as a very good thing because being in the right place and being able to lock stuff but not kill it fast is much less frustrating than being in the wrong place all the time being killed by the single ceptor that was lucky enough to lock you.
Some datapoints from my logs: 2008 Jan to June An attempt is underway to activate the module - 116 occurences An attempt is underway to deactivate the module - 2 occurences 2009 Jan to June (I did play quite a bit during this period, lag was just that good) activate - 0 deactivate - 3 2010 Jan to June activate - 7 deactivate - 245 (mainly occurs when deactivating mods by clicking their mini-icon next to target)
Regarding stuck modules I still think the problem is clientside as well. The server may stall sending the expected message back but it is the client that stops you interacting with the mod when it's blinky-red. If you could interact with it you could send new deactivation requests (which do somehow work), as shown by the mini-icon workaround. It's broken in normal non-laggy gameplay too because you can't do stuff you want to with a deactivating module like: - Right click on it to get it's show-info (eg. check your optimal/falloff) - Check or change it's autorepeat/autoreload status - Pre-heat it
Good engineers don't just fix a problem once afterall so I think you should fix this clientside too.
Anyway good luck and thanks for the blog, I might just have a new favourite dev (favourite new dev at the very least). _
Northern Coalition - Best friends forever <3 |
Liol Wongster
|
Posted - 2010.08.24 03:31:00 -
[86]
Originally by: Ki Rathos .........
Think it would be cool too if you guys could develop some kind of tool that allows the thin client to say run on my comp and take requests from your central server, maybe have it connect into sisi.
Would leave it on while I am working, you guys would then have a veritable army of PC's ready to put tons of automated pew pew ships onto a node. Maybe once you guys add in some diagnostic tools. A system like that would allow you to mass test whenever you needed from actual client machines, sort of the end to end way to check on things.
+1 for this. I would happily let this run for the hours I'm not able to be online and active myself. The mass tests all happen at a time that is no good for me to log in with my chars anyway. Anyway I caould help, I'd do happily. |
Vaal Erit
Science and Trade Institute
|
Posted - 2010.08.24 03:34:00 -
[87]
It looks like the lag hunting team and the thin client are making good progress. From the sound of this dev blog we might be getting a decent improvement in lag situations with the next expansion. Go go CCP! - It's not "Play through a pre-set story, become stronger, do endgame". Gameplay is open ended, and you make your own story. Unless you're too afraid of 'pvp grief' to do anything relevant |
Thor Brawn
|
Posted - 2010.08.24 03:36:00 -
[88]
Good work!!! Keep going and this game will become hotter than a Sandy beach with Victoria Secret models...
Well almost
|
Whatever Dood
|
Posted - 2010.08.24 03:38:00 -
[89]
Edited by: Whatever Dood on 24/08/2010 03:41:42 Edited by: Whatever Dood on 24/08/2010 03:41:11
Originally by: Jinli mei Is CCP doing anything fancy and magical like replacing the GIL for Python with something less suck?
I'd guess they plan on doing something like running a separate instance of the Python interpreter on each thread, each with completely separate GIL's, and then manage their thread interactions themselves.
I swear my IQ dropped 20 points watching that presentation. I have never seen anything so totally ******ed in my life. "This is a problem that's been solved in operating systems" - yeah, like two-three DECADES ago. "Don't use this talk to justify not using threads" - maybe to justify not using Python?
I had to watch the presentation here, original link doesn't play all the way through for me:
http://www.mefeedia.com/watch/28851035
|
Blazde
4S Corporation Morsus Mihi
|
Posted - 2010.08.24 03:46:00 -
[90]
Originally by: Axemaster Actually, why not use a gpu to process this? They seem tailor-made for these kinds of massive parallel computing problems.
GPU computing is not like having dozens of multi-purpose CPUs at you disposal. It's more like having dozens of scientific calculators each with say 128 bytes of RAM and attached to a shared hard drive. You can load some pretty complex programs onto them but you need to spend time pushing buttons to give them data at the start and to read it back from their screens at the end. They can't access your EVE database, or do any other useful I/O. Unless you can find enough highly parallel math based work for them to do then you spend all you time interacting with the calculators and never get any useful work done yourself. You in this case being a high performance general purpose computer yourself so you're pretty damn good at doing the same things you're spending time telling the calculators to do. Infact you're much, much better, there's just a lot of them.
It's surprisingly difficult to even come up with problems that benefit from GPU computing. _
Northern Coalition - Best friends forever <3 |
|
Agrilad
|
Posted - 2010.08.24 03:51:00 -
[91]
I really liked this dev blog. Almost need to make my manager read it, along with the rest of my team.
With 50.0% of my professional experience being in C# and the .Net framework. With the rest being T-SQL.
There is a very direct correlation in the problem you saw and the laziness of try..catch programming. Why bother to write good 'if' checks if you can just try..catch the statement and not worry about them? Every catch costs 17.5 ms (or did at that time on that server). Which is all fine and dandy in 10's and 100's of executions, but 1,000s? 10,000s? Where did this story come from? Well at a very base level, you have to translate a sql cell into an object in code. Some programmer at some point thought that testing whether a datetime is null was best with a try catch. So every nullable datetime field that was null in any db call to build our objects was costing 17.5 ms. So change that to an if check for null, and a massive server performance bottleneck fixed. (That 17.5 ms is the cost if an error occured and the .net framework had to process the error to the catch.)
One of my pet peeves.
Oh and the one course of my comp sci education that I directly apply every day I work, and I code all the way from core framework to UI. Is Algorithmic Analysis. It is as important in filling a UI with data, or changing visible controls, as it is to processing data at a low level.
The 2nd course was Programming Language Design. Basically what the differences are between the current languages and how to use them optimally.
My next favorite was real time computing.
|
Noun Verber
Gallente
|
Posted - 2010.08.24 06:04:00 -
[92]
For people still confused:
Converting the algorithm before fixing it will just allow it to do more stupid things in the same amount of time, but still need to be improved later (possibly by someone who will need to learn the stupid again), so it's best to do it early by someone who understands it.
|
Ban Doga
|
Posted - 2010.08.24 06:37:00 -
[93]
Good riddance!
But now think about how long this issue was present and how long it took you to fix that (and how long before that you did not even try to fix it). IMO there are quite a handful more of those "beauties" hiding in EVE.
Maybe this little bug can show you the difference between your "we are excellent" and your players' "please become excellent again".
|
ihcn
|
Posted - 2010.08.24 08:38:00 -
[94]
We need more dev blogs like this, that was interesting as hell
|
Caius Sivaris
Dark Nexxus
|
Posted - 2010.08.24 08:42:00 -
[95]
Hum, so this blog is basically admission that you started working on a bug that has been crippling and well known for years last June...
Quality first **** yeah.
|
Camios
Minmatar Insurgent New Eden Tribe
|
Posted - 2010.08.24 08:52:00 -
[96]
Originally by: ihcn We need more dev blogs like this, that was interesting as hell
This Dev blog is the best one because it's about specific problems we see in fleet fights, and it explains a lot of concerns of the playerbase.
I hope you are right when you say that there is much optimization to be done, but does that mean that it was coded badly?
|
Cheap Dude
|
Posted - 2010.08.24 09:59:00 -
[97]
Best blog yet! It's a good read because it's about 1 certain problem and the way to victory (the fix)
|
|
CCP Oveur
|
Posted - 2010.08.24 10:07:00 -
[98]
Edited by: CCP Oveur on 24/08/2010 10:07:51
Originally by: Caius Sivaris Hum, so this blog is basically admission that you started working on a bug that has been crippling and well known for years last June...
Quality first **** yeah.
No. What you might have missed in previous blogs and might not be as clear here is, that as big as this sounds, we have months of investigation, implementing fixes and testing left in the war against lag. This was a big low hanging fruit we saw. Like a pineapple. The size of the moon.
The next 100 fixes and improvements won't be that big, in fact they will most likely be the opposite where the gravity of the sun, the moon affect the dolphins capability to navigate but in a subtle way so that they miss the pineapple.
I hope that made sense.
Executive Producer EVE Online
|
|
Hirana Yoshida
Behavioral Affront
|
Posted - 2010.08.24 10:12:00 -
[99]
Were you really that surprised at "rare" in Eve meaning "OMG its everywhere!"?
Super-/capitals, pirate ships, bugs .. you name it.
Whenever something is referred to as rare it is in fact omni-present
Good blog though, good to see that the powers that be realise that sacrificing a little time to create tools pays off down the road.
|
RiotRick
Agony Unleashed Agony Empire
|
Posted - 2010.08.24 10:46:00 -
[100]
Edited by: RiotRick on 24/08/2010 10:46:18
Originally by: CCP Oveur This was a big low hanging fruit we saw. Like a pineapple. The size of the moon.
The next 100 fixes and improvements won't be that big, in fact they will most likely be the opposite where the gravity of the sun, the moon affect the dolphins capability to navigate but in a subtle way so that they miss the pineapple.
I hope that made sense.
You've had to much coffee --
|
|
Hawk TT
Caldari Bulgarian Experienced Crackers Circle-Of-Two
|
Posted - 2010.08.24 11:19:00 -
[101]
Originally by: Whatever Dood[quote=Jinli mei Is CCP doing anything fancy and magical like replacing the GIL for Python with something less suck?
I'd guess they plan on doing something like running a separate instance of the Python interpreter on each thread, each with completely separate GIL's, and then manage their thread interactions themselves. Edit: or rework the Python interpreter internals and remove it entirely.
I swear my IQ dropped 20 points watching that presentation. I have never seen anything so totally ******ed in my life. "This is a problem that's been solved in operating systems" - yeah, like two-three DECADES ago. "Don't use this talk to justify not using threads" - maybe to justify not using Python?
I had to watch the presentation here, original link doesn't play all the way through for me:
http://www.mefeedia.com/watch/28851035
One might wonder, why CCP took the decision to use Stackless Python in the first place? I think this is the place to justify that - back in 2001-2003 Intel used to promise 10+ GHz CPUs in 5 years. There were no dual/quad/multi-core CPUs in the workings. Apart from that, StacklessPython gives the Devs unique possibilities - running thousands of very light-weight tasklets (micro-threads), something unthinkable on the OS level, becasue of the very "expensive" OS threads (in terms of memory etc.). By the time EVE was ready for release, Intel and the others have shifted their strategies from "GHz is the King" to "Multi-core is the King", AMD came up with x64 instruction set (backward compatible with x86 32-bit code), the 64-bit evolution took off (meaining no 3/4GB memory limit in the OS).
Quite of a twist, as you might see...
Fast forward to 2010 - CCP has millions of lines of StacklessPython code, Multi-core really became the King, but the GIL stays...Rewriting EVE is different from refactoring, so this is not a viable option...
It would be really interesting if the CPP Devs share some thoughts about the possible directions they consider in order to overcome / remove the GIL obstacle - no commitments, no dates, just ideas ___________________________________ Science & Diplomacy Manager @ BECKS Circle-of-Two |
Tiger's Spirit
Caldari
|
Posted - 2010.08.24 11:26:00 -
[102]
I read devblog 1-2-3, but i didn't find from CCP "we found a solution" just "we found problems" technoblabla.
|
HeliosGal
Caldari
|
Posted - 2010.08.24 12:04:00 -
[103]
we seem to be getting a lot of gates locking up on jumping is this a side effect ?
|
|
CCP Explorer
|
Posted - 2010.08.24 12:07:00 -
[104]
Originally by: Vuk Lau
Originally by: Darth Vapour June 25th, 2010:
Quote: EVE is now, from a technical standpoint, in a better state than it has ever been.
And now this:
Quote: The "rare" error happened 1.5 million times in the month of June, 2010 on TQ.
Does this mean the error occurred even more before the server came to be in the best state it ever was or is the statement in the minutes the nonsense everyone thinks it is?
I will have liberty to say that I almost pooped all over Socratesz when I heard the famous "EVE is now, from a technical standpoint, in a better state than it has ever been." so my bet is that was pure example of nonsense
My dear Vuk Lau, you were present at both those CSM meetings, with CCP Oveur and then with CCP Atlas, and you have the full context of this remark and the full details. This disappoints me.
For everyone else: At the meeting with CCP Oveur then a claim was made that EVE was in its worst state ever. I rejected that such a general statement could be made and in the second meeting presented to the CSM the overall, general health of EVE. We emphasized at the second meeting that although overall general health was in good shape then we acknowledged that there were problems in 0.0 fleet fights. We had already been working on those issues at the time of the CSM meeting and have continued that work with reinforced vigour since then.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
|
CCP Oveur
|
Posted - 2010.08.24 12:30:00 -
[105]
Edited by: CCP Oveur on 24/08/2010 12:31:16
Originally by: Tiger's Spirit I read devblog 1-2-3, but i didn't find from CCP "we found a solution" just "we found problems" technoblabla.
It's maybe hard to spot in the blog but this revelation has lead to changes which are getting deployed to Tranquility and will be tweaked there.
It's an example where we found a problem, have a potential solution, that needs to be deployed to Tranquility and worked with there, data reviewed and gathering the experience.
It might work, it might have to be retracted, changed, approached differently (like in this case where a fix to something caused another problem) and ... well, yes, this is just the beginning of the lifecycle of identifying a problem. And yet this is just one solution to a specific problem of a hundred possible solutions to other problems that'll be tried in the coming months.
And I say a hundred because this is a long continuous fight. That means a lot of trial and error, many of which won't even go as far as ending up on Tranquility but die a horrible death on Singularity.
Executive Producer EVE Online
|
|
Bartholomeus Crane
Gallente The Crane Family
|
Posted - 2010.08.24 12:34:00 -
[106]
Oveur, leaving all the dolphins and unicorns aside. It is clear that you now have a couple of techies working for you who know what they are talking about and know how to use and develop proper tools and fix things (eventually). Also, what this blog shows is that the EVE code (at the least), still leaves a lot to be desired when it comes to excellence (or even stability). Call it technical debt if you want (I opt for technical depth, but OK). I think you've seen how not addressing these issues (publically at least) rankles with the players. Can you give the players any assurance that these guys (and gals) will get all the resources and support they need to, progressively, fix the quite substantial backlog of technical issues with EVE?
I think we can all agree that this won't happen over night. An aspect relatively neglected for so very long simply can't be fixed just like that (and some trade-offs will always have to be made). But, seriously, what guarantees do we as players currently have that management's attention won't focus away from this issue when some other shiny new development (or feature) props up on the horizon? Will Veritas, or Masterplan, or someone else, then be assigned away, in the scrum way, to, lets say, Incarna, or some other development idea?
As process has clearly been shown not to be CCP's strongpoint, what will you actually do, as the responsible producer, to prevent another diversion of attention away from these issues? 20% is all fine and dandy for those developers (in the strict sense) no directly assigned to the core development group, but, given how many bugs and fixes are still required to fix lag, and EVE in general; build up over years and years; what will you do to give these guys (and gals) all that they need and require? And what will you do to bring more knowledgeable developers into the team to speed things up (18 months and all that)?
Because, as it is, this is clearly a medium to long term process, and a technical one at that (not your strongpoint), but without some firm statements and quantifiable commitments to the future, this smells a bit too much like short-term placating of an irate customerbase. Now I have experience with Icelandic evasion of commitments (notwithstanding your dedication to spandex leisurewear) but there are no two ways about this: You've thrown your considerable weight behind this direction, quite visibly and vocally; you are, as the responsible producer, ultimately responsible for its success or failure; what will you do to maintain and expand it to a successful end? Specifically? Actually? With numbers?
EVE used to have a clear vision of where it was going (including, but not exclusive to, world domination). This was backed up by strongly held and expressed company core values for CCP. The aspect of CCP eventually getting things right and fixing things (and there was much wrong and broken, some of it is still around today) never needed explicit mention in that vision as it was covered by trust and belief (if you will). But with the diversions of Dust, WoD, and partially Incarna for CCP, the vision for EVE has become somewhat blurred for the outside world, and trust and belief in CCP eventually fixing the wrongs in EVE has sapped away. You've (be)lately re-found some of CCP's core values (from an outsides point of view) like transparency, and fearlessness. Beyond mere expressions of intent, isn't it about time to reconfirm (if that's the case) the vision CCP has for EVE (and in general), transparently, fearlessly; and confirm commitment to that vision concretely where trust and belief have lapsed over the years?
I understand that this might be a bit much to ask for a forum post, but a blog or something like that will do nicely as well. Such a commitment would go a long way to setting minds at ease, and I'm sure you'll agree it's the right thing to do right now ... Inappropriate signature removed. Zymurgist |
Freyya
Advanced Planetary Exports Intergalactic Exports Group
|
Posted - 2010.08.24 13:18:00 -
[107]
Very naice Devblog! Continue onwards like this in the years to come like you have in the years well past us. Ohh the fond memories of devs trolling on forums
Anyways, the way i read it, with a very limited understanding of programming whatever, is that evecode is suffering from osteoporosis. Especially the "rare" exception thrown shows this in detail. It's bones are starting to become too rigid and weak with the subscriber base and action piling up on it. The way i see it is that there's just too many services (be it location, character or effects node/whateveryacallit) piled up on a single thread and with each increasing action sent or requested to/from the node/thread/cpu/figure-it-out-whatever (from here on in called femur)it starts to crack untill it snaps.
What i've gathered is that you're already working your way to dynamic load balancing of nodes when fleetfights occur but is this also true for all the services you're running for each client? Would it not be benificial to replace the femur with a titanium specimen instead of injecting some cartilage around the cracks and hope it holds?
This ofcourse means rewriting entire sections of the evecode , which in turn will prove to be impossible because there are too few devvers and there are too many projects going on which rely on the current codebase already.
Would it however be workable to run each process that a client needs for updates as to speed, location, assets, damage, drones etc. etc. etc. etc. on a dedicated cpu/cluster/node/blade? Or is that actually the same effort it would take to rewrite the entire basecode....
Also; fix the forums so my typing window doesn't shoot back to top as soon as i start to get the scrollbar it's annoying as hell. ___________
NOW COLLECTING ISD AND CCP AUTOGRAPHS It'll be worth something someday. -Rauth
|
Axemaster
|
Posted - 2010.08.24 13:25:00 -
[108]
Originally by: Bartholomeus Crane EVE used to have a clear vision of where it was going (including, but not exclusive to, world domination). This was backed up by strongly held and expressed company core values for CCP. The aspect of CCP eventually getting things right and fixing things (and there was much wrong and broken, some of it is still around today) never needed explicit mention in that vision as it was covered by trust and belief (if you will). But with the diversions of Dust, WoD, and partially Incarna for CCP, the vision for EVE has become somewhat blurred for the outside world, and trust and belief in CCP eventually fixing the wrongs in EVE has sapped away. You've (be)lately re-found some of CCP's core values (from an outsides point of view) like transparency, and fearlessness. Beyond mere expressions of intent, isn't it about time to reconfirm (if that's the case) the vision CCP has for EVE (and in general), transparently, fearlessly; and confirm commitment to that vision concretely where trust and belief have lapsed over the years?
I think this hits the point exactly. The thing I always found disturbing in all this controversy was the fact that CCP seemed... murky? Not sure that's the right word, but I think that a lot of people were having a hard time understanding what was going on, what was actually going on, with the developers. The fact that there was no clear message for such a long period of time, made many people feel that they were being ignored.
We want to have confidence in you. The best thing you can do, now and in the future, is to respect us, and give us honesty and transparency. The worst thing you can do, is to allow the PR people to take control of the dialogue.
As long as you behave openly, you ultimately will have nothing to fear. Let us know what's really going on, tell us when new things come up, good or bad. The playerbase will be glad to have you, and your occasional mistakes will be forgiven because of that goodwill.
|
Mara Rinn
|
Posted - 2010.08.24 13:36:00 -
[109]
Originally by: Bartholomeus Crane Also, what this blog shows is that the EVE code (at the least), still leaves a lot to be desired when it comes to excellence (or even stability). Call it technical debt if you want (I opt for technical depth, but OK).
Technical Debt is a technical term which is vastly different in meaning to technical depth.
Technical Debt is best explained as code that was built in a hurry to meet a deadline, that someone thought they'd get back to later, but seven years down the track it's still that hurriedly built mess of spaghetti that is now the focus of a major bug report.
There are two ways of addressing technical debt - one is to only add one or two new features every six months while half the team works on fixing bugs. The other is to halt development for twelve months while everyone works on fixing bugs.
When you have an MMO which sees massive increases in new subscribers every time you release new features, which way would you go?
-- [Aussie players: join ANZAC channel] |
Bartholomeus Crane
Gallente The Crane Family
|
Posted - 2010.08.24 13:43:00 -
[110]
Originally by: Mara Rinn
Originally by: Bartholomeus Crane Also, what this blog shows is that the EVE code (at the least), still leaves a lot to be desired when it comes to excellence (or even stability). Call it technical debt if you want (I opt for technical depth, but OK).
Technical Debt is a technical term which is vastly different in meaning to technical depth.
Technical Debt is best explained as code that was built in a hurry to meet a deadline, that someone thought they'd get back to later, but seven years down the track it's still that hurriedly built mess of spaghetti that is now the focus of a major bug report.
There are two ways of addressing technical debt - one is to only add one or two new features every six months while half the team works on fixing bugs. The other is to halt development for twelve months while everyone works on fixing bugs.
When you have an MMO which sees massive increases in new subscribers every time you release new features, which way would you go?
Yes, thank you, but I'm quite aware what the difference between the two terms is. Which is why I used them in the way I did. And no, those are not the only two ways of addressing technical dept, but thanks for trying ... Inappropriate signature removed. Zymurgist |
|
Ban Doga
|
Posted - 2010.08.24 14:01:00 -
[111]
Edited by: Ban Doga on 24/08/2010 14:03:00
Originally by: Mara Rinn
Originally by: Bartholomeus Crane Also, what this blog shows is that the EVE code (at the least), still leaves a lot to be desired when it comes to excellence (or even stability). Call it technical debt if you want (I opt for technical depth, but OK).
Technical Debt is a technical term which is vastly different in meaning to technical depth.
Technical Debt is best explained as code that was built in a hurry to meet a deadline, that someone thought they'd get back to later, but seven years down the track it's still that hurriedly built mess of spaghetti that is now the focus of a major bug report.
There are two ways of addressing technical debt - one is to only add one or two new features every six months while half the team works on fixing bugs. The other is to halt development for twelve months while everyone works on fixing bugs.
When you have an MMO which sees massive increases in new subscribers every time you release new features, which way would you go?
Technical debt comes from "financial debt" and should be treated like that: Incurring debt can allow you to achieve/do things which would be impossible without doing so but excessive debt can slow you down, in the most extreme cases to the point where it crushes you completely.
Technical debt is not the same a bug (a technical debt can cause a bug, but strictly speaking one is the cause and the other is the effect; a complete bug-free system can be loaded with technical debt) like financial debt is not the same as a miscalculation in your budget or a deviation from the planned expenses.
As with financial debt a strict "zero debt policy" will only slow you down and make your life much harder than is has to be, but accumulating execessive amounts of debt will ruin you. The only long-term way is to keep aware and in control of debt and use it where it helps you and prevent and fight it where it hurts you.
|
Katarin Savage
Gallente azinko
|
Posted - 2010.08.24 14:05:00 -
[112]
excellent sleuthing there CCP and I worship at the feet of CCP:-
-0- _v_ -0- _v_
for magically investigate this infamous ally of the lag monster!!!
Apart from pledging my undyling love for CCP, I cant offer anything constructive but at least I can shout out:-
CCP are gods for being so diligent and awesome in finding, fixing and reporting their combat with the lag monster and its' friends == our enemies!!!
However, perhaps you could document this work (as CCP Veritas has done with his most excellent awesomeness) and send it over to Microsoft so they can apply similar duly diligent awesomeness in fixing the many bugs in windows7 and all its allies?? However, I am more confident thatn CCP will do a better job than Microsoft... x oo (x infinity) katarin savage ceo, azinko corp building a better future |
Axemaster
|
Posted - 2010.08.24 14:22:00 -
[113]
Edited by: Axemaster on 24/08/2010 14:25:35
Originally by: Mara Rinn
Originally by: Bartholomeus Crane Also, what this blog shows is that the EVE code (at the least), still leaves a lot to be desired when it comes to excellence (or even stability). Call it technical debt if you want (I opt for technical depth, but OK).
Technical Debt is a technical term which is vastly different in meaning to technical depth.
Technical Debt is best explained as code that was built in a hurry to meet a deadline, that someone thought they'd get back to later, but seven years down the track it's still that hurriedly built mess of spaghetti that is now the focus of a major bug report.
There are two ways of addressing technical debt - one is to only add one or two new features every six months while half the team works on fixing bugs. The other is to halt development for twelve months while everyone works on fixing bugs.
When you have an MMO which sees massive increases in new subscribers every time you release new features, which way would you go?
But you're forgetting the fact that the players themselves are the best advertisers. And the fact that adding more features only makes an already complicated game even harder for noobs to get their mind around.
Consider both of those, and you realize it's really more in CCP's best interest to spend more time on polishing existing content, as opposed to making even more unpolished stuff.
Edit: Btw, I don't know if the devs are still reading this thread, but I was still hoping for an answer to my question back at post 38.
|
Zendoren
Aktaeon Industries
|
Posted - 2010.08.24 14:28:00 -
[114]
Originally by: Hawk TT
....
Fast forward to 2010 - CCP has millions of lines of StacklessPython code, Multi-core really became the King, but the GIL stays...Rewriting EVE is different from refactoring, so this is not a viable option...
....
I mentioned refactoring because if they do decide to switch to I different language, all that hard work with optimizing the code for stackless python will be for not.
Sorry if the smileys at the end confused you!
|
|
CCP Veritas
|
Posted - 2010.08.24 14:53:00 -
[115]
Originally by: Axemaster Btw, I don't know if the devs are still reading this thread, but I was still hoping for an answer to my question back at post 38.
Yup, we are. I thought I handled post 38 in post 48. Did I miss something?
|
|
|
CCP Veritas
|
Posted - 2010.08.24 14:58:00 -
[116]
Originally by: Bartholomeus Crane Big callout of Oveur
Oveur's busy dreaming of dolphins and unicorns at the moment (or whatever it is Producers do ), but I can say from my side of things that I have no complains so far about support for the work I want to be doing here. We've got a good team formed with a clear mandate, some good tools and more on the way, and the hardware we need to run with it.
|
|
Louis deGuerre
Gallente Amicus Morte Shock an Awe
|
Posted - 2010.08.24 15:09:00 -
[117]
My respect for your excellent explanation. I think even non-technies might be able to understand. I realize a bug like this must have been a pain to trace (which does make me think, no logging wtf ?). So \o/ for you guys.
I still think you should allocate a lot more resources to EVE, the game proper. You're saying yourself how much work there is left to do to dig out the bugs. Sol: A microwarp drive? In a battleship? Are you insane? They arenÆt built for this! Clear Skies - The Movie
|
Axemaster
|
Posted - 2010.08.24 15:17:00 -
[118]
Originally by: CCP Veritas
Originally by: Axemaster Btw, I don't know if the devs are still reading this thread, but I was still hoping for an answer to my question back at post 38.
Yup, we are. I thought I handled post 38 in post 48. Did I miss something?
My bad, I meant post 56.
|
Tres Farmer
Gallente Federation Intelligence Service
|
Posted - 2010.08.24 15:22:00 -
[119]
Originally by: CCP Veritas
Originally by: Bartholomeus Crane Big callout of Oveur
Oveur's busy dreaming of dolphins and unicorns at the moment (or whatever it is Producers do ), but I can say from my side of things that I have no complains so far about support for the work I want to be doing here. We've got a good team formed with a clear mandate, some good tools and more on the way, and the hardware we need to run with it.
Any chance for a list of services/processes running on the location node for us to see? please
|
SARPIDON
THE BLUE BEYOND
|
Posted - 2010.08.24 15:39:00 -
[120]
Edited by: SARPIDON on 24/08/2010 15:39:32 Edited by: SARPIDON on 24/08/2010 15:39:17
Originally by: CCP Veritas
Originally by: Bartholomeus Crane Big callout of Oveur
Oveur's busy dreaming of dolphins and unicorns at the moment (or whatever it is Producers do ), but I can say from my side of things that I have no complains so far about support for the work I want to be doing here. We've got a good team formed with a clear mandate, some good tools and more on the way, and the hardware we need to run with it.
Big call out indeed, as has been noted in other EvE related forums. Looking forward to the reply.
Thanks for the blog. It managed to convey the issues you've have faced and still yet to face really well. For a total non techy like me, that's no small feat.
|
|
|
CCP Oveur
|
Posted - 2010.08.24 15:49:00 -
[121]
Originally by: Bartholomeus Crane Oveur, leaving all the dolphins and unicorns aside.
Never. I'm also not that fat.
Originally by: Bartholomeus Crane It is clear that you now have a couple of techies working for you who know what they are talking about and know how to use and develop proper tools and fix things (eventually)
Let's be fair and not confuse the competence of my team with my incompetence in getting communicated what they are doing and why.
Originally by: Bartholomeus Crane Serious business.
I did an earlier reply on the 18 months and what changed in recent times and later on commitment to EVE, both of which should be turned into a blog as they are excellent examples of where my statements on strategy and commitment should be put forth in a more visible manner.
The short answer till then is the boys and gals in the team working on lag specifically have a clear mandate and resources available to them till they are done. This is in addition to the "20% allocation" of the other teams both fixing lag, fixing bugs and refactoring.
Short answer for long term vision of EVE shorter than "world domination" is that EVE will continue to have one of the largest development teams in the industry on it till it dies. It has to date and it will continue to have that.
In numbers? CCP is reaching 600 people because we hired new teams for our new games instead of moving them away from EVE which is the common thing to do in our industry.
I'm sure you'll probably ask why they aren't all working on EVE. We have tried and the diminishing returns are staggering and we believe in Dunbar's number. This is the reason why we have compartmentalized core technology and game teams into scrum teams, to counter that.
That's it for now, I need to continue my eternal struggle of death by meetings. Blog will come but you will have read most of it's content right now, par perhaps more details on the game vision.
Executive Producer EVE Online
|
|
|
CCP Veritas
|
Posted - 2010.08.24 16:09:00 -
[122]
Originally by: Axemaster My bad, I meant post 56.
Right-o. I let that one go 'cause I honestly don't know much of the inner workings of the physics simulation. It's also fairly low load on the profiles I've seen, and so long as it stays that way I'll remain ignorant of it.
I'm a big fan of spending time looking at the biggest problems, not the most interesting ones. I certainly didn't set out at this aiming to get to know the inner workings of Dogma, but it's proven itself to be the biggest problem, so that's exactly what I'm doing.
|
|
Caius Sivaris
Dark Nexxus
|
Posted - 2010.08.24 16:39:00 -
[123]
Originally by: CCP Oveur Edited by: CCP Oveur on 24/08/2010 10:07:51
Originally by: Caius Sivaris Hum, so this blog is basically admission that you started working on a bug that has been crippling and well known for years last June...
Quality first **** yeah.
No. What you might have missed in previous blogs and might not be as clear here is, that as big as this sounds, we have months of investigation, implementing fixes and testing left in the war against lag. This was a big low hanging fruit we saw. Like a pineapple. The size of the moon.
The next 100 fixes and improvements won't be that big, in fact they will most likely be the opposite where the gravity of the sun, the moon affect the dolphins capability to navigate but in a subtle way so that they miss the pineapple.
I hope that made sense.
I'm actually reading all dev blogs. TBH I enjoyed throughly this one, it shows someone with the right skill set being assigned to a problem, tackling it and making obvious progress. Very good so far. (can he do the overview next, so tired of ghosts and flashy red stations....)
What bothers me immensely is that it took the CSM showing you a video for the specific problem (weapon cycling issues, not lag in general in all its manifestation) being worked on. The workaround for this specific bug (manual weapon cycling) has been discussed openly on forums since at least 2008, so the hint was right there. I would however bet good isks that the issue never made it to a dev because the bug reports were relentlessly filtered, because yes, a reproduction case was hard to impossible to find.
The bug hunters discarding bug report are shielding the devs from the truth and doing the game a disservice. I'm afraid it's the balls of destiny being discovered by a player, discarded and rediscovered independently by a dev all over again.
|
Axemaster
|
Posted - 2010.08.24 16:53:00 -
[124]
Originally by: CCP Veritas
Originally by: Axemaster My bad, I meant post 56.
Right-o. I let that one go 'cause I honestly don't know much of the inner workings of the physics simulation. It's also fairly low load on the profiles I've seen, and so long as it stays that way I'll remain ignorant of it.
I'm a big fan of spending time looking at the biggest problems, not the most interesting ones. I certainly didn't set out at this aiming to get to know the inner workings of Dogma, but it's proven itself to be the biggest problem, so that's exactly what I'm doing.
Fair enough, I figured that was probably the reason you passed it over. I'd bet the way the engine works, is it really has just one main equation; a one dimensional equation dictating the speed (scalar) of a ship approaching a target speed. All you'd have to do is input the current speed of the ship, and the target speed (plus variables for mass, inertia modifier, ship max speed etc.), and the equation would predict the future speed curve.
Do that 1D equation in all three dimensions and you'd have a simple predictive equation for the vector velocity of the ship. To find the magnitude, just pop on the 3D equation for the hypotenuse (actually, you'd have to backtrack that part in writing the equation, since the hypotenuse is actually the max velocity, making the 1D speed maximum dynamic).
So that works for the "approach" command. To do "orbit", just approach the tangent of a sphere around the target, and update it every second or so (this is evident especially in the orbits of drones).
Now that you can predict velocities, all you have to do to find the position of a ship is integrate the velocity equation and add any change to the last recorded position vector. So in other words, you can fully describe the dynamics in an analytic manner. I strongly suspect that that's exactly how Dogma works, which is good and efficient.
Collisions in Eve are a bit odd though. They seem to use a sphere with a "force gradient" around the ship, meaning that when ships are colliding, they are updating their equations repeatedly as they slip through each other's collision spheres. Evidence for this comes from the way ships sometimes bounce around inside a station, actually picking up speed (which is impossible without a "force gradient" or similar). That's not efficient at all, and is both unnecessarily complex and a waste of server resources.
Instead, ships should have a collision sphere that is somewhat smaller, or perhaps even in a shape that fits closely around the ship (like an oval). When two such shapes intersect, they would exchange momentum based on a vector normal to the colliding edges of the spheres. That momentum transfer (which could easily be based purely on simple 1D collision physics applied to 3D) would set the new target velocity, via the earlier velocity equation. The "depth" of the collision could be represented by a scalar modification to the mass/inertia of the ship by some percentage, meaning that deeper collisions would produce a more rapid change in direction and speed.
By that means, you could basically run a collision with a single calculation, which makes it simple and easy to understand, and of course more efficient. You could even make the collisions partially inelastic depending on the angle of attack, simulating the "crunching" as opposed to "bouncing".
Hope this helps your thinking when you play with Dogma!
|
Bartholomeus Crane
Gallente The Crane Family
|
Posted - 2010.08.24 16:57:00 -
[125]
Edited by: Bartholomeus Crane on 24/08/2010 16:58:46
Originally by: CCP Veritas
Originally by: Bartholomeus Crane Big callout of Oveur
Oveur's busy dreaming of dolphins and unicorns at the moment (or whatever it is Producers do ), but I can say from my side of things that I have no complains so far about support for the work I want to be doing here. We've got a good team formed with a clear mandate, some good tools and more on the way, and the hardware we need to run with it.
Well, that is certainly good to hear, because it seems you and the rest of the team are (finally, belatedly, eventually, whatever adverb you wish to apply here) getting things together and building up some momentum.
With the long long lists from the CSM and elsewhere, and the role the core teams clearly have to play in addressing a lot of those issues; I want to be sure that you keep that good team together, preferably grow it when possible/efficient, and keep getting the support you need to get the necessary tools, hardware, and most precious of all, time to strive for the excellence on the technical side EVE needs and is currently (in places) missing.
It is that medium- to long-term commitment I'm after, and the only guarantee I see working is if the quy responsible (who is next in line for a reply) makes a clear and public promise (we, the players, can and will be keeping him to) to do so.
Anyway, good blog, the situation sounds painfully familiar, but keep at it, eventually things will fall into place ... Inappropriate signature removed. Zymurgist |
Raimo
Genos Occidere HYDRA RELOADED
|
Posted - 2010.08.24 17:16:00 -
[126]
Originally by: Caius Sivaris
What bothers me immensely is that it took the CSM showing you a video for the specific problem (weapon cycling issues, not lag in general in all its manifestation) being worked on. The workaround for this specific bug (manual weapon cycling) has been discussed openly on forums since at least 2008, so the hint was right there. I would however bet good isks that the issue never made it to a dev because the bug reports were relentlessly filtered, because yes, a reproduction case was hard to impossible to find.
The bug hunters discarding bug report are shielding the devs from the truth and doing the game a disservice. I'm afraid it's the balls of destiny being discovered by a player, discarded and rediscovered independently by a dev all over again.
This is a very good point. While I'm sure many BHs do a lot of good unthankful work, the general (and my personal) experience when submitting bug reports, especially of the "low hanging fruit" variety is very discouraging. Hell, I'm trying to help CCP fix their product for free and I get to go through a ton of hoops only to get my issue either added in to an age- old pile or it's "working as intended" (or "irreproduceable" like hinted here)
Also, enable inserting multiple spaces (for speed-search with copypasting) in to the contract item type field as well as the bookmark generation name field! (Just my personal "working as intended" pet peeve/ very bad bugreporting experience ) ---------- www.eve-arena.com
|
Tres Farmer
Gallente Federation Intelligence Service
|
Posted - 2010.08.24 17:29:00 -
[127]
Originally by: CCP Veritas
Originally by: Axemaster My bad, I meant post 56.
Right-o. I let that one go 'cause I honestly don't know much of the inner workings of the physics simulation. It's also fairly low load on the profiles I've seen, and so long as it stays that way I'll remain ignorant of it.
I'm a big fan of spending time looking at the biggest problems, not the most interesting ones. I certainly didn't set out at this aiming to get to know the inner workings of Dogma, but it's proven itself to be the biggest problem, so that's exactly what I'm doing.
How many more services are there in the code for which can be said the same?!?
|
Bartholomeus Crane
Gallente The Crane Family
|
Posted - 2010.08.24 17:34:00 -
[128]
Originally by: CCP Oveur
Originally by: Bartholomeus Crane Oveur, leaving all the dolphins and unicorns aside.
Never. I'm also not that fat.
Well, the weight thrown around was mentioned purely metaphysically ofcourse. I guess.
Originally by: CCP Oveur
Originally by: Bartholomeus Crane It is clear that you now have a couple of techies working for you who know what they are talking about and know how to use and develop proper tools and fix things (eventually)
Let's be fair and not confuse the competence of my team with my incompetence in getting communicated what they are doing and why.
Well, I grant you that, but from my point of view, it also took them quite some convincing to 'do-it-another-way', as it where. That, and your self-acknowledged lack of technical understanding of the issues involved, gives pause to worry. This is not an issue that allows for a wandering eye. What is needed is someone responsible to fully grab the bull by the horns are ride it headlong off a cliff. OK, not the best mixed metaphor here, but you know what I mean, and guess what: you are it ...
Originally by: CCP Oveur
Originally by: Bartholomeus Crane Serious business.
I did an earlier reply on the 18 months and what changed in recent times and later on commitment to EVE, both of which should be turned into a blog as they are excellent examples of where my statements on strategy and commitment should be put forth in a more visible manner.
The short answer till then is the boys and gals in the team working on lag specifically have a clear mandate and resources available to them till they are done. This is in addition to the "20% allocation" of the other teams both fixing lag, fixing bugs and refactoring.
Short answer for long term vision of EVE shorter than "world domination" is that EVE will continue to have one of the largest development teams in the industry on it till it dies. It has to date and it will continue to have that.
In numbers? CCP is reaching 600 people because we hired new teams for our new games instead of moving them away from EVE which is the common thing to do in our industry.
I'm sure you'll probably ask why they aren't all working on EVE. We have tried and the diminishing returns are staggering and we believe in Dunbar's number. This is the reason why we have compartmentalized core technology and game teams into scrum teams, to counter that.
That's it for now, I need to continue my eternal struggle of death by meetings. Blog will come but you will have read most of it's content right now, par perhaps more details on the game vision.
Yes, there have been many statements in the forums, and through dev blogs, on a great many issues in the past few weeks. On :18months:, commitment to EVE, mandates, resources, focus, 80-20 percent rules; but each separate titbit of information, and there have been many, leads also to speculation, interpretation, and general hubbub, which then has to be reacted upon. That's fine in itself. It certainly is a lot better than the corporate messaging going on previously. But what is missing is the one vision statement to tie it all together. Which like a nice carpet, really ties the room together.
And that's what management is supposed to do (beyond death-by-meeting): tie things together into a long-term vision. It's not an easy thing to do, because it means stepping back from the daily stream of disasters that also need to be solved, but it is equally vital, perhaps even more so.
A nice long blog on how CCP sees EVE in the future, what is needed for that, how to get there, how everything done now fits into that (Carbon, Dust, Incarna, whatever), and lots of promises on how you're going to do it. Is that the blog you're intending to write? If so: will read ... Inappropriate signature removed. Zymurgist |
Dubyou Bush
|
Posted - 2010.08.24 17:34:00 -
[129]
I see you erased my post. Okay, well let me put it in different words. Stop talking about it and fix lag. These blog posts are'nt going to do anything if we don't see any results. You've had months, my friends are all going afk and it sucks. The second someone comes up with a comparable PVP mmo you guys are going to get blown out of the water. Results, or shut up - that's my opinion.
|
Ranger 1
Amarr Dynaverse Corporation Sodalitas XX
|
Posted - 2010.08.24 17:52:00 -
[130]
Originally by: Dubyou Bush I see you erased my post. Okay, well let me put it in different words. Stop talking about it and fix lag. These blog posts are'nt going to do anything if we don't see any results. You've had months, my friends are all going afk and it sucks. The second someone comes up with a comparable PVP mmo you guys are going to get blown out of the water. Results, or shut up - that's my opinion.
===== If you go to Za'Ha'Dum I will gank you. |
|
Axemaster
|
Posted - 2010.08.24 18:21:00 -
[131]
Originally by: Dubyou Bush I see you erased my post. Okay, well let me put it in different words. Stop talking about it and fix lag. These blog posts are'nt going to do anything if we don't see any results. You've had months, my friends are all going afk and it sucks. The second someone comes up with a comparable PVP mmo you guys are going to get blown out of the water. Results, or shut up - that's my opinion.
RAWR
|
Whatever Dood
|
Posted - 2010.08.24 18:28:00 -
[132]
Originally by: Dubyou Bush I see you erased my post. Okay, well let me put it in different words. Stop talking about it and fix lag. These blog posts are'nt going to do anything if we don't see any results. You've had months, my friends are all going afk and it sucks. The second someone comes up with a comparable PVP mmo you guys are going to get blown out of the water. Results, or shut up - that's my opinion.
I bolded the parts that are wrong.
|
Freyya
Advanced Planetary Exports Intergalactic Exports Group
|
Posted - 2010.08.24 19:07:00 -
[133]
Normally i'm not one to press anything but I was really wondering about my previous question and still hoping on an answer that will elevate me a bit more to the knowledge you lot possess. Like from the depths of hell as in ; AARRGH, My brain is on fire...wtf are they talking about and am i on the right track asking a question that will at least help move me up a notch in Dante's Inferno? 104 Pretty please with Oveur in even tighter spandex riding a unicorn alongside some dolphins graciously swirling through the river of life dominating the world? (It appears to be the magic combination of summoning a dev to respond so what the hell) ___________
NOW COLLECTING ISD AND CCP AUTOGRAPHS It'll be worth something someday. -Rauth
|
Whatever Dood
|
Posted - 2010.08.24 19:24:00 -
[134]
Originally by: Freyya Normally i'm not one to press anything but I was really wondering about my previous question and still hoping on an answer that will elevate me a bit more to the knowledge you lot possess. Like from the depths of hell as in ; AARRGH, My brain is on fire...wtf are they talking about and am i on the right track asking a question that will at least help move me up a notch in Dante's Inferno?
If you don't mind a non-CCP dev taking a crack at it, the pertinent section you're looking for an answer to is...
Originally by: Freyya Would it however be workable to run each process that a client needs for updates as to speed, location, assets, damage, drones etc. etc. etc. etc. on a dedicated cpu/cluster/node/blade? Or is that actually the same effort it would take to rewrite the entire basecode....
What we're talking about here is decomposing the "location" or fleet-fight load-balancing unit (LBU), which is a process, into multiple threads. (They've already said that's in the works, and I agree with Warlock that a precondition is to finish the dynamic LBU reallocation work before attacking the fleet-fight concurrency problem.)
Anyway. All the processing you're referring to is very fine grain. It would involve communication between threads at a high frequency, so would probably be best handled on a single node, with the threads running concurrently on multiple cores. This is so that the threads handling speed, damage, drones, whatever etc. can communicate to each other through shared memory, which is very fast compared to cross-node (ie, over LAN) communication.
Exactly how the processing is broken up depends on current processing flow, which is an interesting problem. But, regardless, the solution is to decompose the load into schedulable processing blocks and fire them off on separate cores, not nodes, blades, cpus, etc. (Exactly how is again, very interesting.)
It's probably reasonable to exhaust all conventional optimization opportunities AND finish dynamic node reallocation support before attacking this.
|
|
CCP Veritas
|
Posted - 2010.08.24 19:31:00 -
[135]
Originally by: Freyya Pretty please with Oveur in even tighter spandex riding a unicorn alongside some dolphins graciously swirling through the river of life dominating the world?
Please, please, no more spandex.
Also, what Mr. Dood said. If he didn't clear it up, please refine your question a bit - I kept thinking about my mom and hoping she's taking her calcium supplements.
|
|
|
CCP Oveur
|
Posted - 2010.08.24 20:10:00 -
[136]
Originally by: Bartholomeus Crane :18months:
Yes, I intend on write about that.
Ps. Thank you for the kind words on scrapheap.
Executive Producer EVE Online
|
|
Tiruriku
|
Posted - 2010.08.24 20:25:00 -
[137]
Thanks CCP:
Like most people I could easily write a 'Top 10 Things I'd Change If I Was An Eve Developer' which probably exists on some 'under consideration' plan somewhere and, until recently, I definitely felt as if less and less attention was being spent on the core issues.
I've been playing EVE for over a year (and reading each dev blog) and the posts from the past two weeks represent what appears to be a new side of CCP. I find both the technical information, as well as the processes you use, to be quite interesting. As a developer I know these are very difficult issues to solve but I'm fully convinced now that it is definitely being worked on and CCP is highly motivated to fix them.
Let me also say that it is rare to see any company be so forthcoming with their process and game architecture and I'm finding it quite fascinating. Coworkers who don't play EVE have read them and found them interesting. I very much hope entries like these continue because it reinforces the fact that you are committed to quality far more than simply saying you are committed to quality. Well done.
|
Whatever Dood
|
Posted - 2010.08.24 20:31:00 -
[138]
Originally by: Tiruriku Let me also say that it is rare to see any company be so forthcoming with their process and game architecture and I'm finding it quite fascinating. Coworkers who don't play EVE have read them and found them interesting.
The amount of information provided by CCP into their process is borderline surreal. This is NOT normal. (I can't actually think of any recent parallel.)
|
Master Akira
Child Head Injury and Laceration Doctors
|
Posted - 2010.08.24 20:36:00 -
[139]
Originally by: CCP Oveur
Originally by: Bartholomeus Crane :18months:
Yes, I intend on write about that.
Please do!
I have read blogs about technical stuff, about bugs, about balance and gameplay issues, about new shinies... but never have read one of longterm plans, of where do YOU want the game to be in the future...
I have only read somewhere something about a masterplan written on a napkin about tech 5 and world domination.
Originally by: CCP Oveur Ps. Thank you for the kind words on scrapheap.
Lol. <Insert notsureifserious.jpg image here>
|
|
CCP Atropos
|
Posted - 2010.08.24 21:12:00 -
[140]
Originally by: Freyya Normally i'm not one to press anything but I was really wondering about my previous question and still hoping on an answer that will elevate me a bit more to the knowledge you lot possess. Like from the depths of hell as in ; AARRGH, My brain is on fire...wtf are they talking about and am i on the right track asking a question that will at least help move me up a notch in Dante's Inferno? 104 Pretty please with Oveur in even tighter spandex riding a unicorn alongside some dolphins graciously swirling through the river of life dominating the world? (It appears to be the magic combination of summoning a dev to respond so what the hell)
If I might clarify your analogy; we're not fixing up a broken femur, as you suggested, rather we're replacing them with the provided titanium specimens where relevant. Most of the code is perfectly fine; as CCP Veritas mentioned elsewhere, there are places where improvements can be made, and redesigns are needed, and we won't be shying away from those, but there's no need to recode a service just because you think you might get better performance. It's all about systematic research and testing, no more shots in the dark.
Software Engineer Core Engineering |
|
|
|
CCP Atropos
|
Posted - 2010.08.24 21:18:00 -
[141]
Originally by: Caius Sivaris What bothers me immensely is that it took the CSM showing you a video for the specific problem (weapon cycling issues, not lag in general in all its manifestation) being worked on. The workaround for this specific bug (manual weapon cycling) has been discussed openly on forums since at least 2008, so the hint was right there. I would however bet good isks that the issue never made it to a dev because the bug reports were relentlessly filtered, because yes, a reproduction case was hard to impossible to find.
The bug hunters discarding bug report are shielding the devs from the truth and doing the game a disservice. I'm afraid it's the balls of destiny being discovered by a player, discarded and rediscovered independently by a dev all over again.
You would be surprised at how many bug reports have nothing more for reproduction steps than "just hold a fleet fight and have some guys jump through a gate". I've seen people posting on the forums claiming that they've just submitted a bug report with pages of information on how a bug occurs and the cure for world hunger, only to look at the bug report and find it contains nothing more than the example I gave above.
The CSM's video however works wonderfully; it clearly shows a bunch of things, with a wealth of client activity and the effects that are seen when a particular bug presents itself, including all the little things that people forget to mention in bug reports that are crucial to fixing the problem! I would even go as far as to suggest all bug reports have handy videos attached detailing the ingame effect of a bug; they've proven immensely useful.
That said, we're always after more people bug reporting, simply so we can track how prevalent a problem is.
Software Engineer Core Engineering |
|
Amida Ta
German Mining and Manufacture Corp.
|
Posted - 2010.08.24 21:19:00 -
[142]
Originally by: Hawk TT
For those interested in the Python GIL (Global Interpetter Lock) drawbacks and in Python cooperative-multitasking: David Beazley's - Understanding Python GIL - PyCon 2010
This is David Beazley's presentation @ PyCon 2010...who the f**k is David Beazley?!?! - OK, Google him The presentation is fun, it's informative, it shows how Python behaves on multiple-CPU cores (BAAAAD!) etc.
Thanks for sharing the link! I mean everybody knows that Python has VERY bad performance implications. But that one is utterly hilarious. So 16 processors = 16 times slower *g* _________________________ EveAI.Live - The EVE-Online API/class library for .Net, C# and VB.Net |
Freyya
Advanced Planetary Exports Intergalactic Exports Group
|
Posted - 2010.08.24 22:10:00 -
[143]
The replies are most satisfying yes. I might have even almost escaped hell on those..Sorry about the Mother/calcium thingy and even more sorry about the spandex but it served it's purpose well might i say I probably won't be sleeping much tonight..
As to the limits this GIL thingy apparantly imply; How far are you tied down by the design fundementals of Python/stackless or not in regards to multiple cores? Are you pretty much tied to the definitions it provides or can you rewrite the core code parts of Python to stomp away the stupid things it makes you do? As to avoiding the whole spaghetti workarounds and such... Remember; i'm not afraid to implement the mental image of a certain exec prod. wearing a certain diabolical fabric used to conceal (or show in this case) the appropriate body parts. I might even step it up a notch or 2.. ___________
NOW COLLECTING ISD AND CCP AUTOGRAPHS It'll be worth something someday. -Rauth
|
Bomberlocks
Minmatar CTRL-Q
|
Posted - 2010.08.24 22:35:00 -
[144]
Loved the blog, Veritas. This really was awesome!
|
Caius Sivaris
Dark Nexxus
|
Posted - 2010.08.24 23:12:00 -
[145]
Originally by: CCP Atropos
Originally by: Caius Sivaris What bothers me immensely is that it took the CSM showing you a video for the specific problem (weapon cycling issues, not lag in general in all its manifestation) being worked on. The workaround for this specific bug (manual weapon cycling) has been discussed openly on forums since at least 2008, so the hint was right there. I would however bet good isks that the issue never made it to a dev because the bug reports were relentlessly filtered, because yes, a reproduction case was hard to impossible to find.
The bug hunters discarding bug report are shielding the devs from the truth and doing the game a disservice. I'm afraid it's the balls of destiny being discovered by a player, discarded and rediscovered independently by a dev all over again.
You would be surprised at how many bug reports have nothing more for reproduction steps than "just hold a fleet fight and have some guys jump through a gate". I've seen people posting on the forums claiming that they've just submitted a bug report with pages of information on how a bug occurs and the cure for world hunger, only to look at the bug report and find it contains nothing more than the example I gave above.
The CSM's video however works wonderfully; it clearly shows a bunch of things, with a wealth of client activity and the effects that are seen when a particular bug presents itself, including all the little things that people forget to mention in bug reports that are crucial to fixing the problem! I would even go as far as to suggest all bug reports have handy videos attached detailing the ingame effect of a bug; they've proven immensely useful.
I dealt with a lot of crappy report, and likely have been guilty of them myself. Such is life. The issue I take with the way bug hunters filter bug reports is that without perfect reproduction steps a bug is just discarded (or it's the impression given, is it actually true?), when IMHO they should be filed under a "non reproducible" category.
The interest is twofold. The first one is that the sheer amount of them gives good hints about the prevalence of a problem, which avoid the "we didn't knew" that never goes well with the player base (thinking of the hidden station guns timer for example, that affected 99% of anyone ever getting a GCC in lowsec). The second effect is is building a body of evidence that may eventually lead to reproducible steps. The union of enough incomplete reproducible steps of the same problem converge toward full reproducible steps.
Quote: That said, we're always after more people bug reporting, simply so we can track how prevalent a problem is.
So we agree on that one, but do devs actually get to see a bug report that was filtered? Actually explaining in depth how bug hunting works may actually motivate people which don't bother anymore. As of now, people getting their bug filtered get the impression they bothered for nothing. If it's different, it would be smart to say so.
|
Mashie Saldana
BFG Tech
|
Posted - 2010.08.24 23:12:00 -
[146]
Originally by: CCP Atropos That said, we're always after more people bug reporting, simply so we can track how prevalent a problem is.
Mm, and then we do submit bug reports and they are ignored for weeks, 99206 for example.
Speaking of bugs, I noticed a few days ago that an old drone bug that was fixed a year or so ago has returned as can be seen in 99632.
18 months |
Denidil
Gallente The Graduates Morsus Mihi
|
Posted - 2010.08.24 23:33:00 -
[147]
COOPERATIVE MULTITASKING?! ARE YOU KIDDING ME?!?!?!
is this 1995? omgfcking gawd.. the fact that windows still used cooperative in 1995 was inexcusable, but the server cluster for eve is using it in 2010?
FIRE WHOEVER DECIDED THAT EVE SHOULD BE USING COOPERATIVE MULTITASKING. NOW
|
Bartholomeus Crane
Gallente The Crane Family
|
Posted - 2010.08.25 00:38:00 -
[148]
Originally by: CCP Oveur
Originally by: Bartholomeus Crane :18months:
Yes, I intend on write about that.
Good, because I doubt that you're very happy to have that remain out there as the grand vision for the EVE of the future ...
Originally by: CCP Oveur Ps. Thank you for the kind words on scrapheap.
No hiding for the wicked either it seems ... Inappropriate signature removed. Zymurgist |
Bomberlocks
Minmatar CTRL-Q
|
Posted - 2010.08.25 01:21:00 -
[149]
Edited by: Bomberlocks on 25/08/2010 01:23:49
Originally by: CCP Oveur
Originally by: Bartholomeus Crane :18months:
Yes, I intend on write about that.
Ps. Thank you for the kind words on scrapheap.
SHC is pretty much no holds barred, and while there is an immense amount of utter crap there, it has the redeeming quality that people say what they mean without having to try to get past forum censors and word filters. Additionally, the rampant elitism there, while painful a good deal of the time, has the effect of filtering out a lot of the uninformed rubbish that gets posted here. If you really post insightful stuff, people will listen.
For a long time, we had the impression that no one at CCP was listening.
P.S. Ban '10s
|
I'm Down
|
Posted - 2010.08.25 03:15:00 -
[150]
Edited by: I''m Down on 25/08/2010 03:18:02
Originally by: CCP Veritas
Originally by: Cedori Since you noted that drones seemed to push the server over the edge, wouldn't it be a possible optimization step to "group" drones as guns are grouped?
Just because they pushed load over the edge doesn't mean they're a lot of load themselves. Think of it this way, if drones add 10% CPU and player modules add 95% CPU, having folks start all modules and then launch drones would make it feel like drones are a lot of load, since having them out pushed the server over 100% CPU. However, any time spent addressing their 10% would be considerably better spent addressing the 95% elsewhere.
10% or really any number might not sound like a lot to you, but to us players, it sounds like a huge number that's way more important to cut down than some stupid walking is stations or Dust concept sounds like... That's 10% more room for other areas to **** up.
Truth be told, Drones are too prevalent in this game anyways. 90% of the ships that have drone bays only have them because some ******ed developer couldn't think of a better way to balance the ship. There are drone ships and there are non-drone ships. Non drone ships shouldn't have drones... but most have some sort of bay for some unknown reason, I mean look at the rook/falcon FFS.
I'd watch your comments when you say drone load isn't important, it's very Important IMO at 10% or 5% or any %. It's not like you're going to cut down the other 90% by a huge margin either. So if you can remove 9 out of 10 from drones, why not do it. Yes I realize that's probably not the accurate number, but point stands.
Quote: What bothers me immensely is that it took the CSM showing you a video for the specific problem (weapon cycling issues, not lag in general in all its manifestation) being worked on. The workaround for this specific bug (manual weapon cycling) has been discussed openly on forums since at least 2008, so the hint was right there.
No ****... What bothers me most is if your developers played the game, almost every FC in game now knows and tells his fleets just how to counter lag.... so WTF, are you guys just not playing at all. Me thinks the Wrath of Goons v. BoB spooked you guys into all being empire miners or something.
|
|
Denidil
Gallente The Graduates Morsus Mihi
|
Posted - 2010.08.25 03:35:00 -
[151]
Originally by: I'm Down ...
you understand nothing about software development and clearly cannot understand the words coming out of Veritas' mouth.
kindly STFU.
|
Ranger 1
Amarr Dynaverse Corporation Sodalitas XX
|
Posted - 2010.08.25 03:58:00 -
[152]
What I find surprising about these blogs is that they had to be written in the first place.
What has been lined out is simply a brief glimpse into the methodology of any company in the gaming industry (although CCP has several unique, and stellar concepts that outclass their competition).
For some reason the EVE forum community feels it is their right to have the senior management and development team come and personally hold their hand, explaining every last detail of what they are doing and why (which any idiot should already have a general grasp of), and then argue with them in a egocentric attempt to show them the "right way to do it".
Throw in a liberal helping of "we know you said this, but we all agree you really meant that" nonsense and you end up with the most myopic, rabble rousing, self centered collection of misfits it has been my displeasure to interact with.
The only positive thing to come out of this sorry mess is that I was pleasantly surprised that CCP took you seriously enough to give you more insight into their development process than any other gaming company (or any type of software company) has to my knowledge. Of course, they were met with condescension and general idiocy but hey, that appears to be the norm on these boards.
Now if you can raise the general level of response to something higher than you would expect from your average 13 year old muppet you might actually deserve the respect you have been given.
===== If you go to Za'Ha'Dum I will gank you. |
Ban Doga
|
Posted - 2010.08.25 05:39:00 -
[153]
Edited by: Ban Doga on 25/08/2010 05:39:46
Originally by: Ranger 1 What I find surprising about these blogs is that they had to be written in the first place.
What has been lined out is simply a brief glimpse into the methodology of any company in the gaming industry (although CCP has several unique, and stellar concepts that outclass their competition).
For some reason the EVE forum community feels it is their right to have the senior management and development team come and personally hold their hand, explaining every last detail of what they are doing and why (which any idiot should already have a general grasp of), and then argue with them in a egocentric attempt to show them the "right way to do it".
Throw in a liberal helping of "we know you said this, but we all agree you really meant that" nonsense and you end up with the most myopic, rabble rousing, self centered collection of misfits it has been my displeasure to interact with.
The only positive thing to come out of this sorry mess is that I was pleasantly surprised that CCP took you seriously enough to give you more insight into their development process than any other gaming company (or any type of software company) has to my knowledge. Of course, they were met with condescension and general idiocy but hey, that appears to be the norm on these boards.
Now if you can raise the general level of response to something higher than you would expect from your average 13 year old muppet you might actually deserve the respect you have been given.
No one is forcing you to read the dev blog threads or the player comments. If you find this to be such a displeasure you can just steer clear of them.
I assume you are old enough to find out what you like and dislike and provide yourself with an environment that suits you. Viewer discretion is adviced...
|
Miklas Laces
The Wretched. Northern Coalition.
|
Posted - 2010.08.25 06:47:00 -
[154]
Quote: At the Council of Stellar Management (CSM) summit in June, the CSM made an excellent presentation of the issues around fleet-fight lag, specifically about the issues of modules becoming æstuck' and the workarounds used by players. This provided useful insight into a problem which, until recently, we'd never been able to reproduce in a development environment.
Are you serious ? You didn't know how to reproduce this without that video ?
HAHAHAHAHAHAHAHAHA
________________________________________________ CCP Claw > Sokata has been destroyed for boundary violation Drug Kito > Sokata you'll always be remembered as a noob in history of alliance tourname |
Miklas Laces
The Wretched. Northern Coalition.
|
Posted - 2010.08.25 07:06:00 -
[155]
Originally by: CCP Oveur Edited by: CCP Oveur on 24/08/2010 10:07:51 No. What you might have missed in previous blogs and might not be as clear here is, that as big as this sounds, we have months of investigation, implementing fixes and testing left in the war against lag. This was a big low hanging fruit we saw. Like a pineapple. The size of the moon.
"Need for speed" started years ago, but it failed, lag is worse now then when the program begun, despite many lag-generator systems beeing changed (number of drones nerf, scanner nerf, warp-to-zero, fleet health bars removed, and so on).
The only time when it was looking to get a bit better was in 2009, but then Dominion came..
I understand that there were 10k concurrent players in 2005 while now you have 50k, but hardware is also more powerful now and you have way more resources then 5 years ago.
And it's not only fleet fights, the entire game is way more laggy and slower. Look at a video from 3 years ago and see how fast it was to undock from a station or jump through a gate.
p.s. Also very old issues are still around: if you undock with a new ship it takes twice the time compared to undocking with a ship you have already undocked previously in that system. Is this by design ? It's a bug ? Will we know one day ?
________________________________________________ CCP Claw > Sokata has been destroyed for boundary violation Drug Kito > Sokata you'll always be remembered as a noob in history of alliance tourname |
Sedilis
Lead Farmers
|
Posted - 2010.08.25 07:56:00 -
[156]
Best dev blog ever... very interesting.
But essentially you're saying it was fine without drones... soooo if we get rid of drones it will work! Aw sucks to you be you Gellente
|
Vuk Lau
|
Posted - 2010.08.25 10:46:00 -
[157]
Originally by: CCP Explorer My dear Vuk Lau, you were present at both those CSM meetings, with CCP Oveur and then with CCP Atlas, and you have the full context of this remark and the full details. This disappoints me.
For everyone else: At the meeting with CCP Oveur then a claim was made that EVE was in its worst state ever. I rejected that such a general statement could be made and in the second meeting presented to the CSM the overall, general health of EVE. We emphasized at the second meeting that although overall general health was in good shape then we acknowledged that there were problems in 0.0 fleet fights. We had already been working on those issues at the time of the CSM meeting and have continued that work with reinforced vigour since then.
My dear CCP Explorer. 1st to make things clear, I am almost always adding a pinch of troll in my posts esp. on Mondays, but I really found your statement back then lets say...strange, cause even if it is true (and it was from your standpoint) game was never in worse condition (if we put aside week after deploying every patch) for me and for the people I play and communicate with. That just shows how detached your metrics are with actual User experience which further leads to the conclusion that metrics are not.....erm...that good in judging the state of your product. I hope you didnt took this personally, and you will not remove me as friend on facebook because then I will not be able to stalk you like I stalk CCP Oveur.
|
Camios
Minmatar Insurgent New Eden Tribe
|
Posted - 2010.08.25 10:48:00 -
[158]
Originally by: Miklas Laces
Quote: At the Council of Stellar Management (CSM) summit in June, the CSM made an excellent presentation of the issues around fleet-fight lag, specifically about the issues of modules becoming æstuck' and the workarounds used by players. This provided useful insight into a problem which, until recently, we'd never been able to reproduce in a development environment.
Are you serious ? You didn't know how to reproduce this without that video ?
HAHAHAHAHAHAHAHAHA
QFT. It may mean that despite this thread, people at CCP don't join fleet battles, or the ones that do are not listened to.
The knowledge in that video is pretty much the basis of fleet warfare, something that every 0.0 BS pilot know.
I would like to think that CCP is just very polite and they know what is going on, but they want to encourage player participation in solving this problem and for that reason they said that the presentation is interesting.
Originally by: Miklas Laces
Also very old issues are still around: if you undock with a new ship it takes twice the time compared to undocking with a ship you have already undocked previously in that system. Is this by design ? It's a bug ? Will we know one day ?
May you refer to the session change timer due to ship change? It adds 30 seconds to wait before undocking.
|
Trebor Daehdoow
|
Posted - 2010.08.25 11:11:00 -
[159]
Originally by: CCP Atropos That said, we're always after more people bug reporting, simply so we can track how prevalent a problem is.
IMHO the current bug-reporting system actively discourages people from reporting bugs, because the process is so time-consuming and frustrating. Furthermore, the non-public nature of the bug-reporting system causes massive duplication of effort by players and extra, pointless clerical work by the BH team. I have no doubt that many bug reports that contain some crucial nugget of information get lost in the pile because they didn't get past the "send us logs" and "could not replicate" filters.
Just as sunlight is the best disinfectant, it is also the best insecticide. EVE should have a public bug-reporting system, implemented using an open-source tool like Bugzilla, with an option for private reporting of exploits. That way players can check to see if someone else has reported a bug, and add information when they find edge cases and replication methods -- not to mention append screenshots and videos.
Having a public bug-reporting system will occasionally cause embarrassment. But it will pay off many times over in reduced bug-hunting effort.
Make bug-hunting fearless, transparent, excellent and a united effort between players and CCP.
Confessions of a Noob Starship Politician Spending Hours blogging the Minutes
|
Lev Aeris
b.b.k
|
Posted - 2010.08.25 12:14:00 -
[160]
Awesome to see somebody doing some quality work on the lag. I'd love to see an entire expansion of this nature.
EVE: FIXANIS
Get all those incarna devs to stop playing with dolls and hammer out all the existing content. ;)
This List isn't getting any shorter.
|
|
Ollodem
|
Posted - 2010.08.25 12:42:00 -
[161]
Originally by: Trebor Daehdoow
Originally by: CCP Atropos That said, we're always after more people bug reporting, simply so we can track how prevalent a problem is.
IMHO the current bug-reporting system actively discourages people from reporting bugs, because the process is so time-consuming and frustrating. Furthermore, the non-public nature of the bug-reporting system causes massive duplication of effort by players and extra, pointless clerical work by the BH team. I have no doubt that many bug reports that contain some crucial nugget of information get lost in the pile because they didn't get past the "send us logs" and "could not replicate" filters.
Just as sunlight is the best disinfectant, it is also the best insecticide. EVE should have a public bug-reporting system, implemented using an open-source tool like Bugzilla, with an option for private reporting of exploits. That way players can check to see if someone else has reported a bug, and add information when they find edge cases and replication methods -- not to mention append screenshots and videos.
Having a public bug-reporting system will occasionally cause embarrassment. But it will pay off many times over in reduced bug-hunting effort.
Make bug-hunting fearless, transparent, excellent and a united effort between players and CCP.
I strongly agree with this. I reported 3 bugs in my eve-time, 2 said yeah we know already. And in both cases i couldnt see what exactly had been reported before and if i could maybe add anything helpfull.
But on an unrelated note: I allways thought about posting this in one of these threads nut allways way too afraid as i actually dont really understand what is going on and i cant imagine that my uneducated idea might actually be one of the problems leading to lag but whatever, in one of the last devblogs it was said that the problem might as well be something stupid.
As i understand it, lag has allways been worse in fw and general lowsec (maybe only shining in fw as lowsec seldom has huge fleetfights otherwise). And it got worse in 0.0 with Dominion right? What i allways wondered, how is in lowsec checked for sec standing increases or decreases? As i would imagine that some system that checked for every other shot a player fires wether this shot was legal or not and wether it decreases his sec standing or nets him a GCC, might scale horrible. Especially as the targets sec status might change in between as well because it fires too. To me who only writes small simulation programs in MatLab, this sound really scary.
And if this might really be a small problem, could this somehow happen in 0.0 too? Might the system node have to check for each fighting player in the system wether it will increase the systems millitary or whatever index? Probably not, but, yeah, i allways wanted to point this out. ^^
|
Cor Aidan
Shore Leave
|
Posted - 2010.08.25 12:50:00 -
[162]
Very interesting and informative blog. It's quite interesting to get a small peek into the architecture of the code, and while I could jump on the opinion bandwagon about one technology versus another, instead I'll just say this to all the aspiring engineers of any type out there:
Remember kids, decisions that seem very reasonable under certain sets of assumptions often have "interesting" side effects or consequences when those assumptions are violated. Also remember that assumptions are always violated during the course of development on any project ("Hey, this will be enough paint to paint this room...oops!")
In this specific case, choice of programming tools (interpreted vs compiled) and general task architecture (cooperative vs preemptive vs real-time) all have tradeoffs: team skill, time to develop, ease of maintenance, scalability, performance, and even things like toolchain costs must all be considered - not just "hey I heard this technology is cool and awesome let's use that!".
Kudos all around for the increased communication and also to the folks that are allowing those pesky engineers to have the correct tools for the job!
|
Raimo
Genos Occidere HYDRA RELOADED
|
Posted - 2010.08.25 13:05:00 -
[163]
Edited by: Raimo on 25/08/2010 13:04:59
Originally by: Trebor Daehdoow
Originally by: CCP Atropos That said, we're always after more people bug reporting, simply so we can track how prevalent a problem is.
IMHO the current bug-reporting system actively discourages people from reporting bugs, because the process is so time-consuming and frustrating. Furthermore, the non-public nature of the bug-reporting system causes massive duplication of effort by players and extra, pointless clerical work by the BH team. I have no doubt that many bug reports that contain some crucial nugget of information get lost in the pile because they didn't get past the "send us logs" and "could not replicate" filters.
Just as sunlight is the best disinfectant, it is also the best insecticide. EVE should have a public bug-reporting system, implemented using an open-source tool like Bugzilla, with an option for private reporting of exploits. That way players can check to see if someone else has reported a bug, and add information when they find edge cases and replication methods -- not to mention append screenshots and videos.
Having a public bug-reporting system will occasionally cause embarrassment. But it will pay off many times over in reduced bug-hunting effort.
Make bug-hunting fearless, transparent, excellent and a united effort between players and CCP.
Agreeing 100%. This would have so many benefits. ---------- www.eve-arena.com
|
Yeay Fritg
Caldari Confrerie de Kaedri Cluster Of Rebirth
|
Posted - 2010.08.25 13:37:00 -
[164]
Hello,
When a real Dev Blog about 'features bugs' not lag effect ?
When will you solve the bugs you have identified in the Dominion features e.g. Infrastructure Hub it also impact all the 0.0 ?
Why not answering this point ?
Good to know you worked on the Lag but it's not a Bug, it's an effect.
When a Backlog CCP Dev Blog or Position ?
Yeay
|
Ranger 1
Amarr Dynaverse Corporation Sodalitas XX
|
Posted - 2010.08.25 14:43:00 -
[165]
Edited by: Ranger 1 on 25/08/2010 14:43:15
Originally by: Ban Doga Edited by: Ban Doga on 25/08/2010 05:39:46
Originally by: Ranger 1 What I find surprising about these blogs is that they had to be written in the first place.
What has been lined out is simply a brief glimpse into the methodology of any company in the gaming industry (although CCP has several unique, and stellar concepts that outclass their competition).
For some reason the EVE forum community feels it is their right to have the senior management and development team come and personally hold their hand, explaining every last detail of what they are doing and why (which any idiot should already have a general grasp of), and then argue with them in a egocentric attempt to show them the "right way to do it".
Throw in a liberal helping of "we know you said this, but we all agree you really meant that" nonsense and you end up with the most myopic, rabble rousing, self centered collection of misfits it has been my displeasure to interact with.
The only positive thing to come out of this sorry mess is that I was pleasantly surprised that CCP took you seriously enough to give you more insight into their development process than any other gaming company (or any type of software company) has to my knowledge. Of course, they were met with condescension and general idiocy but hey, that appears to be the norm on these boards.
Now if you can raise the general level of response to something higher than you would expect from your average 13 year old muppet you might actually deserve the respect you have been given.
No one is forcing you to read the dev blog threads or the player comments. If you find this to be such a displeasure you can just steer clear of them.
I assume you are old enough to find out what you like and dislike and provide yourself with an environment that suits you. Viewer discretion is adviced...
Thanks for the advice Ban, but I'm right where I think I need to be.
I know the truth hurts, but that doesn't change the fact that you need to hear it occasionally.
You may now go back to sticking your fingers in your ears and singing "lalalalala".
===== If you go to Za'Ha'Dum I will gank you. |
Miklas Laces
The Wretched. Northern Coalition.
|
Posted - 2010.08.25 14:46:00 -
[166]
Originally by: Camios May you refer to the session change timer due to ship change? It adds 30 seconds to wait before undocking.
No. Do this:
Log in, click "undock", in whatever ship you are, take note of how much time it takes to actually undock and load (you will be surprised how much time passes from the moment you click undock to the moment you are in control of your ship in space).
Then dock and undock a second time, without changing ship. Take note of how much time it takes to undock and you will see it's much shorter.
Dock again, wait 30 seconds, change ship, undock, take note of the time it takes, it's same as first undock again.
________________________________________________ CCP Claw > Sokata has been destroyed for boundary violation Drug Kito > Sokata you'll always be remembered as a noob in history of alliance tourname |
|
CCP GingerDude
|
Posted - 2010.08.25 15:43:00 -
[167]
Check out this guys work. It's awesome:
http://knol.google.com/k/upsideyourhead/chapter-i-ship-motion-in-eve-online/2mdavnicxps8v/4
Originally by: Axemaster
Originally by: CCP Veritas
Originally by: Axemaster Btw, I don't know if the devs are still reading this thread, but I was still hoping for an answer to my question back at post 38.
Yup, we are. I thought I handled post 38 in post 48. Did I miss something?
My bad, I meant post 56.
|
|
Solra Wolfe
GunStars
|
Posted - 2010.08.25 17:12:00 -
[168]
Edited by: Solra Wolfe on 25/08/2010 17:13:13
Originally by: CCP Atropos
Originally by: Caius Sivaris What bothers me immensely is that it took the CSM showing you a video for the specific problem (weapon cycling issues, not lag in general in all its manifestation) being worked on. The workaround for this specific bug (manual weapon cycling) has been discussed openly on forums since at least 2008, so the hint was right there. I would however bet good isks that the issue never made it to a dev because the bug reports were relentlessly filtered, because yes, a reproduction case was hard to impossible to find.
The bug hunters discarding bug report are shielding the devs from the truth and doing the game a disservice. I'm afraid it's the balls of destiny being discovered by a player, discarded and rediscovered independently by a dev all over again.
You would be surprised at how many bug reports have nothing more for reproduction steps than "just hold a fleet fight and have some guys jump through a gate". I've seen people posting on the forums claiming that they've just submitted a bug report with pages of information on how a bug occurs and the cure for world hunger, only to look at the bug report and find it contains nothing more than the example I gave above.
The CSM's video however works wonderfully; it clearly shows a bunch of things, with a wealth of client activity and the effects that are seen when a particular bug presents itself, including all the little things that people forget to mention in bug reports that are crucial to fixing the problem! I would even go as far as to suggest all bug reports have handy videos attached detailing the ingame effect of a bug; they've proven immensely useful.
That said, we're always after more people bug reporting, simply so we can track how prevalent a problem is.
The problem with bug reporting is that often it's impossible to reproduce the bug, so it then becomes pretty much useless from a bug hunter's point of view. In the case of lag, it is in fact possible to reproduce the problem by saying "jump in a fleet of 100 ships and start fighting". I think what Caius was trying to say is why did it take a video from the CSM about manual cycling for you guys to understand the problem, when this has been a known work around for a long time. Does no one at CCP play the game at the fleet combat level? One would think that somebody does, and would have been able to do a video of their own to show to their devs wtf is going on with this ****.... -------------------------------------------------------------------------------- [GNSTR]
GO CANADA! |
|
CCP Explorer
|
Posted - 2010.08.25 19:58:00 -
[169]
Originally by: Vuk Lau
Originally by: CCP Explorer My dear Vuk Lau, you were present at both those CSM meetings, with CCP Oveur and then with CCP Atlas, and you have the full context of this remark and the full details. This disappoints me.
For everyone else: At the meeting with CCP Oveur then a claim was made that EVE was in its worst state ever. I rejected that such a general statement could be made and in the second meeting presented to the CSM the overall, general health of EVE. We emphasized at the second meeting that although overall general health was in good shape then we acknowledged that there were problems in 0.0 fleet fights. We had already been working on those issues at the time of the CSM meeting and have continued that work with reinforced vigour since then.
My dear CCP Explorer. 1st to make things clear, I am almost always adding a pinch of troll in my posts esp. on Mondays, but I really found your statement back then lets say...strange, cause even if it is true (and it was from your standpoint) game was never in worse condition (if we put aside week after deploying every patch) for me and for the people I play and communicate with. That just shows how detached your metrics are with actual User experience which further leads to the conclusion that metrics are not.....erm...that good in judging the state of your product.
I think there is a perfect match there. I rejected the general statement and provided the context and background of my argument, while at the same admitting that there were specific problems in 0.0 fleet fights, which matches your statement above about user experience. The truth is complicated, it has layers and depth.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
Dr Lebroi
|
Posted - 2010.08.26 00:27:00 -
[170]
Originally by: Sedilis But essentially you're saying it was fine without drones... soooo if we get rid of drones it will work! Aw sucks to you be you Gellente
Pesky drones.... Time for broad strokes methinks, cut out drones and drone stuff, make isk and skill point reimbursement as necessary, you can do this while killing off learning skills and reimbursing those points. No drones, then Gallente suck ass (moar ass) for PVP, missions etc - solution? All Gallente die in Gallente only space disease - Gallente get to re-roll a new character with their SP, you won't even have to fix blasters......
|
|
Megan Maynard
Minmatar Rep-X
|
Posted - 2010.08.26 00:56:00 -
[171]
Originally by: CCP Veritas
Originally by: Ix Forres Great facial expression, good dev blog. How many major fixes have come about since the introduction of the thin client platform, and when was this made internally available? What were your methods of debugging EVE before it was available?
Thanks~
The thin clients matured enough for usage roughly a month ago, and while it took a fair bit of time to get them to do useful things, much has come from them already. It's hard to say how many major fixes have come from their usage so far, since that's dependent on your definition of major. Certainly most of what I talk about in this blog was made possible in the timeframe it happened via thin clients, and there are some nice optimizations coming down the pipe as well that originated in controlled thin client setups.
Before the thin clients we did load testing by getting as many warm bodies to log in to test servers, both internally and with the public mass tests. This type of testing is fantastic for finding things you didn't think to test, but not very useful for the kind of specific drill-down testing that I've been talking about above. Removing the need to use mass tests for that purpose has been very liberating, both in that we can do more of it and that we can focus on higher level information during mass tests.
It's nice to see you guys getting into the realm of what us engineers do quite often. (Use smaller simulations to gauge performance of a larger system.)
A couple questions: 1. Do you use thin clients on tranquility before/after patches to verify function? If not, look into it. It's a great way to run thousands of tests without someone needing to be there. (Because you can simply look at the results as you have time to catch the little things.)
2. Are there plans to incorporate a gui specifically for running multiple thin clients all at once? It sounds weird, having a gui to run another set of code that controls essentially another gui, but I like to think of it as the "turbo" button on my old N64 3rd party controller.
Originally by: F'nog
Originally by: Stareatthesun No no no ... Polaris is where CCP keeps the death star that will destroy eve when the servers shut down.
Thankfully I've got Interceptors trained to V. S |
|
CCP Veritas
|
Posted - 2010.08.26 09:55:00 -
[172]
Originally by: Megan Maynard 1. Do you use thin clients on tranquility before/after patches to verify function? If not, look into it. It's a great way to run thousands of tests without someone needing to be there. (Because you can simply look at the results as you have time to catch the little things.)
We don't yet have that kind of regression testing framework for them yet, but it's absolutely on the table. Of course, thousands of tests don't write themselves, so it will take time.
Originally by: Megan Maynard 2. Are there plans to incorporate a gui specifically for running multiple thin clients all at once? It sounds weird, having a gui to run another set of code that controls essentially another gui, but I like to think of it as the "turbo" button on my old N64 3rd party controller.
I regularly command hundreds of them at the same time; I'd go mad if I had to execute commands on them separately =)
|
|
Yeay Fritg
Caldari Confrerie de Kaedri Cluster Of Rebirth
|
Posted - 2010.08.26 12:46:00 -
[173]
Sorry,
But CCP I just want a BackLog Bug Dev Blog !
Do you read the forums or will you moderate all our quality request if not in line with your marketing plan ?
Yeay
|
Leena Raphael
|
Posted - 2010.08.26 14:36:00 -
[174]
Originally by: Yeay Fritg Sorry,
But CCP I just want a BackLog Bug Dev Blog !
Do you read the forums or will you moderate all our quality request if not in line with your marketing plan ?
Yeay
Oh, just shut up.
Jees...
|
Yeay Fritg
Caldari Confrerie de Kaedri Cluster Of Rebirth
|
Posted - 2010.08.26 14:59:00 -
[175]
Originally by: Leena Raphael
Originally by: Yeay Fritg Sorry,
But CCP I just want a BackLog Bug Dev Blog !
Do you read the forums or will you moderate all our quality request if not in line with your marketing plan ?
Yeay
Oh, just shut up.
Jees...
lol
|
Fantome
Section XIII Cursed Alliance
|
Posted - 2010.08.26 19:24:00 -
[176]
Originally by: Miklas Laces
Quote: At the Council of Stellar Management (CSM) summit in June, the CSM made an excellent presentation of the issues around fleet-fight lag, specifically about the issues of modules becoming æstuck' and the workarounds used by players. This provided useful insight into a problem which, until recently, we'd never been able to reproduce in a development environment.
Are you serious ? You didn't know how to reproduce this without that video ?
HAHAHAHAHAHAHAHAHA
I must say than i got the same reaction than Miklas (o/mate !). We are using it (disable autorepeat / cycling guns) in fleet since years.. have you never played your own game on tranquility ??
Anyway nice blog and good to see we could get some nice improvement.. soon (tm) Signature removed for not being EVE related. Zymurgist |
Samuel Miner
Caldari Perilous Expedition
|
Posted - 2010.08.28 16:24:00 -
[177]
Edited by: Samuel Miner on 28/08/2010 16:25:15
After reading this particular blog I am a little concerned, and late in reading it because of uni starting.
Concerned though because it seems the system, even if completely fixed, bug free with optimum yields in place for priority tasks to get processed, will still only be able to scr4pe by in a heavy load situation.
My question is if you had the chance to rewrite all the functions for combat (or maybe even deeper in the core systems) from the ground up, couldn't you design it more efficiently. It seems, once again, you are searching for just enough of a fix to squeak by until the next round of rage lag threads.
|
ceaon
|
Posted - 2010.08.29 17:13:00 -
[178]
Originally by: CCP Oveur Dunbar's number
since you bring this up and there are higth chances that you have read The Tipping Point what you can comment about the Broken windows theory because you get this thing on EvE and because few broken windows the :eve is dying: have reached a tipping point.
did you talk whit Bill Gore how they scale their company around dungar's number ? also is this the reason why you open offices on new locations ?
also i fixed ur link
Originally by: CCP Adida The male thread was locked because the discussion turned into transsexuals and man boobs.
|
Pellegro
|
Posted - 2010.08.31 04:58:00 -
[179]
Originally by: CCP Oveur Dunbar's number
Curious. A guy named David Wong wrote an interesting little bit about Dunbar's number, calling it "The Monkeysphere". That was back in 2007.
Then we had the player, "The Monkeysphere" whose exploits of being able to fly in local undetected are now infamous. While some may have thought being caught using such a hack/exploit would result in a ban, "The Monkeysphere" is back (although his/her killboard is decidedly less impressive now).
Obvious alt is obvious.
|
Yehat Quan
Gallente
|
Posted - 2010.09.01 12:21:00 -
[180]
Hello there,
awesome blog. However, I seriously disagree with your assesment about Width vs. Depth, aka, "I have to fix the algorithm before I change anything".
a) The algorithm, and the bug, results from using cooperative multitasking. It would probably be a completely different algorithm if it wasn't for Python.
b) from the tiny amount of physics you are doing, and the fairly small amount of players per node your nodes should not be CPU-bound. If anything, an MMO node that is not doing serious physics (and you don't) should be network bandwidth - bound. (For comparison: A server written in Javascript, (of all the languages!) (Node.js) has been shown to serve about 6500 requests a second. You have a maximum of 1500 simultaneous users in Jita. And I don't think you run your calculations every second for every ship, do you? )
b): C*O(n) in reality (as opposed to theoretical informatics) _can_ be larger then c*O(n^2) for appropriate C and n. Now, we are (hopefully!!!) not talking O(n-square) levels of suck here, and our n is -- if we take Jita as the worst case -- only 1500. If you can halve the work by changing the algorithm, but cut the execution time by a factor of 3 by simply switching to a different programming language, what do you think should have a higher priority? And we aren't talking about anything as little as factor 3... not nearly. But I'll say something about that later.
Now I understand why you guys use python and have a hard time switching:
Originally by: Cor Aidan In this specific case, choice of programming tools (interpreted vs compiled) and general task architecture (cooperative vs preemptive vs real-time) all have tradeoffs: team skill, time to develop, ease of maintenance, scalability, performance, and even things like toolchain costs must all be considered
However, let me tell you a little story.
2005 we had an assignment in a bioinformatics class. It was "align two DNA sequences of a certain length a thousand times and calculate X". (The specifics evade me right now).
Quote:
Our tutor: "It takes about ten minutes to write the code. After that, you can go and have a coffee. Or a dinner." My partner in crime (who is a mathematician): "How long does it run, exactly?" Our tutor: "About 2 hours". Me: "What programming language?" Our tutor: "Python."
Me and my study partner look at each other, sit down and write the code in C. It takes us half an hour (three times longer then it took our tutor to write his.)
Prise question: how long does it run?
(drumroll)
12 seconds.
- No, I am NOT kidding - No, I didnŠt mean to write 12 minutes. - No, we didnŠt change the algorithm. It was EXACTLY the same. - No, it didnŠt thread or use multiple cores. We only had one. It was 2005. - No, it didnŠt leak memory (since it was pretty straight-forward and I am an industry programmer who knows his ****.)
(And if you are wondering, yes, it did produce the same result as the python code.)
What did I learn from that? Transporting an algorithm 1:1 from one language to another can give you a time gain of (2 hrs / 12 seconds) = 120*60/12=600x It can take 3x longer to write. In pure numbers, that adds up to a 200x gain. Multiply this by a factor of your choice reflecting how much you value developer time versus hardware costs.
Conclusion: Of course, NPC behaviour, GUI interaction, etc, are all fine and good in python, since a graphics- or a story designer might look at it and understand it. However, unless the python interpreter has been massively rewritten since 2005, Python is a toy language. Writing serious server-side _processing_ code in python is like trying to build a lego robot out of Barby parts. And the whole GIL thing doesnŠt exactly make this any better. I would ask you to consider how much easier your life would become if you didnŠt have to control the yielding behavior of your code by hand, versus how much time you might spend learning a new language (which, in itself, can be fun).
|
|
Qujulome
Amarr
|
Posted - 2010.09.02 17:03:00 -
[181]
Originally by: Yehat Quan Hello there
-snip-
CCP, hire this guy. Seriously.
|
|
CCP Veritas
|
Posted - 2010.09.03 17:35:00 -
[182]
Originally by: Yehat Quan <stuff>
Hi there.
I at first felt like going point by point with you, but I think there's a deeper point I can touch on that covers most everything.
I've been a professional C/C++ programmer for the better part of a decade, and was raised on it early. I know the performance difference between Python and C. I know, deeply and exactly, why that difference exists.
I've also done game development in C++, and am very familiar with the maintenance nightmare that such a codebase can become after many years of disjoint development by a shifting team with shifting focus. The tradeoff between speed of execution and ease of maintenance and extension is not as simple as you make it out to be.
There's a time for reworking code from a higher level language to a lower level language. It used to be dropping into ASM from C, now it's droping into C from something higher level. That time has always been after you've cut away the unnecessary computation and poor design models. From what I've seen so far with Eve, we're not at that point yet. If we had one little tight loop that was consuming most of the time, you'd have to hold me back from pulling it over to C-side. That's simply not the situation we're in, however.
|
|
Ban Doga
|
Posted - 2010.09.03 18:49:00 -
[183]
Originally by: CCP Veritas
Originally by: Yehat Quan <stuff>
Hi there.
I at first felt like going point by point with you, but I think there's a deeper point I can touch on that covers most everything.
I've been a professional C/C++ programmer for the better part of a decade, and was raised on it early. I know the performance difference between Python and C. I know, deeply and exactly, why that difference exists.
I've also done game development in C++, and am very familiar with the maintenance nightmare that such a codebase can become after many years of disjoint development by a shifting team with shifting focus. The tradeoff between speed of execution and ease of maintenance and extension is not as simple as you make it out to be.
There's a time for reworking code from a higher level language to a lower level language. It used to be dropping into ASM from C, now it's droping into C from something higher level. That time has always been after you've cut away the unnecessary computation and poor design models. From what I've seen so far with Eve, we're not at that point yet. If we had one little tight loop that was consuming most of the time, you'd have to hold me back from pulling it over to C-side. That's simply not the situation we're in, however.
Yes, premature optimization is the root of all evil. But then someone might come along and ask if optimizing years old code is still premature.
But I wanted to ask something else: Did you see the GIL talk at the PyCon 2010?
I was really shocked to see 50 million decrements of a numeric variable took over 5 seconds. I did the same in Java (still an interpreted language, although with a compilation step before execution and optimization while running) on my notebook (pretty comparable to the MacBook used in the talk) and it completed in less than 5 milliseconds. So roughly 1000 times as fast.
Is Stackless Python just as slow as that?
And yes, that's not a benchmark for real-world performance at all, but factor 1000 is just too much to ignore IMHO.
|
Yehat Quan
Gallente
|
Posted - 2010.09.04 13:19:00 -
[184]
@Ban Doga: the reason Java is that much faster in that test is because the JIT compiles the loop into native machine code. Why thatŠs faster, see below...
@CCP Veritas:
Originally by: CCP Veritas
I've been a professional C/C++ programmer for the better part of a decade, and was raised on it early. I know the performance difference between Python and C. I know, deeply and exactly, why that difference exists.
Then you are aware of the fact that depending on how badly the interpreter is able to optimize, you will have a function call for every mathematical operation that SHOULD have been a CPU instruction, right? In best case, that is the difference between a CPU register access and main memory access. In worst case you have to insert the overhead for pulling some data from a data segment, then jumping into the code area that implements math, and then pushing back the data into main memory, for every single operator. In 1996, on a 80486 that needed 500 cycles to multiply, with an ISA bus, the difference was at least 4x. With current CPUs and all their caching, pipelining and predictive branching crap this can easily account for the factor 200-1000 people see.
I just sure as hell hope you donŠt have a database access somewhere in the module loop ;-)
Originally by: CCP Veritas
I've also done game development in C++, and am very familiar with the maintenance nightmare that such a codebase can become after many years of disjoint development by a shifting team with shifting focus. The tradeoff between speed of execution and ease of maintenance and extension is not as simple as you make it out to be.
You are right, there is probably no way to emulate stackless features in C++. However, I would be interested how much you actually use the stackless features, and how large the memory (or anything, for that matter) savings are. Because having a maximum of 1500 concurrent users on a server really does not showcase any performance advantages you might have gained by using Stackless, and if you donŠt need it, PyPy JIT might save you.
Also, isn`t using a model where you have to control yielding by hand and fine-tune the yielding behaviour empirically much closer to using Assembler then to a high-level language that supposedly is less work for the programmer?
Originally by: CCP Veritas
There's a time for reworking code from a higher level language to a lower level language. It used to be dropping into ASM from C, now it's droping into C from something higher level.
To be honest -- and I know there is a huge community ready to stone me to death after I say that -- I have trouble regarding Python as a higher-level language than C++.
- You can only find type errors by running your program. You know what other language has this "feature"? Assembler. It just doesn't fail quite as gracefully.
- I can't think of anything short of the stackless feature that you can do in Python that you can't do with a library like Boost in C++. Including garbage-collection. So what exactly makes python high-level, the pseudocode-like syntax, or the interactive environment?
If it is the latter, there are enough C++ IDEs nowadays that can tell you that you mistyped the variable name or you're doing an assignment with two different types that you don't really need a crummy interactive command-line... Sure, exploratory programming is great, especially with things that have too little documentation to be useful otherwise, but we are talking a serious big-a** "for money" game development project -- don't you guys write documentation for your code?
Python was invented in 1990, when C++ compilers were slow, lack of compilation seemed like a good idea, and the CPU time for a MUL instruction was comparable to a function call. Nowadays, for any project that is not monolytic (like using a cr.pton of templates all stuffed into header files) AND enormously large, recompilation times are negligible -- run times just aren't.
|
Ban Doga
|
Posted - 2010.09.04 15:48:00 -
[185]
Originally by: Yehat Quan @Ban Doga: the reason Java is that much faster in that test is because the JIT compiles the loop into native machine code. Why thatŠs faster, see below...
Well that surely helps a lot, but even when forcing the JVM into pure interpreted mode (-Xint) it still completes in under 0.5 seconds.
|
Liang Nuren
Parsec Flux War.Pigs.
|
Posted - 2010.09.15 16:58:00 -
[186]
Originally by: Yehat Quan ...
So I was recently working on some Project Euler problems, and I was browsing the forums after completing one of them. I figured I'd see what kind of performance I was missing... turns out lots of people had their C solutions completing on the magnitude of 12-16 hours. Mine, written in Python, ran in four seconds for much much larger values of N.
Algorithm is everything.
-Liang -- Eve Forum ***** Extraordinaire On Twitter Blog
|
|
|
|
Pages: 1 2 3 4 5 6 7 :: [one page] |