Zeddrick

Will the 'Element Stacking Exploit Fix' actually only prevent people from using the element stacking exploit? Because at the moment nearly all my ships complain and say they will be disabled due to this but none of them are using the element stacking exploit. I'm 100% behind stopping people from using the actual exploit but I'm not going to mess about moving elements 1 pixel to the left because there was a bug in the game when I built a ship (or someone decided to tweak the bounding box or whatever) and the stacking exploit detector is too stupid to tell the difference between that and an actual exploit. How hard is it to calculate the volume of overlap as a percentage of the element's volume and say 'things overlapping by < 5% are not stacked'. Or if it can't be limited only to the people who used the exploit and actually got some advantage from that, don't do it because if you break 50% of the ships in the game then IMO the cure is far worse than the problem you're fixing.

We'd have to wait and see how this actually looks, but it sounds like you might be able to make a small core hauler which, even though it accelerates more slowly than a PvP ship, has a higher top speed so provided you can survive long enough (shields/armor/etc) you can eventually escape because the bigger PvP ship can't keep up with you.

No, it's OK. There is a new PvP shiny thing. And all the PvP players will be 'Oooh, shiny thing over there' and go fight each other in a corner so you can go about your business without being attacked.

If only we had some sort of plan for the future of DU so we had some idea of what was coming next. Perhaps some sort of roadmap or something? We should suggest it to NQ ...

Nobody is *forced* to do this. There are plenty of alternatives including AFK mission running. Agreed it's bad design, but the OP asked for a version which takes less time and gives a smaller reward. There are other types of mission which take less time and give smaller rewards.

Even the warpable safezone missions have alternatives which take less time, and have less reward.

So you just want to complete them faster? That's it? If you want to make less money and avoid the risk of PvP there are safezone missions which take less time to complete and give you a lower proffit. What's wrong with those that means we need another option?

Yes please!

Eve just about gets away with 1 org per character by having 3 characters per subscription so you can be part of a multi-player org and still have your own personal service corp, etc. It also has far better support for transferring assets, etc. The need to have a personal org in DU (and yes, a lot of players 100% need this, particularly the ones who use multiple characters) would make it very difficult to have 1 org per character in DU. There's no reason there can't be a 'primary org' or whatever though which you could set to the multi-player corp.

Are you sure that isn't just because a lot of players have multiple accounts and made a personal org for them? By far the easiest way to manage multiple accounts is to make a personal org, put all of your characters in it and make them all legates. The voting gets annoying but once you get past that you just make all of your constructs owned by the org and all of your characters can access all of your constructs without needing to mess about with RDMS. Trying to do this without an org gets messy fast because you need to make RDMS policies in *every account* to give rights to all the other accounts, keep that up to date, remember to tag every construct you deploy, etc. Even within an org the need to tag everything and maintain the character lists in the various RDMS policies (because there aren't any definable 'groups') is far more hassle than just making all of your characters legates.

If someone doesn't want cores abandoned at random they can easily choose some cores and manually abandon them , right? You can do it right from the map interface without visiting the cores 5 minutes before the deadline. Why would it be a problem for orgs which can't be bothered to manage their core count by hand getting hit by random abandonment?

If I had to guess I'd say that all of this was estimated, but the estimates ended up being way off because the model was based on slow growth in player numbers and what actually happened was large numbers of players built stuff and then left the game, resulting in a continued cost without any income to match it. I also think that the result of repeated gaffes and large player exoduses is that only the more dedicated players who really like the game are left and that means that the average number of constructs per live player is more than they were expecting. Neither of these things would have been predictable with any particular level of precision. I imagine they just estimated the numbers and planned to use the beta process to fine-tune, which is what is now happening. The new approach of upping the limits to 200/account but only after a long skill train (based on their figures I estimate 6 months to get all 200) is an interesting compromise which I think is still part of the fine tuning. I think they'll see how many people actually do train the skills over time and max things out and how many people deconstruct unused ships/etc instead of doing the training then make more adjustments. It's the sensible thing to do.

People keep saying that, but 8 years ago you would have had absolutely no idea what the storage cost in AWS would be *now* for a given quantity of data. You also wouldn't know the speed and you might not even know which technologies you would need to access that much data, how it would scale, etc. You would also have had no idea how many constructs per user there might be, how they would cluster, how many meshes would get retrieved per minute, etc. In fact, even 4 years ago it would have been pretty tough to estimate that sort of thing. I'm fairly sure NQ have completely changed the storage system since the beta started from DynamoDB to something else so that would completely change the costs, for example. I would have thought that one of the things a company needs to do in *beta* is validate the cost model and adjust accordingly, which is what's happening here. I am a little worried about the amount of history which is disappearing when the old constructs from unsubbed players get deleted though. In a game where the players create the content for one another deleting player-made content is certainly a brave step!

Am not a huge fan of HPE. Haven't been involved with it for a few years but it was always the sort of organisation where you had a problem, tried to use HPE to solve it and then you had 2 problems. Or 3 or 4. Again, it depends on how available and flexible the hardware really is and what you need. Can they give you 2x as many nodes for 1 hour a day and only charge 5% extra for example?

Will partial talent point refunds be done for partially trained org construct management skills during the upgrade? So if I have Advanced Org Construct Management Specialization trained halfway to 5 will I get the 2 million TPs back for that?

That sounds like interesting emergent gameplay to me. There is counter-play possible because you can see a list of who donates which core counts and you can also hide your capacity by keeping unused and un-donated counts secret (or you can do it back to your enemy).

Obvious question which I'm surprised wasn't answered in the devblog. How long to the new talents take to train? Can we please get a list of the 6 talents (three personal and three organisational) and the length of time it will take to go from 0 to fully trained? This is a super-important detail, if for example, it takes 6 months to get the second one up to 5 then this is a complete non-starter but if I can train all 3 to full in a 3 month period then IMO this is a great compromise.

Again, it depends on how much flexibility you need here. Generally speaking you want all the servers in your cluster 'close' to each other -- meaning in the same datacenter. Otherwise the round-trip times on the interactions start to mean that you can't really get as much power as you think you're going to get. Generally speaking this means that if your usage is flat you could use something like self-host but if it's going to spike or scale (in two directions) you can't do that. Say you're DU, for example, and you do a big beta launch event. The servers start to creak and grind, people are queueing longer than normal. You scale up and all is well. Then you make a mistake with your 0.23 update (for example) and 80% of the players leave. If you were self-hosted you are now screwed because when you scaled up you probably bought servers on a 5 year loan, extended your switching capacity way beyond what you now need, signed a new 1-year deal with a hosting provider, bought new SAN shelves for storage that your ops people still haven't finished getting online or whatever. With AWS you just turn them off again. What that means is that you really want to start this stuff off in a public cloud with lots of cheaply available power and lots of pre-made solutions to some of your problems (like backup) and then just grow and focus on making a good game. Then later when it's stable and big enough that it's unlikely to have a sudden influx of players (or outflux when New World opens or whatever) you look to more static solutions and compare the price.

The problem with private clouds, though, is capacity and availability. Say you need 10T of RAM and >10,000 cores at peak but less than 1/10th of that for 70% of the time. Private clouds are unlikely to have that sort of kit sitting around waiting to go so it's not certain that you will be able to have that. With AWS they can just kill some spot instances and give you what you need right away. I once started a system with 40T RAM and got all the nodes I needed in under 2 minutes. It was definitely expensive but I had a system which would cost millions to buy and was paying 100s per hour for it. It depends how much flexibility you need really ...

I disagree again here. If there is a large quantity of idle servers then that's doing it wrong. You can spin up nodes surprisingly fast in AWS (well under a minute) and you should be able to predict when this is necessary. Also in games like this particular areas tend to be serviced by individual servers, so a large battle would typically all run on one server. That's how EvE works, for example. So really the number of servers in use at any given time would depend on how many people are logged in and that is definitely predictable with the time taken to launch new servers not being completely different than the time taken to log into the game in the first place. And even if the game does require idle servers, it will probably only require them for a few hours of the day and you *will* have enough notice to create them when the logins spike or when people start moving near to each other. Also there are some aspects of the game which would work with a CDN. Game updates for example. ALso I imagine there's a large amount of static data which gets updated with modifications. It certainly seems that when I get far away from ground I modified or when I go in with a surrogate the game starts with the original ground shape and then applies changes to that. This is all speculation of course, I'm just challenging the assumption that AWS is bad for a small company to be built up on. Having actually built one on AWS I found it to be perfect, letting us have access to the sort of technology we could never have had otherwise because we couldn't afford the large upfront investments and longterm financial commitments required to have those things. IMO AWS is perfect for small businesses and it's only when you get to the medium scale (1000s of people and a high 6 figure annual AWS bill) that you can start to think about doing better with hosting.

Completely disagree with your point about AWS. Having actually done this sort of thing in a small company and saved a massive amount of money with AWS over the hosted solution (as in the AWS bill after moving 200 servers was lower than the *power bill* for the hosted solution) I can tell you that AWS is not as expensive as it looks. Of course, as with anything, you can do it wrong and it can cost too much. But there are a lot of hidden costs with hosted solutions which you just don't have in AWS (including not needing to hire as many people). Done properly (which means not trying to make something which looks like a hosted solution in AWS) a lot of money could be saved here. One good example for an MMO is that the server load is unlikely to be constant. There will be times in the day/week when a lot of compute is needed and times when it isn't. With AWS you can scale up and down to accomodate that but with a hosted solution you usually need to buy what you need for peak capacity and have that run idle when not needed.

But surely you can see the problem with that? I have 25 slots to give. I give it to org A. I put 25 constructs into A. I take it away and give it to org B. I put 25 more constructs into B, and so on. Of course it could be that the constructs get frozen somehow (like they do when tokenized) instead of being abandoned. But then a lot of constructs like runways, landing pads, showrooms, etc would probably still work as intended when frozen.

This is a really good point actually. Despawning constructs in other places might technically be OK because nobody ever said they were safe, but this is exactly what sanctuary was for. I remember when it was introduced there was a video where JC explained that this was going to be a place where you could put your things and they would be safe until you came back into the game. Now there are two ways to lose your sanctuary constructs -- they can be owned by one character and parked on the tile belonging to another of your characters or they can be yours but your org now has too few slots to hold them, possibly *because you are unsubbed and so cannot put back the org construct talents and assign the slots to your org*. IMO this goes directly against what was said before, and some players may well have unsubscribed after moving everything to sanctuary based on the assurances given previously about that being a safe way to leave things.

I have more to say on the core limits (and on removing cores in general) but will think on it more first. In the meantime, why is there now an arbitrary distinction between 'personal' and 'org' cores? A lot of players now have multiple accounts and for those players personal cores are going to be a huge pain, so most probably create an org and put all their cores into that for convenience (make all your characters legates and never have to mess about with RDMS). I'm sure I'm not the only one doing this. For players with a personal org, the player-specific core slots seem a bit redundant. I certainly don't/won't use mine because it's too annoying to need to use a specific character for specific things. But I'm sure there is another category of player who has just one account and no personal org. For them the org-specific core slots are probably just as redundant and annoying to use. So why have we got two different pools of construct slots at all? Why not just have one set of skills for a character which says how many cores they can have, then they can donate some of those to orgs and whatever is left over is for the character's personal constructs. Perhaps use multiple skills and make it go higher. It could go up to 100 with a series of skills which have longer and longer training times so in order to actually get 100 constructs on a character you need to devote several months of training. That would act as a brake to stop *everyone* from having a lot of cores but those who really need them will train them. Also with this change I think it's naive to think that most orgs will get any slots from their members at all. Slots are going to be at a real premium and I imagine it will be possible to rent them out to other players for a monthly fee. Orgs will probably have to pay their players for slots ...

Of course I know this is the case. I can read and do basic arithmetic. If each player can donate up to 25 cores, but you'll be lucky to get more than 10 from most, then 1600 (or whatever it is) needs to be made up from approx 150 players. It's never going to be fewer than 1600/25, which is still 64 players. How about we stick to useful comments about the feature rather than commenting on other peoples comments without reading them properly eh? And NQ, can we have a 'dislike'/'Downvote' button here as well as the heart please so we can filter the fools out like you can on reddit?