You have now announced a new secondary profession Archaeology (Thank you! Thank you! Thank you! for making it a secondary profession. I enjoy cooking & fishing a lot), but what about raising the level cap on primary professions? The progression goes 20 - 35 - 50 - 65 and logically the next one comes at 80. You can certainly make every available recipe/design/pattern grey at whatever skill level corresponds to the new level 85 cap.
People are going to complain no matter what you do, but can you please consider a mechanism so that crafting doesn't become obsoleted after you reach level 80 even if we cannot max out the profession until the next ** 2 expansion and a level 90 cap?
Yes I know, when I played WoW (from Feb 2005 to Feb 2009) I always played on Ubuntu with OpenGL, but the windows version doesn't support the fancy shadows...that's why I've asked for this as well...
Now is really the time for you restart your account and log in. Blizzard is doing an online census.
The number of people they see logging in from Linux boxes is going to mean more than any questions we can ask in an interview (and we asked about Linux support the last time we had this opportunity).
I would have never come back if not for the changes they have made to leveling. Several of my friends would never have started playing. I am positive that the number of people who dislike the accelerated leveling are in the minority.
A very vocal minority, same as with all the current whining by the twinks who get to level x9 and stay there, spending most of their time ganking n00bs in battlegrounds who were just passing through.
TBC had flying around quests (bombing runs, exploratory),
Yeah. I revisited the bombing run in the hills near the Dark Portal many times before I got to level 70 and could fly on my own. Once I became friends with the Ogres in Ogri'La, I discovered my all-time favorite quest "Bomb Them Again!" http://thottbot.com/q11023
And honestly, that's sad. One of the things that Blizzard has always done well is tell a story. Even if some can claim that the stories are lifted from other sources, it's the quality of the story teller that matters just as much as the source of the tale.
There are plusses and minuses. I've heard of folks who have soloed Onyxia and Kara. I can't remember where I found it (maybe it was elitistjerks) but there's a forum somewhere devoted to the topic of undermanning raids. It seems to be full of people who missed the old content and wanted to see it.
The newest content has some great story lines. The quests for attunement to Sons of Hodir is epic. There's another quest line where you get enslaved and have to run errands for your "master". The starting zone for Death Knights has an interesting story, which includes one quest where you have to kill villagers who run away at the sight of you and bravely kill women and children who are cowering in terror.
I'm leveling a priest now and doing pretty much what you did - do every quest in a zone before moving on. There's a lot of stuff I've never done before.
I'll always remember WoW for those pre-expansion Worgen related quests (no clue if they've been added to in the expansions)
The latest rumor flying around (I guess we'll be finding out shortly how true it is) is that Worgen will be added as a playable Alliance race in the next expansion.
I don't play WOW, but is there an option for Death Knights to start at level 1?
No and there's no way to skip any of the starting area. By the time you're done you're at least level 58ish, have a decent set of blues and can go through the Dark Portal to start questing in Outlands. You know all of the flight points in the old world.
The real downside, as others have pointed out, is that your professions all start out at zero (except for first aid).
It's a pity that this got moderated down to -1. Start date had everything to do with it. The first Macintosh, bad as it was, failed mainly because by the time it got to market the IBM PC had gotten all the market and mind share.[1]
There were three O/S planned for the IBM PC, PC-DOS, UCSD P-System and CPM/86. PC-DOS was in the market first and the only thing available for the earliest IMB PCs and guess what won market and mind share?
[1] You can place the blame on that solely on the development manager who signed off on doing the system in assembly language.
Nothing is more exciting than leveling a character for dozens if not hundreds of hours and then being asked to sift through monster dung for Nagrand Cherries.
Most of the time, you can't even use a different compiler on the SAME platform.
Sigh. Children. About 90% of Linux compiled with the proprietary DEC/COMPAQ compiler when I was doing a Turbolinux port to Alpha ~2000.
My first introduction to GCC came when it was ported to the AT&T 3B1 aka Unix PC. C code could be compiled on both that and Steve Johnson's compiler. Interchangeable. Same as on Suns of that period.
I have had a tougher time doing portable Ada than I've ever had doing portable C.
Arbitrary programs if they were coded by people like you? No. Well written programs? Yes. I've had decades of experience dealing with that.
Most programs written in HLL's can't simply be recompiled either. What does this have to do with anything?
My usual response to a comment like this would be to ask to share whatever it is you're smoking brother/.er, in this case I'm not so sure I really want to.
I tried finding a book on assembly when I was around 14 because I really wanted to learn how to mod save game files and understand how things worked better after learning basic then turbo pascal 7 but I couldn't find one anywhere.
There were books by then... I learned 6502 assembly in high school from a data sheet xeroxed at the local computer store (and by asking questions to a friendly and most knowledgeable person there). By 1980 there was a book available on 6502 assembly, so I bought it. By 1992 there just wasn't much need for assembly language knowledge, so I guess I'm not surprised you could not find a trade book then.
It was also helpful reading the original Apple ][ red manual that contained annotated assembly listings of the ROM code. I was much less impressed by Applesoft BASIC[1] (which I made a disassembled listing of to study). Woz's Integer BASIC was tighter code and ran much faster.
Applesoft BASIC had code in it to prevent anyone from reading the source (an autoexecute bit that would prohibit a loaded BASIC from being read). It also had things like extensive use of the 6502 3 byte NOPS where the 2nd and 3rd bytes contained machine instructions and were jumped to in the middle to do slightly different things.
[1] For those who don't know history, that was Microsoft BASIC rebranded for Apple.
When I started out assembly programming the 6502 as a kid, I didn't have the cash for an assembler, so I coded with pencil and paper, hand assembled to machine code, and entered byte by byte.
You date yourself. The original Apple ][ had the mini assembler in ROM where you could at least type the assembler mnemonics in and have them machine translated to assembly code. That was removed in the Apple ][ plus:-(.
If abstractions make life complicated for the OS developer, but easier for the user, is it a win? It depends on whether the OS has more developers or users.
The whole point of an O/S is to provide some kind of abstraction to the hardware and divide resources efficiently between users/processes.
But, I also find it remarkable that people are still using CP/M disk drive letters when they were stupid idea 40 years ago.
The design goal has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs."
So long as you have a very limited target platform that's doable. The two most important layers are between user & system mode and IRQ processing. The former can be eliminated in "real time" versions in Linux[1], there's nothing you can do about the latter.
I applaud these guys for coming up with competition - Competition Is Good. I don't agree with their approach - Assembly Is An Inefficient Use Of Resources. Close sourcing their 64 bit kernel also seems sort of stupid especially with such a target niche audience and lessons learned in the last four decades.
[1] I can talk about Linux, I think I'm still under NDA regarding the System V/386 Unix kernel.
What was the most recent language that had provision for multiple entry points? PL/1?
The earliest standardized versions of "C". The entry keyword was removed after awhile. It had provisions, but was never implemented. I guess there just wasn't a real world need.
Maybe you just don't have the ability to detect your bias. As far as my assembler skill, I've been programming in x86 assembler since the 8086. I also use HLL's. I mix the two because I happen to choose the right tool for the job. I don't have this ignorant mindset that only one tool is great.
But what do you do if someone wants to run your code on an ARM or (gasp) an Alpha?
And even in the 70's, compilers were good enough that the Unix operating system could be written mostly in C, with a few thousands lines of assembler for optimization.
That was probably the most important decision that an O/S implementer has ever made. Do note though, that Dennis Ritchie's first compiler for a language invented for Ken Thompson to write the first Unix kernel in, more resembled "B", than modern day "C". It was also highly dependent on the PDP.
It wasn't until Steve Johnson wrote the "Portable" C compiler that C became a viable language.
s/15 - 20/50/
I suppose it is one of the great ironies of computer history that an operating system written for a hardware company (DEC) that never ended up adopting it (Unix), would later end up killing it (DEC). Tru64 was too little, too late. RIP Alpha.
That is using assembler for every single nut and bolt in an operating system is essentially the same as hand optimizing every piece of code. You can do it but your time is better spent elsewhere.
Amen.
The one thing compilers could be improved on is in knowing which parts of code need to be optimized for speed and which need to be optimized for space (not at all the same thing, though on some simpler cpus they're very similar). Some newer GCCs allow pragmas to change optimizer flags on the fly, which is a help but it's still cumbersome.
Linus sometimes has harsh words for the GCC guys, but they really have done an excellent job of improving the compiler over the years. It's little short of miraculous that they can support so many different language front ends and machine architecture backends and still produce great code most^H^H^H^Hnearly all of the time.
Carefully coded C (or some other high-level languages) can approach (though not meet) the performance of carefully coded assembler, and is much more portable and maintainable.
You "approach (though not meet)" the truth - carefully coded C will exceed the performance of 99.999% of the work of an assembly language coder.
That's not to say that a really great ASM programmer wouldn't do better than VCL, but he would have to work much much harder.
That question was settled half a century ago. Unless you're working with an underpowered CPU (like the early microprocessors 8080, 6502, etc.) or where you do not have a high level language to work with, programming in assembly for any important work is a FAIL.
When writing Assembly you have to take care of these side effects, which is usually done using push&pop.
Spoken like someone who has never written Assembly on a stackless machine. Stack-based architectures didn't win until the mid 1970s.
My O/S class project was doing a kernel on an HP 1000. 16 bit machine, no stack and "subroutine" calls wrote the return address into the word just above the code called.
Whoosh. The point of doing number crunching in FORTRAN is that FORTRAN does not reorder expressions. This is critical to maintain accuracy in certain computations.
Who cares how fast it is if you come up with the wrong answer?
You have now announced a new secondary profession Archaeology (Thank you! Thank you! Thank you! for making it a secondary profession. I enjoy cooking & fishing a lot), but what about raising the level cap on primary professions? The progression goes 20 - 35 - 50 - 65 and logically the next one comes at 80. You can certainly make every available recipe/design/pattern grey at whatever skill level corresponds to the new level 85 cap.
People are going to complain no matter what you do, but can you please consider a mechanism so that crafting doesn't become obsoleted after you reach level 80 even if we cannot max out the profession until the next ** 2 expansion and a level 90 cap?
Not any more! (Or at least when the next expansion hits).
Yes I know, when I played WoW (from Feb 2005 to Feb 2009) I always played on Ubuntu with OpenGL, but the windows version doesn't support the fancy shadows...that's why I've asked for this as well...
Now is really the time for you restart your account and log in. Blizzard is doing an online census.
The number of people they see logging in from Linux boxes is going to mean more than any questions we can ask in an interview (and we asked about Linux support the last time we had this opportunity).
My wife plays. There are a lot of (real) women players.
http://www.youtube.com/watch?v=urNyg1ftMIU&feature=channel_page
I would have never come back if not for the changes they have made to leveling. Several of my friends would never have started playing. I am positive that the number of people who dislike the accelerated leveling are in the minority.
A very vocal minority, same as with all the current whining by the twinks who get to level x9 and stay there, spending most of their time ganking n00bs in battlegrounds who were just passing through.
TBC had flying around quests (bombing runs, exploratory),
Yeah. I revisited the bombing run in the hills near the Dark Portal many times before I got to level 70 and could fly on my own. Once I became friends with the Ogres in Ogri'La, I discovered my all-time favorite quest "Bomb Them Again!" http://thottbot.com/q11023
And honestly, that's sad. One of the things that Blizzard has always done well is tell a story. Even if some can claim that the stories are lifted from other sources, it's the quality of the story teller that matters just as much as the source of the tale.
There are plusses and minuses. I've heard of folks who have soloed Onyxia and Kara. I can't remember where I found it (maybe it was elitistjerks) but there's a forum somewhere devoted to the topic of undermanning raids. It seems to be full of people who missed the old content and wanted to see it.
The newest content has some great story lines. The quests for attunement to Sons of Hodir is epic. There's another quest line where you get enslaved and have to run errands for your "master". The starting zone for Death Knights has an interesting story, which includes one quest where you have to kill villagers who run away at the sight of you and bravely kill women and children who are cowering in terror.
I'm leveling a priest now and doing pretty much what you did - do every quest in a zone before moving on. There's a lot of stuff I've never done before.
I'll always remember WoW for those pre-expansion Worgen related quests (no clue if they've been added to in the expansions)
The latest rumor flying around (I guess we'll be finding out shortly how true it is) is that Worgen will be added as a playable Alliance race in the next expansion.
I don't play WOW, but is there an option for Death Knights to start at level 1?
No and there's no way to skip any of the starting area. By the time you're done you're at least level 58ish, have a decent set of blues and can go through the Dark Portal to start questing in Outlands. You know all of the flight points in the old world.
The real downside, as others have pointed out, is that your professions all start out at zero (except for first aid).
Now put them back to their original dates.
It's a pity that this got moderated down to -1. Start date had everything to do with it. The first Macintosh, bad as it was, failed mainly because by the time it got to market the IBM PC had gotten all the market and mind share.[1]
There were three O/S planned for the IBM PC, PC-DOS, UCSD P-System and CPM/86. PC-DOS was in the market first and the only thing available for the earliest IMB PCs and guess what won market and mind share?
[1] You can place the blame on that solely on the development manager who signed off on doing the system in assembly language.
Nothing is more exciting than leveling a character for dozens if not hundreds of hours and then being asked to sift through monster dung for Nagrand Cherries.
Most of the time, you can't even use a different compiler on the SAME platform.
Sigh. Children. About 90% of Linux compiled with the proprietary DEC/COMPAQ compiler when I was doing a Turbolinux port to Alpha ~2000.
My first introduction to GCC came when it was ported to the AT&T 3B1 aka Unix PC. C code could be compiled on both that and Steve Johnson's compiler. Interchangeable. Same as on Suns of that period.
I have had a tougher time doing portable Ada than I've ever had doing portable C.
Arbitrary programs if they were coded by people like you? No. Well written programs? Yes. I've had decades of experience dealing with that.
Now, get off my lawn!
Most programs written in HLL's can't simply be recompiled either. What does this have to do with anything?
My usual response to a comment like this would be to ask to share whatever it is you're smoking brother /.er, in this case I'm not so sure I really want to.
I tried finding a book on assembly when I was around 14 because I really wanted to learn how to mod save game files and understand how things worked better after learning basic then turbo pascal 7 but I couldn't find one anywhere.
There were books by then ... I learned 6502 assembly in high school from a data sheet xeroxed at the local computer store (and by asking questions to a friendly and most knowledgeable person there). By 1980 there was a book available on 6502 assembly, so I bought it. By 1992 there just wasn't much need for assembly language knowledge, so I guess I'm not surprised you could not find a trade book then.
It was also helpful reading the original Apple ][ red manual that contained annotated assembly listings of the ROM code. I was much less impressed by Applesoft BASIC[1] (which I made a disassembled listing of to study). Woz's Integer BASIC was tighter code and ran much faster.
Applesoft BASIC had code in it to prevent anyone from reading the source (an autoexecute bit that would prohibit a loaded BASIC from being read). It also had things like extensive use of the 6502 3 byte NOPS where the 2nd and 3rd bytes contained machine instructions and were jumped to in the middle to do slightly different things.
[1] For those who don't know history, that was Microsoft BASIC rebranded for Apple.
When I started out assembly programming the 6502 as a kid, I didn't have the cash for an assembler, so I coded with pencil and paper, hand assembled to machine code, and entered byte by byte.
You date yourself. The original Apple ][ had the mini assembler in ROM where you could at least type the assembler mnemonics in and have them machine translated to assembly code. That was removed in the Apple ][ plus :-(.
If abstractions make life complicated for the OS developer, but easier for the user, is it a win? It depends on whether the OS has more developers or users.
The whole point of an O/S is to provide some kind of abstraction to the hardware and divide resources efficiently between users/processes.
But, I also find it remarkable that people are still using CP/M disk drive letters when they were stupid idea 40 years ago.
The design goal has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs."
So long as you have a very limited target platform that's doable. The two most important layers are between user & system mode and IRQ processing. The former can be eliminated in "real time" versions in Linux[1], there's nothing you can do about the latter.
I applaud these guys for coming up with competition - Competition Is Good. I don't agree with their approach - Assembly Is An Inefficient Use Of Resources. Close sourcing their 64 bit kernel also seems sort of stupid especially with such a target niche audience and lessons learned in the last four decades.
[1] I can talk about Linux, I think I'm still under NDA regarding the System V/386 Unix kernel.
What was the most recent language that had provision for multiple entry points? PL/1?
The earliest standardized versions of "C". The entry keyword was removed after awhile. It had provisions, but was never implemented. I guess there just wasn't a real world need.
Maybe you just don't have the ability to detect your bias. As far as my assembler skill, I've been programming in x86 assembler since the 8086. I also use HLL's. I mix the two because I happen to choose the right tool for the job. I don't have this ignorant mindset that only one tool is great.
But what do you do if someone wants to run your code on an ARM or (gasp) an Alpha?
And even in the 70's, compilers were good enough that the Unix operating system could be written mostly in C, with a few thousands lines of assembler for optimization.
That was probably the most important decision that an O/S implementer has ever made. Do note though, that Dennis Ritchie's first compiler for a language invented for Ken Thompson to write the first Unix kernel in, more resembled "B", than modern day "C". It was also highly dependent on the PDP.
It wasn't until Steve Johnson wrote the "Portable" C compiler that C became a viable language.
s/15 - 20/50/
I suppose it is one of the great ironies of computer history that an operating system written for a hardware company (DEC) that never ended up adopting it (Unix), would later end up killing it (DEC). Tru64 was too little, too late. RIP Alpha.
That is using assembler for every single nut and bolt in an operating system is essentially the same as hand optimizing every piece of code. You can do it but your time is better spent elsewhere.
Amen.
The one thing compilers could be improved on is in knowing which parts of code need to be optimized for speed and which need to be optimized for space (not at all the same thing, though on some simpler cpus they're very similar). Some newer GCCs allow pragmas to change optimizer flags on the fly, which is a help but it's still cumbersome.
Linus sometimes has harsh words for the GCC guys, but they really have done an excellent job of improving the compiler over the years. It's little short of miraculous that they can support so many different language front ends and machine architecture backends and still produce great code most^H^H^H^Hnearly all of the time.
Carefully coded C (or some other high-level languages) can approach (though not meet) the performance of carefully coded assembler, and is much more portable and maintainable.
You "approach (though not meet)" the truth - carefully coded C will exceed the performance of 99.999% of the work of an assembly language coder.
Please read up on the history of the most important compiler of all time - the first FORTRAN compiler. Start here - http://www.ibiblio.org/pub/languages/fortran/ch1-1.html
Now, get off my lawn!
That's not to say that a really great ASM programmer wouldn't do better than VCL, but he would have to work much much harder.
That question was settled half a century ago. Unless you're working with an underpowered CPU (like the early microprocessors 8080, 6502, etc.) or where you do not have a high level language to work with, programming in assembly for any important work is a FAIL.
Optimal is for the function to push registers that it is going to use and pop them when done
You're as ignorant of the past as the poster you're responding to. What are these push and pop instructions on a CPU without a machine stack?
You too, get off my lawn!
When writing Assembly you have to take care of these side effects, which is usually done using push&pop.
Spoken like someone who has never written Assembly on a stackless machine. Stack-based architectures didn't win until the mid 1970s.
My O/S class project was doing a kernel on an HP 1000. 16 bit machine, no stack and "subroutine" calls wrote the return address into the word just above the code called.
Now, get off my lawn!
Whoosh. The point of doing number crunching in FORTRAN is that FORTRAN does not reorder expressions. This is critical to maintain accuracy in certain computations.
Who cares how fast it is if you come up with the wrong answer?