NQ-Ligo

Hello everyone, I'll try to answer the questions above, but please understand that the fact that the booleans were not correctly binded was a real problem, both in the background and on the player side. Converting and/or comparing to an integer each time is far from optimal. In addition, default values, particularly useful for managing optional arguments (as you saw with the radar for 1.4 on this previous devblog) will now be better managed, saving a lot of operations in the DU code. It's important to understand that Booleans aren't just 0's and 1's behind the scenes, it's all about memory management and optimization. This problem has been in DU for a long time, in fact I've put off fixing it as long as possible so as not to break your scripts. However, this Lua polishing update to 1.4 required this fix, both for some additions, and to improve performance; and also to allow you to improve your performance. As far as major scripts or systems are concerned, I'm fully aware of the problem, and that's why I've tried to be in direct contact with their creators to prepare the transition as well as possible; even if it's clear that I can't do this for all scripts, I want to limit the damage to the community as much as possible. I'm also aware that this won't reassure everyone, and that some scripts you probably use a lot will be impacted. Thank you for your understanding. NQ-Ligo

Just to make sure it's not misunderstood. When I talk about content creation, I'm talking about User Generated Content. As @Wyndle says, it's more about systems/tools that allow you to create services, cities, events ...etc. But of course we also work on gameplay

I can confirm that there is still some development going on on the Lua feature. Don't worry, there are many things planned that have already been exposed to the Lua community; it just may take some time or wait for the integration of other features (like for example the known issue of remainingSchematics that will be solved with the integration of another feature soon). But no no, I'm still here and still working on extending the possibilities of Lua especially for content creation.

This could be a very interesting idea. I will share it with the team.

The schematicId field is deprecated, so return always 0, it's a relic of the industry API before the new schematics were implemented. For the known issue with updating schematicsRemaining field, we still have some work to do on the server, it will be fixed as soon as possible.

As explained in your stream this afternoon, the currentProductAmount is the amount of products produced by the industry since the last startup. However, there does seem to be a problem with the numbers being too high. I will check this with the server team.

I had planned to add the required number of schemas to the table returned by getRecipes, so this will certainly be added.

This is a good topic and good ideas. Redesigning the databank element is on the table for many reasons, including the impact on performances. However, I can't promise when, how...etc but it will certainly address some of the points in your suggestion.

As replied by @Yoarii, our goal is not to have everything accessible on the screen units. However, we have already discussed internally to have time related functions in the screen units. And we have also discussed adding a different IO for local use for larger data packages. Obviously, I can't promise anything, but know that these are things we have in mind.

To be more concrete, you can already link the axis inputs on different bindings in the game, like the look for example. But for the whole piloting gameplay, which needs joystick/hots support, we have to implement it properly on different levels, additional settings and C++/lua integration. My bad if my answer was not clear.

To answer your question, Dual Universe does have Joystick and Hotas support in the true sense of the word. Nevertheless, their integration in the gameplay, especially the piloting, requires some adjustments, additions and changes. This is something we want to integrate but it will probably only be integrated post-release.

@space_man I have identified your problem. Indeed, we did not add the depreciation of the getStatus function. We're fixing it for the Mercury update. Please report this type of problem to support next time to let us know that it happens.

Hi Noveans ! First of all thank you for telling us what you think of the additions and changes exposed in the devblog (although this is only a selection) and the global direction we chosen for the Lua feature, before you even formulate serial requests. Thanks Secondly, please understand that some changes can be much more complicated than they seem, especially due to architecture choices for the Lua binding made many years ago. Many of the changes require substantive changes and others are planned as general changes. Concerning the offline CODEX, it turns out that there were multiple reasons for its removal including maintainability issues, anyway, I just published the API mockup for the 0.30 Mercury on our official github to allow you to have it updated, here: https://github.com/dual-universe/lua-examples Moreover, a detailed thread is being finalized as exposed on the devblog, it will give you a much more detailed view of the changes by telling you what is new, by what has been replaced such or such function ... etc Regarding deprecation @space_man, it is a complete deprecation, nothing has been removed or changed without deprecation. I personally followed the Lua players tests to make sure that everything was working well, especially with the community custom systems like ArchHud. No concerns about deprecation have been reported. When a change of return type was made, we deprecated the old one and changed the name of the new one to avoid any problems. If any problem appeared, please report it to us with a ticket. Concerning the suggestions @P4rty_Boy, as always, I'll be happy to discuss them on a specific thread where you can tag me to explain them in more details. Overall, I really hope that all the changes will please and show the interest of Lua for us, many of them are not listed in this devblog and will be clearer on the detailed thread. Thank you.

NEW Weapon Displays information about the weapon's state Functions NEW [int] getAmmo(): Returns the item id of the currently equipped ammo NEW [int] getAmmoCount(): Returns the current amount of remaining ammunition NEW [int] getMaxAmmo(): Returns the maximum amount of ammunition the weapon can carry NEW [int] isOutOfAmmo(): Checks if the weapon is out of ammo NEW [int] isOperational(): Checks if the weapon is operational NEW [int] getStatus(): Returns the current weapon status return [int]: The current status of the weapon (Idle = 1, Firing = 2, Reloading = 3, Unloading = 4) NEW [int] getContainerId(): Returns the local id of the container linked to the weapon NEW [float] getHitProbability(): Returns the current hit probability of the weapon for the current target NEW [float] getBaseDamage(): Returns the base weapon damage NEW [float] getOptimalAimingCone(): Returns the optimal aim cone NEW [float] getOptimalDistance(): Returns the optimal distance to target NEW [float] getMaxDistance(): Returns the maximum distance to target NEW [float] getOptimalTracking(): Returns the optimal tracking rate NEW [float] getMagazineVolume(): Returns the magazine volume NEW [float] getCycleTime(): Returns the weapon cycle time NEW [float] getReloadTime(): Returns the weapon reload time NEW [float] getUnloadTime(): Returns the weapon unload time NEW [float] getTargetId(): Returns the id of the current target construct of the weapon Events NEW onReload([int] ammoId): Emitted when the weapon start reloading [int] ammoId: The item id of the ammo NEW onReloaded([int] ammoId): Emitted when the weapon has reloaded [int] ammoId: The item id of the ammo NEW onMissed([int] targetId): Emitted when the weapon has missed its target [int] targetId: The construct id of the target NEW onDestroyed([int] targetId): Emitted when the weapon target has been destroyed [int] targetId: The construct id of the target NEW onElementDestroyed([int] targetId, [int] itemId): Emitted when an element on the weapon target has been destroyed [int] targetId: The construct id of the target [int] itemId:The item id of the destroyed element NEW onHit([int] targetId, [float] damage): Emitted when the weapon has hit [int] targetId: The construct id of the target [int] damage: The damage amount dealt by the hit

Warp Drive Based on the principle of the Alcubierre drive, this unit creates a powerful negative energy-density field capable of distorting space-time and transport your ship at hyper speeds through space. Functions NEW initiate(): Initiate the warp jump process NEW [int] getStatus(): Returns the current status of the warp drive return [int]: The current status of the warp drive (NoWarpDrive = 1, Broken = 2, Warping = 3, ParentWarping = 4, NotAnchored = 5, WarpCooldown = 6, PvPCooldown = 7, MovingChild = 8, NoContainer = 9, PlanetTooClose = 10, DestinationNotSet = 11, DestinationTooClose = 12, DestinationTooFar = 13, NotEnoughWarpCells = 14, Ready = 15) NEW [float] getDistance(): Returns the distance to the current warp destination NEW [int] getDestination(): Returns the construct ID of the current warp destination NEW [string] getDestinationName(): Returns the name of the current warp destination construct NEW [int] getContainerId(): Returns the local id of the container linked to the warp drive NEW [int] getAvailableWarpCells(): Returns the quantity of warp cells available in the linked container NEW [int] getRequiredWarpCells(): Returns the quantity of warp cells required to warp to the warp destination set