Msoul

Yes but you can't do this on an individual construct level. In a universe with player interaction, there has to be some amount of standardization or you end up needing to relearn how to fly every time you pilot a new construct. In the case of Dual Universe that standardization is the action list. Event filters are currently limited to the 32 actions you saw after clicking on the empty onStartAction() field and only these actions are able to serve as control inputs. As a result all constructs and programing boards are using the exact same action set. Lua scripters can still define what these actions do, but it is encouraged that they stick to basic conventions like having the "break action" turn on breaks. Now when it comes to setting custom keyboard controls you can redefine which keys are connected to these actions via your local client settings. Simply press ESC to access settings, go to controls, and scroll down to the Piloting/Control Unit/Lua section. Here you can freely remap the individual hotkeys used to trigger said actions. Thus we end up in the scenario where players can choose their own unique hotkeys without imposing those definitions on others.

Very fair point there, looks like my preferred gamma setting is 1.5 but if I drop it to 1.0 like you suggested then I am able to reproduce the image you provided here. Yes everything is much darker but the light itself is still behaving as I would expect. These square lights project downwards in a cone (like shown below) so it is not surprising that they fail to illuminate the areas you have indicated. In general it would have been better to use a vertical light for this close range indoor setting but none the less I have indeed been assessing things thinking that 1.5 gamma was typical. If 1.0 is the standard then I absolutely agree that either the market areas need better lighting or perhaps lighting intensity in general could use a buff.

No I am not NQ and as I said in the opening, lighting is not my area of expertise. However I would like to obtain a high level understanding of all aspects of DU and hence decided to dive in and try to figure out how this all works. After awhile I had collected a bunch of interesting data so I figured I might as well share it here in the hopes someone would find it useful. I was unable to find any instances of a Square Light L in the market building. It appears that most of the lights being used there are actually white luminescent voxels which as I pointed out in my post have the lowest range and are poorly suited for general illumination. I did however manage to find a pair of Square Light M near the entrance elevator and they seemed to be doing a fine job in my opinion. Perhaps it could be improved but once again this is not because lighting is broken, it is just not being used effectively here. The landing pad only has 4 light elements and they are placed in the far corner. Everything else is once again luminescent voxels. As I said in my post they appear best suited for short range interior lighting. The vertical light L will only illuminate things within ~20m and those illuminated things will only be seen as illuminated from up to 300m away. The long and square lights have less intensity but surfaces illuminated by them will be visible from much further. It seems that I am not able to reproduce this. The ground directly beneath my ship has the same light level as the rest of the terrain. There is however a very faint glow coming from the nearby district which makes sense because there are 4x square light L on that platform. I do agree with you that water has seemingly no impact on lighting. Not sure if that is something that can be easily added but I am certainly not opposed to the idea. Yes the amount of light present during the night was increased and yes that does have a negative impact on immersion but I was there during this period in time and the heavy darkness was often quoted as an major issue by players. Personally I think it is better now but that is just my opinion. Perhaps your right and the majority of players feel it was turned up too high. I would love to hear more people comment on this. Ah the avatar's flashlight. I actually investigated that too but it was an entirely different class of lighting object which was far more complicated. To be honest I still don't fully understand how it works, something about cubemaps and box projections. I will have to look into again when I have time. Personally I find the flashlight works well but I will admit there are times I wish it had a wider FOV.

The following is an examination of the various player lighting options in Dual Universe as of Update 1.1. Please keep in mind this is not my area of expertise and many of the conclusions drawn here are highly subjective. Hopefully you still find it useful and free of errors. Summary of Findings (TLDR) The Headlight XS is uniquely situated as the spotlight of Dual Universe and it does that job exceptionally well Long and Square lights are functionally equivalent and best suited for illuminating surfaces that need to be seen from a distance The Vertical light has the lowest effective range but being omni-directional with high intensity makes it ideal for indoor lighting of complex geometries. Luminescent Voxels are best suited for decorative highlighting rather than general illumination. Physical properties of lighting elements are standardized but be aware that the Vertical light L has increased mass, volume, and health XS light elements are tier 1 + nanocraftable while S, M, and L sized lights are tier 2 with standardized recipes Current fabrication costs for light elements are primarily from schematics and manufacturers are fully capable of supplying consumer needs right now Introduction There are 4 different types of craftable light elements Headlight XS, Long Light, Square Light, and Vertical Light with the last 3 having size variations XS, S, M, and L. Each of these elements can be configured to blink at a regular interval and/or output RGB colors through the right click menu. Note that the RGB values must be scaled between 0 and 1 so if you are referencing integer color values (ie: 1 to 255) simply divide it by 255 before inputting. In addition there are 11 different kinds of Luminescent Voxels creating a fairly diverse color palette that spans the visible spectrum. These lights as shown below are the primary focus of this post, but it is also worth noting there are a large number of alternative sources such as fireworks, deco-lamps, engine VFX, and of course the sun itself. Lighting Characteristics The main objective behind adding lights to a construct is to use them to illuminate surfaces. These are the key parameters that influence this. Field of View (FOV) – The angle centered about an object’s normal within which light is cast Intensity Factor – The relative power of a light source measured in multiples of 100,000 lux Attenuation Distance – The distance between a light source and a surface, beyond which said surface is no longer illuminated Penumbra Factor – A measure of how fast projected/surface light intensity decreases from the epicenter Visible Distance – The distance between an illuminated surface and an observer, beyond which the light on said surface begins to fade out When it comes to FOV all light elements have approximately the same value of 100 degrees with the exception of vertical lights which are omni-directional. The remaining stats are plotted below with reference to element size. Note that gaps in the bar graph represent break points on the y-axis which were added to prevent exceptionally large values from obscuring the rest of the dataset. The headlight XS has the greatest light intensity and attenuation distance which makes it effective at illuminating distant surfaces, but the high penumbra factor causes that intensity to rapidly decrease as the light spreads outwards from the point of incidence. Consequently it functions as a powerful spotlight that is great for lighting up distance objects with a narrow beam. The long and square lights closely mirror each other with the larger variants exhibiting slightly longer range. These lights also have the highest visible distance making them well suited for general illumination of mission critical surfaces like runways and landing pads. Vertical lights on the other hand have the lowest overall range but being omni-directional, with moderate intensity, largely makes up for that. They are well suited for locations that require many nearby surfaces to be irradiated at once such as building interiors or complex voxel geometries. In order to further highlight the differences between these light sources, the following visual reference was created. It showcases the amount of light spread that would occur on a 32x32m (ie: S-core size) flat surface when illuminated by each source from the respective distances listed on the left side. Physical Characteristics When it comes to general properties all light elements are approximately equal with the exception of the vertical light L. It has over three times the mass, four times the storage volume, and triple the amount of functional surface area. It is also the only light with any meaningful amount of health although it is still not recommended that they be utilized for defensive purposes since these decorative type elements do not even have damage resistance. In terms of dimensions each increase in the size category roughly doubles the primary side length of each respective element. Fabrication Costs The production recipes for XS lighting elements are all Tier 1 and can be made in the nanocrafter. All other sizes are Tier 2 and must be crafted in industry units, specifically an Assembler XS for everything except the vertical light L which requires the S sized variant. An overview of the fabrication costs per individual element produced is provided below. From it we can see that if you neglect schematics the only differences between baseline unit costs are associated with an item's tier. However once again the vertical light L proves to be an exception as it also has a substantially longer crafting time, likely due to it being paired with with the Assembler S. Under current market prices these schematics represent upwards of 50% the overall cost expenditure to manufacture said lights. Taking a brief look at public market orders it becomes clear that despite this, there is a moderate surplus of elements available for purchase (note that outliers with absurd +/-1000% prices have been removed). Smaller sized lights in particular appear to have been produced in excess of player demand and are now being listed at or below that of production costs. It is difficult to estimate when the existing supply will be exhausted as player demand for small lights is not easily quantified. However due to the low fabrication costs and crafting times, affluent manufactures will be able to quickly restock this market should the opportunity arise. The situation with larger sized lights is more dynamic right now. The low volume of units that are presently on the market have been listed with profit margins of about 20% which is indicative of a more limited supply and/or a greater demand. To assess supply concerns, the following plot compares the fabrication costs for lights to that of atmospheric engines. From it we can see that the total schematic costs for engines is slightly higher while the requisite ore requirements are substantially higher, particularly for M and L sizes. Despite this, market sell volume for engines is much greater than that of lights while also maintaining above zero profit margins. Thus we can infer that player industries exist which are capable of meeting supply requirements for the large lighting sector but they are instead targeting other items like engines, likely due to even higher consumer demand and hence greater profits. Luminescent Voxels Unlike lighting elements these voxels appear to operate solely as emissive surfaces and produce a highly localized glowing effect. In terms of the ore costs per m3 they are similar to the other Tier 2 light elements but only require about a fourth of the T1 ore (more specifically 11 and 30 litters of T1 and T2 respectively). Schematics cost per m3 is exceptionally low at 172.45 quanta. This would ordinarily make luminescent voxels the cheapest form of Tier 2 lighting but their more limited range also means that a substantial amount is needed to achieve the same level of illumination as the other light elements. They do however have the unique ability to be precisely shaped and seamlessly integrated into other voxel structures. Considering all of this I believe luminescent voxels are best suited for decorative highlighting rather than general illumination. Conclusions and Recommendations Based on the above, it is my determination that Dual Universe currently has adequate lighting options which when employed correctly, will handle the majority of scenarios. There is however plenty of room for expansion and/or further diversification down the road, when time permits. In terms of expansion I recommend adding a secondary element with omni-directional properties such as a sphereical light. Also consider decreasing the overall effectiveness of the headlight XS and instead utilizing its original properties on a larger sized variant (ie: headlight S). In terms of diversification, the most restricted parameter right now is FOV so assess the merits of adding that as a configurable variable or providing more FOV variation across the existing element set. Finally @Aaron Cain your original inquiry was with regards to crafting costs for L sized lights with respect to T2 engines, considering the associated player demand for both (static building vs dynamic construct). Based on market trends alone, it is safe to say that the demand for large engines is presently higher. From a practical standpoint this examination shows that it only takes a couple strategically placed L sized lights to fully illuminate an S core sized surface. I also reason that illuminating a dynamic construct of identical core size will typically require more lights than its static counterpart due to the need to handle both interior and exterior surfaces as well as the more complex geometries associated with piloting elements. So the question becomes why are large lights less popular then large engines? Rationally, it is either because the majority of players are less interested in them and/or are unwilling to invest into them. With regards to baseline costs these lights are already a fraction of the cost of said engines, primarily due to their sparser ore requirements. Perhaps that is still not sufficient, but with engines flying off the proverbial shelves it is difficult to say this conclusively. The only thing I can conclude is that the majority of players place low importance on lighting. The next step would be to reach out, ask why, then determine if anything should be done or if players are satisfied.

Territory Mechanics If you have no existing territories on a given planet/moon then when you go to deploy your territory unit on that body, the deployment fee will be set to zero. If you already have claims then it will cost you a flat fee of 500,000 quanta regardless of how many claims you have. The only restriction applied to inactive territories is that they will be unable to start mining units. You can run industry units on inactive tiles as of Panacea update 0.28 Currently a territory marked as headquarters (HQ) can be left inactive indefinitely. As long as your territory is marked as HQ that red payment reminder can be ignored and will periodically reset itself. Now the reason why you have heard conflicting information here is because concerns have been raised regarding the permanence of HQ tiles for accounts who have unsubscribed and are unlikely to return. Players have proposed that the 90 day inactive asset requisitioning (IAR) rules should apply to HQ territories as well, which would mean they would become abandoned should the owner's account remain unsubscribed for more than 90 days. Please note that this has not actually been implemented by the game designers but it is possible that they could make alterations so be sure to keep up with the news. Gyroscope Control There is no default hotkey for toggling the gyroscope while piloting a construct but you can easily create one by editing the default lua script. The function call required for engaging the gyroscope is slotname.activate() and it can be subsequently deactivated with slotname.deactivate() or directly toggled via slotname.toggle(). Simply link your gyroscope to your control unit (ie: pilot chair) and keep track of which slot number it occupies as you will need to replace slotname in the function call with the exact name given to said slot (note you can also rename them for convenience). Next open the lua editor and click on the predefined system slot. Press add filter at the bottom, then select the onActionStart() event by hovering over the 3 dots. Next click on the blank field within the brackets and choose which hotkey you want to use (note that option 1 = Alt+1 by default but you can also change that under your client settings). Then with your new onActionStart("hotkey") event selected, type slotname.toggle() into the lua editor field and press apply. Now whenever you press that hotkey while piloting, your gyroscope will toggle on and off. Here is a visual of what you need to achieve. Note I am using lshift (ie: left shift) as my hotkey and my gyroscope is plugged into the slot8 which I renamed as gyroscopeSlot.

Yes NQ-Rocketman and all the support staff in general are awesome. Thank you guys for taking the time to investigate all our bug reports and get us out of jams. We will most likely continue to do crazy things in Dual Universe so strap in for a wild wide.

It seems the original topic here as proposed by Snow, was about which style of gameplay is preferred, one of abundant resources and heavy sinks or scarce resources and light sinks. This is actually a very interesting question so perhaps we could get back to it and stop with all the off-topic speculating and non-constructive comments. Personally I prefer something in between because if you venture too far to one side your essentially in creative mode (which gets boring very quickly) and too far to the other side your grinding resources 24/7. The question then becomes where is that healthy midpoint? How much grind is acceptable and how do we quantify it? I suppose one way would be to base it off the time required for a solo player to acquire a decent ship. In which case how about scaling it like so: Tier 1 = 1-2 hours Tier 2 = 1-2 days Tier 3 = 1-2 weeks Tier 4 = 1-2 months Tier 5 = 6-8 months Is that being to generous or is that too grind heavy? How would you structure it?

I do recommend you check out Aegis at some point if you have time, the fact you were not even aware of it makes DBxWanderer concerns all the more valid here. Also SirJohn85 is correct in that NQ has reserved said rights so they can showoff their universe and the player constructs within without needing to dive into legalities. With that said, the real reason why your construct would appear in a promo image is probably because it looks awesome and thus caught the attention of NQ either through other players pointing it out via the old community spotlight submission form or by a staff member happening upon it.

The Aegis Space Market was added to Dual Universe as part of the Athena Update. Said update also happened to include the first iteration of Space Territory Warfare via the alien cores system. These two paired together rather well in beta and I suspect they will do so once again during release. However the next iteration of alien cores is still being developed right now. Your proposal of migrating some missions to Aegis would certainly help in the intern but either way I think Aegis has a lot of potential for growth due to its central location in Helios. Whether or not it ever reaches the same level of popularity as the Alioth markets is hard to say but I wouldn't call it impossible.

The most recent patch also included a launcher update and that refresh is likely what triggered your antivirus software. Unfortunately there is no way to manually trigger integrity checks on the Novaquark client right now. However if you happen to be on steam then you can utilize their validation system to find and correct any installation issues. I am also in support of adding an option to manually initiate integrity checks even if the associated self-repair functionality is not included with that (ie: deferred for later due to being low priority). Just knowing that the game files are free of errors eliminates a lot of uncertainty when it comes to diagnosing other issues. Oh and welcome to the forums MrTenneal!

You are only allowed to sell your DAC for quanta not anything irl but there is currently no method of performing such a transaction with 100% security. As a result there have been several instances of players not following through on what was promised effectively scamming the other party out of their DAC/quanta. Personally I recommend you wait until NQ implements a system which formally backs these kinds transactions or at the very least exercise caution and utilize a trusted third party to help avoid issues. Also keep in mind that advertising DAC transactions here on the forums or on the official discord is currently not allowed. See here details.

Localization was completed in update 1.1 and if you know of a problem that is not in the known issue list then I recommend submitting a bug report just in case the devs are not aware. Also these are some great fixes. I am a little sad that I can't name my dynamic construct a series of blank spaces but to be fair that was always a bit naughty.

I examined the model from Thingiverse you linked and I suspect the reason you are encountering problems is due to how the normals have been defined on these 3d prints. This is fairly easy to solve using 3d modeling software as nearly all of them allow you to re-export without said normals. However if you would prefer to avoid that route then you can always manually remove them. Simply open your .obj file up in any plaintext editor and remove all lines beginning with "vn". For example if you see something like this, you would need to delete lines 3 and 4 but leave everything else alone. v -81.464111 11.354034 16.692894 v 34.420517 19.880941 27.747639 vn -0.0005 -0.2839 -0.9588 vn 0.5546 0.2754 0.7852 s 0 f 1//1 3//1 2//1 If that still does not work then I really need to see the specific model in question in order to figure out what is going wrong. I do understand your concerns about sharing specifics on your build so consider sending it to me privately via forum DM. My only motivation here is to help you out and if you want to keep your design private then I will respect that.

Haha, you sound a lot like my old boss. "Why are you designing Y, shouldn't you be doing X?" "I would love to do both but Y is system critical, X is just the gravy, and HR has still not figured out how to clone me." Honestly thou I am not sure why and this thread is more centered around pets so I don't think it is a good idea to get into it here. If you find it annoying then either update your account email preferences, block it, or consider mentioning it to one of the CMs so they can investigate.

One schematic is enough to create one standard unit of product as listed in the base recipes found via the crafting interface (hotkey = K ). Industry units however have preset batch sizes whereby instead of allowing you to produce an individual standard unit of product they often require that you create several at once. This was done to improve game performance as it far less intensive to create say a 1000 screws every 1000 seconds, then it is to create 1 screw every single single second. Since you mentioned it, lets take a look at the Square Light XS as an example. This is the base recipe as listed in the crafting interface and from it we can conclude 1 schematic will produce 1 light while also costing a single basic connector and basic power system. Now if we look at the associated industry unit interface (in this case an assembler XS) we see that 6 are produced for every run and that each run takes 3 minutes. Thus you will need to have at least 6 schematics inside the schematic bank, one for each standard unit which is being produced. Hopefully that helps. I know this question popped up a lot especially during the first few days after batches were introduced. If you have any suggestions on how to make it more obvious that would be really helpful.

If you are not receiving Dual Universe emails and/or newsletters and would like too, double check your email preferences both here on the forums (board.dualthegame.com/index.php?/notifications/options/) and on the main website (www.dualuniverse.game/account/preferences). Also keep in mind that certain emails are sent out in batches so some may receive it faster than others. If you are confident that you have setup everything correctly but are still not receiving mail then reach out to NQ support for assistance.

That is very fair. Apart from the third party kickstarter page, most of the remaining information pages were archived after several years, likely to avoid confusing newcomers with unobtainable reward packs offering "alpha access". Since there seems to be questions regarding what rewards to expect I will write up a more detailed overview on everything soon and post it here on the forums.

In most cases this is not intentional, its just that parking larger ships can be challenging and clients with lower specs also tend to have difficulties rendering all constructs in busy areas. Perhaps in the future NQ could add a new feature to alleviate this and/or make adjustments to the parking rules, but for the time being there are still some things you can do to get by. Attempt to extract your construct using the maneuver tool. Utilize the fetch tool to teleport your construct away. (Right click on said construct in the map listing while standing in a clear area) Message the construct owner, let him know he is blocking you, and ask him to move. (Note this can be done via /w <playername> <message>) Submit a ticket to NQ support and ask them to assist directly. In the event this does becomes a persistent problem then obviously NQ will step in but ideally we all just put a little more effort towards parking etiquette so they can instead focus development on more important things.

I am not aware of any online tools for this and the projector does not have any built in lua capabilities right now. I think your best bet is to learn how to use 3d software like blender (there are tons of online tutorials for this) or if you are able to share said model then either myself or another player here would likely be willing to assist you with making the necessary adjustments.

Its actually not that complicated. The Automata pet has 5 variants while the Anicham has 3 thus the later is the kickstarter pet and the former is from the supporter packs. Here is a quick breakdown of what to expect. Silver Founder = Automata Tier 1 & Anicham Tier 1 Gold Founder = Automata Tier 2 & Anicham Tier 2 Sapphire Founder = Automata Tier 3 & Anicham Tier 3 Ruby Founder = Automata Tier 4 & Anicham Tier 3 Emerald/Diamond/Kyrium Founders = Automata Tier 5 & Anicham Tier 3 Contributor Supporter = Anicham Tier 1 Sponsor Supporter = Anicham Tier 2 Patron Supporter = Anicham Tier 3 Note the reason that founders are receiving some of the supporter pets is because NQ decided to gift them certain parts of the supporter packs back in March 2018 as per this graphic.

There is currently no way to alter how a 3D model is rendered inside the game client apart from the basic transformations listed in the right click menu of the projector element. If you are having a hard time seeing your model then it could be related to how the mesh is defined. If you are using blender then perhaps try to perform some preprocessing like what is described in this tutorial or try prepping it with this plugin. Alternatively, could you provide screenshots from both your 3d modeling software and in-game. Seeing that comparison could help us better understand the problem you are facing.

The pets provided in this update are specifically for backers who supported the game early on and which ones you get is dependent on the backer pack purchased. Once again there will likely be more opportunities to obtain/purchase pets in the future so be sure to keep an eye out for DU announcements. If you did receive pets in this update they will be added to your Novean Overview Screen (hotkey = P) where you can also selectively activate/deactivate them.

Some players seem to be completing it without issue. Can you please submit a ticket with a detailed description of exactly how to reproduce the error you have encountered. That could go a long way to helping fixed said bug once and for all.

Here is the simplified breakdown. Note that some overlaps are possible whereby an account can belong to more than one category. Kickstarters are those who supported directly during the kickstarter campaign (ie: Iron/Silver/Bronze/Gold/Sapphire/Ruby/Emerald/Diamond/Kyrium) Founders are those who purchased one of the equivalent kickstarter packs directly from NQ when they made the decision to extend said campaign. The rewards being offered were not modified in any way so suffice to say Founders = Kickstarters when it comes to rewards. Supporters are those who purchased the pledge/supporter packs that were made available in late Alpha (ie: Contributor/Sponsor/Patron) Pioneers are those who purchased some form of gametime prior to official release and subsequently logged in at least once during the first 6 months of said release. @DarkmatterShips Since you paid during beta you have a Pioneer account. There are no exclusive rewards being offered to Pioneers in this update but it would not surprise me if NQ provides more opportunities to obtain special rewards via future events/contests. Also don't forget there are quite a few gameplay features and improvements packed into this update with many more planned for update 1.2.

Hello PaddyBaptiste and welcome to the forums. Steam requires that a singular, non-reoccurring, purchase for at least 1 month of gametime be made through them to unlock the ability to play on the persistent server via said steam client. If you browse to the steam store page you should see an option to buy 1 month of gametime listed there. After making that purchase another option will then appear on steam for launching the non-demo version of Dual Universe. Please note if you do make said purchase, there will be a new Redeem Gametime button added to your My Products page which you will need to press to add the gametime purchased via steam to your Dual Universe account (see here for more details). Since you gifted your friend a DAC they most likely have not made their first steam purchase and thus do not currently have the non-demo version unlocked on steam. Thankfully Novaquark does not impose this kind of stringent requirement on their own launcher so if you friend wants to play on the persistent server using your DAC then they can procced to this DAC page to redeem it and then download the Novaquark launcher via the button at the bottom left. Hope that helps. Please let me know if anything is unclear or if you have further questions.