Jump to content

Anyone else STUNNED space cores aren't excluded from the core cap?


 Share

Recommended Posts

I mean, I thought it was blindingly obvious: space stations might be big, but individual stations are rarely close together (meaning only the player building the station can impact their own load time), there's no terrain to render, and generally less traffic around them so system o/h is far lower than ground constructs - plus incentivising players to move into space would drive more traffic necessary to drive progression and at a minimum one-step closer to PvP.

 

Sometimes I wonder who's calling the shots at NQ and what on Alioth they're thinking (or not thinking.)

 

[EDIT: Please also let us convert statics to space and fix BP alignment, so we can just BP our ground bases and move them onto a deck in space.]

Edited by Megabosslord
Link to comment
Share on other sites

Nope. This is no defense of NQ's decision, but I don't think it's about performance and load time. The issue is with data storage in the cloud and how NQ isn't earning enough revenue to cover the costs of the game. Every construct you own has information about it that they need to maintain somewhere. Reducing the number of player-owned constructs means a cap on the size of the databases - that, they can future plan for. Static, dynamic, or space makes no difference - they exist, and they cost NQ money. Seems like this would be something to plan for in the very beginning. They should have decided how much data per player is sustainable and enacted limits. Doing it this late in the game means someone's estimate was waaay off, they've lost the minimum critical mass of subs to cover costs, or costs have risen so much since initial planning (they've been at it for like a decade) that the current format is unsustainable.

 

TL;DR - doesn't matter the type of core, NQ needs you to have less of them to save money

Link to comment
Share on other sites

19 hours ago, Megabosslord said:

Please also let us convert statics to space and fix BP alignment, so we can just BP our ground bases and move them onto a deck in space.]

I had suggested this a very long time ago, in the meantime my basis has arrived in space via copy-paste - that was a feat of strength. Due to the new core limit, I now have to delete some of the cores again. 

Would generally be in favour of a selection of BP, in which form you want to summon it (static-Space-Dynamic).

But it would also make sense to be able to dismantle an entire core via "collect all" and disassemble it into the inventory. It takes an enormous amount of time to dismantle 100 cores, for example, just because the core limit has been changed again.

Link to comment
Share on other sites

On 1/29/2022 at 2:31 AM, PsychoSlaughter said:

Nope. This is no defense of NQ's decision, but I don't think it's about performance and load time. The issue is with data storage in the cloud and how NQ isn't earning enough revenue to cover the costs of the game. Every construct you own has information about it that they need to maintain somewhere. Reducing the number of player-owned constructs means a cap on the size of the databases - that, they can future plan for. Static, dynamic, or space makes no difference - they exist, and they cost NQ money. Seems like this would be something to plan for in the very beginning. They should have decided how much data per player is sustainable and enacted limits. Doing it this late in the game means someone's estimate was waaay off, they've lost the minimum critical mass of subs to cover costs, or costs have risen so much since initial planning (they've been at it for like a decade) that the current format is unsustainable.

 

TL;DR - doesn't matter the type of core, NQ needs you to have less of them to save money

Hey PS! Hmm… It is possible you’re right, that it’s not compute cost, but that like a lot of recent start-ups they assumed storage and transfer cost would fall over time (they haven’t, not by a lot - and transfer less that disc. I’ve been running large dev projects for ~25 yrs.) What tells me it has to be compute is how quickly Deckard dismissed the observation that XL cores would render more efficiently than multiple L cores. (XL cores would benefit disc and DL vol even more.) It also makes no sense that they gave all historic players 5 HQs even if unsubbed and only after an outcry added it back to Panacea. (Removing abandoned constructs should benefit compute but also disc AND DL - assuming there’s nothing whacky going on in DB structure or metadata on null voxels.) Do you have a source my good friend?

 

[EDIT: I still think they’re sitting on a potential goldmine with this game if they can not jag it up. Not just the space travel zeitgeist being hot, but the ~$1bn p/a spend demographic that has rolled thru Minecraft onto Roblox are soon going to be looking for a grown-up version of same. I hope they have someone sharp on VC.]

Edited by Megabosslord
Link to comment
Share on other sites

I do think they need to somehow include the download amount in their limits. 
 

it’s likely the bandwidth rather than the storage of the construct data per se that’s causing mayhem.  
 

having a construct on MP6 that gets downloaded 100 times a day is obviously more impacting than a site that gets one new visitor a month even if the complexity of the constructs is the same. 

Link to comment
Share on other sites

On 1/31/2022 at 2:57 PM, Endstar said:

A core is core is a core

Think about out it, if you incentivise moving into space you avoid having to load terrain. And because space stations are further apart and scattered in 3 dims, you also don’t have the sequential loading of constructs as players travel across the surface of a planet. (Topography maximises data load by forcing things into a single plane.) The transfer cost of someone flying to a space station is a fraction of surface flight to a ground base. In space you can also enforce distance between bases. 

As for XL cores, NQ have said they’re coming - just not yet. The longer they leave it though, the more constructs are being built in less efficient L cores. The data volume is marginally lower for the same shape in one core compared to splitting that shape over multiple cores due to duplicate header info. But it’s the rendering where the big improvements are - reducing FPS drops using LOD.

The XL core - if it has double the dims of an L - needs to ‘cost’ (talents, cap, and build cost) 6-7x an L core, or provide some other benefit, like longer elevator jumps, since you want to incentivise using an XL over just using 8x Ls and some irregular shapes that would have used fewer Ls. A XXL (3x3 Ls) would be exponentially more efficient replacing 27x Ls and need to cost 20-25x an L.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...