DrCrusher

I'm sorry, I don't have any more information about the situation. Maybe Walt-Her has? I can however say that the ISP involved (XS4ALL) is the best ISP in the Netherlands. They are technically very knowledgeable and are actively fighting for everybody's rights such as privacy and anti-censorship. They must have had a very good reason to block the IP-range. Cheers, DrCrusher

In this case DNS had nothing to do with the connection problem. The problem was not that the name of the EL website couldn't be resolved, the problem was that all traffic to the EL website was blocked. Furthermore I believe opendns is a threat in itself. It breaks several important Internet standards and protocols which result in unexpected behavior and prevent the possibility to debug/solve certain problems. But let's not get off topic here, we don't want to start a flame in this thread

There has indeed been a problem for about 4 days connecting to the EL website from the Netherlands, at least for ppl connected to some ISP's. Note that connecting to the game server / playing the game worked. From the little info I have there seemed to be a problem with the entire network range in which the EL webserver is hosted being blocked or some routing problem, possibly at the ams-ix (Amsterdam Internet Exchange). The problem seems to be solved now, so I can post this reply DrCrusher

In HTTP/1.0 it is not allowed to put an absolute URI in the get request. Host headers are indeed a HTTP/1.1 feature, but I believe virtual hosting is also. I think all (HTTP/1.1) servers with virtual hosting configured will accept the host header even for HTTP/1.0 requests. In any case, the eternal-lands webserver does (I checked). In HTTP/1.1 it is allowed to put an absolute URI in the request, even when not using a proxy server but talking directly to the webserver (RFC 2616, section 5.1.2). But the host header is still mandatory (RFC 2616, section 14.23).

Hi, I did a search, but I could not find any relevant post regarding this problem. The problem is, when auto-updating the client sends a GET request for GET http://www.eternal-lands.com/updates/files.lst HTTP/1.0 CACHE-CONTROL:NO-CACHE I have a connection through a transparent HTTP proxy (not a classic proxy as you would normally configure in your browser, but one that is invisible to the browser). It has problems handling this request. Such a request for an absolute URI (thus including the http://host.foo.bar/ is only allowed when talking to a classic HTTP proxy server (see RFC 1945, section 5.1.2). When talking directly to a webserver, as is the case (the transparent proxy is something the client cannot be aware of, it should act as if it is talking to the webserver), you should get only the path portion: GET /updates/files.lst HTTP/1.0 CACHE-CONTROL:NO-CACHE But since the webserver has virtual host, you'll also need to include a host header to make it work: GET /updates/files.lst HTTP/1.0 host: www.eternal-lands.com CACHE-CONTROL:NO-CACHE I don't know if the client is aware of proxy settings in the browser and uses this proxy when present. If so, it might be necessary to adjust the behaviour of the client according to the situation it is in. I hope the problem is clear and it is fixed in a future version Thanx, DrCrusher

I think the devs would have no problem adding that pretty devastating weapon they gave Marvin to stop that Frogstar Scout robot class D with.

It doesn't seem to make any difference in FPS when I adjust those OpenGL settings. Besides, it does not explain why the previous version was performing much better with the same OpenGL settings. By the way, several people told me ingame that they also have a serious performance drop, but they did not post here (yet). Hopefully they will do so later, so you get more info on the issue. Thanks for trying to help.

That's what I suggested in my initial post It works pretty good on my machine with adjusted perspective, but my wife's machine is a bit less powerfull and she must play the new version in isometric view to get a reasonable FPS. The old client worked well for her in perspective mode. And i've an old P3 667 Mhz too, with which I could play the old version, but which is too slow to be able to play the new version at all. Can you plz confirm if the cause is indeed the far plane distance and if it has changed since 1.1.2? If so, would you consider making this setting configurable in the options screen? Thanks, DrCrusher.

You must be doing something wrong. My machine is an AMD 64 +3000, ATI Mobility 9600 64MB VRAM And I get over 50 FPS in most of the places, unless I am near some storage whe I get maybe 30 FPS. Post a screenshot so I can see the perspective you are using. Unfortunatly i can't post screenshots now, but my post in the RC3 thread explains a lot i think: RC3 thread Look at my posts #37 and #39. If needed I can post screenshots later today. Thanks, DrCrusher

gives me 1 or 2 frames more, still far away from the performance of the old client...any chance to get the client w/o the speed fix to work with the new version? I have the same problem and I reported it for several release candidates. Unfortunatly it was not picked up there. It seems the new client shows objects far more in the distance. Therefore much more objects need to be rendered and FPS performance grinds to a halt. The performance increases much if you are on the edge of a map and face the edge, so I think it realy has to do with the number of objects to be rendered. A workaround is to change your perspective settings so you don't see as much of the environment or to play in isometric view. It would be nice if there was a configuration option for the maximum distance that is rendered (is that the far plane? I'm not a 3d programmer). My machine: Windows XP SP2 with all patches installed P4 3.2 Ghz, 1 Gb ram Radeon X740XL 128 Mb I tried several graphic drivers, including Omega drivers, but no real difference in performance. I only got a chance to play the update when there were almost no monsters, so i'm looking forward to play again tonight with all monsters present Cheers, DrCrusher

Aditional info: - I can use home, del and insert to move thru these areas. I can't click on these areas but movement seems perfectly possible thru them. So, mapwalking should also work. - If I, for example, walk to Noria using the keyboard thru this black ground, then I can return to the "normal" ground zones clicking on it. I found that if you enable the ATI bug and mouse bug options you can walk on those black areas by just clicking on it like normal ground.

I found another small bug today. I don't know if it also happens in the old client, but with the new client I noticed it once today. When I posted something on the market channel, i did see my text in the graphic screen, but when i switched to console mode i did not see my message. I tried to scroll, but that did not help. When I switched back to graphic mode my text had already disappeared, but when someone else posted something in market a moment later, my message did suddenly appear in the console screen also (before the text of the other guy, as I would have expected). I think the text was just scrolling of my (graphics) screen at the moment I switched to console mode the first time. I'm pretty sure I did not imagine this It's not very important, but I thought i'd mention it anyway

I also had a crash today when I entered SKF from Nordcarn. I could not reproduce it though. And here are some screenshots from the Carmien Manor problems:

I tested the new el.exe today. I also found some ground missing, but it was inside Carmien Manor, near the ogre spawn. And is the carpet in Carmien Manor before the door from the trolls to the ogres supposed to be black, or is something missing there also? I'm not visiting the manor a lot, so I don't remember I did not test the portland storage with this el.exe yet.

I have seen this once too, but since I never saw it again I figured it was a glitch in my system. I've also seen a couple of totaly black creatures (wolves, deers) once. After a relog the problem was gone and I never saw it again.