Yoarii

Honestly, we don't need adverts for DU, at least not in the current stage. What is really needed is a way to retain players aka reasons for one to keep a sub and stay active. Without that, they can spend as much money as they have advertising the game and it will result in people leaving after the first months.
 
We need content, and by that I mean actual content. Having an ongoing lore event like we had for the PvE is cool and gives everyone an objective, adding new stuff to the game (even if that's just QoL) also helps a lot and gives a feeling that the game is being taken care of, even if there isn't a solid roadmap.
 
Taking care of the public image of the game is also another thing that helps, if the company actually listens and implements changes that are popular and well-received, there's a good chance players will recommend the game to others and the player base will grow organically, not to say that it also helps on retention. This is also important if they decide to advertise, since one might click the ad, but give up after reading too much negative stuff online.
 
Advertising works well for single purchase games, but for subscription stuff like DU, retention is king.

Hello there, Noveans!
 
Today I'd like to present you with two online tools (possibly more coming soon) I've been recently working on, that aim to make the Dual Universe life easier!
 
Item Database Explorer
Link: https://dual.wolfe.science/tools/item-database-explorer
An online database containing useful information related to DU items and their recipes.
It has a search bar where you can search for any item or resource, and by selecting one from the list you can see the following set of information:
Basic  data such as ID, category, tier, volume, mass and density; All available crafting recipes for that item, including when it is a by-product of something else; All recipes that use that item as an ingredient; All honeycomb types that can be produced using it; All resources, parts and items where that resource is required as part of the chain (except when it's part of a Catalyst);  
As a starting example, you can check out Pure Iron and see how many parts and items use it
 
There's also a new section in the works that will list all planets, moons and moonlets where a certain resource can be found, but it's still a WIP, due to some divergence I found when comparing in-game ore lists with the Atlas file.
 
Celestial Body Calculator
Link: https://dual.wolfe.science/tools/calculators
This one is more like a general-purpose visualization of the Atlas, but also supports few calculations on things based on altitude. At the moment it offers:
Gravity information, including the altitude where gravity is 0.01g; Atmosphere information, including the altitude where atmosphere density is 10%; Surface minimum, average and maximum altitudes; Construct build limit altitude; Total surface area and number of territories; Calculation of gravity, atmospheric density and total circumference length at desired altitude;  
I hope that information is somehow helpful for the community and I'm completely open to suggestions on what could be improved or added!

Just read the devblog in the launcher on changes coming to 1.4. Awesome news, all of it.
 
Just a small ask, @NQ-Ligo, please document the exact changes to the API so that we can determine what we need to change.

> We've added a compatibility patch to prevent your existing scripts from breaking.
 
Could you please elaborate on this a it?
 
We're all dying to know more about the getInstructionCount and getInstructionLimit functions, could you please let us know more about those too and how they are intended to be used?
 
Br,
 
Yoarii

I assume they are.
 
NQ: Please consolidate all rules to a central place where both new and old players easily can find them. Maybe even via a link in the launcher?

The real community is on Discord.
NQs unwillingness to simply ban the 3 schmucks who fill every forum post with a tired rant on how the game isn't being developed anymore, and how no one is playing (both wrong) makes it a dreary drudge to try and read anything here.  I still try though.  

Edit: Hallelujah! Keybinds for Identify and Engage are in 1.4.2!
 
Core PvE feedback:
 
Clicking on widgets for almost all combat actions is fun-destroyingly painful!
 
Keybinds for the following actions would go a really reaaaalllly long way to a combat experience that has flow:
 
1.  Identify selected target  now present in 1.4.2
2.  Engage selected target now present in 1.4.2
3.  Reload All
4.  Vent
5.  Cycle Shield Resistance Presets
 
If I could click a target's icon around me with the reticle, and from there out interact with it solely by keybind it would at least put us on par with tab target MMOs
 
There is potential for fun here, but the current method solidly, solidly blocks it.  This one point must be addressed in order for the combat to retain appeal and players.
 
Other PvE feedback:
 
Enemy killcount to complete the Very Easy mission feels high for the time alotted.  Reducing the # of kills required by about 30% would feel better, or an extra 5 minutes on completion
 
Being killed by running out of time feels harsh, an automatic portal out would be better.  Players already expend fuel/ammo and sustain damage, simply leaving the mission without payout is punishment enough imo.
 
Enemies should not spawn and fire on the player the very instant they enter their construct seat.  Perhaps the intention was to feel like you were being ambushed?  However if so this is not communicated to the player.  A 30 second countdown to the arrival of the first wave would be good.
 
Ressurrection node selection logic needs to be looked at, as currently a rez node on a carrier at the mission entry point has not been where I've been sent on death.  Rather all the way back to Alioth?

There may be other options besides the subscription.  But what you're asking for is just unrealistic.
 
This isn't a game in the sense that they can just give you a copy of the code, and you get to play it forever.  It's an unfinished project that requires them to maintain servers so you can play in a shared persistent world.
 
Even if they decided to sell you the game for a one-time fee of $70.  There is absolutely no guarantee that you will be able to continue playing it indefinitely.  They would be doing you a disservice by selling it to you under the pretense that it is a product that you can own.
 
It's a service, not a product.
 
Whether it's a service that is worth paying for may be up for debate.  But asking them to lie to you and sell it to you like it's a finished product isn't going to fix anything.

1. Check atlas.lua in your game folder, I think that info is there.
2. Planets don't rotate. The skybox moves.
3. Spherical afaik.

Would be cool if you could start distributing that with the game client prior to 1.4 so that we can start using it now.

I am happy with the new Lua changes, but a bit upset about the fact that we can't test it on a PTS session.

Some scripts are very sensitive and may discourage many players if they stop working. There are several examples, but among there is a huge change that ArchHud won't work anymore and will generate a lot of stress among some players.
Archegeo did an awesome job following the changes and testing them on PTS for the good of the community. He is not the only one in this case, but certainly the most known.
Not allowing us to test our script and being able to have a version fully functional on release force us to not enjoy the release and having to work on our scripts. In long term people get tired and just stop.

 

Just read the devblog in the launcher on changes coming to 1.4. Awesome news, all of it.
 
Just a small ask, @NQ-Ligo, please document the exact changes to the API so that we can determine what we need to change.

> We've added a compatibility patch to prevent your existing scripts from breaking.
 
Could you please elaborate on this a it?
 
We're all dying to know more about the getInstructionCount and getInstructionLimit functions, could you please let us know more about those too and how they are intended to be used?
 
Br,
 
Yoarii

Greetings, Noveans!
 
This is NQ-Ligo again.
 
We’ve heard your questions on script compatibility since announcing the Lua changes coming in update 1.4. I’m writing to share more information to enable you to better prepare for the update.
 
There's only one change that we haven't been able to make compatible with existing scripts. For everything else, a compatibility layer has been added, there is no need to worry about that!
 
The "breaking" change is the Boolean type fix. For a long time, functions that were supposed to return a Boolean, such as unit.isRemoteControlled, returned an integer (0 or 1). It took a while to correct, but from now on, these functions will return a Boolean (true or false). However, functions requiring a Boolean argument will continue to support integers in addition to Booleans.
 
To assist you, here's an exhaustive list of EXISTING functions that currently return an integer and will now return a Boolean:
 
unit.hasDRM
unit.isRemoteControlled
unit.isMouseControlActivated
unit.isMouseDirectControlActivated
unit.isMouseVirtualJoystickActivated
unit.isAnyLandingGearDeployed
unit.isAnyHeadlightSwitchedOn
databank.hasKey
databank.clearValue
transponder.isActive
transponder.setTags
shield.getState
shield.setResistances
shield.inLockdown
shield.isActive
shield.startVenting
shield.stopVenting
shield.isVenting
shield.setLockdownExitTime
door.isOpen
forcefield.isDeployed
forcefield.setMaxLength
landingGear.isDeployed
light.isActive
light.isBlinking
weapon.isOutOfAmmo
adjustor.isActive
adjustor.setTags
adjustor.isIgnoringTags
brake.isActive
brake.setTags
brake.isIgnoringTags
airfoil.isStalled
airfoil.setTags
airfoil.isIgnoringTags
engine.isActive
engine.isTorqueEnabled
engine.isOutOfFuel
engine.hasFunctionalFuelTank
engine.setTags
engine.isIgnoringTags
antiGravityGenerator.isActive
receiver.hasChannel
receiver.setChannelList
core.isEngineIgnoringTagsById
core.deleteSticker
core.moveSticker
screen.isActive
screen.getMouseState
gyro.isActive
laserDetector.isHit
laserEmitter.isActive
manualButton.isDown
manualSwitch.isActive
manualSwitch.isDown
radar.setSortMethod
radar.isConstructIdentified
radar.isConstructAbandoned
radar.hasMatchingTransponder
construct.isWarping
construct.isInPvPZone
construct.isPlayerBoarded
construct.isPlayerBoardedInVRStation
construct.isConstructDocked
construct.setDockingMode
construct.dock
construct.undock
construct.forceDeboard
construct.forceUndock
construct.forceInterruptVRSession
player.isSeated
player.isParentedTo
player.isSprinting
player.isJetpackOn
player.isHeadlightOn
player.isFrozen
player.hasDRMAutorization
system.destroyWidgetPanel
system.destroyWidget
system.destroyData
system.updateData
system.addDataToWidget
system.removeDataFromWidget
system.isFirstPerson
system.isViewLocked
system.isPlayingSound
 
As for other changes, such as the JSON library change, we've made sure to maintain compatibility with your existing scripts, either by making added arguments optional (thanks to the implementation of the nil type in our API), or by adding derivations. However, in the future, I recommend including the "json.lua" library instead of "dkjson.lua" to avoid using the compatibility layer if you want to optimize your script.
 
As with every update, we'll also be pushing an updated Lua API mockup on the game's official GitHub.
 
We hope this helps you better prepare for the upcoming Lua changes in update 1.4! Happy coding, Noveans!
 
NQ-Ligo

You're not wrong, but I think the smarter move would be to embrace existing code editors instead of doing their own, as well as other tooling that already exists in the community.

You're not wrong, but I think the smarter move would be to embrace existing code editors instead of doing their own, as well as other tooling that already exists in the community.

> 100 Nano-craftable Elements -  Including XS Dynamic Core Unit above
> Six (6) Light Sources - XS lighting elements only
 
Up to or exactly 100 elements and 6 light sources?

Now that this has been posted to the forum too, I'll just link my original question above, and add this: Please, provide an out-of-game codex. Until such a time that the in-game code editor can measure up to VSCode with Lua plugins, and use of du-luac, most larger projects will be coded outside the game while not even having DU running. You have a perfect place for this - your GitHub repository. You've made a good start with the API mockup, but it needs more work and up-to-date annotations, like in this PR that's been waiting review/approval since Sept 8, 2022.

DEVBLOG: 1.4 LUA API UPDATE
 
Greetings, Noveans! This is NQ-Ligo again,
 
Some time ago, we redesigned the Lua API of Dual Universe, introducing new features and opening up many possibilities. Today, we’re launching the next major update to the game’s Lua, addressing the remaining fundamental issues and adding numerous new features.
 
In this post, I’ll present some upcoming 1.4 changes to give you ample time to adapt your creations. I’ll walk you through the changes we're making to the backend, as well as some cool additions to the game’s Lua API.
 
Fundamental Changes
 
Let’s start with the fundamental issues we had yet to address in the game’s Lua.
 
- Update of the Lua Environment
 
To leverage the optimizations and basic improvements in the Lua environment, we have updated it to version 5.4.4. You can review the changes on the official website of the language (https://www.lua.org/manual/5.4/readme.html#changes. Still, please note the introduction of new features such as:
New generational mode for garbage collection
New attributes for variables (const and to-be-closed)
New implementation for math.random
New semantics for the integer 'for' loop
Optional 'init' argument to 'string.gmatch'
New function 'coroutine.close'
String-to-number coercions moved to the string library
New format '%p' in 'string.format'
 
- Replacement of the dkjson Library
 
For some time, we have been addressing performance issues with Lua systems. A significant factor related to these performance issues is the use of JSON. Thus, we reduced the use of JSON in favor of Lua tables. However, after consulting many of you, it appears that JSON is still widely used by our players. Hence, we decided to replace the dkjson library with the json.lua library (https://github.com/rxi/json.lua), a pure Lua library that is much more efficient.
 
We've added a compatibility patch to prevent your existing scripts from breaking.
 
- Boolean Type and Nil Support
 
Until now, booleans returned or used in the Lua API were treated as integers 0 or 1. While this may seem minor, it was crucial to resolve for several reasons, including performance and backend considerations.
 
Good news: we've now resolved this issue, allowing the Lua API to accept arguments and return real booleans! This will allow you to optimize your scripts.
 
Additionally, we've integrated nil. Until now, we could neither return nor accept nil as an argument. Again, while this may seem minor, resolving this issue allowed us to introduce the concept of optional arguments and optimize the Lua data stack. You will see its application in the additions we are introducing.
 
In addition to these visible fixes, we've made several backend improvements to the game's Lua binding. Consequently, we decided to use this opportunity to increase the instruction limit of the Lua environment (the limit that triggers the CPU OVERLOAD error). Starting from version 1.4, this limit will be increased from 2,000,000 to 10,000,000 instructions, accessible with the getInstructionCount and getInstructionLimit functions added to the Lua system API.
 
With this change in Boolean support, you will need to adapt your existing creations to ensure they continue to function as expected. We believe the benefits of these updates justify the effort and we appreciate your understanding and cooperation as we continue to improve the game's Lua environment.
 
Improvement of the Syntax Highlighting
 
We've enhanced the syntax highlighting in our code editor interface to simplify your coding experience. We understand that coding can be challenging, especially for beginners. That's why we took the time to create a straightforward syntax highlighting system to make coding in Dual Universe easier and more enjoyable.
 
While we've improved syntax highlighting, it isn't a full-fledged code analyzer. It's merely a tool to help you read and understand your code more easily. We aim to make coding more accessible and affordable for everyone, and we hope this update will contribute to that. The new system incorporates the coloring of APIs for system, unit, library, construct, player, and Lua operators.
 
Enrichment of the Lua Codex
 
We're thrilled to announce a new section in the Lua CODEX - the "Usage Example" section. This section provides detailed explanations and code examples to help you better understand how to use the functions within our API. It will be added to each function or event that requires further explanation.
 
We understand that learning to use a new API can sometimes be daunting, especially if you're new to coding. Therefore, we believe that providing examples, use cases, and deeper instructions on how to use the various functions in our API will help you better understand our game's API, making your coding experience more enjoyable.
 
 
Radar Data Pre-filtering
 
Despite our efforts to optimize and make the processing of radar data more flexible, particularly by integrating the getConstructs function to return the list of constructs in scope as a Lua table, we've considered and studied additional improvements.
 
Thanks to the integration of nil support in our Lua environment, we decided to improve the getConstructs function by adding the following optional pre-filters:
[bool] isMatching: True to filter out constructs with a matching transponder, false otherwise
[int] constructKind: The construct kind id to filter out constructs (Universe = 1, Planet = 2, Asteroid = 3, Static = 4, Dynamic = 5, Space = 6, Alien = 7)
[string] coreSize: The construct core unit size to filter out constructs ('XS', 'S', 'M', 'L', 'XL')
[bool] isAbandoned: True to filter out abandoned constructs, false otherwise
 
This filter is in the form of a table in the third argument of the getConstructs function. So you can, for example, filter:
{isMatching = true}, to list only constructs with a matching transponder
{isMatching = false, constructKind= 5}, to list only dynamic constructs with a non-matching transponder
As you can see, this filtering is combinable and optional, enabling you to filter the data you receive before processing it through Lua, allowing you to optimize your scripts.
 
Conclusion
 
We hope these updates and performance upgrades will improve your Lua experience in Dual Universe. There are still many other additions to the Lua API waiting to be discovered in this release. Happy exploring!

Greetings fellow Noveans,
 
im planning to offer a space, some cores for the public to build on and some free voxel material for a relaxed building jam-session.
All skill levels are welcome to join. If there is enough people interested i can imagine doing this in a bi-weekly or monthly schedule on Sundays between 16 and 19 UTC.
Starting this Sunday, may/7th
 
(Open to other timeframe suggestions, but i hope that time might be ok to give a wide range of time-zones the chance of participating)
 
First jam-session will be without a specific theme, just some free building and modeling.
(If you are interested in themed jams like for example: columns and pillars that might also be discussable)
 
So if you are interested in hanging around with some relaxed people and sharing some creative ideas, this might be a good chance
 
Everybody is welcome, this is a (mostly) nice community here and we got really strong tools for creating awesome designs in voxels, so let us share some creativity and inspire each other on creating even more insane structures on this vast playground.
 
Contact me in discord if you like: B0neshredder#9341
 

Hello, Noveans!
 
During our most recent livestream, NQ-Deckard and NQ-Entropy joined us and answered questions about upcoming features in update 1.4, which will be coming soon to Dual Universe. We know you have many questions, and to make it easier for you to stay informed, we wanted to summarize what was shared.
 
PvE Missions
 
We are excited to add PvE Combat missions in update 1.4, where players participate in missions against NPCs using familiar PvP mechanics. Here's an overview of what to expect in PvE Missions:
 
Difficulty Levels: Missions will have various difficulty levels, from very easy to very hard. Players can solo the lower tiers, but as the difficulty increases, players will need to team up to complete the missions using ships with a crew equipped with multiple sets of guns.
 
Challenging Gameplay: Even for experienced players, the higher-difficulty missions will be tough. Players will need to strategize and optimize their ships to achieve victory.
 
Customizable Mission Ships: Players must build their own mission ships within the parameters set by each mission. Restrictions may apply, such as not allowing large battleships in easy missions. Players can choose their preferred weapons, shields, and variants for their ships.
 
Instanced Battles: Missions will be instanced, using similar technology as VR challenges. However, players can now bring their own ships and enter the same instance alongside multiple other players. You must also supply your own ammunition, scrap, and fuel; any lost elements during the mission will be your loss.
 
Rewards: Completing missions will earn players quanta, addressing feedback requesting more ways to make in-game currency. PvE Combat provides an alternative method for players to fund their gameplay, similar to hauling missions.
 
Scaling Difficulty: The intention is for very easy missions to be accessible to new players with a few days of talents without requiring perfect equipment. As players progress to higher difficulties, missions become more demanding and require precise strategies.
 
Loss Consequences: We are currently finalizing what happens when players lose a mission, with the goal of not being overly punishing. One possibility is allowing players to salvage their ships if they fail a mission.
 
Mission Retreat: If players find a mission too difficult, they can retreat to the entry point to save their ship and resources. Completing the mission isn’t needed to escape.
 
More information about PvE Missions, including specifics on the consequences of losing a mission, will be provided as we develop and refine the feature.
 
PvP Changes
 
We are implementing significant changes to our PvP mechanics, including:
 
We’re changing the tracking formula that runs hit or miss calculations, especially the impact of ship cross-sections on the formula. We expect this to shift the meta away from lighter ships with small cross-sections by removing the protection they currently enjoy from the low probability of being hit by medium and large guns.
 
We’re also adjusting most parts of PvP, with changes to systems such as base weapon stats and removing debuffs from weapon variants.
 
Shield venting is also being changed, and stasis weapons are being buffed to make them more powerful and relevant to their role, for instance, in tackling small ships that get caught.
 
We are also investigating server issues and lag in PvP. To help us address these problems, please submit detailed reports with player names, ship names, times, and any other relevant information when lag occurs. These issues are difficult for us to replicate on our end, and being specific in your reports will enable us to analyze our logs better.
 
Planets
 
In Update 1.4, we aim to reintroduce two planets, each with exciting new features and locations:
 
Sicari: Retaining its original feel but visually enhanced with more interesting elements and a new location.
 
Sinnen: Completely reworked from the ground up and placed in a new location.
 
Following player feedback, we are experimenting with closer positioning for the new planets. Stay tuned for upcoming images showcasing these planets in the coming weeks.
 
Additionally, Update 1.4 will introduce three new Alien Core Units, enabling access to all types of plasma in the game.
 
LUA Changes
 
We are implementing several updates to the Lua system, which may cause temporary disruptions but are essential for long-term improvements. Some changes include:
 
Update Lua version to 5.4.4 Slightly improve the syntax highlighting Fixed the boolean type to return 'true' or 'false' instead of 1 or 0. Seeking faster solutions for JSON encoding and decoding.  
We've taken the opportunity to introduce some minor changes to radar to help filter signals.
 
We will have more detailed information coming on the Lua changes soon.

 
Joystick Support
 
This feature has taken significantly more resources than we had anticipated, but it does look like we’ll have full joystick support in update 1.4.

 
Thanks for reading, Noveans. If you have any questions about the PVE Mission System, you can submit them to our upcoming PvE special episode of Ask Aphelia using this form and we’ll do our best to answer them.
 
The Novaquark Team

Don't worry Dixiii!
 
No developers who work on the content that you're asking for were harmed in the creation of the April Fools change log, actually it wasn't even written in work time.
But I'll notify them that you're concerned for their well being. 👍
 
Happy April Fools.
- NQ-Deckard

The maintenance unit is not a replacement for the hand-tool. That said, the times are a bit too long and they should really be based on the actual amount that is to be repaired or deconstructed, not on core size imho.
 
And yes, the "set schematics container" menu needs to be moved from its current place.

Nope, same thing. Been like that since years.

If you don't want to play, don't. It is a game, not a job. No need to also shut it down for everyone else. Some of us love this game. 

Hi there me and some others tested PTS Saturday so maybe some similar sounding Feedback comes in.
Maintance Unit Working Fine Dismanteling an own Static L Core 12hours maybe a bit high but ok and working fine. But maybe it not helps if you want to dismantle a building on an other Players HQ Tile after the 90 Days Timer runs out if there was a machine still running or a container with stuff or schematics in it if the player can´t reach it if its buried under dirt. Repairing Ships with Scrap and Elements works fine.  But on this the Tile Owner need at least the rights for moving dynamic Construts that are being repaired/dismantled even if it ends in an abort of the repair or dismantle process. Me and some others think it maybe can end in Mass Trolling for example a Random Player could block your entrance or parking area by parking a Dynamic Core L Infront or ontop of it and start a repair on this construct with an other L Core Ship.Then noone can move that L Core until the Maintance Unit get stopped so it could be ending in an endless repair loop to blocking Static/Dynamic Constructs so at least the Tile Owner still needs the power to move that Constructs to stop the Maintance Unit. So needed Improvement is at least that the Tile owner still need to have full Power to move on all Dynamic Constructs on his own Tile to prevent trolling.    
best regards
Corgan7

Not an actual bug, but some general feedback. The time it takes to repair a ship seems based on core size with a time of 3h for an M-core. That seems very steep. I get it, it is not a replacement for the repair tool, but still. imho the time it takes to repair should be based on the amount of damage that it needs to repair, not a fixed time.
 
Also, are repair talents taken into consideration when using the maintenance unit to repair a ship?