alanschu

Too bad we don't know what the stabbing was related to.

http://www.ageia.com/physx/titles.html

I shall investigate!

I went for broke, given that I'm stupid/rich.

I'm pretty sure CoD standard doesn't have StarForce, but that doesn't necessarily mean anything I guess. In any case, I must say that jags is kind with his words :">

I think support is still kind of limited. Do they not mention which games have support on their website?

Haha, excellent point.

I did get the European version. The scene that was cut ultimately didn't add much to the game. I was hoping for more substance.

Based on what exactly?

It also says Freedom is Slavery and War is Peace.

Heh, isn't E3 itself "closed to the public?"

I killed Razor. Then I started lagging or somethinb, because my shields were taking damage even though I never got hit

That doesn't necessarily mean anything. It's possible to make a level with the original Quake engine that can make current computers crawl. Just give it ridiculously stupid, unnecessarily high polygon counts. I can run Half-Life 2 fine on my rig. But my computer does struggle with the HDR update that they released. Mostly because I'm pretty sure my card doesn't support it in hardware (Radeon 9800 Pro). In any case, my comment was more due to the fact that I'm not buying any new games until my new computer comes in.

I suspect it's a bit of an issue with the prevalency of games getting patched (for all we know, it's still a small subset of total customers that buy a game).

Because the impression that I was getting from you in the How Short is Too Short discussion wasn't about going back and fixing the tools when an error happened and starting from the old build, but that designers could bounce back and forth between different versions of the toolsets. In any case, the point I was making in the How Short is Too Short discussion with respect to evolving Toolsets, is that sometimes the Toolset evolves in such a way that stuff designed previously doesn't work (I think we can agree that this doesn't happen). I assumed here you were talking about using a Toolset Editor, and not "editing the toolset" (i.e. tweaking the toolset). Even then, a problem with working with an evolving Toolset is that sometimes as the toolset evolves, it is unable to continue working with existing stuff. Content created with a toolset later found to contain bugs can easily compromise the integrity of all that content created. If you're lucky, it's not a big deal. If you're unlucky, you're redoing that content. And it's not just as simple as keeping the original idea and adding in the new idea. This may result in the error proliferating, as well as increases code bloat. This also becomes a problem if the designer ends up mistaking an error in the Toolset for just how it works. For instance, a hypothetical example could involve the Script Compiler. If the parser for the compiler has a subtle error in it, scripts could be written that successfully compile and run appropriately. However, when that error is found in the Parser and fixed because of a certain situation where a script wouldn't successfully compile, the parser will have to be changed. But it cannot necessarily accept the previous implementation because there may be logical inconsistencies with how it is presented. So you'll need to change every script that has this error. Though as an aside, this example is relatively minor and can be easily fixed with minimal effort. I just thought of it because of an experience I had while programming an assignment where it turns out the compiler I was using had a bug in it, and to get my code working I ended up working around it (I didn't realize it was a bug in the compiler, since I'm no expert on compilers, and assumed the error was in my code). When the new compiler came out, this bug was fixed. In the end it ended up making more sense, but I had to go back and fix all places where it was an issue. There's other, much more severe details than can become an issue. It could turn out the a particular event handler is hideously slow. The Tools team could recognize this later when they start running into issues with it that weren't initially noticed. When the implementation is changed, parts of the code that used the original now break, and it needs to be updated with the optimized code. The team could decide to keep legacy support, but if they figure it's too computationally expensive, it may be in the best interests of the final product to axe the original implementation of that handler altogether, as it could help prevent issues down the road. And since I obviously wasn't very clear, content creation does not need a 100% perfect and working toolset. But in my experience it does need to have a relatively finalized toolset, particularly with respect to various aspects. Placing abstract or conceptual designs can be possible. But when, in the middle of the project, the programming team decides it's necessary to rewrite parts of the core engine (including the entire graphics engine), suddenly there's no guarantee if the existing decisions on the toolset and how it implements things are going to continue to be useful. They could design the new parts of the engine around the existing tools and whatnot, but this creates code bloat and can affect performance. Especially when it's something that wants to be as optimized as possible such as a graphics engine.

And you're still not making any sense. What are you saying? What are you talking about with respect to going backwards and reverting? Because it's quite obvious that they did not do that with respect to the DM Client, because the DM Client doesn't work any more. Furthermore, I'm usually pretty careful about using absolute words like "impossible" or "HAD" when discussing things, particularly in computer programming. Here's a hint: I knew you were trying to take a jab at my previous points. But you did it in such a way, that I seriously cannot make sense of your post. Which is why I stated "This post doesn't even make any sense."

This post doesn't even make any sense.

All right, change the interpretation of my post to be "We are now at a state in development that we are no longer certain of whether or not the DM Client will be in." I wouldn't be surprised. It's not as uncommon as you think.

I think their initial plan was to not require changes to the DM Client. But trying to modify code in new ways, while supporting legacy (in this case the DM Client) can be a hassle. It's possible that something got changed that made it impossible. I suspect they just announced it now, because given the way things currently are, they are now convinced that the likelihood of it not making release is much more certain. They probably didn't want to announce its removal until they were certain it wouldn't be possible to get it in a state that they were comfortable with releasing it with.

RE: Lockpicking in Oblivion Move the pick to the tumbler, and push up. I think the goal is to click right when it is about to hit the top. In any case, if I wait for the slowest one, I pretty much never miss. I would conservatively say that I probably picked hit about 100 tumblers in a row at one point.

That's just it? Does it really? Or is it just something that you would like it to be? I have played lots of SP and MP in NWN, but I've never used the DM client, nor have I played a game with a separate DM. This is just my experience, but I haven't seen anything that indicates the DM was a large selling point. I think the fact that Vampire: Redemption had it and didn't go anywhere (as you said) serves as an indicator that a DM Client doesn't rate that high up in the eyes of many (most?) gamers? Redemption was a poor game though, whereas NWN wasn't (while I have my reservations against the OC, I am in your camp that I think people unfairly criticize it). They did rebuild the graphics engine entirely. I suspect that when they started doing that, changes to the core engine were probably required (or occurred for a different reason), that the initial hopes of keeping the DM Client the same disappeared as it was no longer possible to just add it into the code base.

Were they set in the Forgotten Realms with custom characters? A DM Client isn't part of the D&D setting (setting was the important word here too....I haven't heard about DMs existing in Eberron or in the Forgotten Realms). In any case, I was meaning the Forgotten Realms setting. It probably has a a fair bit to do with a precedent set by the slew of D&D games that don't have a DM Client. In any case, it's not like the game doesn't have a DM. The DM is just the computer. I don't know enough about the DMC, but "part of the engine" might not be exactly the case.

I was hoping for that with the AGP cards as well, but it hasn't really been the case in my area. They are cheaper, as all things get cheaper, but I didn't get the large price drop I was hoping for. Probably because there is still too much demand for them. SIMMS didn't immediately drop in price when DIMMS came out for instance, and I guess it'll take a while before whatever new tech comes out soon to really have a significant impact on the price IMO.

Absolutely. It's not like they decided to not ship it even though it is done. But if they felt that the target audience was banking on the DM Client or that it was critical to their sales, then I suspect the game would either be delayed, or something else would be cut. Finally, things like Gnomes and whatnot, while unpopular, are a part of the D&D setting. They are probably also easier to add than a DM Client.

I wasn't going to comment, but since you baited me into it, I will. You clearly have zero idea what it means to be in QA, and are unequivocally unqualified to make any statements about it.