Yes, most "optimization" is about looking at trade-offs in code execution and tipping the scales from one side to the other: You trade CPU time for memory, code speed for extensibility, graphics performance vs quality vs flexibility, load times vs memory usage, game complexity vs modability.... It goes on and on. It's pretty rare that you come across a situation where you can make code changes that have no negatives. Even then, the trade-off is still somewhat paid in resource cost (but you were probably paying that already). A lot of the optimizations they've put into the game have had these sort of visible consequences, but most people simply don't care are aren't looking close enough to notice them. Texture atlasing was a great addition to the game in terms of display quality and texture performance, but it also added some mild weirdness in rendering at specific distances. They traded an overall improvement in appearance and performance for a limited degradation in behavior. Trade-Offs. The graphics are actually pretty good quality for an MMO. Comparing it to an FPS is simply apples and oranges. If you don't understand why, then some research is probably in order. The performance problems (in my sort-of professional opinion) mostly stem from the need to perform graphical updates in synchronization with a remote server. Limiting the amount of power required for rendering any given frame helps them manage the wide range of hardware being used to play the game. Giving users options for how much they want to use might be a nice thing to add, but remember that those sort of controls have a performance cost in themselves. There isn't much additional "power" available via x64. The major "power" upgrade in modern processors is the drastically improved IPC, integrated memory controllers, pipelined cache management, and better interfaces to the PCIe bus. You don't need an x64 client to take advantage of those things. The biggest improvement that 64bit compilation gives you is a bigger per-process memory limit. While SWTOR could benefit from that, the performance increase wouldn't be nearly what most armchair developers think it would be. If you're referring to a fully-multicore-capable client, then the potential is slightly higher. However, SWTOR doesn't really lend itself all that well to full multicore implementations. It's possible, of course, but server interactions still need to be primarily synchronous and unified, so even if the client could split out threads to handle other tasks, there would still be a main "game" thread that would need to handle authoritative game state.

I would have preferred a different form of the "stance" system where each force user could use any of the three lightsaber styles (plus vibroblades, I guess...), with various tradeoffs. Some of the combos, then, would have poor performance, but the choice would be on you (and it would be obvious what your stance was). However, the original design of the game was based on some other UI design ideas which were very popular at the time. These stated that games felt more natural if their opponents (in PvP or PvE) exhibited easily identifiable shapes. Even the difference in posture between a mercenary and a powertech would evoke this response. The count and orientation of lightsaber achieved the same thing. It's a nice thought, and games like TF2 have proven it to be both true and stronger than people initially thought. However, it does also encourage game design with static roles and appearances. Pretty quickly, the ideals were broken. Guardians/Juggernauts were giving better DPS, and it became harder to tell the difference between a defensive class and a strong DPS class. Then Shadow/Assassin tanks came along, looking just like our bursty-stealth force classes. The desire for armor customization tossed aside the old patterns of armor appearance as a cue for class behavior. In the end, these were all good things overall, but to understand why we have weapon restrictions, you need to look back at the psychology behind the separation of classes. Perhaps sometime we'll have another revamp which gives us more choice over weapons. At the moment, this is largely prevented by the lack of animations for other weapon types. But maybe some day....

I'll admit that Path of Exile has some of the best customization I've seen in a shared-world RPG. It also has the biggest problem with drastically over-powered builds. In some cases, the builds are almost ridiculously imbalanced to the point of being a mockery of normal RPG practices. I know they've been trying to control those a bit, but it's not a coincidence that the game has a ton of player customization and drastic game imbalance. Even then, if you really look at Path of Exile, you'll find that a large group of people are still just copying a small number of popular choices. It offers something more than the simple illusion of choice, but if you want to have anywhere close to the highest performance, skill can't get you there. You need to use one of the current best-in-class perk combinations. So, it gives you choice, but the choice is between feeling unique or being as effective as people who use cookie-cutter builds. That's the sort of thing that most MMO designers are trying to avoid.

Do you know it's exactly the same? Do you know the legal requirements for "false advertising" claims? Didn't think so. Okay... I know you're just trying to complain about the duster not being the unique thing that you really, really wanted it to be, but no one ever promised that. The statement you quoted is the advertising equivalent of statements like "This movie is amazing" being attached to virtually every movie ever made. Are there hundreds of movies guilty of false advertising because you only found a dozen of them amazing? Can you objectively prove that they aren't amazing? If you want to try to accuse someone of a crime based on semantics, you better be sure that you're applying them correctly. The statement says that it will set you apart from other heroes. It doesn't say how many of them. It doesn't say which group. Can you prove that every single player will be using it? If it sets you apart form 10% of the other players, doesn't that still fulfill the statement? Even if we hypothetically accept that this is false advertising, the best recourse you can hope for is to be refunded the cost of the item plus any additional damages or inconveniences you might have suffered. And, of course, you'd have the item taken away from you. So... since you didn't pay anything for it (old argument, but the law is clear: You paid for the subscription, with the promise of an incentive that holds no monetary value), you get no refund. Since you never had it, there's no inconvenience or additional damages. And you don't get the jacket at all. Happy?

That's the best compliment you could give me. It's always possible. I think a lot of the early optimizations they did like this were quick ways to give drastic improvements to the game in an effort to address the rather loud criticisms (which weren't unwarranted, though the style of presenting them might have been). Since then, there have been a number of additional improvements. I think that change occurred before texture atlasing was included and before some of the other texture optimizations. I suspect they might be able to handle many more textures now, though that's really just a guess. The bigger issue is simply that there isn't a lot to gain by adding it back. Sure, it makes for a prettier environment, and neither I nor the developers are unaware of that. However, there's often this reluctance to spend resources on improving things that aren't really seen as providing any substantive change when you've got a bunch of other things where you could really feel the improvements. Yeah, it's a sign of a development team that is short on development resources, but to be completely honest and practical, in the fifteen years I've been a developer, I can only remember 18 blissful months when I was on a development team that had spare time to seek out ways to improve the product because we had extra resources. Development teams seem to be chronically stretched thin. So, yeah, it might change, but I suspect there isn't much incentive to. Instead, we'll just see the quality of NPCs in new areas increase and we'll stop seeing this sort of cloning used in them. I guess time will tell.

This is an example of the difference between what the industry considers a "programmer" and a "software designer/developer". A programmer only thinks of how to accomplish some task. A designer needs to think about the implications of that solution. The designer is paid more because they need to think of more than just how to get something done. Put in simpler terms: A programmer is a hammer looking for nails. A designer is a carpenter looking for the best way to get a job done. Someone who doesn't have to think about performance would easily come up with the "Let's randomize it!" solution. That is actually the lazy answer. There are novice programmers in high school that can come up with that answer. However, "randomize it" ignores the resource and performance problems that may result. The sad reality is that a large part of software development is accepting less-ideal implementations in order to maximize performance and optimize resource utilization. Before you decide to call someone lazy, make sure you've done the analysis to see that your "any idiot could do this" fix doesn't cause bigger problems than it fixes. NOTE: There's all sorts of crap involved with job title descriptions in the software/IT industry. My comments here revolve around a tentative consensus of a questionable majority of the culture. The term "programmer" is often assigned to lower-experience positions. Things like "engineer", "architect" and "developer" are used for higher experience levels. Yeah, this annoys architects and IETF members ... and .... I don't know, commercial construction developers, probably. I don't pick the names, I just try to use them to get ideas across.

I think the explanation is even easier than that: From what I remember, at launch it was common to see randomized NPCs in an area. However, along with some of the other framerate optimizations (reducing animation updates based on distance, reducing texture quality based on distance), there was a change that made many NPCs clones of each other. This would mean that instead of having to load textures for 30 different NPCs in an area, you only have to load textures for 10. Rendering the same NPC model/texture in two or five different places is way less work than rendering five different NPCs. I know I first noticed it in the Senate Plaza on Coruscant, as it has a few groups of people who used to be generic NPCs but turned into lines of clones. New content made after that seems to have been designed to reduce the number of textures and models loaded in any single area.

I just don't see it. They are both masks. Beyond that, there's nothing compellingly similar. I'd water there's more similarity to Vader's mask than Revan's. Storm troopers. Tie pilots. Even some random background characters have masks with more stylistic similarities to Ren's mask than Revan's mask.

Why would you even think that was the case? Why manufacture this disappointment from zero evidence? Because they're not releasing an Op with the expansion? That doesn't say anything at all about the future. Taking that to mean that they're never ever going to include any group content is a bit silly and alarmist. Especially considering that they've told us they had a bunch of developers working on adapting the old Ops and FPs to work with the gearing and level changes. Those are the actions of a group that is looking to change how future group content is created, not to stop producing group content altogether.

It's released on the 16th in many European countries, the 17th in the UK, and the 18th in the US/Japan. I think the UAE gets it the 14th or 15th. Dunno why, but I seem to remember that was the very first official release.

Going to go out on a limb here: The use of him is that we can use him in later levels.

Welcome to confirmation bias. I've yet to hear of anyone running SWTOR on a computer with a purple monitor, so I conclude that SWTOR cannot run on computers with purple monitors. You're looking at the support forum --a forum for people who are having problems-- and looking for issues related to a new, popular piece of software. Its not shocking that you see it show up a lot. That doesn't mean that everyone using it is having troubles. You're seeing dozens of problems reported from the thousands of people running Win10. More to the point: I run Win10. I have have no problems with SWTOR. In fact, it smoothed out the framerate a bit more than Win7 and Win8.1 did. The framerate isn't all that much higher (5% maybe), but the dips aren't as drastic and its generally more consistent. This is largely due to the use of WDDM 2.0 which is sitting behind DX12. Now, it is a new OS, so that means you're going to need to do standard maintenance to get it working properly. You need to get new GPU drivers. You probably need new sound and motherboard drivers (though MS might have compatible ones...), and you may or may not need new drivers for storage controllers, depending on what sort of storage you're using. You'll need to check your network settings, and you will probably want to do some picking and choosing of which services need to start up. Provided you do that, Win10 is a small performance upgrade and for the majority of people, a stability upgrade as well. Most of the problems people are reporting are because of drivers, not the OS. The OS choice is sort of the cause behind the problems, but most drivers are fixed pretty quickly. At the very least, the vast majority of people are having no problems at all. You're just looking at the minority that are speaking out.

A bachelors degree in computer science, from a theory-based school. That includes a year of calculus-based statistics and probability, along with a year of algorithm analysis, a year of theoretical computation, and the equivalent of a year of discrete math. I've been a programmer for about 15 years now, during which time I've implemented a few pRNGs, worked with a half dozen others, and mentored new programmers in developing code for scientific applications.

Statistically, I think you'd have some pretty good evidence at 1000 rolls. At 100, you'd be able to start making some sort of conclusion, but it would only be convincing at very high discrepancies. One of the points of any decent pRNG is that sampling doesn't actually affect the level of randomness. Some cheap/bad pRNGs are affected by this, but if we take a very conservative approach and assume something like the Mersenne Twister is being used, then there is no added or removed randomness experienced by selecting a random subset of the full stream. That's actually a pretty common novice mistake in pRNG usage. People think that they're making numbers more random by adding two random numbers together, or that they will get better results by skipping a random bunch of numbers in the stream. Mathematically, it simply doesn't work out. If you generate a sufficiently large set of random numbers, all subsets of the same size will --on average-- have the same level of randomness. So... short story: No, there are no localized effects of randomization with the professionally used pRNGs.

Ugh. I know. "I've been seeing a problem with the roads in my area over the last week. Every road I drive on makes horrible noises, and oil starts seeping up from the asphalt and creating lots of smoke. I know its not a problem with my car."

I normally play in front of my monitor, and just slightly above my chair. If you're looking for a more geographic region, it's usually within a dozen feet of an annoyed cat who wants to play fetch with me.

I made no such assumption. I merely pointed out that my conclusions were based on mathematics, science, and professional experience. So far, you have only cited a "feeling". Barring any actual evidence, the null hypothesis given by mathematics, science and experience (mine and many others) is that your feelings fall perfectly within the expected results of normal randomness as filtered by a mildly biased perception.

My conclusion is backed up by math, programming experience, and a classic series of psychology experiments.

This is the prefix to all sorts of bad conclusions. You don't have actual data, but you feel that there is some bias. The truth is: There is. But the bias is within your brain, not the RNG. Making an RNG with reliable, controllable bias is actually tricky. Making your brain see patterns in randomness is so easy that sometimes you can't even prevent it if you try. So, you spotted some pattern in a statistically insignificant set of samples, and your brain developed this bias. Now, it uses that bias to evaluate all similar situations afterward, and it has a strong tendency to remember events that fit the bias, and forget events that don't. Thus, you actually believe that the bias you feel is real, even though you have no actual mathematical evidence for it. Programmers, engineers and mathematicians are trained in ways to try and avoid having this color our conclusions.

You're welcome. I'm here to make people happy. Bioware isn't going to announce those things based on some customer question. Beyond the normal marketroid-based reasons, there's a really bad history of this community handling any sort of uncertain information, especially when it deals with development plans. If they're working on it, they'll announce it when they've got a 98% certain release date, and they'll refuse to even acknowledge it before then. Again, considering past behavior here, there's sadly a lot of wisdom in that approach. That was part of my point. People say that there are no improvements, but the majority of those people don't actually pay close enough attention to the game to realize what's been done. Raise you hand if you noticed the drastic improvement in frame rates in the large open spaces around update 1.1-1.3. A decent number of people might actually remember this. How many of them realized that it was largely achieved by cloning NPC appearances to drastically speed up texture/model draw times? Or what about the big performance boost that came with the change to reduce the update frequency of animations based on distance from the player? You can still see it today on open planets with large creatures. Alderaan is a favorite. Notice how the thranta animations become more jumpy as they fly away from you? That was an engine optimization to spend less process/render time on things that weren't happening nearby. And while the shadows may still appear to have the same blocky texture as launch, there are settings that allow them to look far better. They also take less work to draw. And they manage to pull off better mixed-lighting results than the previous implementations (situations where multiple sources should moderate the contrast in light contrast). Also take a look at the trees. Notice how the light doesn't just brighten the side facing the light. Both surfaces of the leaves accept light, resulting in far more realistic appearances, and at the same time running faster and playing much better with antialiasing settings. Are any of them mind-blowing? No. Why would you expect that? The goal of upgrades and optimization isn't to drastically change the output, but to provide a better version of the same output that has better performance. With the release of KofFE, we'll see some more of the detail that the game is capable of after the various improvements. They weren't included before because they never intended to change the entire appearance of the game, just improve performance.

No, you don't. The point is that once the crate is opened, its contents are generated and you store the crate and its contents using the Character Inventory storage mechanism. That's an already-designed system. Essentially, once you open the crate, its a completely different type of item. Here's a rough hypothetical of what is likely going on. CHARACTER INVENTORY: SLOT[28] = Item{ ID:292819 } // Imagine: #292819 = Mid Rim Explorers Crate There's no need to store anything more than the type of item. You can trade it, sell it, give it to med droids, and the only thing that needs to be tracked is an item ID. We don't need to maintain extra storage for the GTN, or med droids or the mail system. Once its opened, it becomes an inventory crate, just like any other, but with its old name: CHARACTER INVENTORY: SLOT[28] = Item{ ID:292820 // Imagine: #292820 = Mid Rim Explorers Crate (Opened) contents: { Item { ID: 99281 }, Item { ID: 998181 }, Item { ID: 99118 }, Item { ID: 98776 } } } Now its a crate, but you can't pull it outside your inventory. Any storage for the items inside is covered by the code that already exists for the storing of character inventories and cargo bays.

I really don't mean this to be judgmental, but its going to sound that way, anyway: If you're at the point where you're commenting about the relevance of missing semicolons, then you're not quite at the level needed to consider the cost-beneift of major engine changes. Yes, the engine is updated frequently, just not in ways that people who know code by bullet lists on review sites would understand. We've had two major rewrites of the shaders. We've had two major changes to how lighting and shadows are handled. We've had a number of additions to the internal quest scripting capabilities. They've done redesigns on how models are rendered that allow for things like dyes, environmental color palettes (looking at you, Ziost) and additional ability effects. They haven't made major changes to the underlying technology because many of those things would end up changing the system requirements and that's something that studios try pretty hard not to do, as it can result in legal issues in some cases. Moving to DX12, for example, would result in a large number of users not being able to play. Switching to a 64-bit client would have similar results. Should people be moving to Win10 and 64bit, absolutely, but that wasn't in the requirements when they paid for the game, and they'd have some valid reasons to complain if Bioware changed that. Moreover, switching to DX12 would require some pretty drastic overhauls of the rendering system. That takes time, and the cost of doing that with a project that is in a periodic-production-release phase is even higher than it would be for a development codebase. The idea of a 64bit client is even worse, as simply switching to 64bit compilation gives you virtually no improvement in performance, but almost inevitably results in some annoying issues. In order to get good results from it, you need to restructure a large part of the client to take advantage of the things that 64bit does well. Again, the cost of trying to do that with a live product is significantly higher. So, in the end, what is the benefit you see with all that money you've put in? Higher framerates? You're not going to redesign the artwork. You're not going to change the models or the maps. It's just going to be slightly better performance and some new shiny effects. Is it worth paying twice as much for those improvements rather than spending those resources on expanding actual content in the game? Or, put even more realistically, why assign the resources (developers) just to give mild performance improvements to this game, when those same resources could accomplish far more creating some other game that didn't have the restrictions that are already in place on this one?

Almost certainly, yes. Until we have any evidence to the contrary, the overwhelming assumption is that CM crates, or cantina crates, or even the comm boxes have their contents generated by drop tables essentially identical in implementation to the ones used by mobs. When the mob is killed or the crate/box is opened, the game randomly selects items from the drop table. Just as easy, yes, but you'd have to store the results. With any reasonable amount of experience building software like this, storing information is a pain you try to avoid whenever convenient. Since the contents are just random selections from a table, there's no point in pre-selecting them and paying the cost of storing those results when you would get functionally equivalent results later without the need to store them. You generate them when they get transferred to the user, and use the user's inventory storage. But that's just the start. Imagine how many crates exist. You have to store contents for all of them. And for all the chests in the world. And for all the comm boxes that people buy. And for all the cantina crates sitting in people's mailboxes. What does all that storage gain for you? Nothing. Its still just random selections from a table. What if I want or need to change what drops from a crate? Well, if I generate the contents on opening, all I need to do is update the table and I'm done. If I generate the contents when the crate is created, now I need to run through all the crates of that type and fix them. Of course, since laziness is the first virtue of programming, my solution would be to simply re-roll every unopened crate (of that type) in the game. But, if I'm doing that, then what's the point of pre-rolling them in the first place? And if I'm pre-rolling the contents, it means there's a store someplace that knows which crates contain better items than others. That creates a juicy target for exploits. Why not avoid the problem by not storing the data at all? Instead of generating data an hour or week before anyone would ever be allowed to see it, why not wait until the very last millisecond before generating it?

This. As a coder, it's far easier for me to use a stateless pRNG (meaning: a random number generator that stores no information other than the last generated number) than to create a pRNG system that fiddles with the probability based on the past history of 2 to 16 players. Not only does the math get really fiddly, but the amount of data storage and access time gets unreasonable. Remember: The game is rolling random numbers hundreds of times a second. Even if it just fiddles with rolls for gear, it's still doing a ton of data access to create a system that is --by definition-- unintuitive. Next... Which would be a valid perspective if we assumed Bioware was utterly silly and decided to create their very own pseudo-random number generator. Outside of cryptography, that's done so rarely that no sensible person would consider it as a default assumption. pRNGs are a rather technical topic, and yet, they are regarded as "solved problems" for developers outside cryptography. You'd never waste time creating your own. You'd pick one based on beneficial characteristics and just move on. Even across different languages, the interfaces are pretty much the same. Bugs in said functions are very, very rare. There's a decent chance that Bioware is using the standard random function. However, there's at least an equal chance that they're using a different pRNG library, as the standard function (which I believe uses a linear congruential algorithm), but that doesn't have great performance. It's pretty easy to find/use Merseinne Twister libraries which are much faster, and things like XOR-shift or WELL512 which have further improvements. Game developers are very aware of different RNG libraries like this. They likely selected one and simply moved on. Questioning the "randomness" of it is pointless. They would only really ever waste time thinking about performance. TL;DR: Developers know way more about randomness and how its generated than your average gamer. If you're questioning the randomness, you need to come up with more than "I feel it might not be random..."

Just for information., from the Rules of Conduct: I don't know how vigilant they are on the stupid X-bracketing of names, considering all the far more grievous infractions of the naming policy out there (example: the herd of unoriginal Ahsoka clones....), but technically speaking, they can force you to rename.