halethrain

If you ever experience crashes from alt-tabbing, I recommend you set the game to Fullscreen Window mode when the setting is available. Using true fullscreen grants the application exlusive rights to your graphics driver (as in your desktop isn't being rendered once the app opens). Alt-tabbing in this scenario means that the desktop has to be redrawn, and alt-tabbing back to the game requires windows to hand-off control again. Some games don't handle this well, which is why they crash, or you come back to just a black screen. Full Screen Windowed modes cause a small hit to performance, but allo

It's not like this game won't be fully rebindable.

Probably possible, I just don't know enough about how the system works. If it were possible in that system, I wouldn't' mind PVC if it came with granular controls: [*]Accept PVC from all players [*]Accept no PVC [*]Allow PVC for the following: [*]Accept PVC from allies [*]Accept PVC from guildmates [*]Accept PVC from friends [*]Allow PVC Requests (requests with slider bar for duration) If the PVC were implemented I'd also like to see a general Do-Not-Disturb setting with a time slider.

As an aside, do you know if current PVC systems position sound in 3d space, or is it just a volume gradient based on x,y distance? I wasn't talking about how muddy it would be, but rather the technical limitations and load that would be placed both on the client and server-end from having to process the information. I

How do games that feature really big battles or highly populated towns deal with localized voice chat? Like how would the servers and your computer parse 300 different voice inputs simultaneously? I don't know much about in-game voice chat, but implementing in a game like this may be more difficult than it is in other games.

So literally only two people in a house could play? I've already outlined exactly why this wouldn't work, which you already previously quoted. It's pretty much a non-starter for any online title.

That doesn't solve all of the scenarios listed in point 1, or prevent people from using point 2 to bypass the security. Reading more about Tera, it looks like they limited the amount of logins per day for reasons aside from multiboxing: The system that Tera uses would not prevent multiboxing at all, as you are allowed to login to each of the 10 accounts unlimited times per day, just no more than 10 unique accounts in total.

1. Here are 5 scenarios where restricting based on an IP address would not be effective: a) Family units made up of more than a single parent and child. b.) University dormitories c) Quadplexes, or similarly multi-unit houses that share internet d) Corporate networks (yes, some people play games at work - hopefully when they're not actually on the clock) e) People with multiple roommates 2. VPNs cost as little as $60 a year (if you don't want lag) and easily circumvent IP restrictions. 3. Putting in a ticket to bypass IP restrictions would allow anyone to circumvent the rule by s

There's no such thing as 100% preventative security. Preventing multiple instances makes it difficult enough to bypass that the person would be better served using a second computer. If someone were inclined to key clone, they can still do over an internal network . You limit it the best you can, and rely on your support team and issue trackers to monitor for problems. If you're able to validate methods where the system is being circumvented you close the holes and punish the perpetrators. There's no sense in chasing every little thing so far down the rabbit hole.

It helps that the Simpsons have exhausted every possible story and joke possible.

It is incredibly unlikely, as in i would season, cook, and eat a hat, that the developers would restrict the game based on IP. That's like applying make-up with a shotgun.

I added a technical essay to my last response to you. The ways around multiple instance detection are for the flawed versions. If you simply look for the process name, people will edit the process name, and such. However, in layman's terms, you can code your application to directly try to do a particular check during its launch, which will fail because the first instance of the application is holding that check. If the application gets a failure reply on that call, it simply doesn't open.

Very easily. Depending on how it is implemented there are ways to get around certain implementations though. Here is a technical essay on the subject if you're on the savvier side of code.

I can pretty much guarantee, they are going to limit it so only one process can run at the same time. You can have as many accounts as you'd like, you just can't open the app more than once.

Called it >.>