Jump to content

Ater Omen

Alpha Tester
  • Posts

    148
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Ater Omen got a reaction from JayleBreak in Voxels, voxels everywhere..   
    A copy of the dev blog without the images : https://fasrtraveler696.weebly.com/blog/dual-universe-trailers
     
     
    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
     
    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).
  2. Like
    Ater Omen reacted to SpiceRub in The Arkship Offensive   
    I've had just about enough with DU, Naunet leaving is just another cannonball to NQ's face.

    And so, Statues of Naunet will be erected all over the Arkship circle.
    I'm reaching out to everyone with a tile touching the big purple arkship circle, or very close to it. Want access to a few key permissions on your tile:

    Deploy Core unit on construct
    Deploy dynamic core unit on territory
    Deploy Item
    Deploy Overlap building zone
    Deploy static core unit on territory 

    Set the perms for SpiceRub, and send me coords to the Territory in question.
     
    Statue in question, 2 L cores tall.




    Looking to put as many down as I can, will work to create a sparse circle around the Arkship and then continue to fill in the gaps.

    Before you ask, no I will not be giving out free copies of the statue.

    Will probably be able to finish this before the servers go down. ta x
     
  3. Like
    Ater Omen reacted to NQ-Naunet in Dev Blog: The New DRM System   
    Hello Noveans,
     
    With release 0.23, we have introduced a long-due system to protect and manage the intellectual property rights of construct creators. This is not just a variant of the existing . Rights and Duties Management System (RDMS), which is mainly in the hands of the owner of a construct. Instead, the Digital Rights Management (DRM) system is in the hands of the creator of a construct, who might be another entity than the current owner. Let’s have a look at how it works.
     
    Creators and DRM flags

    When a construct is created from scratch, that is, when someone deploys a core unit, whoever deploys this core unit becomes the construct creator. This can be an organization, if the deployment is done in the name of the organization. This notion is crucial because when interacting with a construct being the creator will give you certain privileges. 
     
    Note that if the creator is an organization, any legate of this organization will be considered as the creator. It’s a great way to share “creatorship” between several players and be more resilient about people not being in the game for whatever reason.
     
    There are four things you might want to protect as a creator when somebody else is going to buy/use one of your constructs (with the caveat that we may add more things in the future if needed):
     
    The creation of blueprints The copying of voxel structures out of the construct The edition of Lua code in Control Units The edition of HTML content in Screen Units  
    However, we wanted the creator to be able to select which protection to activate or not, to give them more control, and also to allow to make a distinction between Control Units/Screen Units that might have been added after the purchase of the original construct (and which should, obviously, not be subject to any protection). So, we needed flags on elements to be able to say yes/no regarding each of the above protection abilities. That’s the purpose of  the DRM (which is a commonly used acronym for copyright protection of digital assets in the real world).
     
    The DRM flag for blueprint and voxel copy protection is held by the Core Unit. Otherwise, each Control Unit and Screen Unit has its own flag.
    From there, the rule for accessibility of any of the above four actions is defined by: 1. Is the player performing the action the creator? If yes, authorization is granted, if no: 2. Is the DRM flag of the corresponding element activated? If yes, authorization is NOT granted, otherwise it is.
     
    Note: Historical constructs, created before the introduction of the notion of creator signature in construct (roughly around April 2020), do not have a creator. In this case, we chose to disable DRM entirely. Since there is no easy way to guess who was the creator (we can’t easily trace back the history of a construct, originating from several blueprints, etc.), we will leave it at that.

    Blueprint creation and DRM management
     
    How do you set the DRM flags? It is done automatically for you when you create a blueprint of the construct. By default, all DRM flags are set to “activated” on the Core Unit, all Screen Units, and all Control Units;  however, you have  a relatively hidden (because relatively dangerous) right-click menu option in “Construct/Advanced/Create Core Blueprint without right protection” that allows you to create a Core Blueprint that has no DRM flag activated, which means no protection at all. We will see below in the “use cases” section that this is not quite as useless as it sounds.
     

     
    It is important to understand that the flag configuration is held by the Core Blueprint. Any construct that will be spawned from blueprints originating from the Core Blueprint will inherit the flag configuration: either all activated or all deactivated.
     
    Once a construct has been created with such a blueprint (or even on the original construct if need be), the creator can still individually unflag any of the flagged elements (with the right-click menu “Advanced/Release DRM Protection”). Unflagging the Core Unit will release the DRM protection for blueprinting and voxel copying. It does not mean that anyone can now blueprint the construct, since now the owner (who is not necessarily the creator here) can use the usual RDMS restrictions on blueprint creation to define who can use this ability. In the same way, a DRM-free Control Unit is still subject to the RDMS as for who is allowed to edit the Lua inside it. But again, this is now a consideration for the owner, who is managing the RDMS, rather than the creator.
     

     
    Once unflagged, a Core/Control/Screen Unit cannot be re-flagged by the creator. So, be careful when using this, it cannot be reversed.
     
    Now, if the owner of a DRM protected construct decides to customize the construct and add some Control Units or Screen Units, these elements will be deployed without the DRM flag activated. In effect, it means that the owner will be free to edit them, as expected. There will be two types of Control/Screen Units in this construct then: those coming from the original DRM-protected blueprint, with their flag activated and therefore not editable, and those coming from the owner’s personal additions with no flag activated and full edition rights.

    Use cases

    Let’s be practical here and see some patterns of usage that we believe will be quite frequent.
     
    1) The ship designer: This player/org typically intends for their constructs to be sold and fully protected. A Core Blueprint will be created with full DRM activation, and constructs made from the Blueprint originating from this Core Blueprint will be ready for sale and fully DRM-protected.


     
    2) The org internal ships: Those ships are meant to be used by org members and should be created in the name of the org. A special blueprint without DRM would be issued to create ships for the org’s internal use. RDMS would play its role in managing internal org rights as usual.


     
    3) Voxel library designer: By definition, selling or simply sharing a voxel library construct would imply the creation of a blueprint without DRM, otherwise the voxel copying will not be possible.

    4) Special customer deal for a ship designer: It could be that the designer of a ship accepts to unlock some aspect of the DRM for a given customer. In this case, the creator will have to access the sold construct and operate on it to deactivate the flags wherever needed.

    Still to Come
     
    We are still missing some important features to fully cover the DRM mechanism. In particular:
     
    We need to improve the way to find out who is the creator of a construct and provide an easy way to contact them. (You can currently find this info in the “Construct Information” tab of the Build Helper, but it should be easier to find.) We need a way for a creator to be able to transfer their “creatorship” to another player/org. We may need a way to separate DRM protection for blueprint and for voxel copy. We may need a way to allow the creator to activate the DRM flag, not only to deactivate it. (This means the construct should remember what was an original Control/Screen Units in the list of elements of the construct.)  
    This will come in future updates. Until then, we hope you will enjoy this new addition to the game mechanics related to constructs and that, in particular, ship sellers will now be able to mass-produce and sell their creations without fear!

    Want to discuss this? Visit the thread linked below! ?
     
     
  4. Like
    Ater Omen reacted to NQ-Naunet in We've Heard You!   
    0.23 and What We Learned

    In reading through the reactions from our community regarding the recent 0.23 update, we’ve gained some valuable insights. 

    Before we talk about the changes we’ll make in our processes going forward, let’s get back to the fundamental reason behind the update itself. What we did in 0.23 is at the heart of the vision for a game where a society of players is interacting directly or indirectly with each other through an elaborate network of exchanges, cooperation, competition and markets.
     
    As it was, the current state of the game consisted mostly of isolated islands of players playing in almost full autonomy. A single-player game where players happened to share the same game world but with little interactions.
     
    It’s hard to imagine how the appeal could last for more than several months for most players once they feel they have “finished” the game. It is also a missed opportunity to try something of larger proportion, a society of players growing in a fully persistent virtual world. For this to work, you need more than isolated gameplay. Players need to have viable reasons to interact and need each other.
     
    In many single-player space games, you have ways to make money, and the game then offers you ways to convert this money into whatever you need in the game to progress, mostly via markets. This is the state in which we should end up for Dual Universe once all the necessary ingredients are in place, You get into the game, you farm a bit of money in fun ways, and you buy more and more powerful ships, equipment, weapons, etc., to help your character grow. The difference is that here, the ships or equipment you buy have been made by other players, instead of the game company. On the surface and during the first hours of gameplay, to a new player it would look similar to any of those other space games, but it would in fact reveal itself to be much deeper once you spend a bit of time in the game. Everything you would do would be part of another player’s or organization’s plan, everything would have a meaning. And soon you would realize that you too could be part of the content creation and, somehow, drive the game in the direction you want.
     
    In its current beta stage, DU doesn’t have enough ways for people to make money because we haven’t yet had the opportunity to implement all of the necessary features. There’s mining, of course. Trading is not as good as it will eventually be because markets are not really used to their full potential. As a consequence, players rightfully turned to a solo or small org autonomous game mode. 
     
    We tried to nudge people out of this with the changes introduced in 0.23. While necessary, many players expressed that the changes of 0.23 came too soon because it lacked a variety of lucrative ways for people to make money outside of mining.

    What We’ll Do Now
     
    The vision expressed above still holds. We want people to consider going through the industry specialization only if they intend to become industrialists and not necessarily to sustain their individual needs; however, we understand that it’s too soon to press for intense specialized gameplay considering the lack of sources to earn money. 
     
    Here’s our plan for now. We will modify the formula of the schematic prices to make it considerably more affordable for Tier 1 and still challenging and worth a commitment but less intense for anything Tier 2 or above. 
     
    This will allow most factories focused on T1 to resume their activities rapidly while keeping an interesting challenge for higher tiers, spawning dedicated industrial facilities aiming at producing to sell on the markets. We will also reimburse players who have bought high-priced schematics since the launch of 0.23 (please give us some time since it may take a few days as we go through the logs).
     
    We will keep monitoring the price of schematics to see if it makes sense to increase or decrease the costs. The right approach to set such a price would be to evaluate how much time it takes to recoup your investment by selling the products that the schematics allow to produce. It should be a few months so that the investment is a real commitment and it makes sense to plan for it.  We currently lack the metrics to properly assess this return on investment time. We need a player-driven market price for the components and a market price for the products to assess the profit made by each run of a schematic. This will come when the markets start to work as intended, and we can gather more data about them. 
     
    Feedback and Testing

    The release of 0.23 also taught us that we need improved ways to test new features, both internally and with community participation. The Upvote feature on the website was a good start, but it’s not enough. 
     
    To address this, we have two courses of action that will be taken. The first will be to set up an open public test server, hopefully with shorter release cycles, for players to try out new features. This will also allow us to explore ideas and be more iterative. If all goes according to plan, this test server should be introduced for 0.24, the next release. It will mirror the content of the production server with regular updates to sync it. 
     
    The second important initiative is to revise the role of the Alpha Team Vanguard (ATV), getting them more involved in early discussions about new features and the evolution of the game. We are still defining the framework, so more information will be released as available. 

    What is to Come
     
    In the short term, we will push a few corrections to improve 0.23, which include:
     
    Ships will now stop (be frozen) when their core is destroyed in PvP, making them easier to catch. Element destruction will impact the restoration count only when it occurs through PvP, at least for now (not when the ship is colliding/falling as we want to avoid having players penalized simply for crashing their ships because they’re learning how to maneuver them, for example). Recycling of un-restorable elements through a recycler that will take an element as input and grant a small amount of the schematics required components as output.
    The next major release is already in the making and will be about the mission system, a first step toward giving players more fun ways to earn quantas. We will reveal about it shortly so that we can get as much feedback as possible.
     
    We also want to reassure you that the mission system is not the only answer to offering more varied ways to earn revenue in Dual Universe. Things like asteroid mining and mining units will be introduced in the next few months. 

    This list is by no means complete, but should be a good jumping off point that gives players reasons to fight and to explore, opportunities for pirates, new ways of making money, and a plethora of other activities our creative community will think of even if we didn’t. 

    That’s it for now! We want to thank you again for your support and patience as we progress along this beta road! See you soon in Dual Universe!

    Want to discuss this announcement? Visit the thread linked below:
     
     
  5. Like
    Ater Omen reacted to blazemonger in DRM Update - fail number one   
    option is on right click menu on core
  6. Like
    Ater Omen got a reaction from Deintus in Beyond 0.23 - What did my game just update?   
  7. Like
    Ater Omen reacted to NQ-Naunet in DevBlog: The Maneuver Tool and Disconnecting Ships - DUscussion thread   
    So based on what I've read so far here and on Discord, these are my main takeaways:
     
    Many players are concerned that the Alt+F4-stop-and-login-to-instantly-regain-speed workaround will potentially be used as an exploit piloting maneuver during PvP, giving those that use it an overpowered advantage. While some players are feeling comfortable with the maneuver tool distance restriction, many are requesting an increase of up to ~250m to accommodate bigger elements such as L Cores. There are some concerns about moving unwanted constructs from player-owned tiles. That there are some bugs that should have been addressed before NQ nerfed the maneuver tool.
    Please let me know if there's anything I need to add to the list! 
  8. Like
    Ater Omen reacted to Apillion in DevBlog: The Maneuver Tool and Disconnecting Ships - DUscussion thread   
    The ship you are chasing will keep moving because you will be in rendering distance.
  9. Like
    Ater Omen reacted to Emptiness in DevBlog: The Maneuver Tool and Disconnecting Ships - DUscussion thread   
    These two explain one major use nicely, albeit log out/in, not alt+f4.
     
    Fix AGG staying up BEFORE this change goes through.
  10. Like
    Ater Omen reacted to NQ-Naunet in November DevBlog 3: The Maneuver Tool and Disconnecting Ships!   
    Good day, Noveans!
     
    Much of the allure of Dual Universe is the ability to be the captain of your own destiny as you pilot the ship of your dreams. Piloting your ship requires skill and a strategic use of the tools available.
     
    The Maneuver Tool is an important part of that toolbox. In its current state, however, it wasn’t working quite the way we planned. As we approach the launch of the 0.23 update, we wanted to talk about changes we’ll be making to the Maneuver Tool as well as changes to issues around what happens when you’re disconnected from the game (intentionally or not) when actively flying your ship.
     
    The Maneuver Tool is for maneuvers

    The Maneuver Tool was originally introduced to offer a simple way to get your ship out of a small hole or to flip it over when it landed upside down. It also provided a handy way to lift your ship off the ground a bit so you could work on it from below.
     
    But as is often the case when designing video games, the cunning imaginations of players found unexpected ways to use the tools that were not intended by the designers, some of which are detrimental to gameplay and could cause issues in the not-so-distant future. Let’s take a closer look at some of the issues caused by the “creative” use of the Maneuver Tool and the upcoming changes we’ll be implementing in the imminent 0.23 update to correct them.
     
    Cooperative play is all about collaboration and players helping other players. That’s great, and we don’t want to discourage players from doing that, but how it’s done is important. The Maneuver Tool was not intended as a way to move a ship “by hand” over kilometers or to create a ladder of two ships used as intermediary steps to reach space. These uses went clearly beyond the original intent of the tool.
     
    To address this, we’re introducing some limitations in line with the purpose of the tool: 
     
    A ship will not be able to move more than 50m in total between accumulated uses of the tool. The distance between the start and end points is added at each run of the tool. The moved distance is reset after three minutes to ensure that players aren’t stuck forever. It is, of course, a per-construct limitation.  Unless the player was in contact with a planet ground or a static/space construct, a ship will no longer freeze in the air during the use of the Maneuver Tool. This will make it possible to lift it up to work under it, but no higher than that.
    No more instant stopping of ships upon disconnection

    Everyone has “the need for speed”, the desire to get from Point A to Point B in the shortest time possible. So you pull that throttle back, amp up the power and blast off. The danger is that if you don’t carefully monitor your speed, you’ll smash full-force into a planet, your ship will blow up, and you’ll find yourself either returned to your bind point or resurrection node. Ouch!
     
    A common workaround for this has been to disconnect from the game just before impact. Upon reconnection, your speed would be reset to zero, and thus you could approach with a safe speed. Although it’s convenient, that’s not how it’s supposed to work.

    With the upcoming change, upon reconnecting, as soon as you get in range of the construct, the speed and rotation will be restored to whatever they were when travel was interrupted. The benefits to this change are twofold. First, it will close the aforementioned loophole. Second, it will prevent you from expending twice the amount of fuel to reaccelerate a ship at maximum speed if you had been disconnected for whatever reason.
     
    Further, if you disconnect while another player is in range, the server already assigns the task of handling the physical properties of your ship to that nearby player. This means that your ship will continue to move in this situation. On a large ship with many people on board, disconnecting will no longer have the effect of freezing your ship because there will always be other players nearby to continue the simulation of your ship’s movement.
     
    We will also add the option to have the Emergency Control Unit (ECU) activated in that case, so that an emergency “braking” can take place if the ship capacity allows it.
     
    Keep Doing What You’re Doing
     
    We tip our hats to the ingenuity of our Beta testing community. The way you use the tools and mechanics we toss into the sandbox gives us lots of food for thought, showing us the changes we need to make to make the game we all want to play. We encourage you to maneuver your way to the discussion thread to tell us what you think about the adjustments we’re bringing to DU! ❤️ 
  11. Like
    Ater Omen got a reaction from NQ-Pann in Hi, I'm NQ-Pann! AMA!   
    Why did you choose Pann as a name? Is it a reference to something?
  12. Like
    Ater Omen reacted to XKentX in Element destruction and playing Mario   
    From the announced dev blog, any crash will now render elements "modified", 3 crashes make them requiring a replacement.
     
    Plan A: 10 cans of hematite to crafting queue, AGG ship above District 6 market. Let's play Mario jumping on the turtles.
    Plan B: Nanopack skills to max, Catalyst 3 full inventory, AGG ship above District 6 market, let's play Mario jumping on the turtles.
     
    For those who are less familiar with game mechanics: If an avatar with mass X jumps on top of your ship while you are flying. X-20tons is added to your ship mass instantly. Full inventory of catalyst 3 is >3,000 tons.
     
    Thoughts ?
  13. Like
    Ater Omen got a reaction from blazemonger in DevBlog: Element Destruction - DUscussion thread   
    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.
     
    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.
  14. Like
    Ater Omen reacted to NQ-Naunet in DevBlog: Element Destruction - DUscussion thread   
    Naunet running by with a quick edit for clarity: Element Destruction will be applied to all damages sustained, both in and outside of PvP battles.
  15. Like
    Ater Omen reacted to Samlow in DevBlog: Element Destruction - DUscussion thread   
    p.s. with these changes, can we also have a no buildmode option in pvp? 
  16. Like
    Ater Omen reacted to Frigidman in DevBlog: Element Destruction - DUscussion thread   
    With a tool being added to "replace an element" (replace broken with brand new), does this open up the possibility to have that "replace" tool work to replace/upgrade elements for current talents?
     
     
  17. Like
    Ater Omen got a reaction from NQ-Naunet in About "Keeping the 'port' in support!" and "floating containers upon death" feature   
    Regarding this announcement: 
    this particular scenario:
    and this future feature:

    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?

     
    note: this is also valid for trap constructs with closing doors and detectors for example, should it be considered as griefing?
  18. Like
    Ater Omen got a reaction from Davian_Thadd in About "Keeping the 'port' in support!" and "floating containers upon death" feature   
    Regarding this announcement: 
    this particular scenario:
    and this future feature:

    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?

     
    note: this is also valid for trap constructs with closing doors and detectors for example, should it be considered as griefing?
  19. Like
    Ater Omen got a reaction from NQ-Naunet in DevBlog: Construct Intellectual Property Protection & Blueprints Duplication   
    But.. Dual deserves its own identity ?
  20. Like
    Ater Omen reacted to Mamba_Lev in DevBlog: Construct Intellectual Property Protection & Blueprints Duplication   
    Let's call them BPO's and BPC's.
  21. Like
    Ater Omen reacted to XKentX in So what info has leaked now ?   
    I would say that wealthy person is wealthy because he is not throwing his money out for no reason. I see no meaningful economic project ATM that would justify losing 200% margin for manufacturing those cores or mass ordering them from a big org that will do it for you.
  22. Like
    Ater Omen reacted to NQ-Naunet in Lua Museum Submissions   
    Good afternoon, everybody!!

    If you (and/or your Org-mates) are a fan of Lua and you've used it to breathe life into a creation you're dying to show off... now's your chance.  

    For a chance to be featured in our Lua Museum (ooooh, ahhhh!), please submit your builds using the handy dandy form we've put together. 

    ? Click HERE to access the form! ?

    Thank you for taking the time to check this out, and happy building!! We can't wait to review your submissions.

    ~ NQ-Naunet

    For those not in-the-know, Lua is a lightweight, high-level, multi-paradigm programming language designed primarily for embedded use in applications. This video contains more information about the ways in which you can use it in DU!
  23. Like
    Ater Omen got a reaction from NQ-Naunet in Forum Overhaul!   
    Adding a section for player scripts, the old topics are locked in the alpha feedback section. I don't think general discussions is the best place for that.
  24. Like
    Ater Omen reacted to Underhand Aerial in Alioth Aerospace Expo - Be part of the largest community event in Dual Universe!   
    The Alioth Aerospace Expo is a Community event where all the manufacturing organizations come together to show off their latest designs. We have events and contests at these Expos as well. For now attendance is free and we rotate which Organization hosts the Expo.
     
    This time Hyperion has the pleasure of hosting the Expo. We are looking forward to present you the biggest event in the beta.
     
     
    ► When:
    Spring 2021
     
     
    ► Why should I attend?
    The Expo aims to become a central hub of the shipbuilding scene. It is an opportunity for both industry giants and innovative startups to attract new civilian and military customers, by showcasing their talent to the wider player base. More than 600 constructs were already participating at the last Expo! 
     
     
    ► Want to show off your ships?
    Players and Organizations can register for exhibition spaces, one construct per area. There will be 9 areas in total.
     
    There will be three phases/ways to register your ships for exhibition.Choose the way you prefer. We recommend our Website.
     
    Phase 1: Pre-Registration on the Hyperion website starting 23rd November
    Phase 2: Registration via a Google Form starting 14th Dezember
    Phase 1 and 2 are live now! Feel free to use our website to register your ships. For boring people we have this google form.
    Phase 3: During the event, free space can be arranged via Discord. For each area there is one responsible person who takes care of it.
     

    ► What are the areas? What kind of ships can be exhibited there?
    1. Military Ships - all ships that are designed for PvP
    2. Freighter - any vessel designed for the transport of goods
    3. Shuttle - all ships designed for the transport of persons
    4. Replica - replicas of constructs from the real or a fictional world
    5. Scripting - all dynamic constructs related to Lua
    6. Starter & Scouts - all ships that can operate as scouts or are especially suitable for beginners
    7. Racing - all ships designed for racing
    8. Luxury Ships - The most glamorous ships with the only purpose to sparkle and shine
    9. Organizations - Extra exhibition space for organizations with a greater amount of ships
     

     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    Further details about the Expo and the events taking place will be posted here

    We welcome any support you like to contribute to the project
    Contributions for the Expo can be made here: ::pos{0,2,16.7544,112.0115,42.2058} Please claim your items
     
     
  25. Like
    Ater Omen reacted to blazemonger in RDMS Question   
    You can also set up tags to apply to screen only.

    Create a Simple tag, say "Passenger Access"
    Create a Composite tag, select the "Passenger Access" as main tag
    Type "screens" as Precision Tag
     
    You will now have a "screens@passenger access" tag
     
    You can now set up the policy for this precision tag and apply the main tag "Passenger Access" to the construct. It will now allow passengers to access any screen in any area they have access to without you needing to add this tag to all screens separately. Passengers  will not have access to anything else in this case, just the screen on the construct they can get to. You would use the "doors" precision tag to set which doors they can use and "chairs" to allow them to sit down in chairs but not control seats.
     
    So you add only the main "Passenger Access" to the construct and that will apply all precision tags you set up "under" it which would allow you to make changes without needing to go through all elements separately and set new tags.
     
     
    Another example is that on an org base you can use this to allow org members to use all industry elements but not access containers unless you set specific rights to the ones they should ba able to access.
     
    To go back to your screens for a moment.. What the "items hierarchy" shows is what a tag would affect, In case of "Screens", their parent is "Displays" which would also be where "Signs" are under.. so a "screens@access" tag would only apply screens, but a "displays@access" tags would apply to both screens and signs.. 
     

    I hope that still makes sense
     
     
×
×
  • Create New...