Originally by: Solbright

---

Well, isn't that a good enough reason? To make some noise so CCP takes action?

---

Originally by: Solbright

---

Originally by: Oblom

---

Too much data or not - it doesn't matter. Updates of the screen with available information should never stop. Like own ship, static surroundings and things like blinking stars . Arriving data can be buffered and processed as time allows. There will be delay with displaying some objects, but no freezes. Then you optimize the code and see what can be done to make things faster.

---

Good stuff. Couldn't have said it better. :)

Quote:

---

But I still think that in most cases it caused by server side delays with client just sitting frozen doing nothing while waiting for server to respond.

---

http://oldforums.eveonline.com/?a=topic&threadID=497236
- Check the posting by Nonym Ous in particular, you get a good descripton of someone dealing with lag but no stutter. I bet, however, if he'd had the full force of the battle, ie: very little lag, he'd not only have had a dose of stutter to deal with he also would have been podded because of the stutter.

Quote:

---

But again, it doesn't reallly matter. We are not going to fix it. We only can make a little bit of noise on the forums about it. Question really is will CCP ever attempt to fix it?

---

Well, isn't that a good enough reason? To make some noise so CCP takes action?

---

Originally by: Xianthar

---

Originally by: Seruph

---

Its in Python isn't it? If so, then theres your problem right there. Please lets not have a UI that takes 3 and a half hours to garbage collect and is incapable of rendering a 700k text document in real time. Try loading a 700k text document in the IGB then viewing source. I recommend you grab lunch.

What I would like to see is, instead of DirectX Fullscreen mode, at least having an option for the "Maximized" mode that ShiftWindow, EVE Launcher, and all those other programs use. The one thing they lack is removing the window decorations so that special themes don't make the fonts blurry and so that the window decorations don't stick out onto second monitors. It could then be possible to decouple the UI from the viewport so we could still have our UI elements without having to have the viewport open. Chat in EVE without having to have it using up all that screen space would be a plus and have the added bonus of not stalling the whole game when you try to do something weird with the IGB.

At any rate, running all that python dribble in a separate thread from the rendering with some clever message passing would improve the game play experience immensely. Maybe add some preemption to python's scheduler so you didn't have to wait for a UI task to complete before updating other UI elements. That way searching the market wouldn't make it impossible to chat or interact with other ui elements.

---

the graphics engine is written in C++ to my knowledge....and it exists in a seperate module from the python code and uses callbacks to communicate between them.

the reason the interface stops is because this it is waiting on the network connection for data needed for rendering. It can't draw a ship unless it knows where to draw it. Some games, FPS mostly, have "predictive" code that, when a server update is not available makes a general guess as to where things are moving. If you've ever played a FPS on a crappy internet connection and been running along then all of a sudden to are jump to another place then you have experienced what happens when the prediction code guesses wrong. At some point in the dev work at CCP they decided against any sort of predictive code structure, probably because eve is not a game where you want what you see to be out of sync with what is really happening, it could lead to a poor decision which could cost you months of work. its not like BF2 where you just respawn with all your stuff.

there are impovements that could be made to the UI but predictive movement is not one of them IMO. i'd much rather have an option to completely dumb down rendering for fleet fights....i.e. draw all ships are simple flat shaded cubes and just keep the overview the same.

-xian

---

Originally by: Xianthar

---

2 weeks post patch: everyone *****es about why the ship that their client thought was 15km away should have been scrammed when the server thought the ship was actually 80km away.

---

Originally by: Xianthar
2 weeks post patch: everyone *****es about why the ship that their client thought was 15km away should have been scrammed when the server thought the ship was actually 80km away.

-xian[/quote

---

This is interesting in relation to the 'distance bug':

what's interesting is that not only is there a disparity between client and server info but that the client once it has its own distances fixed seems to reject server updates to the contrary

Originally by: Princesse Qiao

---

... but that the client once it has its own distances fixed seems to reject server updates to the contrary

---

Originally by: Oblom

---

Edited by: Oblom on 31/03/2007 02:03:22

Lag is a common problem for any online game. But stopping screen updates completely while waiting for server to respond is just a sloppy program design. Nothing more. Not a "decision they made." You render what you can. You know where your ship moves, you render it. You know where static objects are, you render them. And you do it all the time. You don't know where dynamic objects are, you do something different. Predict therir movement or don't display them at all. But just freezing the screen is real mess and not an answer. Especially when completely unrelated things like opening market window cause the whole thing become dead. This is design error, admit it.

---

Originally by: Sal Alo

---

Originally by: Oblom

---

... cause the whole thing become dead. This is design error, admit it.

---

/signed 101%

---

Originally by: Trilium Eagle

---

The file location change fortunately can be reversed by switches on command line so files are used from last place.

---

Quote:

---

As for lag lately in mornings we had situations where three corp members were unable to !mine! due to lag and inability to move cargo from bay to cans. Getting drones to bay took few minutes and they were sitting on roid few km's from ship.
Something really gotten wrong with server

---

Originally by: CCP Wrangler

---

You're not supposed to feel like you're logging in to a happy, happy, fluffy, fluffy lala land filled with fun and adventures, thats what hello kitty online is for.

---

Originally by: Frug

---

I think it's fairly obvious that nothing's decoupled and that the market lag is due to the whole client waiting for an update.

---

Originally by: Za Po

---

When I change a market order, after ten seconds or so, the wallet window refreshes. This freezes the interface for about 4 seconds.

Until now, I assumed that this is because the game is requesting full order info, which might reasonably take 4 seconds to get from the network, and because of bad threading this freezes the interface.

But some people here are saying that the client is already well decoupled, and that the issue is with the UI thread itself.

So, are you telling me that the client actually takes four freakin' seconds to build a list of 250 items, of which only 30 or so are shown, and for which the data to display has already been fetched?!?

If this is true, well, I definitely hope they are really looking into it (as in: throwing the library away). That's worse than your average Windows list by orders of magnitude. Python being bad, not that I'm an expert on python, isn't enough to justify this. Hell, I have written programs that can compile from C++ code, start and fill a 2500-elements list in less than four seconds.

In fact, it's so ridiculously bad that I am hard pressed to believe it. Is there any proof that the client isn't simply waiting on the network?

---

Originally by: Andrue

---

[Pile of techno-babble]

But, meh - this is all speculation. CCP developers aren't idiots and I doubt the UI issues are the result of crappy programming.

---

Quote:

---

It's risky to make predictions about cause/effect even when you have the source code. Doing it from the customer side of our relationship is almost bound to fail

---

Originally by: Solbright altaltalt

---

Apologies if that came across a bit aggressive but you did defended CCP's performance over what is now 7(?) years of development. And greater than 4 years since official launch.

---