Escatopoulos

Has Elysium restricted the viewing distance for NPCs and other players? I find that the game experience globally is not as good as the current technology and connections would allow for a game that was developed for machines now more than 10 years old. I was hoping to play vanilla WoW with max settings and everything, something I was unable to do back in the time, but I feel even though I can see a lot of landscape, mobs and other players disappear way too soon from my view. Is this related to the poor server performance because of the overpopulation?

After all this I really don't understand why they still exist and why the admins allow it.

The problem appeared when Blizzard limited the the % of players that could access certain items of the game, the best ones to worsen it more. It didn't matter how hard all players tried to get those items, the majority of them would be left out, because it is programmed that only the top % of players will get them. And that's when the hardcore players were born, and what made a game a profession for some people, and unfair to compete against that only seek the pleasure and freedom of a game to spend their free time on. But some people actually spend their job times and more in it, a minority, but it seems that the game progresses looking after those players instead of towards the community, a community, by the way, that does not want them, or want them apart playing against each other.

Seriously? The cries I hear are for lowering the player cap, get rid of this lag that high cap is bringing and why not, increase the draw distance so we can better enjoy the game, even if that implies a lower player cap.

We are talking about server population, server de-population, the consequences of the admins decisions, the lag that all these leads to... It is all related. Changes bring consequences. If we want these consequences to be positive for all we must foresee them, or face a server that might be victim of its own success. There are people that will chose to stay in vanilla, again refugees, that will stay in Elysium, but after Anathema has emptied of people migrating to the TBC server, and Elysium 60s have also flown to continue their progression, what will happen to Elysium, an empty Anathema, and an overcrowded new TBC server, facing the same or worse problems that Elysium is already suffering?

In my case I was a new player to in a vanilla private server and reading and looking for the best one, everything pointed towards Elysium, Anathema being dead. But I didn't know about this performance issues. I've always said the population should be capped to a much lower limit and send new players to other servers.

I've been commenting this since I experienced, on the very first weekend I played a BG, how it was completely impossible to Ambush anybody or backstab, and I have played a rogue all the time since vanilla retail. It makes the gaming experience a frustration instead of a funny thing.

This by CM Josipbroz yesterday: "There are currently no plans on offering transfers due to the different realm types and progression."

But being completely honest, how much of the Elysium Project is community based and how much is the private part of "private server"? Because if I understand properly, the Elysium Project is community based for the code, development, bug tracking, forum etc. but is completely closed and private on the owning and administration of the Elysium Project itself. And what I mean is if something is community based, it is by definition democratic, if we need more servers or better ones and we need the money for it, we all fund it, each one as much as he can/wants, and I'm sure people would pay a proportionate amount to have top servers and play a top quality vanilla WoW than anything else.

That is confirmed by the Staff that is not going to happen, and I believe it's the best decision. I would just start a new character there and enjoy the long levelling experience without the need to get to 60 asap. It would reduce the Elysium load too because if I had a 60 and wanted to level up an alt, I would then do it in Anathema so it's ready early when TBC comes ;) That's why I think it's a good decision that Anathema will be the first stepping through the Dark Portal.

Wouldn't it be more logical then to set the server to a population limit that matched it's acceptable performance so even under it's maximum load it would perform well? Now this has the advantage that you don't need a super ultra high spec server, what I'm saying is limiting the population to the server's quality, whatever that is. What is clear now then is that Elysium has reached sustained load periods beyond an acceptable performance level, so it is clear to me that it needs that limit, and that limit is hundreds (if not thousands) below the current maximum.

Oye pues cuántos se necesitan para fundar una Hermandad? jaja porque yo me apunto!

Hola Sonyc, pues alguna hay aunque la actividad española que he visto yo en 3 semanas en el servidor es poca pero bueno :'( El idioma oficial del juego es inglés así que aunque haya gente española, en los chats públicos sólo se puede hablar español, luego ya evidentemente en el chat de la hermandad es libre. Cualquier cosa tú pregunta, ojalá se crease una buena comunidad de jugadores españoles.

UP. I believe more in-game GM's are required and I wonder if it would be possible to just democratize being a GM and being able to just level up a toon happily and block/restrict a player that is violating the terms. Since it's SO obvious most of the times when someone is a bot, I don't see why it's so difficult to control. It ends up worsening the overall experience of other players and corrupting the economy. In the Burning Crusade times you could in-game report a player and I guess if any particular one gets enough reports it can trigger a red light and a GM/Admin/Moderator could simply kick it out.

I think this answer is spot on. But... the problem then is in the game mechanic itself, since it only allows a certain % of the players to reach the top, it means by definition that no matter what MOST players do, there will only be a handful of them allowed (again, by definition) on the top Rank, and therefore allowed the top items etc (the Purple fever). If the honor system was one that allowed ALL players to access everything (just harden the requirements, but don't limit it to a small player %), then it would depend entirely on YOU to reach Rank 14. It would be more democratic, not a Dictatorship of hardcores.

To be honest, I believe the last thing Elysium needs right now is new players, since it's population is already causing the server to struggle and lag. Ironically, I think the opposite is what would benefits all servers, including Elysium itself: closing Elysium for new players or limiting it's population. That would automatically cause Anathema to absorb new players and have more activity, and restrict Elysium to a healthy population that the server machine itself can handle. It seems that right now, that machine struggles with so many silultaneous connections. I would set the population limit low and start new servers if needed, from the very beginning, and I believe many people would prefer to level up a new character there knowing no level 60 with Tier 2 would gank them.

+1 Best way to express it. I'm actually starting to feel concerns that this all is starting to look more like Blizzard's history and less of a community based server.

Hi everyone. The unbearable lag on weekends, is nothing new and I can anticipate the excuses for it but since it's a problem that repeats constantly and in a predictable manner, then the causes can be identified and dealt with. I don't know about servers, TCP/IP, connections etc. but I can think of a logical conclusion: the server does not support it's population. If that's the case, the server could either be updated OR the population should be limited to where the connection is stable. Also on BGs, that are managed by independent servers on retail, where the population is just 10 against 10 players, lag is unbearable, making the game experience extremely unpleasant and frustating. The economic argument is understandable, and in the end, playing Elisyum is free, but if I were the administrator, I would be completely transparent about 1)the current server capacity, 2) the economics required to solve the lag issues and how to defray it, and 3) bringing up the possibility of a population limit if updating the server/connection is not feasable, even if that ends up on queues to log in and people going berserk. It is for our common benefit and the bennefit of Elysium, a server that has made me love the game again.

I doubt there is a single player that doesn't lag on BGs when the server load is high...

Are we seriously discussing wether the server lags or not? I don't like to use the word "unplayable" but try any melee class on BGs when the server is "struggling" and it is UNPLAYABLE, and I mean every letter of the word, and the caps. And remember Elysium is a PvP server.

Hi everyone! The Error Reporting tool keeps popping a lot for me and I was wondering if it would be useful to send these reports to anybody of the Elysium Project (I'm obviously not sending these reports to Blizzard). I'm playing on the Mac client under MacOS 10.12.6, machine is MBP 13" early 2011 (i5 2,3 GHz - 4GB RAM - Intel HD 3000 Graphics) and this is an example of an error I got: WoWBuild: 5875 Local Zone: Thunder Bluff Local Player: Pitufa, 0000000000200575, (-1232.54,36.6773,177.802) Locked Target: Tal, F130000BB30067F7, (-1196.75,26.0777,176.949) ========================================================= Assertion Failed! App: /Applications/WoW-1.12.1-enUS-Mac/WoW.app File: /Volumes/R2/usrbuild/xb/build/WoW_5875patch12.1/WoW/Source/Mac/../../../Engine/Source/Tempest/c3spline.cpp Line: 606 Time: 2017-08-24 15.48.45 GMT+2 Assertion: CMath::fnotequal_((pts[i+1] - pts[i]).SquaredMag(), 0.0f) --------------------------------------------------------- Thread 0 (Crashed) 0 0x001cd145 1 0x00027c71 2 0x00027fde 3 0x00005050 4 0x00278f63 5 0x0027a9fc 6 0x0026c5d5 7 0x00066c16 8 0x000672a2 9 0x00067a10 10 0x00068990 11 0x002841f8 12 0x0028576a 13 0x00428a52 14 0x000fc175 15 0x0000b3f6 16 0x001d50bd 17 0x001da46b 18 0x001da6f6 19 0x0000f1ed 20 0x00004085 21 0x93987abe InvokeEventHandlerUPP(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*, long (*)(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*))+001a 22 0x93933112 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*)+07dd 23 0x93932288 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*)+01a3 24 0x939320d7 SendEventToEventTargetWithOptions+0028 25 0x93968def ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)+0198 26 0x939335e8 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*)+0cb3 27 0x93932288 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*)+01a3 28 0x939436f0 SendEventToEventTarget+0022 29 0x93aca7f4 ToolboxEventDispatcher+0052 30 0x93aca6b3 RunApplicationEventLoop+00c2 31 0x000041b6 32 0x00003172 33 0x0000308d 34 Thread 1 0 0xa165691e mach_msg_trap+000a 1 0xa1655e93 mach_msg+0033 2 0x97f078c1 glcDebugListener+019a 3 0xa1742047 pthread_body+00b8 4 0xa1741f8f pthread_body+0000 5 0xa174184a thread_start+0022 6 Thread 2 0 0x0047c4cf 1 0x00382e17 2 0x001e201b 3 0x001e1d65 4 0x001ce651 5 0x001d1011 6 0x001252bd 7 0x0008926f 8 0x000b3809 9 0x000b39f6 10 0x95a22fde -[NSThread main]+0027 11 0x95a22d78 NSThread__start__+04ee 12 0xa1742047 pthread_body+00b8 13 0xa1741f8f pthread_body+0000 14 0xa174184a thread_start+0022 15 Thread 3 0 0xa165e30e psynch_cvwait+000a 1 0xa1742efc pthread_cond_wait+02d3 2 0xa1742c24 pthread_cond_wait+0019 3 0x0019f2cb 4 0x0003287d 5 0x000b3809 6 0x000b39f6 7 0x95a22fde -[NSThread main]+0027 8 0x95a22d78 NSThread__start__+04ee 9 0xa1742047 pthread_body+00b8 10 0xa1741f8f pthread_body+0000 11 0xa174184a thread_start+0022 12 Thread 4 0 0xa165691e mach_msg_trap+000a 1 0xa1655e93 mach_msg+0033 2 0x93e8251c HALB_MachPort:+0082 3 0x93e5cc7d HALB_MachPort:+0031 4 0x93e596d8 HALC_ProxyIOContext:+06c2 5 0x93e58dc4 HALC_ProxyIOContext:+00ec 6 0x93e89813 invocation function for block in HALC_ProxyIOContext:+0014 7 0x93e58c97 HALB_IOThread:+0047 8 0xa1742047 pthread_body+00b8 9 0xa1741f8f pthread_body+0000 10 0xa174184a thread_start+0022 11 Thread 5 0 0xa165e30e psynch_cvwait+000a 1 0xa1742efc pthread_cond_wait+02d3 2 0xa1743754 pthread_cond_timedwait+001b 3 0x0019f1c5 4 0x00432c95 5 0x000b3809 6 0x000b39f6 7 0x95a22fde -[NSThread main]+0027 8 0x95a22d78 NSThread__start__+04ee 9 0xa1742047 pthread_body+00b8 10 0xa1741f8f pthread_body+0000 11 0xa174184a thread_start+0022 12 Thread 6 0 0xa165e666 select_nocancel+000a 1 0xa165aa51 select+0053 2 0x00378a81 3 0x000b3809 4 0x000b39f6 5 0x95a22fde -[NSThread main]+0027 6 0x95a22d78 NSThread__start__+04ee 7 0xa1742047 pthread_body+00b8 8 0xa1741f8f pthread_body+0000 9 0xa174184a thread_start+0022 10 Thread 7 0 0xa165e666 select_nocancel+000a 1 0xa165aa51 select+0053 2 0x00378a81 3 0x000b3809 4 0x000b39f6 5 0x95a22fde -[NSThread main]+0027 6 0x95a22d78 NSThread__start__+04ee 7 0xa1742047 pthread_body+00b8 8 0xa1741f8f pthread_body+0000 9 0xa174184a thread_start+0022 10 Thread 8 0 0xa165e666 select_nocancel+000a 1 0xa165aa51 select+0053 2 0x00378a81 3 0x000b3809 4 0x000b39f6 5 0x95a22fde -[NSThread main]+0027 6 0x95a22d78 NSThread__start__+04ee 7 0xa1742047 pthread_body+00b8 8 0xa1741f8f pthread_body+0000 9 0xa174184a thread_start+0022 10 Thread 9 0 0xa165e666 select_nocancel+000a 1 0xa165aa51 select+0053 2 0x00378a81 3 0x000b3809 4 0x000b39f6 5 0x95a22fde -[NSThread main]+0027 6 0x95a22d78 NSThread__start__+04ee 7 0xa1742047 pthread_body+00b8 8 0xa1741f8f pthread_body+0000 9 0xa174184a thread_start+0022 10 Thread 10 0 0xa165e30e psynch_cvwait+000a 1 0xa1742efc pthread_cond_wait+02d3 2 0xa1743754 pthread_cond_timedwait+001b 3 0x0019f1c5 4 0x001cabe6 5 0x001cac56 6 0x000b3809 7 0x000b39f6 8 0x95a22fde -[NSThread main]+0027 9 0x95a22d78 NSThread__start__+04ee 10 0xa1742047 pthread_body+00b8 11 0xa1741f8f pthread_body+0000 12 0xa174184a thread_start+0022 13 Thread 11 0 0xa165e666 select_nocancel+000a 1 0xa165aa51 select+0053 2 0x001ca042 3 0x001cb00a 4 0x000b3809 5 0x000b39f6 6 0x95a22fde -[NSThread main]+0027 7 0x95a22d78 NSThread__start__+04ee 8 0xa1742047 pthread_body+00b8 9 0xa1741f8f pthread_body+0000 10 0xa174184a thread_start+0022 11 Thread 12 0 0xa165691e mach_msg_trap+000a 1 0xa1655e93 mach_msg+0033 2 0x94262276 CFRunLoopServiceMachPort+00d6 3 0x942616a8 CFRunLoopRun+0628 4 0x94260e1a CFRunLoopRunSpecific+01fa 5 0x94260c0b CFRunLoopRunInMode+007b 6 0x9354c773 +[NSURLConnection(Loader) _resourceLoadLoop:]+0218 7 0x95a22fde -[NSThread main]+0027 8 0x95a22d78 NSThread__start__+04ee 9 0xa1742047 pthread_body+00b8 10 0xa1741f8f pthread_body+0000 11 0xa174184a thread_start+0022 12 Thread 13 0 0xa165e30e psynch_cvwait+000a 1 0xa1742efc pthread_cond_wait+02d3 2 0xa1743754 pthread_cond_timedwait+001b 3 0x0019f1c5 4 0x0037afe6 5 0x000b3809 6 0x000b39f6 7 0x95a22fde -[NSThread main]+0027 8 0x95a22d78 NSThread__start__+04ee 9 0xa1742047 pthread_body+00b8 10 0xa1741f8f pthread_body+0000 11 0xa174184a thread_start+0022 12 Thread 14 0 0xa165ecba workq_kernreturn+000a 1 0xa1741d06 pthread_wqthread+04ba 2 0xa1741826 start_wqthread+0022 3 ========================================================= Thanks!

So I hope these threads help spread to whoever may adopt those decisions that people are frustrated and fed up of a non-enjoyable (to say the least) server experience.

So the problem is well know, it's constant and it generates concerns amongst users, and it's not being solved? <- That's why it's being debated, you want everybody to be quiet and experience this frustration EVERY weekend? Is that gonna solve it?

GMs should be the first controlling and not promoting off-topics, out of respect for the Original Poster who is expressing a concern that more people may have.

So... after reading all this thread I'm still wondering if Hemorrhage effectively increases the bleeding damage tics or not ?¿?