JayleBreak

If you are going to do a wipe prior to release then do it right: Grandfather all those who have been subscribed to Beta for 3 months or more into the alpha program at a level commensurate the length of time they subscribed (i.e. give them DACs) Give everyone eligible for DACs or who preorders the release a starting pool of talent points (e.g. 30days worth of training). Preserve blueprints. Note: in practice most are obsolete or require a lot (months) of resources & industry development before they can be used. FIX the ECONOMY! A wipe will NOT do that by itself. I suggest: Have all marketplaces on a given planet or moon reference the same pool of buy/sale orders. Sale orders can be created at any marketplace like today. Buy orders can be fullfilled anywhere on the planet (no flying back and forth just to get an item which can be crafted locally faster). Perhaps a new kind of dispenser could be created for use in static constructs.

You should introduce players to the flashlight early on. If they land on a spot at night, or use the VR station to a location at night Its hard to see. Also, its nice to emphasise the loss of inventory on death or exiting VR, but you should qualify it by excluding Tools and Data Files (types in the drop down). The final step of clicking on the POA Manager screen won't work if a tool is selected, which is likely the case if the last action was to fuel up your speeder. And that will be frustrating to someone who hasn't experienced it a thousand times

They never said what the maximum time is - they should have. 18 hours is the minimum time (its in your quote from the devblog) and they didn't say what determined the actual time which would also be nice to know.

There is a lot of Lua code out there that is based on the motion of space ships following a well defined physics model and also using the Lua API that supplies the current velocity, rest mass, and acceleration (e.g. thrust, gravity). Will the new physics model details be published? Is there any change to the way ships behave in the atmosphere?

People seem to be ignoring this response. Let me say that adjustors are intended to produce TORQUE without producing linear FORCE (thrust). This makes it much easier to to build ships that can point in any direction without inducing drift. I personally like the fact that DU uses physical laws instead of video game physics when possible.

I like what I saw in the video (in particular the absence of the actual tool from the field of view). I'm unsure how noticeable the loss in precision will be (no doubt there will be cases where it is noticable). One cautionary note. Some time ago I created a floor tile pattern with thin voxel "grout" lines separating the tiles (created using the old voxel smooth tool so I can't give an actual size - maybe 1/32?). It looked perfect until the vertex server was introduced. Everything was (and is) still fine in build mode but on exit the floor was (and still is) a total mess. The grout lines were distorted in some places and missing in others. Any chance the new grid will be treated better by the vertex server?

Logging was/is CRITICAL to my development of an enhanced flight script. It allowed gathering information essential to understanding how physics in DU work (e.g. air density vs altitude, engine thrust vs. air density, the coefficient of drag etc.). It permitted me to identify (and report) BUGS. E.g. the time when the API (correctly) reported the construct mass sans nanopack mass, but the physics engine was including the nanopack content mass (which caused the ship to crash I might add). So to maintain and improve the flight script I log once a second vital flight information (think of it as my BLACK BOX). Removing this capability is unconscionable, as will become clear as time (and code changes) will prove.

Cloud storage systems have limits based on what you pay. DU has a limit (5 Headquarter territories). Cloud storage gives you more if you pay more. DU lets you have more if you play more. Now if you stop paying things change. In DU at least, I believe your Sanctuary contents will be preserved (but not necessarily the location itself).

I'm pretty sure that was in the context of a game expected to have 10's of thousands of active players. Not the handful of players who think they should be able to build a megalopolis by themselves (with an alt or 2 and maybe a friend) which has to be effectively subsidized by a relatively small player community. NQ has to make this game profitable, and it seems they have a business plan (finally!) based on a realistic view of the number of players they can expect to have. It consists of revenue increases (raise the subscription price) and cost cutting (reduce server and network resource usage - still in progress). The removal of the legacy mining system in favour of the mining unit, and territory taxes are clearly motivated by the need to cut costs. The mining unit change eliminates a whole slew of direct costs. The taxes do not, but do have secondary effects on costs associated with resources that are reserved by players, but unused (especially by inactive players).

Ahhh.. localized Space Jelly then?

Sounds like you want to return to the "Borg cube" meta.

First, to recap feedback in an earlier post on this issue, complexity is a means to limit server load related to voxel storage. It would be nice to know a little more about this. Is it a building cost or the cost of loading in a construct (i.e. related to the mesh server). But either way, the current measure should just indicate where a "hotspot" is to be found in a construct. If there is any move towards enforcing the limitation (it is not now) it should be a construct limit.

You haven't told me anything I couldn't have (and in fact did) figure out for myself. Can you describe the parameters affecting the algorithm determining complexity measure? The number of vertices, the number vertices with an empty neighbour (or 2 or 3) etc?

Why was the chunk size set to 8 meters given that the smallest construct that a server deals with is 16 meters? As it is now, builders have to consider where chunk boundaries are so the complexity (whatever that is) can be shared across chunks.

Thanks for shedding some light on this black box constraint that has been snuck in. What is probably being reported is some abstract measure such as the number of iterations over a block of code divided by some selected threshold. I imagine it would be hard to put that into guidance on what is ok and what should be avoided. I'm curious if the market buildings could be built now within these constraints, or using the vertex editor under development (the voxel "grout" lines between wall/floor tiles look to be 1/16th wide).

Ok, If Peter doesn't actually trust Paul, then he should deploy the construct himself and give Peter the limited rights he needs on that. If he does trust Paul or doesn't care if he does what you are concerned about everything should be fine.

Well, I reviewed the discord transcript. In 35 minutes not a whole lot was explained. So it is perhaps not surprising that my (and other peoples) questions about the voxel complexity restriction was not covered. I really think the developers know this is going to piss off builders. The impression given when released was that it was really a concern for those who do voxelmancy. Because some (many) voxel boards might be unusable when the restriction was enforced, but that wouldn't happen until the vertex editor was ready. But in my experience, with normal building techniques (i.e. the Deploy and Copy & Paste voxel tools) you can exceed the complexity limit, and I mentioned that in my question (and in a ticket I submitted too). In the build I had the issue with, the design was first outlined using Blender, then exported so the projector element could provide the outline for the build, then after progressing well into filling out the outline with voxels - I get this complaint that I would NEVER have anticipated - even today knowing there are limits. The failure here, is this Q&A would have been a good place to provide guidance on how we can in the planning phases reduce the likelyhood of this happening. And worse, no indication that any information on how this feature defines complexity is forthcoming.

Don't over estimate the value of retaining BPs to people. First, placing a static construct BP on a different terrain then what it was originally built on is usually ... unsatisfying. Second, the constructs that took a long time to build probably require multi XL containers worth of resources (meganodes [which have gone away] of ores and industry [with skills] to process them ). Also, those that require advance elements or rare ores that may not be available for some time. As a consequence, third, there are those that will be (or already are) obsolete by time they can be used due to game changes just prior to or even after release (weapon rebalancing or ... brakes anyone?).

This was all about reducing server, and network load (I think local caching as well but that doesn't cost NQ anything). Going from 10s of thousands (and growing) of territories with extensive mining tunnels to a small number (controlled by NQ) of asteroids is a big cost saving win. In my opinion, JC showed his inexperience by not working the numbers that would have shown this was going to be a problem long ago. The Demeter mining system requires very little state per mined territory (the number which is limited by the calibration charges each player can have in conjunction with a tax system that gives incentive to claim territories that are only actively mined).

You should mention that HQ territories provide a tax-free bonus to adjacent territories.

No what it does and what its principle reason for being developed (yes some people were asking for something like this but that had nothing to do with why this feature was introduced) was to reduce the recurring operational cost of the game to make it more likely that the lights can be kept on. And for those who are about to respond that the lights should be turned off - go play another game, I won't miss you - I promise.

Strange the atlas shows Sinned as having: ores = { {"Limestone","Calcaire","Kalkstein"}, {"Coal","Charbon","Kohle"}, {"Hematite","Hématite","Hämatit"}, {"Bauxite","Bauxite","Bauxit"}, {"Quartz","Quartz","Quarz"}, {"Acanthite","Acanthite","Akanthit"}, {"Cryolite","Cryolite","Kryolith"} }, Oh I get it. It has the ores but in just low volumes. As I said elsewhere. DU is a space flight game. You don't find everything your need in one place, so you fly somewhere else and trade for it.

I've done that a few times and it sucks which is why I never had a base there until I got a warp shuttle (48kL of cargo) and an advanced mining unit to give me a constant supply of Petalite to take to Alioth. Yes, it takes a little while to get the cash to buy these things but until now I've had little reason to spend what I collected almost here and there.

Yes, this is a problem that should be fixed. In another thread I suggested that Sanctuary should have 60 markets so that no territory is more than 30km from a market, all markets be reachable via teleport in at most two hops, and it should be the home of the Ark so you would respawn there. Of course running 30km wouldn't be fun either, which is another problem NQ should address by making the starter ships "compactible" so you can keep it in your inventory after you no longer need it as a rescue ship (they aren't lost on respawn). RIght now ask for a lift and see if your friends will give you permission to respawn at their base (you say they are close to your base) until you can get a resurrection node on your tile. Also you should research the closest market that has shuttle service to Alioth and remember the district.

I guess NQ believes that this is a space game, so people will want to travel through space. So the figured a good reason to travel in space is to haul the ore you need (on say Jago) from another planet (say Alioth). And since your going to Alioth anyway why not take the ore that can't be found their (like Petalite) with you and sell it (so you can buy that load of Coal you are missing so). NQ can be so clueless at times huh?