Switching Target

[sMartins]

Pls, can someone tell me definitively how to switch enemy target on the default client? Thx

[leanne69]

Just attack the other target with the action "Attack" (touch t)

[loftar]

Ctrl+Tab is supposed to work, but I've heard it rumored that there's something making it not work on Windows.

[InvaderDoom]

not work on Windows.

You say this as if you're not on Windows loftar. Tell me you're not a Mac user, for the love of god!

[Astarisk]

not work on Windows.

You say this as if you're not on Windows loftar. Tell me you're not a Mac user, for the love of god!

You might want to take a small head start on running before loftar responds

[Adder1234]

not work on Windows.

You say this as if you're not on Windows loftar. Tell me you're not a Mac user, for the love of god!

maybe linux?

[Ozzy123]

not work on Windows.

You say this as if you're not on Windows loftar. Tell me you're not a Mac user, for the love of god!

hes probably on linux lol

[shubla]

He is in linux. Im pretty sure that last thing that would happen is that loftar would use osx.

[loftar]

He is in linux. Im pretty sure that last thing that would happen is that loftar would use osx.

I'd probably use OSX before going to Windows, though. Not that I've tried it for any longer period, but it is allegedly Unix-like so I figure I could just ignore the whole GUI if need be.

I've actually tried Windows on a spare laptop the last few days in order to debug the particular problem in this thread. I haven't done a test like this in like five years or so, so I figured I could try to approach it with as little prejudice as possible so as to see how it fares these days. Since I was doing that, I figured I should try Windows 10, but I've since had to give that up due to what appears to be a bug in Intel's video driver. I've heard that driver troubles are just a problem for Linux users and that Windows just werks with such stuff. (Coincidentally, Debian doesn't even need any externally installed drivers on this laptop.)
Some objective and impartial observations I've made thus far on Windows:

• I really haven't missed point-and-click window management. Long live StumpWM.
• I can't believe how slow Windows Update is. Just checking for updates takes minutes and significant amounts of system resources in terms of CPU time and RAM (you really need 2 GB RAM?), let alone installing them. I've often considered Debian's APT unnecessarily slow on various operations, but it smokes Windows Update by literally orders of magnitude. And really, I still have to reboot after every update, in the Year of our Lord 2016? And oh, how nice of the system to do that automatically for me in the middle of the night, destroying anything I had left open during that time.
• GUIs are kinda retarded. The SysInternals tools are pretty good programs by Windows standards, but their GUI form is really limiting them. While debugging the aforementioned OpenGL problem, I was using Process Explorer to check what DLLs and stuff the Java processes had loaded, and just browsing the list of several hundred entries was really difficult. Not being able to do such things as pipe it to grep or sort, view it with less, redirecting it to a file or save two snapshots at different points in time and compare them with diff is really quite, quite limiting. The data is effectively stuck at whatever the original program producing it can do with it. The funny thing is that even though Linux' pmap program is a much simpler tool, both functionality-wise and code-wise, its non-GUI form still makes it far more useful in the end.
• I actually got my hands on this laptop from an acquaintance who thought it was simply broken and asked me to just get his files off it. Turned out there was nothing wrong with the hardware, but just with the Windows installation on it (but he let me keep it nevertheless), and God help me if I had actually tried to repair it. The STOP screen is about as unhelpful as you could ask for, and documentation -- or even indirect information -- about the related file formats, disk setups and boot procedures appear to be so far out of the question that I'm wondering if they even have access to them at Microsoft Headquarters. The thing with Linux is, of course, not that things never go wrong, but I can't even think of a problem that I've encountered that I've been unable to solve.
• Of course, the OpenGL driver problem I had was very much related to the previous point. Sure, it seems to have been a bug in Intel's driver rather than in Windows itself, but the general complexity and, above all, opaqueness of the OpenGL ICD system made it very hard to figure out what was going on. I wouldn't be the least bit surprised if I had been able to fix a similar problem on Linux, even if it had been a problem with a proprietary, third-party driver, because the rest of the system doesn't actively try to hide from me what's going on.
• The general reliance on GUIs and the consequent lack fo practicality in the CLI that does exist seems to make using an IDE for development the only "natural" choice. I mean, I guess it's possible, strictly speaking, to set up paths and stuff to enable using the CLI-based tools, but it's quite obviously not the intended mode of operation, and even if you do, cmd.exe isn't exactly the nicest shell in the world. (Though I did notice they've added some very primitive form of tab-completion. That's a start, I guess.)
• It really is teh botnet, isn't it? Send every mouse-click to Microsoft and log in with your Microsoft Account unless you read the fine-print and "customize" these "options". (And it probably still phones home with stuff that it doesn't even ask about.)
• Worst of all though, really, is that Microsoft's style of development shapes the entire ecosystem. Every single program for Windows is similarly opaque, isolated and power-user-hostile. I loved particularly how Intel's driver installer program (because to begin with, of course, every little piece of software requires an executable installer; any form of standardized package management would have been too good) just failed with "An error occurred". How helpful. On the other hand, it had saved log files of the installation, which contained thousands of lines of completely internal debugging information, and not a single piece of useful information on what had gone wrong. It really is as if they're thinking that "if it doesn't work completely automatically, there's no need whatsoever to provide any information or alternatives, because noone outside Intel could fix it anyway". And needless to say, it is very much Microsoft who set the precedent for that way of thinking.

So yeah, I don't know how bad OSX is, but I figure there's not a whole lot of territory left for going for worse.

[MagicManICT]

This attitude at Microsoft has really only come up in the last 15-20 years. Of course, back then, it was all window dressing and everything was still CLI. Then again, even back then, DOS was a shadow of what could be done with *nix versions.

I think it's really more of attitude and culture. Linux has risen up out of open source culture and the GNU movement. Even the start of Unix itself is out of a lot of the same attitude being a collegiate and governmental experiments and work. If the same open source licensing existed in the 60s and 70s that started in the 80s, Unix would have been published under it, and 90% or more of operating systems today would be free. Well, 90% would probably be high as Novell is still a large company based on selling support services for a free OS, and making good money doing it. Companies and most individuals really do want things simplified and automated.

From what I've seen of Apple and OSX, the only thing different is that it is a *nix based OS (BSD if I recall right), but otherwise is much the same attitude.... and do note that it is a Unix based OS, not Unix.