Jump to content

JayleBreak

Alpha Tester
  • Posts

    366
  • Joined

  • Last visited

10 Followers

Profile Information

  • Location:
    East Coast USA
  • backer_title
    Contributor
  • Gender
    Male
  • Alpha
    Yes

Recent Profile Visitors

2725 profile views

JayleBreak's Achievements

  1. 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.
  2. 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
  3. 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.
  4. 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?
  5. 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.
  6. 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?
  7. 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.
  8. 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).
  9. 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).
  10. Sounds like you want to return to the "Borg cube" meta.
  11. 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.
  12. 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?
  13. 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.
×
×
  • Create New...