korrode

you're saying you'll put your sister's b'day ahead of EL penguin day activities? son, i am disappoint

http://www.newegg.com/Product/Product.aspx?Item=N82E16814130452 that'll work with 'normal' (non-legacy) nvidia driver ^^ ediy: damj tupos

The 2.6.39 kernel is going to bring significant performance (and probably compatibility) improvements for nouveau. 2.6.39 is still at RC stage upstream and is not available in any Arch repos. Your most reliable option is to rollback your Xorg to version 1.9.x and then you'll be able to use nvidia-96xx again. Another option is to build yourself a 2.6.39-rc3 kernel and see if nouveau then works. I suggest rolling back Xorg for now and waiting for the .39 kernel and any associated nouveau stuff to come into the Arch official repos... but whichever way you want to go, if you need help let me know. edit: If even with 2.6.39 nouveau doesn't work, hopefully nVidia will put out 96xx and 173xx drivers for Xorg 1.10 ...but unlike last time (the 1.7 -> 1.8 debacle) there is more chance they wont now... because nouveau is in fact, apparently, coming along well. edit2: http://www.nvnews.net/vbulletin/showthread.php?t=160143 There a nVidia official at least didn't say that they won't be putting out a new 173xx ^^

http://support.amd.com/us/gpudownload/windows/Legacy/Pages/radeonaiw_xp.aspx?type=2.4.1&product=2.4.1.3.13&lang=English

I'm also a person that some may describe as 'paranoid' in regards to data collection/privacy. I run an OS that doesn't phone home at all, I use a browser that doesn't report any data back to it's creator, I browse with cookies disabled using exceptions for particular sites only ...and if any data retention proposals make it through Parliament in my country I'll be renting a server in another country and routing all Internet data through it over SSH (encrypted). Yet I agree also that the data obtained by others via achievements being public just doesn't matter.

I think of the multiple reasons that channel didn't end up being used regularly, that reason is a minor one. The most fun flaming is when the flames start due to a reason, due to an existing altercation, but the channel was designated 'flames channel, rather than a chat channel where flaming was allowed... but that's way off topic lolz In addition to Ateh's offerings, check out my Succubus http://www.paradoxcomputers.com.au/images/vexxim_minion.jpg She has a nice idle animation where she spanks her own ass and lets out a satisfied squeal too! I think most MMO'ers don't want G-rated 'traditional medieval fantasy'

I tend to agree with Nardo and grud. Though however it goes, there'll still always be the option of using unofficial custom clothes servers, which as someone mentioned earlier, will probably evolve to include the content of any paid official service and then have additional customs... so any of us who don't care about maintaining a G-rated medieval feel can just use those.

Certainly not when they go to PK. The concerns related to PK are irrelevant so long as the option to turn off custom clothing exists.

Maybe. See if the behaviour is consistent in the same situation.

Some time back (around when WTF instance first came in) we observed resync issues when many people were attacking one mob even when the above changes were used. The only plausible reason I could see was that the mob's damage animation queue was getting backed up. I tried making changes to the the damage animation duration for the creatures it occurred on and iirc it did help... but considering the variety of instance/invasion creatures around these days, to set up in such a way that there'll be no resyncs for anyone would involve many changes... and they affect all mobs that use the same model (for eg. changes to mare bula damage animation duration also affect hobgoblins). A better way to address this, rather than everyone fuxing with their .xml files, is to have the server or client drop the sending(server)/displaying(client) of any animation occurring within X time of a previous animation for the same actor. Considering resync'ing can often = death, and death costs US$5 in EL, fixing the resync issues should be top priority, IMO. EDIT: @Panatella Are you saying that you didn't experience resyncs in the same situation on non-CVS client?

So where exactly was this folder located?

Uninstall EL Delete the C:\Program Files\Eternal Lands\ folder if it remains. (If you use 64bit Windows it'd be C:\Program Files (x86)\Eternal Lands\ ) Install EL again.

If i was in your position i'd look deeply into running Xorg 1.7.x (if that is in fact the sole thing stopping the usage of the older ATi binary drivers, which i'm pretty sure it will be). If it's no-go on Debian, success might be found on a distro that's more upstream compliant and has less cross-package integration. (This isn't a stab at Debian, I like Debian, it's just fact.)

This should be done irrelevant of the proposed global advantages. No other MMO that I know of has you doing daily quests that are 'way under your level'.

I can tell you now that building a kernel module against Lenny's 2.6.26 kernel and trying to use it with a 2.6.3x kernel will not work ;p edit: also, the Xorg version differences will cause incompatibility as well. A lack of fglrx driver supporting newer Xorg's could be the sole thing holding you back from using the older ATi binary drivers right now. edit2: Yeah... can see here: http://support.amd.com/us/gpudownload/linux/Legacy/Pages/radeon_linux.aspx?type=2.7&product=2.7.2.3.2&lang=English Xorg 1.7.4 is the latest supported... Pretty crappy really... nVidia put out 96xx and 173xx drivers for Xorg 1.8.x and then 1.9.x so their legacy products would still work on current distros... AMD/ATi need a slap :< edit3: You could try building the Xorg 1.7.3 packages from Lenny and running the older Xorg server... could be problematic tho... That said, a while ago i held back updating to Xorg 1.8 on one of my ArchLinux systems that had a nVidia 5xxx series card while I was waiting for nVidia to put out a new 173xx driver... i kept updating all other packages though, it didn't cause me any problems, but it was only briefly. If you're going to try it, don't forget to also build and install evdev and any other Xorg drivers you use.

And a Wizzy hat (Wizard's) yer and some... umm... hmm... korroded armor... damn it dunt work

If my understanding of ATi/Intel MESA stuff is correct (which I don't have heaps of direct experience with, as all my stuff is nVidia (i won't buy anything but nVidia for a system where I want 3D capabilities for these exact sort of reasons)), all the 3D functionality is provided by MESA, and afaik it is also what provides the entire DRI... so I wouldn't write off updating it as a possible solution. All of the various MESA-related packages are made from just one source package simply called "mesa". ( http://packages.debian.net/search?keywords=mesa&searchon=sourcenames&suite=all&section=all ) You could put a deb-src line for a sid (for 7.10) or experimental (for 7.10.1) repo in your sources.list and then do: aptitude update apt-get build-dep mesa apt-get -b source mesa and then hopefully (barring dependency issues) you'll have a bunch of new mesa binary packages built against your squeeze system, ready to install. Also, you could consider running a newer kernel that doesn't have all the firmware Debian classify as "non-free" ripped out, a common choice for people running Debian on gaming/multimedia workstations is the Liquorix kernel: http://liquorix.net/ I don't know if getting a kernel/firmware newer than the 2.6.32 ones shipped in Squeeze will impact your ATi chip, but I know it's possible it could. (for eg. there's newer, better nouveau firmware in the .38 kernel than the previous ones.) Anyways, it's a considerable amount of stuff to fiddle with and risk causing problems to get one game working... but you can always just revert it all... and frankly i'd try it for teh fun edit: I've used apt-get in my example for getting and building source packages because last I was doing this kind of thing on Debian it wasn't yet implemented in aptitude... but maybe it is now.

Wow, that sucks. So what did you end up doing (here: http://forums.debian.net/viewtopic.php?f=5&t=56429 ) to get to the stage you're at now? I see MESA 7.10 packages are in Sid (and some 7.10.1 packages in Experimental). Did you rebuild those packages against your Squeeze installation? (or just simply install the Sid binary packages?)

Obviously the starting price should be the the minimum the seller is willing to accept. Any seller who doesn't set their starting price as such is just being a nuisance.

I would think on a forum every thread in every section would be a platform for discussion, within a degree of topic bounds. @Nova best to not take Vanyel seriously, even when he's being serious.

Both are good.

Your point being? the point is AISLAR=BAD ! B& from mine bot

Priceless. I giggled reading it. indeed needs to go to qotw thread.

Go into your: My Documents\Eternal Lands\main\ folder and delete the file called el.cfg edit: Although, so long as just one pixel of the title bar of the options window is visible you should be able to drag the window back over. I've swapped from a larger to much smaller resolutions in the past and had the options window be way off to the side, but i've always managed to be able to drag it back over and not had to resort to deleting el.cfg

Your issue appears to be in London, with some Tata Communications routers.