Jump to content

Ater Omen

Alpha Tester
  • Posts

    148
  • Joined

  • Last visited

Posts posted by Ater Omen

  1. On 10/7/2022 at 7:37 PM, Atmosph3rik said:

    I always assumed that the 2km limit was referring to parking AGG ships.  But the wording is pretty vague.

     

    I don't think it is that vague as this rule applies to screens (ads) which were not intended to be displayed on a AAG ship standing 1km above ground (this would be a pretty bad ad). Maybe they didn't know that a tile radius is about 500m, but even that feels impossible to me...

    The only reason I find is that they wanted to forbid AAG ships to park at less than 2km height and forbid people placing ads on the parking. This ended up with this poor wording for both screens rule and airspace rule.

     

    On 10/7/2022 at 7:37 PM, Atmosph3rik said:

    It's true that the markets in the purple zone on Alioth will always have a clear flight path on one side.  But there are a lot of other markets that could eventually have an entire city built around them.  And it would probably be a good idea to decide how to handle this now, rather than later.

     

    Appart the drama about the market 12, I hope NQ understands that this is the biggest concern now : the current (clarified) rules allow griefing on every markets, and blocking missions running, as players could block every angles of the markets. This is not about "just avoid the building and turn right", this is about game stability and griefing prevention. As you said, better sooner than later, I wouldn't trust the good will of the players, always expect the worst.


    note: all of this is obsolete if NQ considers that having a ship that can VTOL from space to ground with only airbrakes is a fair mechanic. I hope not.

     

    edit: as there is a 2km range for mission delivery, there is no problem on that part.

  2. On 5/14/2021 at 2:55 PM, JayleBreak said:

    Why do you think DU doesn't use the GPU in its voxel engine? I seem to recall a dev blog from a year ago that indicated that it does, but that devblog seems to be no longer available. I did find this link which supports my recollection of GPU use: https://www.mmorpg.com/news/dual-universe-dev-blog-looks-at-tech-optimization-2000117365

    A copy of the dev blog without the images : https://fasrtraveler696.weebly.com/blog/dual-universe-trailers

     

    Quote

    GPU culling
    Dual Universe features highly-detailed environments, filled with non-interactive items we call ‘decors’. These include things like grass, trees, small rocks, and more. The engine we use for the game, Unigine, calculates the geometry of these items—usually in the tens of thousands at any given time—using the computer’s CPU, and decides which are more important. For example, items that are behind the player or less visible (i.e. somewhere in the far-off background) will not be rendered. This is particularly important in more dense environments, such as forests. This process is known as ‘culling’, and our team of developers have coded the engine to utilize the computer’s GPU to do these calculations instead of the CPU. Considering it’s already responsible for rendering these decors, this will significantly improve how fast these calculations are produced. What this means for the gamer is improved framerates and more detailed environments.

     

    edit:

    NQ uses Unigine to process the voxels procedurally generated, there is no bigger dataset for bigger planet, at least for the core terrain.

    The additionnal data for voxels are all additions that NQ did on top of the core generation (here is a video about their editor), and all players modifications to the terrain. Add to that all the constructs with elements. All of that is stored on the RAM, the more you have the more detailed the world is.

    To faster this process, the game client stores data locally in a cache folder. It checks for deletions or additions of the voxels with the server and avoid redownloading every voxels data for the place where the player is.

    As DU is not a single player game, all of this data must be synchronized between players, but not only voxels. All positions and orientations of constructs, all elements states (broken elements, lights, engines, force fields, etc), must be known to be correctly displayed and in sync with each player.

    The CPU generates optimized meshes with the desired LOD for the terrain and constructs, then the relevent data is sent to the GPU to display everything. As said above, the culling is done on the GPU instead of the CPU.

     

    I might be not right on all aspects of the game, but at the end, it needs so much hardware to work decently that I'm concerned by the targeted player base. Not everyone can run this game decently. Add to that the niche game design, at a time where fortnite and short game sessions and fast consumption of games dominate the gaming. But the potential of DU is immence, so believe in it :D

     

    To speak of NQ as a compagny where not every employees are devs, I wouldn't compare a prototype voxel engine (as good as it is) or other voxel experiments to a functionning (as far as it is) multiplayer game, with an immence single shard world and all of its new techs (client and server).

  3. Just a small precision about multiple accounts: the benefit is not to get multiplied rewards, it "only" allows for multiples missions at the same time. The player still has to carry all the packages, and need the right ship to do so, and expose himself to a more risky life outside of the safe zone.

    In the current context where this is the only new mechanic to generate money, this is powerful and is the best advantage one player can have.

    Like in other mmorpg, having multiple accounts is often a massive advantage, so we could say it's a form of P2W as the game has too few gameplay loops, and this one beeing the most rewarding (is it?).

     

    But I don't think it is that overpowered, mechanically speaking. In a world where DU is massively played, with a big economy and player made missions are legions, one player should be able to run enough of these missions to fill entirely his hauling ship and make aphelia's missions obsolete (think of EVE Red Frog corp).

    Is it really possible to make Aphelia's missions absolete? it all depends of the reward itself and the game economy.

    We're not yet in this wonderful world of course...

  4. For the moment, the district market 6 is the most active one, making this place a black hole for low configs, and generally a bad shopping experience for a lot of players. I don't think regional trading would be a thing when keeping different district markets so close together.

    Unifying all of the disctricts markets by having a single hub accessible from the 10 current places would spread parked ships across them, it would allow all players to have a decent experience when shopping.

    The only advantage I can think of for the current setup is for ads,  having only one place to cover is easier than 10.

    I'm not a trader so if you see some pros for keeping them as is, share it.

     

  5. What I imagine with this is that an L core with 1 voxel of the best honeycomb gets max shield, depending of the amount it can be too much for small sized ships. I would suggest to also cap the amount of shield depending of the total mass or amount of the ships elements, big ships gets more shield.

     

    If NQ is going to add shields, it will probably be related to energy managment (resistances, recharge rate, etc).

  6. 7 minutes ago, blazemonger said:

    Only the creator of a construct can do that afaik

    Yea but how?

    7 minutes ago, AlexRingess said:

    Yes, deploying the construct again from scratch from the blueprint, which means hours/days of grinding to get enough money to buy the elements. Or, as Blazemonger said, asking to the construct's creator to change drm rights.

    The construct was not made from a blueprint, all constructs are now DRM protected.

  7. 35 minutes ago, blazemonger said:

     

    Nah.. that would mean NQ would have to do more than run a basic script. Now anyone you gave access to your constructs (such as alts) no longer can edit any control elements.. makes perfect sense clearly.. All the ships you gave to org members.. They now all have to get back to you with it to have RDMS released to even change the auto config on their ship's control chair..

     

    Why should NQ consider these situations.. how often would they occur.. can't be that often right /s

    Yea, I can't edit but still have access indeed. So, is there a way to remove or add DRM protection on deployed constructs? 

  8. 42 minutes ago, ManfredSideous said:

    Next critique is destructible elements. For PVP this is an awesome change for non-pvp not so much. My suggestion is for non-pvp aka collision is that collision cannot break an element ( make it red) only damage it ( make it yellow). ITT several players have illustrated that due to bugs , things not loading or server / client issues desynch etc leads to ship crashes or collisions.  So I would highly encourage you with a rethink on non-pvp element damage or you will have a large part of your customers gnashing teeth.

     

    In closing I just want to say that in a Sandbox MMO destruction is the seed of life. I can go on to ad nauseum of the hows and whys justifying and proving my point.  However someone did a much job than me in a much better way.   Let me introduce you to Jean-Baptiste Emmanuel Zorg from Zorg industries in the cult classic Fifth Element.   Enjoy the clip!

    As you said, destruction is the seed of life. Counterparts bring challenges, objectives, basically game balance and gameplays. Why remove this? For player who don't want to leave their confort zone?  When a game becomes too easy, people become bored and leave, without realizing their fears and complains led them here. For bugs? Game balance should not be designed around bugs. Should NQ make a soft transition for that?

  9. 2 minutes ago, kulkija said:

    This destruction principle forces DU economy to "Linear economy model"

    Linear economy is killing our planet IRL

     

    Mankind must go to Circular economy to survive.

     

    I think DU must follow this principle and allow full Circular economy.

     

    References:

    https://en.wikipedia.org/wiki/Circular_economy

    https://medium.com/thebeammagazine/redesigning-the-economy-from-linear-to-circular-and-from-me-to-we-95e418fd0193

    https://www.ellenmacarthurfoundation.org/explore/the-circular-economy-in-detail

    https://kenniskaarten.hetgroenebrein.nl/en/knowledge-map-circular-economy/how-is-a-circular-economy-different-from-a-linear-economy/

    In a finite world, as DU is right now, yes. Will DU stay as finite as now?

  10. 2 hours ago, blazemonger said:

    How will container destruction work in relation to hubs?

    What if the hub is intact but all containers destroyed?

    Same as today I think, we can't remove the element or remove links as long as it will result in an overflow of the hub.

     

    2 hours ago, blazemonger said:

    Frankly, if a destroyed container is replaced in a hub configuration, should that not lead to loss of inventory?

    If a hub is intact but containers destroyed, should that not mean all inventory is lost?

    How I see it is that technically the "destroyed" elements are not destroyed, it is only a state indicating they are "broken and can't be repaired" so we can imagine that the content is intact. If it is the case, I just hope they handled well the transfer of the content and links when replacing a broken container/hub.

     

    If not, there are multiple scenarios where destruction of the containers would be problematic for the distribution of the content in the remaining containers:

    - when an item is too big : like a Territory Unit on a 5 XS containers hub, does it get lost?

    - when the entire content is too big : how to choose which items get lost?

    edit: talents bring the same problem, from which player are they applied?

     

    At the end, should the content be lost? If the container/hub are technically really destroyed (ie totally disappeared) yes, but apart the previous problem,  we need a way to know an element has been destroyed, hence this mechanism. If it wasn't here, our ships would slowly decompose without knowing what elements are missing, repair unit could be handy there but maybe too hard for new players just starting.

  11. Regarding this announcement: 

    this particular scenario:

    Quote

    Some examples of when to ask for a port (approved scenarios):

    • if you’re stuck in an Aphelia construct
    • if you’re trapped in any other player-owned tile (unable to dig)
    • if you’re unable to get past the loading screen upon logging in

    and this future feature:

    bagOnDeath.png.7d774b82fd48bc85b4b5f9e299664acb.png

    Will the floating container stay forever?

    Will a player "killed" by force-respawn leave a floating container?

     

    Depending on this, players will probably build castle moats as trap holes around their bases/tiles. What if everybody does that around the districts?

    If beeing traped is an approved scenario for demanding NQ's help, should setting up such traps be forbidden by the rules?

    Is it bad to play this card?

    trapHole.png.cc2cd3cc75d489a83c8e90986f45e688.png

     

    note: this is also valid for trap constructs with closing doors and detectors for example, should it be considered as griefing?

  12. If the creator gives "Build Construct" right, what happen to a Control Unit if it is removed from the construct, does it keep the DRM flag and all the dynamic properties?

    If yes and if I understood correctly, this would allow us to sell protected Control Units.

    If no, will it be implemented?

     

    Also, a suggestion: currently the action "edit lua parameters" for a Control Unit is bound to the right "edit element", I think it would be better to bind it to the right "Use Element" (or create a dedicated new right) to let the new owner customize the Control Unit without gaining access to its lua code.

×
×
  • Create New...