tag:blogger.com,1999:blog-1461700565722278823.post5988198246038133686..comments2024-02-27T14:44:07.868+01:00Comments on Greedy goblin: Eliminating the soul-crushing lag Gevlonhttp://www.blogger.com/profile/07072766785893313616noreply@blogger.comBlogger34125tag:blogger.com,1999:blog-1461700565722278823.post-58267708575617763062014-01-25T12:03:21.479+01:002014-01-25T12:03:21.479+01:00Nice idea, but you can take it further, especially...Nice idea, but you can take it further, especially that <br />1) big battles are selling points<br />2) valkyrie begs to be set IN such battles (and that means more small, fast objects to care about)<br /><br />Ghosting as you propose is essentially compartmentalization, when part of people fights, the other supply passive bonus according to their actual number. Fine as fast stop-gap measure.<br /><br />Way I would advance the measure is to set a grain to the battle, with reasonably-numbered cells where fighting happens., each cell evaluated as whole regarding to others. (pretty much as ghosting goes)<br /><br />Grain is determined by number of big ships on the grid. Each titan == cell on his own etc. Now each cell need to have a minimal radius, so it would force spacing out big ships. If you have frigate blob, treat is as one entity too, centred on FC etc. Pretty much how table top games handle units.<br /><br />From there, the cell can be in two states, ranged, when it engages other non-neighbouring cell, or "melee" when it engages objects in neighbouring cell, and there is child-object swap (drones, close range ships and munitions). Ranged - state allows only targeting other cell as entity, either focusing on cell-building entity or AOE whole cell. (state sums all effects per tick as one and apples that sum wholesale).<br />Melee-state shuts off all ranged states and treat cells involved as on-grid.<br /><br />So, there might be many people involved in battle, but you need to throw computing power only on those actually engaging close-range, clumping other effects disregarding checking for particulars.<br /><br />Also, do not bother in non-fighting entities like pods, just spirit them away after applying "chance of getting caught in blast" factor.<br /><br />Then again, withoutnchanges to fight mechanics that will require more movement (not only moonwalking from bomber run), the fights would be just blobs slinging at each other.. after all after getting in range position does not matter that much, and stuff generals/admirals use to win actual battles (outflanking, eliminating c3 structures) do not apply. Then more sophisticated model == more computing power .. but only if done in crude manner)LukePhttps://www.blogger.com/profile/16905556036533278632noreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-34273160549491511092014-01-24T16:28:37.311+01:002014-01-24T16:28:37.311+01:00@Gevlon: Sadly this simply wouldn't work witho...@Gevlon: Sadly this simply wouldn't work without either limiting the ghost group immensely or increasing the length of each ghost cycle. <br /><br />If you have a ghost group size of 500 then in a 4,000 strong fleet battle you'd on average spend 1/8 of your time on-grid, which as you said earlier is more than 1/10 so on-paper this would be better. However as I'll explain in a minute this simply wouldn't work.<br /><br />What you're proposing would require a session change for each pilot rotated onto the grid. Session changes are a huge bottleneck in terms of lag. In a recent interview ( http://www.youtube.com/watch?v=UcEUB6h4Br0 ) CCP Veritas explained that when you go through a session change all of your skills are recalculated, ship's loaded etc etc, which causes a lot of server load. <br /><br />He goes on to explain how you can see this during bomb runs, each ship explodes and the pilot's put into a pod which is a session change and TiDi spikes. <br /><br />You can see that in this vid, roughly 100 ships on-grid with no TiDi then bombs happen, which drops the server to 60% TiDi and takes a full minute for all pods to have loaded on-grid http://www.youtube.com/watch?v=Vu8hKt3qZAU#t=2m15s<br /><br />Extending this to 500 pilots being dumped on-grid at the same time and it's easy to see that it'd cause sufficient lag to drop the node to 10% TiDi for well over 3 minutes, meaning that some of the active group wouldn't even be able to load grid before being ghosted out AND it'd still be 10% TiDi.<br /><br />Two ways to mitigate this would be to reduce the size of the active group, which be worse than the current method. Since nodes only start breaking at around the 4,000 mark, reducing the group size would mean that on average a pilot would be on-grid for less than 1/10 of the time. The other solution would be to increase the cycle time of the ghosting process, which fails for the same reason.<br /><br />This particular source of lag should actually be eliminated/mitigated when the Brain in a Box is completed. Basically that offloads the vast majority of the data loaded during session changes to a dedicated server, leading to a much smoother transition, which means your idea could become viable at that point, but I can't say for sure that it would.BleepBloopnoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-77659087967356543962014-01-24T04:20:24.760+01:002014-01-24T04:20:24.760+01:00Satori Okanata: "have you ever noticed lag wh...Satori Okanata: "have you ever noticed lag while searching google"<br /><br />Wrong comparison - Google only does search, whereas EVE does a simulation. Distributed searches don't have to communicate between the individual data hosts; and also, the searches of different users don't need to coordinate with each other. More importantly: the search results don't have to be absolutely correct all the time; eventual correctness is good enough.<br /><br />It is true that EVE could make better use of their clustered environment, but that would take more programming effort than a simple map/reduce search. And one thing to keep in mind is that communication between processes is slow (compared to raw CPU speeds). If the processes sit on different servers, it's abysmal.Druur Monakhhttps://www.blogger.com/profile/07299435488090977357noreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-76798547190487266132014-01-23T19:37:27.581+01:002014-01-23T19:37:27.581+01:00@Provi miner: ghost cycles are fixed. If you are a...@Provi miner: ghost cycles are fixed. If you are a ghost, you know exactly when to return to your computer. There is a countdown.<br /><br />The ghosting is random. So 3000 CFC sits on grid, they are already ghosted because they are a lot. So 1600 CFC sits on grid (200 ghost immune, 1400 active, other 1400 ghost)<br /><br />Now 2000 N3 jumps in, 500 of them are ghost immune because they have several titans, blap dreads). <br /><br />750 doesn't even materialize, they exit jump tunnel as a ghost. Other 750 will materialize.<br /><br />So on field there will be:<br />1400 active CFC with 2x damage modifier<br />200 ghost immune CFC<br />750 active N3 with 2x damage modifier<br />500 ghost immune N3<br />Gevlonhttps://www.blogger.com/profile/07072766785893313616noreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-67219880691256155392014-01-23T19:31:00.149+01:002014-01-23T19:31:00.149+01:00I've been reading about it, and everywhere the...I've been reading about it, and everywhere they say that eve is running in a clustered environment, but the thing is that it behaves much like WoW where every domain is an individual server. There can be hideous TIDI in jita while everything is smooth in piekura, 4 jumps away, just like it was in it's own server.<br /><br />I think they have problems with how they do their load balancing if jita is dying while other places looks like the servers are scratching their balls and having a beer. <br /><br />If their cluster was working correctly, the load balancing would make that, instead of having jita (or wherever the massive pew pew is happening) running at 10% speed, all of the universe should be at 99% wich would be unnoticeable for anyone. <br /><br />A good example of this is, have you ever noticed lag while searching google?Satori Okanatanoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-1572692967885086482014-01-23T19:27:38.844+01:002014-01-23T19:27:38.844+01:00Multi-front battles would be interesting but reali...Multi-front battles would be interesting but realistically I theorize this is what would happen:<br /><br />Attacking group A has to destroy 5 structures at around the same time, so has to split their fleet up into 5 groups. Defending group B doesn't have to split their group up at all, they just defend one structure and they win, so you have A/5 members of fleet going up against B members of fleet. So, A must bring 5x more numbers, and that's what'll happen.<br /><br />If there were some way to force both attackers and defenders to split their fleets up then we'd have something to work with. Artificially making a ship limit is dangerous as well, but could be an option.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-55987545683710930452014-01-23T19:00:30.083+01:002014-01-23T19:00:30.083+01:00This is actually one of the better ideas I've ...This is actually one of the better ideas I've heard for fixing things.Paul Dejeanhttps://www.blogger.com/profile/02078988687695155618noreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-61791193948751048442014-01-23T18:34:54.488+01:002014-01-23T18:34:54.488+01:00Time slices small enough the battle isn't over...Time slices small enough the battle isn't over while you are ghost. Well again thats my poin if you get up you could be unghosted and never know only to find yourself in your home system med bay. <br /><br />if 5 groups go then each get half their ships? My point, and I appologize if I was unclear, might be better explained by this example. Lets say CFC allaince loads grid, and then Nulli loads grid (not n3 just nulli) then NC loads grid (again not n3 but NC) now n3 effectivly has a 2-1 advantage even though they are seperate groups. while most people looking at this would lump nulli with nc will the computer? The computer will assign all groups within the CFC with CFC but if there is no "existing" N3. Then those who were "formally a part of N3" will gain an advantage. What happened in the Sound wars would be a night mare with your solution. CVA and allies (call them provi but they are not a part of a formal alliance) Stain wagon (again not a formal alliance) BL (which wasn't a part of cfc at the time) PL (which wasn't a part of n3) N3, Bombers bar (which has no formal alliance) were effectively shooting each other at one point then helping one another at another point. No way to appropreate a fair system of who gets unghosted. In fact as did happen in 9UY once one party started losing everyone gang piled them till they could extract only a few moments later everyone was gang piling another group with the former piley joining in for kills. Your system appears to me to require people to declare their alligence formally before the battle. Which in eve is pointless you always keep open target slots for turn coats and unexpected droppers and bombers. <br />Provi Minernoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-9892268183182012642014-01-23T17:04:19.431+01:002014-01-23T17:04:19.431+01:00You can't have infinite players.
google can...You can't have infinite players.<br />google can't have the whole internet. ok. well. they can, they trough much tech and brains at anything they encounter. but that's google.<br /><br />We as players don't know the bottle necks.<br />Alot of us (read all) don't have the slightest clue about server client software on that scale in that particular EVE case plus 10 years codebase complexity. We jerkoff about the technews that for example they moved the permadb on fast SSDs. and we like the graph pr0n. but we don't know what it means.<br /><br />in IT: optimisation. is. a. huge. expensive. mind wrecking. thing!<br />Alot of time and resources go into 0.001 % optimisation. It is expensive as hell and doesn't workout all the time. on top of it you need expensive brains to solve the problem(s).<br /><br />The "cheap" solutions. like. run the DB on fast SSDs. Are pretty much taken. Otherwise why would they look at the player heads including all the skills and implants on loading time.<br /><br /><br />Your ghost idea breaks down complexity. this is one of the key things to do. If this helps at all, we do not know. maybe it is something else.<br /><br />I don't know how 10% TiDi + 2FPS client feels like. I surely can't see meaningfulness or any enjoyment from it.<br />If the objectives can be split. meaningful. than there is the opportunity to split the masses and only connect the objectives.<br /><br />Or introduce another game that takes over if the nodes can't handle it :)<br />My creativity limits me. I'm sure CCP can come up with something to make a scalable scyfi "minigame" that works well from 5k up to 1m players. why not.<br />let that game kick in after 30min of max TiDi and local is still spiking. System transforms into a whole different game that can handle allot of players. it's still better than hardwarecapping and watching 10% tidi + 2FPS. Does someone really enjoys that slow fight?<br /><br /><br />But that is all very expensive.<br />TiDi was already a expensive solution. no ghosts or new game will be made to help here.<br /><br />The easiest solution comes from the community itself. People can cap them selfes to have a meaningful experience. you can have good 1500 blob fights 5 times in 5 systems. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-61477815076670584862014-01-23T16:36:46.072+01:002014-01-23T16:36:46.072+01:00I don't like the assumption. Instead of encour...I don't like the assumption. Instead of encouraging a 6 year old soccer game style of play, make it so you don't want to put 4k people into a system. I don't know why players haven't figured this out on their own, but put a harassment fleet in when the other player loaded grid. so sent some other forces to reinforce a whole bunch of other stuff.<br /><br />But if people cannot figure this out, then implement a mechanic. Hell, once the server reaches 4k people, log them all off for what do I care? Next time, someone loads the server, you send your forces elesewhere to take on other soft targets, bring enough into that system to take everyone out of the equasion for a while.Kate 'Onhttps://www.blogger.com/profile/13993019414595472147noreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-23717871292628881962014-01-23T16:18:40.733+01:002014-01-23T16:18:40.733+01:00Of course my idea would change the battle relative...Of course my idea would change the battle relative to the same ships fighting with infinite server power. It works via removing ships from grid in an evenhanded, but still random, fashion. The entire point of the idea is to reduce lag by removing ships. High TIDI is solved in two ways: (a) by encouraging FCs to not blob as much, and (b) by blowing up ships from both sides when TIDI get high, thereby lowering server load.<br /><br />Your idea is basically to take a statistical sample of the whole system population, compute their effect, then scale up their effect based on the weight of the whole before being applied to the enemy sample. Even assuming players aren't gaming it (EVE player here: I've already got a couple potential ways to game it), random fluctuations in the sampling will inevitably affect the outcome, since they are amplified. <br /><br />Still, I'll agree with you that ghosting would keep the current meta unchanged. That is, it preserves "blobbing wins". I want to change that, because I think it has bad effects on the metagame: blobbing brings the blue donut. Von Keigaihttps://www.blogger.com/profile/14469707993470718130noreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-87799438443323129832014-01-23T15:29:27.374+01:002014-01-23T15:29:27.374+01:00because soul-crushing lag is not immersion breakin...<i>because soul-crushing lag is not immersion breaking. Because dying without being able to turn on hardeners is not immersion breaking. Because camping the system from downtime is not immersion breaking. Our only option is seeking a less immersion breaking way.</i><br /><br />Yes it is immersion breaking. But there is a difference between immersion breaking because of a system exceeding its limitations and *designing* immersion breaking into a core mechanic.<br /><br />Also your "only option is seeking a less immersion breaking way" only serves to reinforce the fact that you have no idea what you are talking about when it comes to software and network engineering, or game design. As has been pointed out before there are technical solutions which can be explored which are far cheaper and far more straight forward than introducing a convoluted immersion breaking mechanic.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-56313495561715549812014-01-23T15:11:39.824+01:002014-01-23T15:11:39.824+01:00@Von Keigai: your solution would necessarily chang...@Von Keigai: your solution would necessarily change the outcome of the battle (compared to the imaginary ideal case where the server has infinite power). So the outcome of the battle would depend on server load. Assuming it's properly coded, my solution would give the exact same battle outcome.<br /><br />@Provi miner: the time slices should be small enough to prevent "the battle was over while I was a ghost". <br /><br />The ghosting would affect everyone randomly, so if there are 5 different groups, every group is on grid with half ships, other half is ghosted.Gevlonhttps://www.blogger.com/profile/07072766785893313616noreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-36223527563629621072014-01-23T14:58:29.559+01:002014-01-23T14:58:29.559+01:00I see three main problems:
1: You are a ghost, so...I see three main problems:<br /><br />1: You are a ghost, so you go grab a bite to eat (in your example you take a 30 min food break). Now lets assume ghosting works. With ghosting working fights would be fast there would be minimal tidi. That means your fleet (remember you are gone for 30 min) is getting hammered flat so new members are pop'd in to replace the loss's. So you come back from sandwich making only to find yourself in a medical bay because you were unghosted and not at the key board.<br /><br />2: A pod is a ship, as long as that pod is on grid no new members can come in. So teams that are winning won't pod people just because they can increase their effectiveness by keeping new ships off grid. Oh and pods do zero damage so your X dps times 0 effectively equals zero.<br /><br />3: So take the fights in provi recently, as many as 5 to 8 different groups were fighting with and against each over for hours. Who deiceds who gets to load grid? My point is whats to stop one side from repeatedly loading grid with different corps thereby increasing their percentage of force in the system? <br /><br />Just some things I thought of Provi Minernoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-78130714531205408112014-01-23T14:25:03.747+01:002014-01-23T14:25:03.747+01:00Here is my solution to soul-crushing lag:
this is ...Here is <a href="http://vonkeigai.blogspot.com/2014/01/fleet-crushing-lag.html" rel="nofollow">my solution to soul-crushing lag</a>:<br /><i>this is EVE: if you want something removed, <b>kill it</b>. ... When a particular server is sufficiently overloaded -- let us say, below 20% TIDI -- then there is a chance of a very damaging area-effect explosion.</i><br /><br />How does it compare to yours? First, yours is highly complicated. I have read it twice now and still am trying to work out the implications. By contract mine is simple. Second, yours is highly immersion breaking (and yes, so is soul-crushing lag, but in a different way). Mine is not.Von Keigaihttps://www.blogger.com/profile/14469707993470718130noreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-15132604493987133452014-01-23T13:31:18.351+01:002014-01-23T13:31:18.351+01:00@Gevlon: n*n is not really a problem. You can easi...@Gevlon: n*n is not really a problem. You can easily assemble enough computation power to hndle HED-GP battle and much larger and cost of those servers is fairly low compared to developers team worktime. When servers are able to have about 4k players on grid with 10% tidi there must be at least 10+- other nodes assigned to several groups of systems. If 4 of them could be assigned to HED-GP on player spike, battle of 8k should be possible on 10% tidi comfortably.<br /><br />Problem is to assign that power to that solarsystem. Eve is currently unable to add servershards to already running solar systems.<br /><br />And having computation power to handle HED-GP battle ready on all solar systems at all times starts to be immensely costly.<br /><br />So far eve doesnt grow faster than computation power. Even when we takes it as n*n problem coputation power should doble every two years (http://en.wikipedia.org/wiki/Moore's_law) and eve would have to double every four years at least which it is not (http://eve-offline.net/?server=tranquility)Oska Rusnoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-53523065054589359672014-01-23T13:02:17.423+01:002014-01-23T13:02:17.423+01:00> If you assume some reasonable success to EVE,...> If you assume some reasonable success to EVE, you soon reach the point where all the computers of the planet couldn't handle the load.<br /><br />EVE has been around for 10 years, has during all that time never grown fast and has been stagnant for the past 3 years or so, I think we have a pretty good idea how successful it can be.<br /><br />As Jester says, everyone who is into Science-Fiction sandbox games has probably heard of EVE at this point and is either playing it or know why he isn't playing it. EVE is currently the only game filling this niche and is way too adapted to its niche to ever have much appeal beyond it. <br /><br />The goal is to keep the game stable at its current playerbase and not to lose players to competitors that may be crowding into the same niche (Star Citizen).<br /><br />> (if not, there is no point spending resources on recoding)<br /><br />This is not true. EVE cannot handle the current player numbers and if this state of affairs continues long enough players will leave. Remember that EVE is the only source of income CCP has, CCP has no choice but to invest whatever it takes to keep it alive.<br /><br />Players aren't just paying for what the game currently is, their decision to play (and pay) today is influenced by what they expect for the future. I can live with a year or two of massive lagfests (has happened before after the introduction of fleet finder) as long as I know that CCP is actually working to fix the problem. If I knew that CCP has no inclination to fix the problem I would quit right now.<br /><br />You may say "but the player number of EVE will decline in the long-term" but total player numbers aren't what causes the current lag. You can have 4,000 players in a battle with 35,000 concurrent users just as you can have a 4,000 player battle with 20,000 concurrent users. What makes these battles big is the degree of organization of EVE alliances/coalitions, not the limit set by total player counts.<br />And while player numbers may drop the process of centralization will only continue - battles won't get any smaller for a long time.<br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-643665718769730602014-01-23T12:00:04.824+01:002014-01-23T12:00:04.824+01:00@Oska Rus: the problem is that all kind of compute...@Oska Rus: the problem is that all kind of computer solution is linear. So if 10x more people want to play, you need 100x more cores or threads or whatever. If 100x more people play, you need 10000x more. If you assume some reasonable success to EVE, you soon reach the point where all the computers of the planet couldn't handle the load.<br /><br />@Dobablo: if players are acting, they must get information. If they get information, they are producing load. The n*n problem remains.<br /><br />@Last anonymous: because soul-crushing lag is not immersion breaking. Because dying without being able to turn on hardeners is not immersion breaking. Because camping the system from downtime is not immersion breaking. Our only option is seeking a less immersion breaking way.<br /><br />Gevlonhttps://www.blogger.com/profile/07072766785893313616noreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-77216447963180448272014-01-23T11:56:35.425+01:002014-01-23T11:56:35.425+01:00The problem cannot be solved by trying to cram mor...The problem cannot be solved by trying to cram more ppl inside one grid.<br /><br />Ghost groups are a nice ideia but its over-convoluted, as a programmer I can tell you the amount of unpredictable variables running arround amok with such an implemtation would make not only gameplay erratic but also make the dev team lifes a living hell.<br /><br />Grids and gates can be improved for sure, and there is no reason for ships that are "new on grid" to be held defenseless with a black screen on their client, CCP can and needs to fix that aspect of session change. But that will only get you so far and will give less gameplay not more.<br /><br />What we need to do is to remove the incentives of current gameplay to gang so close together on 1 single grid. I'll give you a few examples:<br />- Take advantage of multiple SBU's, link them and require multiple coordinated strikes. Put them *outside* systems instead of inside.<br /><br />- The game needs low SP artillery hulls, AOE artillery and not Alpha strike artillery. Dynamic battlefields breathe of of this. Bombers provide cirurgical strikes, artillery provides flak fire. This pushes weak subcaps to pounce instead of just sharing grid with caps.<br /><br />- Remove drone assist, not because of TiDi but because of gameplay, make it a skill to be able to control up to 5 assisted drones, no more. Under Tidi, clump drones together into 1 single entity (overview, bracket, HP kills drones as it reaches 1/5, 2/5 ...).<br /><br />- Make systems and grids have a max player restriction. The argument of the first guy who gets there wins is the real problem. 10 soldiers filling up a 1x1 meter square of ground provide a tactical advantage why??? Cramming a coalition into a single system is adavantageous to sov mechanics why??? <br /><br />Sov rethinking is urgent and will solve more problems than programmers or hardware.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-10821202117312411822014-01-23T11:44:30.257+01:002014-01-23T11:44:30.257+01:00Gevlon, you are proposing an *immersion breaking* ...Gevlon, you are proposing an *immersion breaking* solution which quite probably will not work. To my knowledge you do not have a background in software or network engineering so you probably should leave the solutions up to the experts. Sufficed to say, any solution which breaks immersion is no solution at all. I mean they could write code which aggregated every single thing in a fleet, figured out its dps and auto faught the whole battle with a basic calculation - but the player base would not consider this acceptable.<br /><br />Multithreading is throwing out there by commentators a lot whenever lag crops up, as some sort of holy grail solution. Firstly, number of CPUs does not equal number of threads. Threading is one method of concurrency management which generally involves timeslicing. Sure you can run more 'single' threads in an embarrassingly parallel system and it will go faster, but running multiple *threads* is not predicated on having multiple processors.<br /><br />They already manage concurrency using Stackless Python. It uses microthreads as it's approach to concurrency. There are others, such as the event loop/reactor pattern which is popularised by node.js. All of these are valid means of trying to manage concurrency but none of them will really solve the issue.<br /><br />Should eve be able to take advantage of additional processor cores? absolutely. It should. That it doesn't is a major major fuckup on CCPs part. Will it solve the lag problem? No, or at least not entirely. The speed up will not be the "instant problem solver" that people think it will be.<br /><br />@Kontalaa - as far as I am aware, each "grid" cannot be run on a node. The nodes go down to a system level only. That is the lowest level of granularity that is available.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-26885103163908901432014-01-23T11:15:00.079+01:002014-01-23T11:15:00.079+01:00I dont know if threading would be the solution. If...I dont know if threading would be the solution. If it was, and if it was easily done, CCP probably would have done it by now. They are no fools. Ghosting sounds interesting, +1 for out-of-the-box thinking. But it also sounds indeed complicated to implement, let alone understand.<br />What about limiting systems to 2,001 players in local? Granted, that would give victory to the first large group there - but that is the situation already. With everyone knowing the limit, everyone has the same chance to sit in the system as long before as possible. Of course, people awake during during down-time would have an advantage, but that could be adressed by giving a number of wildcards to people in system before downtime. Well details. Main thing is, reduce that numbers-issue for all on an equal, well-known and easy to understand basis! Make the game playable and enjoyable above "having the largest battles".Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-23713959293139114422014-01-23T10:29:14.017+01:002014-01-23T10:29:14.017+01:00EvE advertising is based on "Massive space ba...EvE advertising is based on "Massive space battles" Cutting them up smaller teams would prevent that.<br /><br />I'd fix it by grouping ships and treating them as a single unit. Aggregate similar ships into groups of 10. Individuals still get to active their modules (and F1 their weapons) but the surver aggregates this so all anyone else sees is the totals for the group.<br />The net result mostly unchanged from current. Leader still picks the target. Fleet still presses F1, but server load is reduced by a factor of 10 (or however the ships are grouped).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-19411381257357590482014-01-23T10:09:03.888+01:002014-01-23T10:09:03.888+01:00I dont gnow about your IT background goblin but n...I dont gnow about your IT background goblin but n*n problems are generally considered as easy.<br /><br />problem of eves performance comes from its legacy of 2000s when noone even dreamt about dynamic load ballancing. Today it is common part of many applications. It allows to assign more resources to already running application which is under serious load or deassign resources from idling instance.<br /><br />Eve server would require mayor overhaul to be able to do this because of its initial design and such overhaul is super costly and risky.<br /><br />All other solutions are just temporrary patches and bandaids but couldnt possibly solve situation where you have to have assigned certain resources for every empty wormhole or nullsec system and cant concentrate them fast enough for such a large events.<br /><br />Your sollution is one of that temporrary patches and is overly complicated thus prone to bugs, other performance problems and abuse.Oska Rusnoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-15373230924224407922014-01-23T09:27:06.310+01:002014-01-23T09:27:06.310+01:00Random events like removing a group and placing an...Random events like removing a group and placing another group out of the "ghost pool" would make it impossible to win or lose a battle.<br /><br />If you win your opponent will say: "CCP won the fight by giving us shitty groups!!! We would have had won otherwise!!!"<br />If you lose you will say:<br />"We had better fleet, more pilots, but the server f*cked up splitting our efficient groups into sitting ducks!!!"<br /><br />How is that different from "We lost the fight because X was on grid before us!"?<br /><br />It wouldn't solve the problem.<br /><br />I really like how the SOV grinding works in factional warfare. A single frigate running a novice plex while the enemy is bashing the iHub can defend the whole system for some time. You don't have to wait for timers to happen, if you can't take system X you reorganize your fleet and jump over to system Y.<br />It doesn't matter if your enemy is "plexing" a novice plex with 50 frigates while you take 3 of his novice plex with one frigate each.<br />You don't focus that much on one system @ xx:xx UTC.<br /><br />Sure, for nullsec it would require some tweaks and changes as the FW mechanic is focused on instant action and systems can be flipped too fast.<br />Change SOV mechanicnoreply@blogger.comtag:blogger.com,1999:blog-1461700565722278823.post-3204978326745932822014-01-23T09:18:11.827+01:002014-01-23T09:18:11.827+01:00The solution is algorithm and number based. As suc...The solution is algorithm and number based. As such, players - especially Eve players - will find a way to exploit the fuck out of it, one way or another.<br /><br />The problem, and solution lies at design levels. Change the game and mechanics in a way that would encourage multi-front battles spread over larger areas instead of thousands of people trying to dogpile on single server. Ever read about the Battle of Leyte Gulf, where IJN bait carrier fleet led away sizable USN detachment away from the main battle, almost turning the tide despite IJN being outnumbered several times over, with USN battlegroups each larger than total IJN force in the region? Such a thing is completely impossible in EVE. The design needs more depth. Toss in multithreading on top of that and we'll be fine for anotehr couple hundred thousand subscribers.Anonymousnoreply@blogger.com