Ripper

Your AK-47 example is identical to the narcotic example. Both are banned items in a geographic area, by the governing authority. Every AK is banned. It doesn't matter whether China, Russia, or some other country manufactures it. WHY would an organization BAN EVERY INSTANCE of a specific resource? Your Kinder Surprise Egg example, is banning a specific brand of a product by the governing authority. Candy eggs haven't been completely outlawed in the US. Just the ones with the toys inside of them. So bringing this example into Dual Universe, instead of banning a weapon outright, the org would only ban "Band of Outlaws" created weapons. The demand for that weapon would still exist and would be supplied by OTHER organizations. There's no need to smuggle the BOO weapons unless its for "vanity purposes". I'm confident no org will hold a monopoly on crafted items. So why pay a premium on a smuggled BOO weapon, when I can buy the same weapon from the Terran Union on the open market. Then it comes down to "customs enforcement". I just don't see an org paying someone to fly around all day scanning other ships for contraband. I ALSO don't see any player wanting to do it. You're not going to force a new player in your org to do anything. You also cant enforce an organizational law upon your members. If they want to trade with someone, they will. If you attempt to discipline them, they'll just move on to another org. Hence the need for NPCs...

I think of smuggling in the traditional sense. That is, having a specific item (such as drugs) outlawed in a specific sector. You're right, you CAN smuggle commodities. It's done every day by rogue countries to avoid sanctions. But your description assumes one organization has a monopoly on a specific resource, and that it won't sell directly to another org. I doubt any org will have a monopoly on resources. So this means the other org, can easily purchase the resource on the open market. What your describing makes sense, but I seriously doubt a player is going to spend all his time playing as customs enforcement. Prohibited items like drugs would need to be enforced on the NPC level.

I'd like to add to the END of the list. You know, after all the good stuff is added. When we start interstellar exploration, I would like to see (at some point) NPC aliens. I'd like to run into some friendly races that might have their own laws regarding materials (so that we could have some decent smuggling). I don't believe the RDMS will do smuggling justice. The only way to do it right is with NPCs. And who doesn't want to eventually run into a hostile alien civilization?

The LUA scripting Devblog goes into this. The "Control Unit" is the interface between the game client and your computer hardware. It is what is used by your scripts to access different types of input methods, such as keyboards and mice. There's been no confirmation of analog inputs. So what you're suggesting is exactly what I've proposed.

I would prefer to see multiple analog axis inputs made available on the control units, which return a value of -1 to 1. Let the players get the joysticks working with the ships. Assignable axis inputs would allow for gamepads, joysticks, rudder pedals, etc...

If you watch the video that's an "accessory". I wouldn't know what it is, but you can change its color by adjusting to accessory color. So maybe its optional

Noticeable drag in the space ship flight model, when landing. I'll actually be happy with just about ANY flight model, because imho, its a small part of the game. But it WOULD be nice to have a little inertia... Being "Pre-Alpha", I'm not that concerned.

This is one of the coolest videos so far.

Devblog posts categorized http://dualuniverse.gamepedia.com/Dev_Blogs

Redacted

.

Anyone else get this feeling around whales?

I'm pretty much done here. If you'd like to know how to create IPs in a cloud environment, google "Amazon elastic IPs." It doesn't matter whether NQ uses Amazon, or some other party to host their servers. Any decent hosting company has an equivelant solution.

Your attacks are on addresses (and their resources) that you are aware of. I can procedurally create as many server names and IP addresses as I need. Even IPs hosted by completely different providers. For every address you know about I can create 100. Now I've taken your argument to an extreme, which isn't realistic. But your arguments haven't made a dent in my solution. I've taken a central point of failure and a bottleneck and distributed it across a redundant solution. That's something that's not possible with websites. Yes. Given the size of the botnet, my solution can be taken down. But it's decentralized AND redundant. And much more difficult than taking down the Whitehouse's website.

Given your example: At least two IPs are known to you, the hacker. The initial authenication server and the current "sector server" (the 3D sector you're in) If you attacked my "authentication server", I could drop all traffic to that server and the game clients would continue to connect to another authentication server IP. Given the hosting provider, the IPs wouldn't have to sit on the same subnet, so they would use completely different routes and network resources. So the DDOS packets wouldn't affect the other "authentication servers" on the list. The packets could also be dropped WAY upstream. The "sector server" could be impacted but it would only effect a small number of users, and I addressed those concerns in my original post. Including determining WHICH game client was the actual hacker so they could be banned.

My previous post indicated why a generic client can't solve the DDOS issue, vs a dedicated game client. DDOS attacks target a known resource. For example http://www.whitehouse.gov My solution moves the critical game infrasturcture from a single "known resource" (known to the hacker) to multiple new unknown resources. The DDOS can continue to attack the "known resource", or the hosting company can block all traffic to the "known resource" entirely. The game clients can then connect to the next server on the list.

Sorry about the misunderstanding. To clarify about the algorithm. My suggestion would indicate the server name doesn't necessarily need to be static. It just needs to be known on both ends. That's why DDOS is so effective for web browsers and websites. There's no way to do this with a generic browser, but its completely doable with a game client. A generic browser has one URL that its attempting to connect to. As long as the attacker floods junk packets to the URL, it doesn't matter if the hosting company changes IP addresses, or points the URL somewhere else. The DDOS just hits the new location. The server needs to know the randomly generated name so it can setup the name in DNS. There's no charge for a third level name, So, there's no additional expense. The server DOES need to create the name at least 24 hours in advance to account for DNS propagation. The client needs to know the name so it can connect to the server. The server names could be stored statically, but a hacker would eventually find them. An algorithm could be used to generate random names on both the server side and client side. The client could also have 1 or 2 static names in the list for redundancy, but they're the ones most likely to be attacked. The client just needs to go down the list of valid server names until it connects. The static server names AND the algorithm could be changed at NQs discretion via the standard client updates. This would make it more difficult for a hacker, because they would need to start all over to hack the algorithm.

Correct! However DNS and IP addressing have nothing to do with the server architecture. It doesn't matter whether they're physical servers or hosted by a third party.

Anycast or an alternative solution is already in use by most cloud hosting companies. There's no need to hack into their infrastructure. DNS allows for changes to IP addressing. Novaquark would not need to know the IP address provided by the hosting company until the server name was created. There's most definitely a reason servers have names instead of just having IP addresses. Ask any Admin. A single IP address is the SOLE cause of why DDOS is so effective. But once you do authenticate your client will be connected to the server service that hosts the sector your avatar is in. It may not be an actual server. It could be a service, but it will most likely have a dedicated ethernet interface and IP address. DDOSing is not about gaining an advantage over one player within a game. Its about holding the game hostage and asking for a ransom from Novaquark. There's a good "Wired" article about how hackers held an online gambling site hostage, asking for a ransom. A hacker doesn't need to send encrypted packets to the service. All they have to do is overwhelm the network infrastructure with invalid packets. (junk packets) This will take the entire game down, thereby denying revenue to Novaquark. At the very least, turning off players, and making NQ look bad to the gaming community as a whole (which ultimately impacts revenue). As for IPs.. I can go onto my EC2 servers and obtain an IP within seconds. Registered to Amazon. And I can drop that IP address seconds later. There's no need for NQ to purchase an entire block of IPs. This ability coupled with DNS resolution allows the hosting company to deal with the DDOS packets in multiple ways. The key concept is to not make anything a single point of failure, or define a static environment. It should be completely dynamic. This will give NQ and their hosting company several methods to address the mass spamming of invalid packets.

TCP is a poor choice for gaming. It would never be used for FPS, and I wouldn't use it for "tabbed targeting" RPG games either. There's a lot of redundancy and overhead with TCP. However, it won't make much of a difference for DU. I just believe the server resources could be used more effectively elsewhere. UDP can be used for unreliable data AND reliable ordered packets. For more information: http://www.gafferongames.com

And yet you're still here...

From your own admission, you're NOT going to convince Novaquark to change their mind. You and your "community" have already withdrawn your pledges. Why are you here? To Troll? To cause strife within the community? To undermine the Kickstarter?

There's a difference between encryption and obfuscation. A good coder should know how to obfuscate their own code. NQ would need to encrypt and decrypt the scripts. This will add overhead to the client, but a good PC should be able to handle it.

This is a cool idea for a thread. Mere speculation here, and I'm not a game developer. But I have a few ideas. DDOS is always an issue. Here are some ideas that I would consider if I were to create a game. THE INITIAL CONNECTION: The client should have the ability to connect to multiple URLs (server names) for the initial connection. I would probably program an algorithm to generate those URLs so they're not statically stored on the client. Maybe even a second algorithm to generate a set of URLs that are dynamic (such as date specific). If the client can't attach to the first URL, it attempts the second and so on. The algorithms would also be used server side to generate valid URLs such as S3de932.dualthegame.com (S3de932 is randomly generated by the algorithm). You have to have the algorithm on both sides, so that the client and server are identical. The algorithms ARE client side, so there is the potential that a hacker could eventually decipher the algorithm. So possibly update the algorithm every so often to throw them off. The above solution means a DDOS attack can't focus on a specific server name, and by extension, on a single IP address. Then I would use ANYCAST for IP addressing. There are two good reasons to use anycast. First, you can geographically disperse servers with identical IP addresses. This would allow a user from America, and a user from China to connect to the same IP address, but connect to servers that are close to them. The second reason to use anycast is that it can dynamically load balance to other servers. A DDOS attack might hit the IP address, but the load would be distributed to multiple servers. Coupling the two above solutions would increase performance geographically, and not limit the initial client connection to a single server or anycast IP address. Each URL would point to a differnt anycast IP address. GAMEPLAY SERVERS: Once the players are logged in, they're automatically going to be passed to the server that hosts that 3D portion of virtual space. So, if the DDOS were to get past the initial login, it would be limited to a specific sector of space within the game. The attacker would need an authenticated client connection, which could be BANNED if a DDOS were attempted. And once they're disconnected the "3D space server" (whatever it's called) could have a new IP address assigned to it if needed. This would prohibit the banned user from continuing to hit the server, by spamming junk packets to the IP. Configure the server/firewall to only accept packets from authenticated users. This would prohibit an authenticated game client from passing good IP addressing information to the botnet. Also, the code used to dynamically scale the servers shouldn't rely solely on player count. If the botnet WERE able to bypass the above firewall rules, the server service would become overloaded. There should be a mechanism to scale or even offload legitimate users to a separate server and allow the unauthenticated packets to continue to hit a server that's no longer being used. By selectively offloading users over time, the "hacker" account could be deduced by noticing when the new server was hit by the botnet. What do you think? I'd love for you to shoot holes in my solution.

From your own admission, you're NOT going to convince Novaquark to change their mind. You and your "community" have already withdrawn your pledges. Why are you here? To Troll? To cause strife within the community? To undermine the Kickstarter?