Meticulously sticking to details on the lighting of the carpet, but the uniforms need to be redesigned, yeah. The ones in their gallery just look wrong (example http://startrek.perpetual.com/images/gallery/conce pts/large/1.gif), like they have hard plastic pieces attached on shoulders and chest and added some giant boots. Looks stupid and certainly not different enough from a distance to justify it, sorry, they fail.
Re:"but no one can get online to play it"
on
World of Queuecraft
·
· Score: 1
I could say the same about you, but that would lead to flaming. I admit I was wrong to change the subject (I did so, because I felt nothing could be said about the topic anymore). I still think the article is about WoW problems ins general and queues in particular with server crashes mentioned in a byline. Given this, the statement from the blurp IS inaccurate. Maybe you see crashes as the main topic of the article and wonder what the heading has then to do with it. Maybe we both see only what we want to see. Whatever the truth (There's mine, yours, the author's, the "objective" and the real truth) I don't think it's worth another post, especially not if one of us is going for the ad hominem road. That is just as wrong as changing the subject, which I did. I'm sorry.
Re:"but no one can get online to play it"
on
World of Queuecraft
·
· Score: 1
And I still say that I don't see that. The author points out server crashes in a sentence but not as the main issue of the whole article, which is queues. And I pointed out that a queue suggests someone IS playing while the quotation states "noone" is. Is this seriously worth arguing any more? We agree Blizzard should set more servers up and the author is complaining about not getting what she feels she's entitled to (Hint: I bet according to the EULA, which thankfully isn't binding here in Germany, she isn't). I found the blurp hyped and the article to be no less so and complained about a specific sentence that is completely illogical given the damn title of the article (which is consistent with most of the article itself).
Re:"but no one can get online to play it"
on
World of Queuecraft
·
· Score: 1
Not enough to warrant "World of Queuecraft" in my eyes, really. The original article is whining about not being able to play as much as the author likes and the Queueing system is just the scape goat, even though it is better than not managing anything or simply closing logins. The real problem is Blizzard not setting up more servers.
I simply don't see how each opening process can use a new knocking sequence while allowing more than one key units without storing those transactions. Either the locks or the keys have to save them and that part is the only one able to work with multiple of the other (of course, both may implement this). Security-wise this whole thing sounds mighty stupid. Unless asymetric signature ID is employed and the lock (which needs a lot of tech) is guaranteed to work under all conditions a mechanical lock would, I prefer the latter. They're simple, robust and, if you choose your model cautiously, pretty secure unless someone used brute force.
I'm really not sure it's that bad (already?), I think TV still has a lot more influence in News than Search engines have, but competition is not necessarily good when truth is concerned, I agree.
Hm, I don't usually search for news, and, frankly, I don't know anyone who does. What I search for is usually way more static and I don't care whether it is three years old, if it's the best hit to my search terms. My news are gathered from state television (in germany they go to great lengths to ensure being independent of the government, works surprisingly well), reuters.com, the cnn breaking-news feed (usually just good for a laugh) and a few other sources, depending on the topic I'm interested in (BBC, Al-Jazeera, etc.), all mixed with firm assumption that they all paint the picture of the event in the best light of their interests.
Re:"but no one can get online to play it"
on
World of Queuecraft
·
· Score: 1
I prefer accurate to reasonable (A lot of bad things get done because they're called reasonable and noone bothers checking facts these days), but I can accept that explanantion (And I certainly didn't say it would help, Blizzard are cheap bastards after all). Please excuse if I sounded a little hostile, btw, I'm in a particularly foul mood today... gotta go catch some sleep.
Re:"but no one can get online to play it"
on
World of Queuecraft
·
· Score: 1
Yes, but that has nothing to do with logging in, has it?
Re:"but no one can get online to play it"
on
World of Queuecraft
·
· Score: 1
I stopped going there months ago, it's just too boring for something claiming to be an RPG (I would go so far as to argue WoW is inspired by RPGs as much as "I, Robot" is inspired by the original Asimov). Just as with Diablo 2, I just bought it because pretty much all of my friends said it was great. *sigh* I should learn that Blizzard just doesn't produce stuff I'm remotely interested in...
Re:"but no one can get online to play it"
on
World of Queuecraft
·
· Score: 1
Care to offer a quote? I can't find that in the article...
Re:"but no one can get online to play it"
on
World of Queuecraft
·
· Score: 1
As soon as someone of those already online quits another person can "get". How precise do you want to define the present? I'm all open for whiney word wrangling today! Seriously, to say noone can "get" online, because someone already "got" is like saying you can't "get" because some has been able to "get" before you. Catch my drift?
If you cannot get online because the server is full and puts you in the queue, then, apparently, there are people online, a whole lot, obviously. That doesn't relieve Blizzard from being cheap bastards that don't provide enough servers, but, as long as you don't want to infer lying, someone seems to be online, it just doesn't happen to be you.
it's impossible to have a second key then without adding a full second set of locking memory to the lock itself. A lock that has to know how many keys to it exist. rich.
That's an issue for the VM implementation, not for Java itself, I think. BTW that is exactly the way things are supposed to be handled by the VM, except that you have to block the main thread manually via join() to all threads started. When (and where!) a thread is actually executed is the job of the VM... I haven't done enough with threads to ever have encountered a problem with thread scheduling, especially not on multi-core machines, so it may be that VM don't follow expectation here in practice...
Well, the other option would have to explicitly unblock. I think that'd be more confusing and in case of the foreach should block the main thread after the first thread is started, killing all your speed improvement, because all threads can then only be processed sequentially (Since it cannot be known how many physical processors there are beforehand, you couldn't predict the code at all if you were to have the VM decide such issues based on available ressources, especially if you'd want every thread started and completed before the next). Threads are a little confusing the way they are (Though in my university their problems (deadlock, race conditions, etc.) are handled during "Operating Systems", so anyone with formal CS education should understand threads easily by inference), but I see no way of making them easier than Java already does (Well, maybe "implements Runnable" could be enough (Just like "implements Serialzable"), so run() isn't needed as a thread-main(), it should be possible to start any method. But then that would not allow you to call a method without starting a new thread, that has a little overhead, of course. *sigh* Point is: The way it is seems like a good solution for giving the programmer maximum flexibility while keeping stuff simple enough in most cases to be rather trivial)
If your "element" "implements Runnable", then "element.run()" in the foreach (Since Java 1.5 this is finally available) should work just as expected, but be careful, you can't be sure when those threads finish, unless you put the main thread on hold until they are. Should still speed your code up nicely, provided the VM used supports multiple processor cores (And this is the crux, but noone is keeping anyone from building one for Cell:-)
I didn't RTFA, but: Just translate every "src",etc. attributes http:, https: ftp:, etc. into int's corresponding data: URI? It's not exactly hard, try it yourself at http://software.hixie.ch/utilities/cgi/data/data.
The result is not/. comment compatible, but quite usable in html per se. Scripts and CSS can be embedded even easier.
> Funny, I have being collecting some "interface measurement dimensions" for a time. Let's see what it does...
You have...
> Concision: Multi window reduce that on GIMP tools, when compared with Photoshop. GIMP menus are also many times several steps bigger, but Photoshop have some other complications, so I think they match on menus.
I consider PS crammed, but suit yourself.
> Expressiveness: Both do nearly the same.
Whatever you mean by that.
> Ease (mnemonic load): Remembering what window you are working (and what is under it) increases mnemonic load. GIMP loses.
Windows, Tabs, doesn't change a thing, sorry.
> Transparency: If I remember it well, Photoshop transformations have preview. If so, they match.
Gimp has previews for most effects and yes, they match, too. Your point?
> Discoverability: Photoshop's single window is normal. GIMP's multiple windows are new. Photoshop wins that. Also, Photoshop's menus are better organized.
New to the Windows user maybe, but hardly in general.
> Scriptability: Both are very bad on that.
I don't know about PS, but the Gimp is pretty easy to script, although I would prefer something imperative over the functional style.
> Memorability (if users forget it when don't use): The only thing to forget is the menus order. GIMP loses on that.
Hm, got a memory problem? I don't tend to forget such things, but then, maybe, as a coder I'm more susceptible to underlying structures than most people?
> Errors: If I remember Photoshop well, GIMP wins by far on error messaging and recovering. The undo window is excelent.
Can't compare PS, but Gimps error messages are just as hard or easy to read as any other coder-type apps... Which mean I constantly hear people complaining.
> Satisfaction: Very subjective. I prefer not to opine.
That is exactly the point I was trying to make, wasn't I?
> You know? There is a reason that all those programs are using tabbed interfaces...
That is not necessarily because "it's better", it could as well be because "everyone uses them". Be carefull here. Tabs are good for relatively static things, like text windows, but I strongly prefer to place different images next to each other when editing, since they're usually related some way.
> It is an image manipulatin program. Why do you think that using the keyboard is reasonable?
It's a computer programm. Why do you think something reminiscent of a piece of soap is better suited to images?
> Because if there's one thing OSS does well, it's providing lots of options for the user
Bzzzt, wrong. The Option is to a) use a fork/plugin/etc, (I don't know whether Gimpshop does this), b) develop such a thing, c) use a different app or d) code optional support into Gimp (though this'll make it bloated). Notice how "swap the UI to a tabbed one" is not one of the options? You CAN have the option, but I asked why one would NEED to have this specific one.
> Yeah the interface sucks I doesn't suck more than the Adobe interface. The definition of "suckiness" always seems biased away from the UI you're used to. I learned GIMP first and didn't have much trouble, but now I can't stand the crammed look of Adobe Apps, other people have it the other way round, and, fankly, I'm tired of people including "Yeah the interface sucks" just because.
> I have to have an entire virtual desktop reserved for it alone I have always considered that to be the point of virtual desktops...
> there are dialogs that pop up behind the window file or vote for a bug report if you consider this disturbing.
> I have to spend more time resizing windows than actually working Use keyboard shortcuts instead of the mouse.
> if you have a lot of images open the taskbar groups them so that it takes two clicks to get to anything if you have too many tabs open they're scrolled (I bet they are, but I don't have Adobe to check). Point is: use keyboard shortcuts instead of the mouse...
> Why not have a nice tabbed interface? Why have one? Just to look'n'feel like Adobe? I am not interested in that (and I'm not interested in bringing the Adobe crowd "over" as well, why would I?)
> Also the name sucks. At best its confusing, at worst its offensive. "GNU Image Manipulation Program" isn't more confusing than something reminiscent of a camera repair shop, just another case of biased perspective. And, as a BDSM person, I get a chuckle out of the abbreviation, too:-)
> Its pretty sad when its obvious to everyone what the problem is, yet its still the same thing after what, six years? Maybe, after six years, you could accept that, apparently, it is NOT an obvious problem to a majority of people spending time on improving GIMP? It was never a problem for me, certainly, and I usually fail to see how it can even be one (I've also never accepted "People can't use OOo, because it's different from Word", every new version of Word shows this is a bullshit argument).
What I can accept as a problem is lacking 16-bit and CMYK support, but only because I don't know enough about professional photo editing to know whether this has any merit. But then, how many people using PS are actually professionals? All my needs, from webdesign, over improving holidays snapshots and making skins for shooters, to preparing imagery for publications, have always been more than fulfilled by the GIMP and then some.
'The release date of this game is "When it's done". Anything else, and we mean anything else is someone's speculation. There is no date. We don't know any date. If you have a friend who claims they have "inside info", or there's some game news site, or some computer store at the mall who claims they know - they do not. They are making it up. There is no date. Period.'
Slashdot Mirror
Meticulously sticking to details on the lighting of the carpet, but the uniforms need to be redesigned, yeah. The ones in their gallery just look wrong (example http://startrek.perpetual.com/images/gallery/conce pts/large/1.gif), like they have hard plastic pieces attached on shoulders and chest and added some giant boots. Looks stupid and certainly not different enough from a distance to justify it, sorry, they fail.
I could say the same about you, but that would lead to flaming. I admit I was wrong to change the subject (I did so, because I felt nothing could be said about the topic anymore). I still think the article is about WoW problems ins general and queues in particular with server crashes mentioned in a byline. Given this, the statement from the blurp IS inaccurate. Maybe you see crashes as the main topic of the article and wonder what the heading has then to do with it. Maybe we both see only what we want to see. Whatever the truth (There's mine, yours, the author's, the "objective" and the real truth) I don't think it's worth another post, especially not if one of us is going for the ad hominem road. That is just as wrong as changing the subject, which I did. I'm sorry.
And I still say that I don't see that. The author points out server crashes in a sentence but not as the main issue of the whole article, which is queues. And I pointed out that a queue suggests someone IS playing while the quotation states "noone" is. Is this seriously worth arguing any more? We agree Blizzard should set more servers up and the author is complaining about not getting what she feels she's entitled to (Hint: I bet according to the EULA, which thankfully isn't binding here in Germany, she isn't). I found the blurp hyped and the article to be no less so and complained about a specific sentence that is completely illogical given the damn title of the article (which is consistent with most of the article itself).
Not enough to warrant "World of Queuecraft" in my eyes, really. The original article is whining about not being able to play as much as the author likes and the Queueing system is just the scape goat, even though it is better than not managing anything or simply closing logins. The real problem is Blizzard not setting up more servers.
I simply don't see how each opening process can use a new knocking sequence while allowing more than one key units without storing those transactions. Either the locks or the keys have to save them and that part is the only one able to work with multiple of the other (of course, both may implement this). Security-wise this whole thing sounds mighty stupid. Unless asymetric signature ID is employed and the lock (which needs a lot of tech) is guaranteed to work under all conditions a mechanical lock would, I prefer the latter. They're simple, robust and, if you choose your model cautiously, pretty secure unless someone used brute force.
I'm really not sure it's that bad (already?), I think TV still has a lot more influence in News than Search engines have, but competition is not necessarily good when truth is concerned, I agree.
Hm, I don't usually search for news, and, frankly, I don't know anyone who does. What I search for is usually way more static and I don't care whether it is three years old, if it's the best hit to my search terms. My news are gathered from state television (in germany they go to great lengths to ensure being independent of the government, works surprisingly well), reuters.com, the cnn breaking-news feed (usually just good for a laugh) and a few other sources, depending on the topic I'm interested in (BBC, Al-Jazeera, etc.), all mixed with firm assumption that they all paint the picture of the event in the best light of their interests.
I prefer accurate to reasonable (A lot of bad things get done because they're called reasonable and noone bothers checking facts these days), but I can accept that explanantion (And I certainly didn't say it would help, Blizzard are cheap bastards after all). Please excuse if I sounded a little hostile, btw, I'm in a particularly foul mood today... gotta go catch some sleep.
Yes, but that has nothing to do with logging in, has it?
I stopped going there months ago, it's just too boring for something claiming to be an RPG (I would go so far as to argue WoW is inspired by RPGs as much as "I, Robot" is inspired by the original Asimov). Just as with Diablo 2, I just bought it because pretty much all of my friends said it was great. *sigh* I should learn that Blizzard just doesn't produce stuff I'm remotely interested in...
Care to offer a quote? I can't find that in the article...
As soon as someone of those already online quits another person can "get". How precise do you want to define the present? I'm all open for whiney word wrangling today! Seriously, to say noone can "get" online, because someone already "got" is like saying you can't "get" because some has been able to "get" before you. Catch my drift?
If you cannot get online because the server is full and puts you in the queue, then, apparently, there are people online, a whole lot, obviously. That doesn't relieve Blizzard from being cheap bastards that don't provide enough servers, but, as long as you don't want to infer lying, someone seems to be online, it just doesn't happen to be you.
it's impossible to have a second key then without adding a full second set of locking memory to the lock itself. A lock that has to know how many keys to it exist. rich.
That's an issue for the VM implementation, not for Java itself, I think. BTW that is exactly the way things are supposed to be handled by the VM, except that you have to block the main thread manually via join() to all threads started. When (and where!) a thread is actually executed is the job of the VM... I haven't done enough with threads to ever have encountered a problem with thread scheduling, especially not on multi-core machines, so it may be that VM don't follow expectation here in practice...
Well, the other option would have to explicitly unblock. I think that'd be more confusing and in case of the foreach should block the main thread after the first thread is started, killing all your speed improvement, because all threads can then only be processed sequentially (Since it cannot be known how many physical processors there are beforehand, you couldn't predict the code at all if you were to have the VM decide such issues based on available ressources, especially if you'd want every thread started and completed before the next). Threads are a little confusing the way they are (Though in my university their problems (deadlock, race conditions, etc.) are handled during "Operating Systems", so anyone with formal CS education should understand threads easily by inference), but I see no way of making them easier than Java already does (Well, maybe "implements Runnable" could be enough (Just like "implements Serialzable"), so run() isn't needed as a thread-main(), it should be possible to start any method. But then that would not allow you to call a method without starting a new thread, that has a little overhead, of course. *sigh* Point is: The way it is seems like a good solution for giving the programmer maximum flexibility while keeping stuff simple enough in most cases to be rather trivial)
If your "element" "implements Runnable", then "element.run()" in the foreach (Since Java 1.5 this is finally available) should work just as expected, but be careful, you can't be sure when those threads finish, unless you put the main thread on hold until they are. Should still speed your code up nicely, provided the VM used supports multiple processor cores (And this is the crux, but noone is keeping anyone from building one for Cell :-)
I didn't RTFA, but: Just translate every "src",etc. attributes http:, https: ftp:, etc. into int's corresponding data: URI? It's not exactly hard, try it yourself at http://software.hixie.ch/utilities/cgi/data/data. The result is not /. comment compatible, but quite usable in html per se. Scripts and CSS can be embedded even easier.
Man, that was the first and only game to ever actually leave an afterimage burned into my screen (fancy amber one, too). *Sigh*
> Funny, I have being collecting some "interface measurement dimensions" for a time. Let's see what it does... You have... > Concision: Multi window reduce that on GIMP tools, when compared with Photoshop. GIMP menus are also many times several steps bigger, but Photoshop have some other complications, so I think they match on menus. I consider PS crammed, but suit yourself. > Expressiveness: Both do nearly the same. Whatever you mean by that. > Ease (mnemonic load): Remembering what window you are working (and what is under it) increases mnemonic load. GIMP loses. Windows, Tabs, doesn't change a thing, sorry. > Transparency: If I remember it well, Photoshop transformations have preview. If so, they match. Gimp has previews for most effects and yes, they match, too. Your point? > Discoverability: Photoshop's single window is normal. GIMP's multiple windows are new. Photoshop wins that. Also, Photoshop's menus are better organized. New to the Windows user maybe, but hardly in general. > Scriptability: Both are very bad on that. I don't know about PS, but the Gimp is pretty easy to script, although I would prefer something imperative over the functional style. > Memorability (if users forget it when don't use): The only thing to forget is the menus order. GIMP loses on that. Hm, got a memory problem? I don't tend to forget such things, but then, maybe, as a coder I'm more susceptible to underlying structures than most people? > Errors: If I remember Photoshop well, GIMP wins by far on error messaging and recovering. The undo window is excelent. Can't compare PS, but Gimps error messages are just as hard or easy to read as any other coder-type apps... Which mean I constantly hear people complaining. > Satisfaction: Very subjective. I prefer not to opine. That is exactly the point I was trying to make, wasn't I? > You know? There is a reason that all those programs are using tabbed interfaces... That is not necessarily because "it's better", it could as well be because "everyone uses them". Be carefull here. Tabs are good for relatively static things, like text windows, but I strongly prefer to place different images next to each other when editing, since they're usually related some way. > It is an image manipulatin program. Why do you think that using the keyboard is reasonable? It's a computer programm. Why do you think something reminiscent of a piece of soap is better suited to images?
> Because if there's one thing OSS does well, it's providing lots of options for the user Bzzzt, wrong. The Option is to a) use a fork/plugin/etc, (I don't know whether Gimpshop does this), b) develop such a thing, c) use a different app or d) code optional support into Gimp (though this'll make it bloated). Notice how "swap the UI to a tabbed one" is not one of the options? You CAN have the option, but I asked why one would NEED to have this specific one.
> Yeah the interface sucks
:-)
I doesn't suck more than the Adobe interface. The definition of "suckiness" always seems biased away from the UI you're used to. I learned GIMP first and didn't have much trouble, but now I can't stand the crammed look of Adobe Apps, other people have it the other way round, and, fankly, I'm tired of people including "Yeah the interface sucks" just because.
> I have to have an entire virtual desktop reserved for it alone
I have always considered that to be the point of virtual desktops...
> there are dialogs that pop up behind the window
file or vote for a bug report if you consider this disturbing.
> I have to spend more time resizing windows than actually working
Use keyboard shortcuts instead of the mouse.
> if you have a lot of images open the taskbar groups them so that it takes two clicks to get to anything
if you have too many tabs open they're scrolled (I bet they are, but I don't have Adobe to check). Point is: use keyboard shortcuts instead of the mouse...
> Why not have a nice tabbed interface?
Why have one? Just to look'n'feel like Adobe? I am not interested in that (and I'm not interested in bringing the Adobe crowd "over" as well, why would I?)
> Also the name sucks. At best its confusing, at worst its offensive.
"GNU Image Manipulation Program" isn't more confusing than something reminiscent of a camera repair shop, just another case of biased perspective. And, as a BDSM person, I get a chuckle out of the abbreviation, too
> Its pretty sad when its obvious to everyone what the problem is, yet its still the same thing after what, six years?
Maybe, after six years, you could accept that, apparently, it is NOT an obvious problem to a majority of people spending time on improving GIMP? It was never a problem for me, certainly, and I usually fail to see how it can even be one (I've also never accepted "People can't use OOo, because it's different from Word", every new version of Word shows this is a bullshit argument).
What I can accept as a problem is lacking 16-bit and CMYK support, but only because I don't know enough about professional photo editing to know whether this has any merit. But then, how many people using PS are actually professionals? All my needs, from webdesign, over improving holidays snapshots and making skins for shooters, to preparing imagery for publications, have always been more than fulfilled by the GIMP and then some.
'The release date of this game is "When it's done". Anything else, and we mean anything else is someone's speculation. There is no date. We don't know any date. If you have a friend who claims they have "inside info", or there's some game news site, or some computer store at the mall who claims they know - they do not. They are making it up. There is no date. Period.'
Why, oh, why is a sucker born every minute?
Maybe some kind of load-balancing done by CC then? Could be they're serving a cache taken from different locales sometimes (weird, but possible)
I don't know what happend, but the CC now reports the same error, probably Goggle poisoned it somehow. You're not missing much though...