And yes capacitor tracking in pvp combat is another thing server should handle, I would suggest to separate pvp combat from other servers, keep it separate or you will lag non-pvp stuff too, however as I stated, this is not a game focused on pvp so they are likely to do anything about cheaters other than anticheat code that usually is not enough to prevent cheating
Servers cant keep up?
- Thread starter BluStar
- Start date
OP: I've had a few connection errors in my ED time however lately the Internet itself has been getting worse. Sometimes going to simple websites can take ages. I'm with Virgin Media and I'm on 100Mb broadband I've been on at them about it and they say it's a fair use policy that in the evening it's more busy.
Sometimes in the evening I get 56k v90 speeds.
Sometimes in the evening I get 56k v90 speeds.
Give a space cookie to this man!
Sorry for the delay, I went off for an Armored Warfare session and then bed, and this will be a bit of a TLDR as I'm headed off for a bit, I'll do the quick and dirty now -
AWS does two specific services well - Big data, and big processing. Big processing is where you've got something that needs a lot of processing power over an extended period of time and the system can hunker down and get on with it, things like long term simulations (Financial modelling is a really good example). Big data is where you've got something that has a lot of information where you need to drill down through that data and pull information out of it and get specific bits out to examine and analyse, you'll see a lot of big data projects where analytics are a thing.
What AWS really does NOT do well is "realtime" work. AWS is not designed to handle interactive loads, now remember when I mentioned big processing? That's where you basically spin up a VM and leave it to cook for a while, that's great, AWS can do that with no problems at all. When you've got very spiky, uneven loads, AWS has real problems dealing with it, because ultimately VM's are only as good as the weakest link in the chain.
AWS is this big fuzzy cloud of lots of hardware distributed all over the world, when you have a very interactive and realtime load, you want that VM to be run on a bunch of hardware that's pretty much *in the same building* as the VM, that rarely happens when AWS is involved, so there's delays, usually milliseconds, but milliseconds is enough, milliseconds add up fast when dealing with real time loads. When dealing with thousands and tens of thousands of people with real time loads, you multiply those milliseconds, you don't add them, it's an exponential problem. Which is why if you're dealing with an interactive issue in AWS you have to assume a factor of 10x whatever it is you're planning for because otherwise the moment it starts being put under load, the milliseconds become noticeable.
That's why AWS is a farm tractor. You don't use it for WRC rallies.
Oddly enough the mission boards last night were loading up really quickly for me. 5 seconds or so compared to the usual 15 or so.
same of you may find this interesting...
https://youtu.be/EvJPyjmfdz0
Edit: already linked by Mark on page 2... which I didn't read very well, apologies!
https://youtu.be/EvJPyjmfdz0
Edit: already linked by Mark on page 2... which I didn't read very well, apologies!
Last edited:
Already watched it, it's interesting, and it's a novel approach, but like EA, the problem with novel approaches is that when you run into reality, novel approaches tend to fall flat on their faces.
This seems considerably more of a problem when dropping into a station/planetary port instance. Dropping out onto uninhabited planets - even ones with a few other players about - is often seamless for me.
Figures. Ports have huge 3D models being transferred to client. Has anyone sniffed the wire to find the number of Gb?
- - - - - Additional Content Posted / Auto Merge - - - - -
And then that's been fact checked on the official sub-reddit?
Sorry to be mean, but there is no official wikia. The ED wikia is just part of the fan echo chamber...
Uh? Then I can't understand why it took so long to find that crashed alien ship, when it was sitting in PC memory of every player all the time!
How does that prove no model transfer?
It doesn't necessarily, but the fact that no online game ever does it save those that allow for custom player generated models to be visible to other players should. UT2k4 falls into that category. CS falls into that category. ED doesn't fall into a player models allowed category even, so why would it support them being shared from a central hub?
Things that are known to be client side :
Art assets (so that means all the graphical stuff is hosted locally). Combat data (so when you fight with someone - that's run locally). Movement data (so when you fly your imaginary spaceship - that's run locally). Mission timers (whilst the missions THEMSELVES are arbitraged by the server, the timer can be managed by a simple date() script locally).
Things that are pulled from the server :
Universe location data (so when you FSD or SC to a location and then drop into "real space", that pause you get is the server being polled for "Where exactly am I?" and the server providing a response.)
Anything connected to credits (that goes through the transaction server and a few other databases)
Anything connected to player assets
Anything connected to the player themselves (such as ranking, bounties and the like)
It should be noted that player information is deemed "Stateless" insomuch as the player's information is only seen as a present "Snapshot", there's no real history behind it, nor is there a massive logfile with all the information to hand, with the exception of information Frontier deems useful for cheat detection. There's no "memory" that makes the Player pawn persistent, which is why things like ship summon needs to be instant, because otherwise you'd be turning a stateless system into a stateful one, and that imposes a lot of extra hassle.
It works, sortof, but there's issues, particularly with the fact that a lot of the stuff being run by the AWS really isn't suited FOR the AWS in the first place, but as I've said, that's what happens when you try making a novel solution, it works on paper, but in reality? Face - meet floor.
Art assets (so that means all the graphical stuff is hosted locally). Combat data (so when you fight with someone - that's run locally). Movement data (so when you fly your imaginary spaceship - that's run locally). Mission timers (whilst the missions THEMSELVES are arbitraged by the server, the timer can be managed by a simple date() script locally).
Things that are pulled from the server :
Universe location data (so when you FSD or SC to a location and then drop into "real space", that pause you get is the server being polled for "Where exactly am I?" and the server providing a response.)
Anything connected to credits (that goes through the transaction server and a few other databases)
Anything connected to player assets
Anything connected to the player themselves (such as ranking, bounties and the like)
It should be noted that player information is deemed "Stateless" insomuch as the player's information is only seen as a present "Snapshot", there's no real history behind it, nor is there a massive logfile with all the information to hand, with the exception of information Frontier deems useful for cheat detection. There's no "memory" that makes the Player pawn persistent, which is why things like ship summon needs to be instant, because otherwise you'd be turning a stateless system into a stateful one, and that imposes a lot of extra hassle.
It works, sortof, but there's issues, particularly with the fact that a lot of the stuff being run by the AWS really isn't suited FOR the AWS in the first place, but as I've said, that's what happens when you try making a novel solution, it works on paper, but in reality? Face - meet floor.
You could bug report it but general network performance is overall diminished as far as I have noticed.
Ctrl b ingame can show some network data.
i have around a 50% chance each time of being able to connect to FD whenever i want to play - either the game will run, or the launcher will say it couldn't connect, or if that works then i'll be at the menu with the launch options greyed out
nowadays i just open FD's support page. if that opens, i can launch and play the game. if i get a timeout error, i go and do something else.
50% is pathetic. i realise there's some duff nodes between the UK and Australia, but still... a 50% success rate is beyond dismal.
nowadays i just open FD's support page. if that opens, i can launch and play the game. if i get a timeout error, i go and do something else.
50% is pathetic. i realise there's some duff nodes between the UK and Australia, but still... a 50% success rate is beyond dismal.
I would guess that the issue is having to perform relatively slow lookups of BGS databases and similar to find out which ships to spawn around the station, set up the commodity market, etc.
Instancing away from the bubble actually seems to have improved a lot - we had 40 players in the same surface instance last night (at Dumbbell Nebula, so no possibility of NPCs) without serious trouble, when on previous expeditions anything over 20 at the surface was horrendously unstable and crashed clients all over the place if you could build one that big in the first place. (So, credit where due: thanks FDev, it was great fun, and good luck with doing the same in the bubble.)
In reality, a multiplayer first person shooter with 200 people per (quite large) zone, fully server authoritative (no p2p), bullet physics and all, can run well on AWS.