NQ-Wanderer

Hello Noveans,
 
Major changes are coming to PvP in Dual Universe with the 1.4 update! We've engaged in numerous productive discussions both with members of our PvP community as well as internally. The balancing changes being introduced to PvP are a result of these conversations.
 
Before delving into the specifics, let's discuss the reasoning behind these changes.
 
In the early days of our beta, we started without shields, leading to a majority of PvP being fought in large cubic ships, which were generally less aesthetically pleasing. Our goal was to cultivate a space where players could transition from using thick voxel layers, leading us to introduce shields into the game for the first time about two years ago with the 0.26 Apollo update.
 
Shields quickly became an essential aspect of PvP combat. Consequently, ships rapidly evolved from having vast voxel quantities to featuring sleek designs with minimal voxels, presenting smaller targets and evading most incoming damage. This led to the inverse of the cube situation, with ships built into long sticks, sometimes devoid of voxels entirely.
 
In several previous updates, we have tried to strike a balance, providing players a reason to own ships that are not just cubes or sticks, but amazing constructs of beauty and lethality with your own personal style!
 
With the 1.4 update, we've revisited many aspects and made changes you’ll want to know:
 
We have revamped the hit-and-miss formulas used in the back end. Shields are less likely to serve as huge one-time batteries and will function more like periodic protection. The venting cycles are shorter and more frequent, allowing you to vent more often but for smaller amounts. Weapon Tracking has also undergone significant change, damage evasion is now a trait more likely to benefit smaller, swiftly moving and highly maneuverable ships, while larger ships have access to more potent stasis weapons to combat smaller ships. Honeycomb now has approximately twice as many hit points, enhancing its importance for tanking while your shields are being vented. Hoverseats and Cockpits now have a higher fitting capacity, enabling you to equip more weapons or a larger radar.  
We hope these changes will enhance PvP enjoyment for everyone. To help you better prepare for the update, here is a complete list of all PvP changes coming to Dual Universe in the 1.4 update, though please note that these updates are still subject to change:
 
Weapons

Cannon XS
Damage has decreased from 7000 to 6500 Optimal tracking has decreased from 10 to 2.75 Falloff tracking has decreased from 10 to 8.25
Cannon S
Damage has increased from 12950 to 13000 Period of fire has increased from 3.375 to 3.75 Optimal tracking has decreased from 5 to 1.1 Falloff tracking has decreased from 5 to 3.3  
Cannon M
Damage has increased from 23957.5 to 26000 Period of fire has increased from 4.55625 to 5.625 Optimal tracking has decreased from 2.5 to 0.44 Falloff tracking has decreased from 2.5 to 1.32  
Cannon L
Damage has increased from 44321.375 to 52000 Period of fire has increased from 6.1509375 to 8.4375 Optimal tracking has decreased from 1.25 to 0.176 Falloff tracking has decreased from 1.25 to 0.528  
Laser XS
Damage has increased from 8000 to 8500 Optimal tracking has decreased from 5 to 1.75 Falloff tracking has increased from 5 to 5.25 Optimal Range has increased from 12500 to 14000 Falloff distance has increased from 5000 to 7500 Weapon capacity has decreased from 80 to 70  
Laser S
Damage has increased from 14800 to 17000 Period of fire has increased from 4.725 to 5.25 Optimal tracking has decreased from 2.5 to 0.7 Falloff tracking has decreased from 2.5 to 2.1 Optimal Range has increased from 24000 to 28000 Falloff distance has increased from 10000 to 15000 Weapon capacity has decreased from 400 to 350  
Laser M
Damage has increased from 27380 to 34000 Period of fire has increased from 6.37875 to 7.875 Optimal tracking has decreased from 1.25 to 0.28 Falloff tracking has decreased from 1.25 to 0.84 Optimal Range has increased from 50000 to 56000 Falloff distance has increased from 20000 to 30000 Weapon capacity has decreased from 2000 to 1750  
Laser L
Damage has increased from 50653 to 68000 Period of fire has increased from 8.6113125 to 11.8125 Optimal tracking has decreased from 0.625 to 0.112 Falloff tracking has decreased from 0.625 to 0.336 Optimal Range has increased from 100000 to 112000 Falloff distance has increased from 40000 to 60000 Weapon capacity has decreased from 10000 to 8750  
Missile XS
Damage has increased from 14000 to 26000 Period of fire has increased from 3 to 5 Optimal tracking has decreased from 12 to 3.5 Falloff tracking has decreased from 12 to 10.5 Optimal distance has increased from 10000 to 12000 Weapon capacity has increased from 24 to 30 Reload has increased from 45 to 60  
Missile S
Damage has increased from 25900 to 37050 Period of fire has increased from 4.05 to 5 Optimal tracking has decreased from 6 to 1.4 Falloff tracking has decreased from 6 to 4.2 Optimal distance has increased from 20000 to 24000 Weapon capacity has increased from 120 to 150 Reload has increased from 45 to 60  
Missile M
Damage has increased from 47915 to 52796 Period of fire has decreased from 5.4675 to 5 Optimal tracking has decreased from 3 to 0.56 Falloff tracking has decreased from 3 to 1.68 Optimal distance has increased from 40000 to 48000 Weapon capacity has increased from 600 to 750 Reload has increased from 45 to 60  
Missile L
Damage has decreased from 88642.75 to 75234 Period of fire has decreased from 7.381125 to 5 Optimal tracking has decreased from 1.5 to 0.224 Falloff tracking has decreased from 1.5 to 0.672 Optimal distance has increased from 80000 to 96000 Weapon capacity has increased from 3000 to 3750 Reload has increased from 45 to 60  
Railgun XS
Damage has increased from 16000 to 17000 Optimal tracking has decreased from 3.5 to 1 Falloff tracking has decreased from 3.5 to 3 Optimal distance has increased from 20000 to 22000 Falloff distance has increased from 20000 to 22000 Reload has increased from 20 to 25  
Railgun S
Damage has increased from 29600 to 34000 Period of fire has increased from 9.45 to 10.5 Optimal tracking has decreased from 1.75 to 0.672 Falloff tracking has decreased from 1.75 to 1.2 Optimal distance has increased from 40000 to 44000 Falloff distance has increased from 40000 to 44000 Reload has increased from 20 to 25  
Railgun M
Damage has increased from 54760 to 68000 Period of fire has increased from 12.7575 to 15.75 Optimal tracking has decreased from 0.875 to 0.16 Falloff tracking has decreased from 0.875 to 0.48 Optimal distance has increased from 80000 to 88000 Falloff distance has increased from 80000 to 88000 Reload has increased from 20 to 25  
Railgun L
Damage has increased from 101306 to 136000 Period of fire has increased from 17.25 to 23.625 Optimal tracking has decreased from 0.4375 to 0.064 Falloff tracking has decreased from 0.4375 to 0.192 Optimal distance has increased from 160000 to 176000 Falloff distance has increased from 160000 to 176000 Reload has increased from 20 to 25  
Stasis XS
Minimum Range has increased from 20000 to 30000 Maximum Range has decreased from 100000 to 80000 Period of Fire has decreased from 5 to 4 Effect Duration has decreased from 5 to 4 Fitting has decreased from 500 to 225 Ammo Capacity has increased from 40 to 60 Reload Time has decreased from 50 to 10  
Stasis S
Minimum Range has increased from 20000 to 30000 Maximum Range remains unchanged at 100000 Period of Fire has decreased from 5 to 4 Effect Duration has increased from 5 to 6 Fitting has decreased from 2500 to 1125 Ammo Capacity has increased from 200 to 300 Reload Time has decreased from 50 to 20  
Stasis M
Minimum Range has increased from 20000 to 30000 Maximum Range has increased from 100000 to 120000 Period of Fire has decreased from 5 to 4 Effect Duration has increased from 5 to 8 Fitting has decreased from 12500 to 5625 Ammo Capacity has increased from 1000 to 1500 Reload Time has decreased from 50 to 30  
Stasis L
Minimum Range has increased from 20000 to 30000 Maximum Range has increased from 100000 to 140000 Period of Fire has decreased from 5 to 4 Effect Duration has increased from 5 to 10 Fitting has decreased from 62500 to 28125 Ammo Capacity has increased from 5000 to 7500 Reload Time has decreased from 50 to 40 Variants have received new bonus distributions and adjustments Defense now gives Range and Cone bonuses Agile now gives Damage and Tracking bonuses Heavy now gives Damage and Cone bonuses Precision now gives Range and Tracking bonuses Variant values have been adjusted. All debuffs removed.  
Ammo
 
Precision Ammo has had its Optimal Range buff reduced from 1.2 to 1.1 Heavy Ammo has had its Damage buff reduced from 1.2 to 1.05 Defense Ammo has had its Tracking reduced from 1.5 to 1.25 Agile ammo remains unchanged.
Control Units
 
The Cockpit and Hovercraft seat Max fitting capacity has increased from 1000 to 1250  
Shield Generators
 
Shield Generator XS:
Venting Cooldown has decreased from 60 to 30 Venting Regen per second has increased from 2500 to 9000 Max shield gain per regen has decreased from 0.5 to 0.25  
Shield Generator S:
Venting Cooldown has decreased from 120 to 60 Venting Regen per second has increased from 10000 to 28000 Max shield gain per regen has decreased from 0.5 to 0.35  
Shield Generator M:
Venting Cooldown has decreased from 240 to 120 Venting Regen per second has increased from 37500 to 64000 Max shield gain per regen has decreased from 0.5 to 0.45  
Shield Generator L:
Venting Cooldown has decreased from 480 to 240 Venting Regen per second has increased from 100000 to 102400 Max shield gain per regen has increased from 0.5 to 0.55  
Variants:
The Active variant will now have the hit points bonus. The Variable variant will now have the mass bonus. The Capacitor variant will now have the Volume bonus. Variant values have been adjusted.  
Voxel honeycomb healthpoints
 
All honeycomb HP values have roughly doubled (x2.08). For example Iron Honeycomb HP has changed from 6000 to 12500 per m3.
We hope that this preview of the PvP changelog has armed you with the information you need to prepare for update 1.4, and look forward to seeing your new warships after the update!
-The Novaqark Team
 

Hello, Noveans!
 
Update 1.4 is just days away, and we’re excited for you to experience the new PvE feature, where you'll battle against mysterious foes emerging from an unknown gravitational signature on the system's outskirts. As you fight to counter this sudden onslaught, you'll also buy time for scientists to identify the threat. The update’s narrative will progressively unlock through server-wide milestones as you complete combat missions.
 
But how can you prepare to engage with this feature on day one? We’re writing to share some information to assist you.
 
First, how can you take missions?
 
You’ll discover a new tab in your missions overview (F8) labeled Alien Warfare.
 


From here, you can choose the difficulty tier you’d like to tackle, specify the planet near which your mission will commence, see the restrictions (more on that below), accept your mission, and review the narrative as it unlocks!
 

 
Remember, there is no collateral needed for combat missions; you can take them on for free.
 
Once the mission is accepted, you can navigate to the mission entry portal, and when in proximity, click the button to teleport you, your passengers, and your ship to the mission site.
 

 
Should you wish to abort a mission, navigate to the beacon within the mission site and press the teleport button again in your mission interface (F8). If, for any reason, you can’t find the beacon, you can also set your waypoint there from the mission menu.
 
There are restrictions on what you can bring into each mission Tier
 
Forbidden in all Tiers:
Resurrection nodes Surrogate Pods Surrogate Stations Repair Units Warp Drives Core Units (Your ship’s Core Unit doesn’t count, but you can’t bring any additional cores into the mission, such as undeployed ones in your inventory.)
Very Easy Missions:
Reward: 260,000 quanta Max Mass: 50t Time Limit: 15 minutes Max Crew: 2 Maximum Ship Core Size: Extra Small Forbidden Items: Small, Medium, and Large Shields; Small, Medium, and Large Weapons  
Easy Missions:
Reward: 900,000 quanta Max Mass: 150t Time Limit: 25 minutes Max Crew: 3 Maximum Ship Core Size: Small Forbidden Items: Medium and Large Shields; Medium and Large Weapons  
Medium Missions:
Reward: 2,500,000 quanta Max Mass: 400t Time Limit: 30 minutes Max Crew: 4 Maximum Ship Core Size: Medium Forbidden Items: Large Shields; Large Weapons  
Hard Missions:
Reward: 5,000,000 quanta Max Mass: 1500t Time Limit: 40 minutes Max Crew: 5  
Very Hard Missions:
Reward: 7,000,000 quanta Max Mass: 2000t Time Limit: 50 minutes Max Crew: 6  
Tips on Completing Missions
 
The objective of the missions is to eliminate enemy forces that spawn within the time limit. You can monitor mission progress and remaining time here:
 

 
Bear in mind that enemy weapons will target you upon entry and are accurate. They will spawn and remain relatively close to you, and they will maintain range with your ship should you decide to kite.
 
We recommend equipping your vessel with potent close-range weapons and the highest tier of shield you can afford. You might also find it beneficial to vent your shields periodically when there's a lull in the combat. Experimenting with ammunition types and shield resistance settings will help you find your most effective setup.
 
While the standard piloting controls will work, you could explore player-made piloting and combat Lua control programs. These can enhance your effectiveness and ease your engagement with the enemy. DU Creators, a player-run website and Discord server, is a great place to start looking for new ships, buildings, and Lua scripts. However, if you don’t want to use custom Lua scripts, the game’s regular controls are still effective, especially with the use of the Tactical Map:
 

 
Lastly, consider planning your logistics. Mission portals will spawn near the planet you designate, and you’ll need to fly to it and return to resupply after the mission. Would a static ground base, an orbital station, or a larger carrier ship minimize the time you spend between missions rearming, refueling, and repairing? The choices are yours to experiment with. 

Update 1.4 is launching on the 20th of June 2023. Servers will go down at 08:00 UTC, and we aim to reopen them at 12:00 UTC. Prepare for a fight, Noveans!
 

Hello Noveans,
 
Major changes are coming to PvP in Dual Universe with the 1.4 update! We've engaged in numerous productive discussions both with members of our PvP community as well as internally. The balancing changes being introduced to PvP are a result of these conversations.
 
Before delving into the specifics, let's discuss the reasoning behind these changes.
 
In the early days of our beta, we started without shields, leading to a majority of PvP being fought in large cubic ships, which were generally less aesthetically pleasing. Our goal was to cultivate a space where players could transition from using thick voxel layers, leading us to introduce shields into the game for the first time about two years ago with the 0.26 Apollo update.
 
Shields quickly became an essential aspect of PvP combat. Consequently, ships rapidly evolved from having vast voxel quantities to featuring sleek designs with minimal voxels, presenting smaller targets and evading most incoming damage. This led to the inverse of the cube situation, with ships built into long sticks, sometimes devoid of voxels entirely.
 
In several previous updates, we have tried to strike a balance, providing players a reason to own ships that are not just cubes or sticks, but amazing constructs of beauty and lethality with your own personal style!
 
With the 1.4 update, we've revisited many aspects and made changes you’ll want to know:
 
We have revamped the hit-and-miss formulas used in the back end. Shields are less likely to serve as huge one-time batteries and will function more like periodic protection. The venting cycles are shorter and more frequent, allowing you to vent more often but for smaller amounts. Weapon Tracking has also undergone significant change, damage evasion is now a trait more likely to benefit smaller, swiftly moving and highly maneuverable ships, while larger ships have access to more potent stasis weapons to combat smaller ships. Honeycomb now has approximately twice as many hit points, enhancing its importance for tanking while your shields are being vented. Hoverseats and Cockpits now have a higher fitting capacity, enabling you to equip more weapons or a larger radar.  
We hope these changes will enhance PvP enjoyment for everyone. To help you better prepare for the update, here is a complete list of all PvP changes coming to Dual Universe in the 1.4 update, though please note that these updates are still subject to change:
 
Weapons

Cannon XS
Damage has decreased from 7000 to 6500 Optimal tracking has decreased from 10 to 2.75 Falloff tracking has decreased from 10 to 8.25
Cannon S
Damage has increased from 12950 to 13000 Period of fire has increased from 3.375 to 3.75 Optimal tracking has decreased from 5 to 1.1 Falloff tracking has decreased from 5 to 3.3  
Cannon M
Damage has increased from 23957.5 to 26000 Period of fire has increased from 4.55625 to 5.625 Optimal tracking has decreased from 2.5 to 0.44 Falloff tracking has decreased from 2.5 to 1.32  
Cannon L
Damage has increased from 44321.375 to 52000 Period of fire has increased from 6.1509375 to 8.4375 Optimal tracking has decreased from 1.25 to 0.176 Falloff tracking has decreased from 1.25 to 0.528  
Laser XS
Damage has increased from 8000 to 8500 Optimal tracking has decreased from 5 to 1.75 Falloff tracking has increased from 5 to 5.25 Optimal Range has increased from 12500 to 14000 Falloff distance has increased from 5000 to 7500 Weapon capacity has decreased from 80 to 70  
Laser S
Damage has increased from 14800 to 17000 Period of fire has increased from 4.725 to 5.25 Optimal tracking has decreased from 2.5 to 0.7 Falloff tracking has decreased from 2.5 to 2.1 Optimal Range has increased from 24000 to 28000 Falloff distance has increased from 10000 to 15000 Weapon capacity has decreased from 400 to 350  
Laser M
Damage has increased from 27380 to 34000 Period of fire has increased from 6.37875 to 7.875 Optimal tracking has decreased from 1.25 to 0.28 Falloff tracking has decreased from 1.25 to 0.84 Optimal Range has increased from 50000 to 56000 Falloff distance has increased from 20000 to 30000 Weapon capacity has decreased from 2000 to 1750  
Laser L
Damage has increased from 50653 to 68000 Period of fire has increased from 8.6113125 to 11.8125 Optimal tracking has decreased from 0.625 to 0.112 Falloff tracking has decreased from 0.625 to 0.336 Optimal Range has increased from 100000 to 112000 Falloff distance has increased from 40000 to 60000 Weapon capacity has decreased from 10000 to 8750  
Missile XS
Damage has increased from 14000 to 26000 Period of fire has increased from 3 to 5 Optimal tracking has decreased from 12 to 3.5 Falloff tracking has decreased from 12 to 10.5 Optimal distance has increased from 10000 to 12000 Weapon capacity has increased from 24 to 30 Reload has increased from 45 to 60  
Missile S
Damage has increased from 25900 to 37050 Period of fire has increased from 4.05 to 5 Optimal tracking has decreased from 6 to 1.4 Falloff tracking has decreased from 6 to 4.2 Optimal distance has increased from 20000 to 24000 Weapon capacity has increased from 120 to 150 Reload has increased from 45 to 60  
Missile M
Damage has increased from 47915 to 52796 Period of fire has decreased from 5.4675 to 5 Optimal tracking has decreased from 3 to 0.56 Falloff tracking has decreased from 3 to 1.68 Optimal distance has increased from 40000 to 48000 Weapon capacity has increased from 600 to 750 Reload has increased from 45 to 60  
Missile L
Damage has decreased from 88642.75 to 75234 Period of fire has decreased from 7.381125 to 5 Optimal tracking has decreased from 1.5 to 0.224 Falloff tracking has decreased from 1.5 to 0.672 Optimal distance has increased from 80000 to 96000 Weapon capacity has increased from 3000 to 3750 Reload has increased from 45 to 60  
Railgun XS
Damage has increased from 16000 to 17000 Optimal tracking has decreased from 3.5 to 1 Falloff tracking has decreased from 3.5 to 3 Optimal distance has increased from 20000 to 22000 Falloff distance has increased from 20000 to 22000 Reload has increased from 20 to 25  
Railgun S
Damage has increased from 29600 to 34000 Period of fire has increased from 9.45 to 10.5 Optimal tracking has decreased from 1.75 to 0.672 Falloff tracking has decreased from 1.75 to 1.2 Optimal distance has increased from 40000 to 44000 Falloff distance has increased from 40000 to 44000 Reload has increased from 20 to 25  
Railgun M
Damage has increased from 54760 to 68000 Period of fire has increased from 12.7575 to 15.75 Optimal tracking has decreased from 0.875 to 0.16 Falloff tracking has decreased from 0.875 to 0.48 Optimal distance has increased from 80000 to 88000 Falloff distance has increased from 80000 to 88000 Reload has increased from 20 to 25  
Railgun L
Damage has increased from 101306 to 136000 Period of fire has increased from 17.25 to 23.625 Optimal tracking has decreased from 0.4375 to 0.064 Falloff tracking has decreased from 0.4375 to 0.192 Optimal distance has increased from 160000 to 176000 Falloff distance has increased from 160000 to 176000 Reload has increased from 20 to 25  
Stasis XS
Minimum Range has increased from 20000 to 30000 Maximum Range has decreased from 100000 to 80000 Period of Fire has decreased from 5 to 4 Effect Duration has decreased from 5 to 4 Fitting has decreased from 500 to 225 Ammo Capacity has increased from 40 to 60 Reload Time has decreased from 50 to 10  
Stasis S
Minimum Range has increased from 20000 to 30000 Maximum Range remains unchanged at 100000 Period of Fire has decreased from 5 to 4 Effect Duration has increased from 5 to 6 Fitting has decreased from 2500 to 1125 Ammo Capacity has increased from 200 to 300 Reload Time has decreased from 50 to 20  
Stasis M
Minimum Range has increased from 20000 to 30000 Maximum Range has increased from 100000 to 120000 Period of Fire has decreased from 5 to 4 Effect Duration has increased from 5 to 8 Fitting has decreased from 12500 to 5625 Ammo Capacity has increased from 1000 to 1500 Reload Time has decreased from 50 to 30  
Stasis L
Minimum Range has increased from 20000 to 30000 Maximum Range has increased from 100000 to 140000 Period of Fire has decreased from 5 to 4 Effect Duration has increased from 5 to 10 Fitting has decreased from 62500 to 28125 Ammo Capacity has increased from 5000 to 7500 Reload Time has decreased from 50 to 40 Variants have received new bonus distributions and adjustments Defense now gives Range and Cone bonuses Agile now gives Damage and Tracking bonuses Heavy now gives Damage and Cone bonuses Precision now gives Range and Tracking bonuses Variant values have been adjusted. All debuffs removed.  
Ammo
 
Precision Ammo has had its Optimal Range buff reduced from 1.2 to 1.1 Heavy Ammo has had its Damage buff reduced from 1.2 to 1.05 Defense Ammo has had its Tracking reduced from 1.5 to 1.25 Agile ammo remains unchanged.
Control Units
 
The Cockpit and Hovercraft seat Max fitting capacity has increased from 1000 to 1250  
Shield Generators
 
Shield Generator XS:
Venting Cooldown has decreased from 60 to 30 Venting Regen per second has increased from 2500 to 9000 Max shield gain per regen has decreased from 0.5 to 0.25  
Shield Generator S:
Venting Cooldown has decreased from 120 to 60 Venting Regen per second has increased from 10000 to 28000 Max shield gain per regen has decreased from 0.5 to 0.35  
Shield Generator M:
Venting Cooldown has decreased from 240 to 120 Venting Regen per second has increased from 37500 to 64000 Max shield gain per regen has decreased from 0.5 to 0.45  
Shield Generator L:
Venting Cooldown has decreased from 480 to 240 Venting Regen per second has increased from 100000 to 102400 Max shield gain per regen has increased from 0.5 to 0.55  
Variants:
The Active variant will now have the hit points bonus. The Variable variant will now have the mass bonus. The Capacitor variant will now have the Volume bonus. Variant values have been adjusted.  
Voxel honeycomb healthpoints
 
All honeycomb HP values have roughly doubled (x2.08). For example Iron Honeycomb HP has changed from 6000 to 12500 per m3.
We hope that this preview of the PvP changelog has armed you with the information you need to prepare for update 1.4, and look forward to seeing your new warships after the update!
-The Novaqark Team
 

Greetings, Noveans!
 
Every gamer is unique, each boasting their own preferred playstyle, control setup, and comfort zones. Your game controls should reflect this individuality. That's why our Input Remapping Upgrades, coming soon in Update 1.4, are designed to give you more control - literally and figuratively.
 
Dual Universe hosts numerous controls, many of which have been hidden from players. Our Input Remapping Upgrades will vastly expand the game's control settings, making these hidden controls visible and customizable. You can rebind them to your preferred keys… including those on gamepads and joysticks! Both systems are now correctly supported. For instance, you can bind specific controls to the axis turn of a joystick.
 
In addition, we've introduced many new controls, allowing you to personalize your settings with intricate detail. If you’re a player who enjoys crafting your control schemes, you’ll find these new options on our control settings page.
 
This is just the beginning, Noveans. We’re already working on introducing more features to Input Remapping in the future, such as the ability to import and export control profiles to the server, allowing for seamless importing into applications like GeForce Now. We also aim for more direct Lua integration in future versions.
 
These changes are designed to empower you and make Dual Universe more accessible by supporting gamepads, joysticks, and more. Whether you plan to intricately craft your control schemes or simply enjoy flying across Helios with a HOTAS system, we hope you’ll have a great time with the Input Remapping Upgrades in Update 1.4.
 
The Novaquark Team
 

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

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

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

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

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

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

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

Greetings, Noveans!
 
Every gamer is unique, each boasting their own preferred playstyle, control setup, and comfort zones. Your game controls should reflect this individuality. That's why our Input Remapping Upgrades, coming soon in Update 1.4, are designed to give you more control - literally and figuratively.
 
Dual Universe hosts numerous controls, many of which have been hidden from players. Our Input Remapping Upgrades will vastly expand the game's control settings, making these hidden controls visible and customizable. You can rebind them to your preferred keys… including those on gamepads and joysticks! Both systems are now correctly supported. For instance, you can bind specific controls to the axis turn of a joystick.
 
In addition, we've introduced many new controls, allowing you to personalize your settings with intricate detail. If you’re a player who enjoys crafting your control schemes, you’ll find these new options on our control settings page.
 
This is just the beginning, Noveans. We’re already working on introducing more features to Input Remapping in the future, such as the ability to import and export control profiles to the server, allowing for seamless importing into applications like GeForce Now. We also aim for more direct Lua integration in future versions.
 
These changes are designed to empower you and make Dual Universe more accessible by supporting gamepads, joysticks, and more. Whether you plan to intricately craft your control schemes or simply enjoy flying across Helios with a HOTAS system, we hope you’ll have a great time with the Input Remapping Upgrades in Update 1.4.
 
The Novaquark Team
 

Greetings, Noveans!
 
Every gamer is unique, each boasting their own preferred playstyle, control setup, and comfort zones. Your game controls should reflect this individuality. That's why our Input Remapping Upgrades, coming soon in Update 1.4, are designed to give you more control - literally and figuratively.
 
Dual Universe hosts numerous controls, many of which have been hidden from players. Our Input Remapping Upgrades will vastly expand the game's control settings, making these hidden controls visible and customizable. You can rebind them to your preferred keys… including those on gamepads and joysticks! Both systems are now correctly supported. For instance, you can bind specific controls to the axis turn of a joystick.
 
In addition, we've introduced many new controls, allowing you to personalize your settings with intricate detail. If you’re a player who enjoys crafting your control schemes, you’ll find these new options on our control settings page.
 
This is just the beginning, Noveans. We’re already working on introducing more features to Input Remapping in the future, such as the ability to import and export control profiles to the server, allowing for seamless importing into applications like GeForce Now. We also aim for more direct Lua integration in future versions.
 
These changes are designed to empower you and make Dual Universe more accessible by supporting gamepads, joysticks, and more. Whether you plan to intricately craft your control schemes or simply enjoy flying across Helios with a HOTAS system, we hope you’ll have a great time with the Input Remapping Upgrades in Update 1.4.
 
The Novaquark Team
 

Greetings, Noveans!
 
Every gamer is unique, each boasting their own preferred playstyle, control setup, and comfort zones. Your game controls should reflect this individuality. That's why our Input Remapping Upgrades, coming soon in Update 1.4, are designed to give you more control - literally and figuratively.
 
Dual Universe hosts numerous controls, many of which have been hidden from players. Our Input Remapping Upgrades will vastly expand the game's control settings, making these hidden controls visible and customizable. You can rebind them to your preferred keys… including those on gamepads and joysticks! Both systems are now correctly supported. For instance, you can bind specific controls to the axis turn of a joystick.
 
In addition, we've introduced many new controls, allowing you to personalize your settings with intricate detail. If you’re a player who enjoys crafting your control schemes, you’ll find these new options on our control settings page.
 
This is just the beginning, Noveans. We’re already working on introducing more features to Input Remapping in the future, such as the ability to import and export control profiles to the server, allowing for seamless importing into applications like GeForce Now. We also aim for more direct Lua integration in future versions.
 
These changes are designed to empower you and make Dual Universe more accessible by supporting gamepads, joysticks, and more. Whether you plan to intricately craft your control schemes or simply enjoy flying across Helios with a HOTAS system, we hope you’ll have a great time with the Input Remapping Upgrades in Update 1.4.
 
The Novaquark Team
 

Greetings, Noveans!
 
Every gamer is unique, each boasting their own preferred playstyle, control setup, and comfort zones. Your game controls should reflect this individuality. That's why our Input Remapping Upgrades, coming soon in Update 1.4, are designed to give you more control - literally and figuratively.
 
Dual Universe hosts numerous controls, many of which have been hidden from players. Our Input Remapping Upgrades will vastly expand the game's control settings, making these hidden controls visible and customizable. You can rebind them to your preferred keys… including those on gamepads and joysticks! Both systems are now correctly supported. For instance, you can bind specific controls to the axis turn of a joystick.
 
In addition, we've introduced many new controls, allowing you to personalize your settings with intricate detail. If you’re a player who enjoys crafting your control schemes, you’ll find these new options on our control settings page.
 
This is just the beginning, Noveans. We’re already working on introducing more features to Input Remapping in the future, such as the ability to import and export control profiles to the server, allowing for seamless importing into applications like GeForce Now. We also aim for more direct Lua integration in future versions.
 
These changes are designed to empower you and make Dual Universe more accessible by supporting gamepads, joysticks, and more. Whether you plan to intricately craft your control schemes or simply enjoy flying across Helios with a HOTAS system, we hope you’ll have a great time with the Input Remapping Upgrades in Update 1.4.
 
The Novaquark Team
 

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!

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!

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!

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!

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!

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!

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!

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!

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!

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!