CodeGlitch0
-
Posts
420 -
Joined
-
Last visited
Posts posted by CodeGlitch0
-
-
It is because NQ systems could not keep up with the level of industry people were creating after beta launch. So they increased minimum batch sizes to lessen the number of server calls required and save the servers.
It is mostly likely a temporary measure, but we do not know for sure or for how long.
-
As @Helediron said, just push the button. If you look a little closer at the screenshot you posted, you will see it says "[saved email]" and "[saved password]" in the fields, indicating it doesn't need to be re-entered. The values are hidden for security. In particular, for people that stream the game.
-
Previous reply was a bit terse and could use additional explanation...
9800N will cancel the effect of gravity if aligned in opposing direction to gravity. It will do nothing else. If you want to move anything (additional acceleration), you need multiples of that. How much depends on what you are tryong to achieve. 4X (4g) is probably about minimum, 10g gives most flexibility.
-
At 1g, it takes about 9800 N to cancel out (not lift!) 1000kg of mass.
-
20 hours ago, Cainon said:
Sorry guys I tried to follow your threads to post my bug report in for the last time the game was accessible I found my designed hoverbike having a cargo container was fine to fly but soon as I put cargo into I could not stop turning in circles when I put cargo into the container. It is in the middle of the craft. Two Every time I fly and try and did turn I had to break first and then speed up the vehicle did compensate for the turn it kept going in the direction I was going in. I do not know if i need a computer to help with that or it was just a bug in the game.
This should be moved to NDA section, but the problem was that you didn't balance your ship properly. Extra weight (interia) exacerbated the problem.
-
Wow, this system is going to make it hard to both design ships AND test them early on. If there are skills for basic things like "flying hover engines" and "flying with ailerons," that will severely limit the ability to build something you can actually test well until much later in game and will likely cause a lot of discouragement in people just learning the game and trying to build things.. I'm sure it'll work out fine by release (and later on in your DU career), but It will make for a ROUGH start. Hopefully there will be better balance simulation/analysis tools when building.
As an analogy: allowing the ability to write code while essentially disabling (or severely limiting) the ability to properly "unit test" or "debug" it seems like a really bad idea at first glance. We'll see how it goes, I suppose.
-
"Directly" being the operative word, I guess. Voxel structures aren't based on edges and vertices like most 3D models. Edges and vertices for display are derived from voxel data.
That doesn't mean it can't be done, it requires something to do the conversion. In fact, the NQ team did just that to import models into the game for demo videos, etc. But, by nature of the gameplay, that won't be available to the general player. We'll have to manipulate the voxels the old fashioned way.
-
@Thainz: "CAD" functionality such as sketching, dimensioning, and measuring aren't directly compatible with a voxel engine. You could use a CAD system (such as onshape.com, which I use) to draw up a schematic, but you'll still have to translate that into voxels yourself. It wouldn't automatically convert in-game. Sure, if you were a NQ employee, you could use their tools to import 3D models into voxels, but that won't be available in game.
However, you can certainly use an engineering schematic created in an external CAD program with measurements to be far more precise with your voxel placements to make the most precise final version possible..
-
Oh you're going way more ham on this than I am, or that I anticipated you'd be. Godspeed I guess. o.o
Yes, well, I'm something of a nerd. Talking about it got me wondering what the actual latency on something like this might be. So, now I want to put together a quick test to see how it actually might perform...
EDIT: I'm also a hobbyist/aspiring game dev (at some point in my life, not that I'll ever get around to it). But something like this may actually end up useful?
-
Yeah, that does seem reasonable.
I'm not sure how we veered this far off-topic, though I'm not sure what more to speculate about their backend... Specific implementations of various microservices and such, assuming your Azure model?
I'm currently working on a diagram of the model. I'll post in the next day or so hopefully. Then we can rip that apart until we have something that feels like it might be a viable back-end for DU. Then I will probably tinker with an implementation of it for performance checking and we can go from there.
-
To buy and build a cloud yourself would be insane. The kind of infrastructure that DU would require would have enormous front-end cost. Certainly, at least 100s of thousands, but in the millions probably. NQ has stated (referenced earlier on this thread) that they will be using a cloud service. At launch, at least. So my speculations assume they make the sane choice: a pre-existing cloud, with pre-made and configured core infrastructure as with something like Azure or Amazon cloud, and not reinvent the wheel. If, by chance, they do decide to try to create their own cloud.. I would be willing to make bets that initial launch would be a complete catastrophe.The intention was an in-depth software/developer discussion, moreso than IT.
-
So you're presupposing they're behind some kind of DDoS mitigation service, the kind that I mentioned in the post that you were quoting?
I think we're in agreement, then.
In your typical service provider patterns, yes you're assigned personal IP addresses. But in a cloud situation, providers like Amazon and Azure, etc are assigned huge blocks of IP addresses which are used as needed by various clients. If you're using static, very long-term IPs in a cloud provider, you're probably not making full and true use of the full power of cloud.
The full power of cloud comes from throwaway virtual machines and dynamic, fluid hyperscale capabilities.
-
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:
Yeah, there are definitely options out there. But I imagine something like DU won't actually require a huge amount of network traffic per client. Latency will be first an foremost. But without a requirement for twitch combat (ie. FPS shooter), the traffic will likely be mostly game events (voxels added/broken, shot fired/target and player movement. It can probably be accomplished within 50-100 kbps (~5-10 KB per second) on average per player. I could be way off on this number, but hey! It's wild speculation day!
Also, an ingress layer helps immensely with that. The responsibility of those nodes is solely: accept traffic, decrypt it, validate/authenticate it, pass on to game services. The major difference between cloud/microservices and tradional game servers is that the cloud doesn't require every single bit of processing to happen on a single node. So, you aren't required to micromanage performance issues in the same regard as traditional. The distribution means you can handle a lot more than normal.
EDIT: But you are right. UDP is generally better for things like gaming. When the game logic is primarily server-based though, it might become a different beast. Dropped packets, except for movement and the like, can be really bad in that scenario. Possibly a hybrid/dual streams is the best choice.
-
Doesn't TCP just do this own its own (sequence numbering in packet headers)? If I send that player A moves to point x, then y, then z, those TCP packets have to arrive in the order I send them and I don't need to worry about it, right? Or if you mean players A and B both in different regions distinct from mine and from eachothers' violating causality... Well I guess you'd have to maintain some sort of server simulation time indexing as well, which you could use to sort data arriving from different regions -- is this what you meant?
[EDIT] That could cause delays, though, if you allow a lagged up packet from one region (at say, server tick 1500) delay the processing of events from other regions (at ticks 1501, 1600, whatever), right? It would have to be smarter than just a queue that you sort and execute in order. Is this what you're eluding to with read vs. write (some kind of analogy I don't get there)?
I'm talking in the context of a "dumb" ingress layer. Yes, at the TCP level, packets would be ordered and retry as normal. But once through to the ingress nodes, that traffic is authenticated, validated, decrypted, and passed on to the actual game logic nodes. It is at this level that I image a queuing system might be necessary. If you have 100 ingress nodes and no queuing, that is a lot of asynchronous traffic (100 streams) being dumped into the game services (let's say 20 server nodes) and it all needs to be handled and processed at once. By implementing a queue (either in process or separate/distributed) you can quickly accept that traffic, then process it as quickly as possible without fully flooding the services. If you use something like Azure Service Bus or Event Hubs (again, sorry for always posting M$ tech), then those cloud services can ingest the millions of messages per second and use Message Queue "topics" to intelligently route to only the nodes that requires the message. instead of the connected node receiving EVERY message, always. Again, it's a trade-off between raw performance or adding a bit of latency to be more intelligent and reduce overall traffic ingestion on specific nodes.
-
I apologize for constantly going back to Micro$oft tech. I use M$ dev stack every day, so it is what I know best.
Well, as stated, I don't know a whole lot about networking...
However, wouldn't anycast require you to have access to the routing tables of the ISPs carrying the connections? Like, say I get an IP address for a US from Level 3, which is from a block of IPs assigned to them, how would I set that as the IP of e.g. a German server connected to the internet via Deutsche Telekom? I mean I know that as an autonomous system, you can set up anycast within your network, but how do you set something like that up for IPs you don't own (or from within networks to which that IP is not assigned to)? How does NQ who isn't even an AS do something like that? I'm confused.
Also, what's the point of using DNS for a system where they make the client and the backend infrastructure? It won't obscure the endpoints clients connect to, IPs aren't secret information, you can just look at the traffic and aggregate a list of servers over time.
Wouldn't it be best to have your client connect to a service (behind some IP, maybe the client could store a list of alternatives) to log in, and at the same time a backend service would negotiate a connection to a cluster local to you?
As for DoS protection in general, the kind of architecture CodeGlitch0 mentioned would, on its own, go a long way against mitigating DoS, since an in-game region's corresponding cluster might be geographically disperse, DoSing would have unpredictable effects, and since you're probably trying to mess with some specific org or player, you can't point the attack very effectively (you'd have to know where they live, and target their closest NQ server).
Of course if you're just trying to bring down game service across the board, you just target all the NQ servers, whose IPs would be public record -- just the nature of IPs and routing, nothing you can do about it. In order to protect the login service from being brought down by a cheaper DoS attack, the login backend would just have to be distributed across all the NQ servers as microservices, as CodeGlitch0 outlined above.
There can be a number of benefits to having a level of protection at the DNS level. With the advent of things like Azure DNS, you can go even further than just security with it. In the cloud, IP addresses can be very fluid. There isn't a whole lot of need to hold on to a single public IP for long periods of time, unless that is how your system is designed. In microservices approach, they can come and go and it wouldn't really matter. DNS protection would only help with the initial connection attempt for each client. Most clients will cache results and then just use the same given IP until something fails and it attempts a reconnect.
Diving in... What can you achieve with a DNS layer protection system? A couple of things. Primarily: automatic geographic distribution, initial load balancing, and DDoS protection. Because IPs can be in flux, a cloud-based DNS server can protect against DNS-level DoS attack by simply blocking evil IPs from the DNS layer. That prevents a level of DoS traffic from even getting to your app. This is more beneficial if IP change regularly. However, most app public access points are fairly static.
Secondly is geographic distribution and load balancing. In something like the cloud DNS, you can have the server know about a number of affinity points for your app. (read: datacenter location specific) Lets say you have "connect.dualthegame.com" as your primary connection point. This service is distributed amongst 30 nodes/IPs in 3 geographically dispersed data centers. The DNS layer can know that you also have "america.connect.dualthegame.com," "europe.connect.dualthegame.com," and "asia.connect.dualthegame.com." When that initial IP resolution query comes in, the DNS service can look at your IP, check it's geographic location and return the appropriate CNAME for your region. It is also possible to select based on latency, I believe. Each of the geographic CNAMES has a list of IP addresses for each cloud load balancer on the connection point for that datacenter. When multiple IPs are returned, the client will essentially just choose one at random and connect to that. This gives a degree of initial load balancing before your client even tried an actual connection to the app.
The malicious botnet will be mitigated in some respect on that initial connection attempt, if it uses DNS resolution. The cloud DNS/front-end load balancers can pick up a list evil IP based on network traffic and prevent before it even touches your app. The load balancer denial also protects your app from direct IP address attacks. If the hackers get through even that, the ingress layer has it own protection now, as I mentioned, because individual nodes are fluid and disposable.
-
-
@Ripper:Those are some great points! The addition of ANYCAST perhaps through something like new cloud DNS services) would definitely be required for the initial connections and help greatly with geographic distribution and DDoS protection. That would pair wonderfully with the Authentication/Connection reservation/encryption key generation I mentioned.This brought to mind a couple of other benefits about having an abstracted ingress gateway layer. The ingress layer would be responsible for all encryption/decryption of over the wire traffic to players and would easily reject any other connections attempts that have not been reserved. If they we targetted by DDoS attacks, it would be easy to scale up additional instances and just dump the attacked nodes. Player connections would simply reconnect to a new ingress node and they would only notice some lag until automatic failover happens and the blip of that reconnection attempt. Everything else would happen behind that ingress layer in traffic that is inaccessible publicly, and actual regions wouldn't actually be affected. The primary downside would be a slight addition to latency, but because it is all part of the cluster it is pretty much just traffic over a local network switch, so we're talking singles or less of ms.
@LurkNautili:Connections between nodes would be direct yes, but messages would need to be queued once received to ensure they happen sequentially. But once in the queue, they can be processed and acted on asynchronously, with some intelligence to resolve conflicts. Individual services, such as the region, can also make use of replicas to allow certain read operations to occur across nodes, while write operations would happen on a single primary node to protect the system integrity. A lot of this can just happen automatically thanks to the cloud services / service fabric layer.Because data-center connections are much more likely to be consistent and predictable than player connections, geographic distribution and synchronization might actually make a lot of sense in a cloud situation. There might be some lag for events from players in one RL region to players in another RL region, but that would happen regardless of implementation. It is inevitable. Distributing RL geographic regions via only the cloud, would likely actually normalize a lot of those inconsistencies.Now you got me thinking even deeper. Perhaps I need a diagram... That'll be later. -
Yeah, I was going to cross-post to the Kickstarter, but I figured there would be far less chance of it getting buried on the forums and I didn't want to duplicate questions. Thank you for responding, though. Sorry it became necessary.I should have noticed the answer in the KS update, but I glanced over that line apparently. My mistake, and I am happy to own up to it.It's unfortunate that the post exploded, when I just looking for a response or an official source. I'm kind of glad that this discussion didn't happen on the KS page though.Anyways.... Moving on! Thanks again.
-
Happy you have your answer.
But dont go around saying silly things if you clearly did not look at all the sources. NQ did state it clearly.
Not intended to start an arguement but honestly...
Funny, it sounds like you are trying to start an argument. A simple like on his post would have sufficed.
Fortunately, I won't bite.
-
Look in the 1st update of the kickstarter :
Thank you! You are a gem.
You saved me from having to write a lengthy response that should never have been necessary anyway. I will put this link on the opening post.
-
It is stated in the definition of the words "access key" which is listed on every single package on kickstarter where that item applies. I don't know what else you want.
I got an "access key" to download World of Warcraft at one point. That didn't mean I could play it without a subscription. It just meant I could download the client/game for it.
Then I would like to point out that NQ and Nyzaltar are very busy with the kickstarter and all.
And if you took the time to look in the news section of the forum you would see that Nyzaltar often posts with answers for the community. Answering all the AMA questions take time. Look its not my job defending NQ but NQ has always been ready to answer questions. They have other things to do then sit on the forum all day long. You could have just contacted NQ if you do not trust the community.
NQ-Nyzaltar is the community manager for DU. It is his/her (I'm not sure which is correct) job to monitor the community (which includes the forum, last I checked) and provide responses on NQ's behalf. I assume he/she is being paid for that job. If not, he/she is being shafted by NQ.
So, no. I don't feel bad asking for a public response from the person dedicated to managing community questions about DU.
-
@Op because I want to show you that we are right. I contacted NQ in your place.
I appreciate that.
But I'd also like to point out that posting on the official NovaQuark forum for Dual Universe, asking for a response from NovaQuark IS contacting the developer.
-
Given all that, how would you design the actual inter-region communications? Do they all talk to eachother directly? Do they only talk to adjacent regions? How do you deal with network delay between regions if they're not geographically adjacent in real life?
Best I can think of is a thing where you do the octree division thing to figure out which clients will be in the same region (cell as NQ calls them), figure out which of their server locations is closest to the center of the clients' geographic locations (ping-wise, in a least squares sense), and assign a node from that cluster to them. Then the avatars closest to you in the game world would have, on average, as low a ping as possible. But things then get more complicated if you want to minimize the distances between the chosen geographic locations for nodes for adjacent regions... given a completely random geographic distribution of connected clients.
You seem to be much more informed on these sorts of problems in practice with typical solutions -- what would you propose?
I don't believe it would work to have them communicate directly. That'd be too much traffic, essentially bottlenecking it back down to the problem you get with a single machine. Instead, everything would need to go through some sort of event router service. The service would have a Level of Detail algorithm to intelligently route messages to valid regions (and players) on a scaled back frequency by distance and importance of the message. Adjacent regions to the source would get the messages on a semi-frequent basis, further regions would get even less frequent, and even further regions may not get them at all. You would also need to take into account that region can be really small in that router. So region size would also be a factor in messaging frequency.
The regions could be comparable to the old-style notion of a server shard, to a degree. A region knows about all the players in it, and all players know the region they are in. This is an in-game region, a chunk of the universe space. The region is also responsible for all the players, NPCs, and constructs in that chunk of space and performs all of the physics/actions/voxel manipulation within it. Because this is all processed on the server cluster, ping time in a region would be dependent on yours and their connection to the server, more so than to each other like you get in typical multiplayer games. Your typical game creates a lobby and may try to establish more of a peer-to-peer connection, which won't be possible in DU.
RL geographic regions would need to be handled differently. To minimize latency you would want to distribute the cluster globally, but this can create other problems, such as keeping copies of a region in sync across datacenters. I'm not sure what the best solution is there: distribute globally and minimize player latency, while increasing some server-side latency (more predictable than user latency) for synchronization or have exactly one copy of each region and players will have to deal with additional latency dependent on how far they are from the actual datacenter hosting that region. That is a difficult problem to solve and I don't have an answer yet.
Holy shit that's actually a thing? So at least a bare-bones version of this is technically feasible? That does make me... somewhat less nervous. Time to read up on them next, I suppose.
Yeah, it's actually a thing. I've been in a couple of their monthly playtest sessions (30 min each month). It works shockingly well. And the battles are absolutely insane. I love it. The server tech will likely prove somewhat similar to DUs in the end.
It's kind of painful reading the docs on that tech. It's so bloated with Microsoft-speak and jargon, to a degree that doesn't seem entirely necessary (but that's MS for ya I guess). Their introductory page seems like 10% technical explanation and examples and 90% marketing spiel.
To a degree, yes. But I am a Microsoft / .NET developer. So it is what I'm used to, and actually quick clear. Linux docs make me crazy. But yes, there is a lot of marketing in there. That was likely the trade-off Illyriad Games made with Microsoft. They got early access to Service Fabric and a lot of direct assistance from Microsoft in the architectural design/development. In exchange, they share some cross-marketing.
Illyriad has actually made a lot of code contributions to the .Net Core codebase, making huge leaps in performance such that Asp.Net Core can actually surpass Node.js now in raw throughput. I'm impressed by them.
-
But honestly if you ask the community a question you should be able to accept the answer or look for it yourself. Its on the forum and the KS page.
The fact of the matter is that no one has answered my actual question yet. I'm looking for a source. Proof. A concrete communication from NQ. Everyone is saying "it is known," but no one has provided a link to the source yet. I have been looking and cannot find it. No one else seems to be able yet either. I am only being told "oh, I read it somewhere, I'm sure of it." The only logical conclusion I can make thus far is that it hasn't been communicated, but is only hearsay. Hearsay doesn't hold up in court, and it doesn't for me either.
All I'd like is a reference to a public communication from NQ, stating it directly.
Can we just buy quanta already?
in The Gameplay Mechanics Assembly
Posted
The balance of the game is focused on people with 8-20 hours a day to play the game, not casual players. So, your best option at this point is to join an active organization that can provide you with resources for designing things. Going solo is not really an option for casual players.
Unfortunately, this is by design.