archaegeo/dualuniverseluaissues

DualUniverse LUA Issue Tracking

dualuniverseluaissues's Issues

Unify autoconf and paste json mechanisms, clean them up, and document them

TL;DR it would be nice to have all of this rationalised, cleaned and documented.

---

The differences between these two mechanisms are a little bit odd, and feel anachronistic.

You can't apply autoconf files to keyboard controllers, which doesn't make a great deal of sense, as the auto-linking mechanism is potentially useful.

Similarly, you can't (as far as I know) get auto-linking with the JSON format although in theory I can see no reason why it couldn't be added.

The

"type": {
                "methods": [],
                "events": []
            }

section of the JSON is either an un-used legacy of an earlier age, or perhaps an undocumented feature that could still be useful?

The slot naming and element linking support in JSON is not very useful, based as it is on slot position rather than element class.

Meanwhile there are some potentially useful features of either/both mechanisms that are missing:

• being able to suppress the generation of the _autoconf table but keep the linking
• being able to specify event handlers to apply to all elements of a given class where select: all is set, rather than having to enumerate them as _1, _2, etc (maybe this is possible? I haven't figured out the syntax yet if so)

Overall, it's a bit of a mess, which would be nice to have cleaned up.

Request ability to hide build helper via lua script while in control unit

Need an ability to hide the build helper while in a seat/remote using lua.
I.e. buildHelper.hide()

impossible to get recipe from Transfer Unit

Probably as it is not really using a schematic, the method getCurrentSchematic() is not returning the recipe chosen on a transfer unit

3D Transforms for the Screen API

Simply... a way to rotate things in a 3D way using the screen API.
A use-case I would have, should it come to the HUD, would be the transformation of text as there is no simple way to do that.

Reliable Time not available in LUA

In various situations we need a reliable "time" in game which is the same for all players no matter in which TZ their client runs.
Currently the time we can retrieve is depending on local real life PC time and timezone settings which makes it unusable in multiplayer use cases. as it could easily be "cheated" by the player changing local PC time or TZ settings.
Ideally just add an API to retrieve e.g. GMT time which does not take local PC time as its base.

Time/Date Library

Simply a library to help convert the current system.getTime() value into a date and time format.

For example, converting it into Tuesday, 12 October 2021, or 12/10/2021, or 5:32 PM, and so on.
Maybe some built-in support for an actual time as well so you can respect time zones.

Required new functionality to allow easy update of DRM protected LUA

As a LUA Developer in DU i want an easy possibility to allow my customers to update their LUA.
As it is today, the only way to "sell" LUA code without open sourcing it is to sell a whole DRM construct under your own creator ID.
If the original creator wants to make an update available to his customers, this can only be done manually on a per construct level and has to be done by the original creator due to DRM.
tbh, as it is today i am often holding back LUA code as i simply do not want to end up into having a full time job in DU just taking care of updates etc.
We need an easy mechanism that enables us to support our customers.
One possibility would be something like a LUA Update data element that could e.g. be sold or given away for free via a dispenser. This Lua Update data element can then only be applied once to a Construct and would re-apply the LUA to an existing Seat / PGM Board. Like a self destroying USB Stick that updates a constructs LUA

Without a possibility like this, we are stopping the developments / distribution of new LUA stuff, as usually a developer does not like to end up in "support hell"

Rendering API setOutput fails if it contains a quote

This is what I'm currently seeing, anyway.

If I send a string with a quote in, I get an error. If I escape the quote (JSON-style), it works ok.

My guess is that under the hood the string is being turned into JSON without getting escaped.

See also #47 which would fix it.

getKeys changed to getKeyList

this function is used on many scripts, to read keys from connected database (json.decode(getKeys()...

when i replaced this like it is intended these scripts wont work.
i am only the user of these scripts, so i do not know if its set up ok

i guess, getKeyList() is a new function introduced in Mercury Update? but the getKeys() is not deprecated, like other functions

Game FOV settings are off from the actual camera FOV [Bug][Game Settings][Camera]

In action of changing the game settings for resolution or fov sometimes the fov recorded in the settings becomes inaccurate to the game view settings. This affects the lua api for returning the one that is accurate to the camera.

From some testing when this occurs the fov value is offset by 10000th of your screen height + width of a degree
This does not quite match up with the value in settings.yaml which is different from the game settings so something weird is going on and is hard to account for with lua.

Here is the example settings file:

system:  # System settings
  vsync: false  # Enable vertical synchronization
  cameraSettings:  # Player camera settings
    znear: 0.1  # Near distance
    fov: 37  # Vertical FOV (we present horizontal FOV to players, beware these are not the same)

Here is how that setting looks in game:

Character Lights

I was thinking about the camera API over the weekend, and sort of thought of a small thing to add along with it: the ability to get the state of your character lights and maybe turn them on and off. Something like this:

system.getPlayerLightState(pid) -> returns true or false
system.setPlayerLightState(cid, true/false) -> enables or disables it respectively. Could

It's a small thing with little actual use, aside from perhaps controlling user lights since some ships look bad when you use your lights, ship builders could add a detection zone to specifically disable and enable them depending on where you go automatically, or simply find out who is using a light.

Input exposure

Inputs, such as mouse clicks, keys on your keyboard, joysticks, all have inputs that should be readable. A generalized onInput() with the ability to get an input ID. You could map these inputs to certain actions, like pitching down when pitching down on your joystick.
Also, mouse clicks.
An instance would be my AR HUD. You could right-click to bring up a custom AR context menu to select actions, or left click to select something.

"Wearable" core

(This idea has substantial scope I realise, and it's not all Lua, but I'm posting it here because the point would be having another place to host lua scripts).

Something I've wanted forever is some sort of "wearable core".

Something you can equip which has controller functionality, and can host scripts that move with your character, and are not attached to a vehicle or static entity.

They could be used for UI enhancement - to add HUDs and interfaces that manipulate things like your wallet, for enhanced comms via the chat window, and all sorts of other things.

You could look at it as a personal core, or as a custom tool you equip (though I think you'd want it to be active whilst using other tools), or even as "clothing".

Possibility to change Default Element Tags

Once upon a time it was possible to change the default tags of elements. By the best of my memory, I do not know the reason why this abiloty was changed, but not changing default tags keeps leading into restrictions when you want to work with "default" tags alongside non default tags.

An example are hovers and vertical boosters: Both are by default targetted by the default groundaltitude. There are situations where one simply does not want the default script to apply to all hovers/vertical boosters and the only current alternative is to develop a whole new groundaltitude function, instead of selectively employing the existing one.

LUA screens do not support text rotation

Currently it is not possible using the new LUA screen functions to rotate text. As a result, is it is not possible to have a screen in portrait orientation with text.

The only way to add text using the new functions is
addText(layer, font, text, x, y)

But the documentation states that this function does not support rotation
Screenshot: https://imgur.com/a/GHxK0w8
Documentation: https://board.dualthegame.com/index.php?/topic/22643-lua-screen-units-api-and-instructions-updated-19072021/

Text rotation is essential and should be high priority as many people use screens in portrait orientation and this will harm adoption of the new API

Rendering input/output should be a Lua object

Honestly, what's with the whole string-thing?

It just makes us do work every time we want to send something non-trivial, which you could easily do for us.

You are probably turning it into JSON behind the scenes, so if you want to impose a size limit (eg 1000 characters or whatever), just apply it to the JSON-encoded form of the object.

Would help with #46 too.

UTC/Ark Time on Lua screens

Basically, would be nice if we were able to fetch both UTC and the Ark times from our Lua screens instead of having to rely on a PB. This would allow us for example to create cool details such as clocks etc.

Retrieve the name of the current construct

I was working on some lua code and wanted to show the name of the current construct ... but it is not possible
It is possible to get the name of every element also the name of the core.

But there is no way to get the name of the construct represented by the core

would suggest something like core.getConstructName()

Lua Market

Premise: Selling scripts in DU is almost entirely done through Discords and, usually, such events are one-time transactions. The issue with this model is that not everyone uses Discord, and not everyone really can be bothered with contacting something through Discord to try to purchase a script, especially considering it's a one-time deal. Especially considering DRM outright makes modification impossible.

Solution: Scripts can be sold through the market or a similar system, or subscribe to a script and attach it to whatever they want. The seller can limit the number of times the script could be added and push updates dynamically to any scripts. Additionally, this may open up the possibility of having "subscription fees", something where you can subscribe to a script for X amount of time and receive all updates. However, if you cancel the subscription, updates no longer pushed to your Lua scripts.

Challenges: This, first and foremost, would be an enormous undertaking due to the numerous UI elements needed and the mechanics for updating a script. Tracking what needs to be updated and how it is updated, ensuring people can't abuse the subscription fee model, etc., all need to be considered.

@ZarTaen, @Archaegeo and @matt225022, do you have any further suggestions?

Improved databank API

A table-like interface should be supported for databanks, which works with real values, and requires no translation to/from strings or JSON.

This should include the ability to store sub-tables without first encoding them.

Event listeners

In general listening for events is more efficient than polling for status. Currently though, to listen for events a script author has to explicitly set up filters for each slot.

This does not really support general purpose scripts. It would be much better if scripts could register to listen for events using an API:

system.listenFor("statusChanged", elementID, function(status)
-- do something with new status
end)

This would also allow us to receive events for elements that are not explicitly connected to the controller.

system.setScreen() is delayed

Going frame by frame, I determined that system.setScreen(HTML) is delayed by exactly one frame. This becomes really problematic for an AR interface in low framerate scenarios.
Of course, this may just be a limitation, and as such, I request if the new Lua draw API comes to the HUD addresses this if it does not.

container.acquireStorage() method is not 10 queries per five minutes like the description says

The current description of the container.acquireStorage() method says "(only 10 queries/5min)", but in actuality 10 calls to container.acquireStorage() can be made and then a 5-minute cooldown is initiated, no matter the spacing of the calls.

It would be much more beneficial to lua coders to have it be a max of 10 calls in a 5-minute rolling timeframe, rather than making 9 calls (either spaced out or in quick succession) and then having the 10th (no matter how long after the 9th call) trigger a 5-minute cooldown. Even if you make 9 calls that are spaced out, the 10th triggers the cooldown and breaks any subroutine you may have had going at the time - this is less than ideal and fixing it would greatly improve the flexibility of utilizing this method.

A popular use case would be a container inventory monitor, of course. Another use case that's a bit more complex would be for Organization container logs, so that an Org could keep track of what members added or removed items from a particular container they have access to.

Industry schematic bank is not readable

Lua scripts cannot read the contents of an industry unit schematic bank.

This makes the setCurrentSchematic function a lot less useful, as it requires schematic IDs to be hardcoded or otherwise entered into the script.

Databanks with many keys freeze the game

Databank operations take a long time when the databank stores many keys.

The following script freezes the game for almost 2 minutes:

databank.clear()

local t_start = system.getTime()

for i = 1, 3000 do
    databank.setIntValue(tostring(i), 0)
end

system.print(string.format("Total time: %.10f", system.getTime() - t_start))

Suggestions:

• optimize databank operations to take less time
• limit the max number of keys in a databank to less than 500
• manually decrement the Lua instruction counter (hookcount of lua_State) in databank functions (to make the databank functions more "expesive" to call and have them trigger the CPU overload error)

Allow using system.lockView(1) with remote controllers

Please allow using system.lockView(1) in Lua scripts running on remote controllers. As of r0.25.12 calling this function does nothing on remote controllers.

Since system.freeze(1) already works with remote controllers, there is no reason why system.lockView(1) should be disabled.

Document the rules for processor overload, and provide diagnostics

I have a script which occasionally overloads. It is a complex script with a lot of lua objects, and it's not at all clear why it is overloading.

It would be very helpful to have the rules clearly documented somewhere. It would be even more useful if some diagnostic output was printed to the console saying why the overload occurred, and giving a stack trace.

Elementification of Lua

Intro

I struck a conversation with ZarTaen#6409 on how restrictive YOLOL code was in Starbase, how you had to have so many of this to do that, but, honestly, it's not a terrible idea. But instead of restricting what you can do currently, rather, it would be better to improve what you can do currently.

Elementification

Essentially, Lua could be expanded to include more elements you link together. Like how you link a fuel tank to an engine to give it the fuel it needs to run, Lua should also link to elements to expand the functionality it could provide.
The current code limit of 200KB could be expanded through a "memory module" by another 100KB, up to two memory modules. Each module would be expensive to purchase, requiring tier three or four items to make.
Then you could add a CPU module to expand the execution limit or enable multi-threaded execution, up to 2.
Furthermore, you could add a graphics module to enable HUD screens.
Maybe even a dedicated display unit that displays how close you are in % of reaching the CPU limit.

Lastly, maybe it could tie into the energy/CPU system.

Mouse Scroll wheel on screens

Screens lack mouse scroll wheel recognition which could be utilized for something like list scrolling without doing janky approach over programmable boards.

More C/C++ Methods

Simply put, I've noticed a large number of the Lua community suggesting certain things be implemented on a lower level, especially JSON processing. So, to that effect, similar to library.systemResolution3(...), library should also have the following:

library.decode/library.decodeJSON

library.encode/library.encodeJSON

Less commonly, here are some of my recommendations:
library.systemResolution4(...) so 4x4 matrices could be done.

Then, while I'm here, I'll suggest that the currently vec3, quaternion, matrix4, and so on, should all be implemented under library like the following, though it is probably unlikely to be implemented:

local vec3 = library.vec3
local vector = vec3({0,0,0})
vector.normalize()
-- and so on

local quaternion = library.quaternion
local quat1 = quaternion({0,0,0,1})
local quat2 = quaternion({0,0,0,1})
quat1.multiply(quat2)
-- and so on

Technically, the actual C methods lie in the "multiply" or "normalize" calls, with just the initial preamble for initiating and organizing it under the library title.

Adding additional script to DRM'ed control - programming board

Ideal would be for DRM to only apply to scripts on the control unit / programming board when DRM is set, or different levels of DRM.

This would let you "buy" someone's chair with their script on it, but still add more scripting to it without loss of DRM but still having access to the existing script running (and with API/Hooks if made available).

EX: Someone write a new engine script DLL. They DRM and sell it, and others can use calls to it for engine control without changing/taking the base code. Or someone wants to add additional functionality to existing script on a control seat/pb.

Databank support or data store for Lua screens

Basically, the idea here is that we could link a databank to a Lua screen and have an API to access its contents. Right now any larger inputs need to be "buffered" with a PB into the input field, which not only is slow but probably ends up taking a toll on the server. Having screens being able to directly access databanks or at least having an internal data store could potentially improve this.

DataBank modify event

As simple as that. Currently we have to constantly read databank and check if stored data got any new updates, if we could have basic event firing when databank gets updated with new value then it would save allot of headache and would provide more optimized and better working scripts which rely on databank for data synchronization and similar purposes.

Need LUA access to camera location and orientation

Need to be able to query via lua the in game camera location and its orientation.

Implement getProductInfo(productType)

Analogous to getSchematicInfo(schematicId), but returning information about a particular product, indexed by the type that getSchematicInfo supplies for products.

It would return a JSON record containing such useful things as:

• the full item name
• the item tier
• the item type
• the item mass
• the item volume
• the primary schematic ID for the product
• the ids of other schematics which produce the item as an additional product

Industry quantities are wrongs

On industry data, depending on the mode (maintain, batch, ...) the setted amount returned in lua is not all the time the good value and it's most of the time a really big value.

Script editor should re-open on the previously selected slot/event

(previously posted here)

Not strictly a Lua improvement, but definitely a quality-of-life scripting improvement:

When re-opening the script editor on a control unit, the previously selected slot and event should be re-selected, and the text cursor should be restored to its previous position.

Version The API

As discussed in various threads on Discord and/or the forums, the API should be versioned (probably using semantic versioning).

This would have some major benefits:

• a new, cleaner v2 API could be introduced without breaking old scripts
• the controller could tell the game which major version of the API it wants to use
• scripts could query the minor version at runtime to work around problems when deployed in different environments (eg on the PTS, or internal staging servers)

Another benefit of this is that it would be possible to silently roll out new API features to the live servers, without them being picked up by all scripts.

In addition to picking API v1 or v2 in the controller's UI, it would be possible to allow users to pick a prerelease bleeding-edge version, which would enable new functionality that's under test. It would also be possible for users with special privileges (eg the game developers) to pick a internal API version that only they could use.

So a new feature might first be rolled out to the internal API version. Once it had been verified as working without unexpected consequences, it could be promoted to the prerelease API version, for the Lua development community to test. Once any feedback from that had been taken on board, and any regressions fixed, it could be incorporated into the official v2 API - at which point all constructs in the game using the v2 API would get the new changes.

This would provide a safe mechanism for testing scripts in the live server environment, before making them part of an official API update. Which might help a bit with some of the regressions we see.

Direct Access To Element Objects

(originally posted here)

It seems fairly crazy that we can iterate the core to get basic information about the id, type, etc of each element (using getElementIdList(), getElementNameById, ...), but we can't get the actual element objects that way. We have to link them, then access the named variables connected with each link. If we want to iterate all linked elements, we have to build our own table and write manual code to add the elements to it.
That doesn't make a lot of sense!

I would suggest deprecating most of the existing API, and just having two element related methods:

• getElementIdList() -- return a list of the ids of all elements in this core
• getElementById(uid) -- return the element object for the given element

All other properties can then be read from the existing element API:

• getElementClass()
• getHitPoints()
• getMaxHitPoints()
• getMass()
  etc...

A few element API additions would be good:

• getName()
• setName(newName)
• getSize() -- return the size (xs, s, m, l, xl)
• getPosition() -- position in construct local coordinates
• getOrientation() -- orientation in construct local coordinates

Add INS (view) to actionOnStart/Stop/Loop

Need INS added to keys seen by actionOnStart/Stop/Loop in order to tell when camera view changes. Alternately a queryCameraView(). Or both.

Additional Import Libraries

Some things are better imported into Lua rather than directly placed. An excellent example is the atlas. A highly detailed list of planets. If you added it directly in your script, you would use a significant amount of your script size budget for it.
Additionally, if anything changes, NQ can ensure that data is up to date.

So, as for the list, here it goes:

• Atlas
• Skill Data
• Item Data
• Schematic Data

Skill data would link into item data so you can do your own calculations for skill bonuses. Additionally, optimally we would have an API along with it to get the effects of a skill.

Schematic Data could be used to assist in creating a list of things to buy at the market automatically.
Example Skill Data Format:

{
   [sId] = { -- skill Id
       name = "Name",
       description = "Description",
       effect = effectId, -- If an effect is based off an ID, not sure the internals
       level = 1,
       multiplier = 0.05 -- Percentage amount per level
   }
}

Example Schematic Data

{
    [sId] = { -- schematic Id
        name = "Name",
        description = "Description",
        item = itemId,
        tier = 1
    }
}

Example Item Data

{
    [sId] = { -- item Id
        name = "Name",
        description = "Description",
        schematic = schematicId,
        tier = 1,
        skills = {skillId1,skillId2,...}
    }
}

As for Atlas, something like the one found here: https://gitlab.com/JayleBreak/dualuniverse/-/blob/master/DUflightfiles/autoconf/custom/atlas_hyperion.lua

Fix 3D transformation of text using SVG/CSS

Right now, there is no way to specify "rotate around your own axis" in SVG/CSS. The way you usually do it is via transform-box: fill-box; using CSS. However, through my testing, I found this does not work for some reason. I don't have any code on hand right now, but I used CodePen, and it definitely worked as intended with there and didn't in the game.

The only current workaround is wasteful and laggy, as in generating a new class in CSS, and defining the transform-origin at the piece of text, for every piece of text you add. This is just a nightmare regex wise and an easy way to cause unnecessary amounts of lag,

toggling Cruise Control via unit.cancelCurrentControlMasterMode() does not work on Remote controllers

on normal pilot controllers we can use unit.cancelCurrentControlMasterMode() to toggle the current control master Mode (Cruise control).
This does NOT work for remote controllers but works for e.g. hoverseats and command controll seats.
This leads to script behaving differently or not working on remote controllers.

Implementing audio playback natively

While it may seem counter-intuitive from the creator to suggest such, I would like to see a native implementation for audio access in some way. I know of the abuse potential, but with the existing third-party implementations, the abuse potential is orders of magnitude higher.

This could be handled similar to the current picture file CDN. Additionally, it requires an RDMS right that allows or disallows access to "player resources", which in this case would be audioplayback altogether.

I know that Copyright might become problematic with this. However, an alternative is exactly how audio_framework does it: allowing access to already existing files, ideally in a predefined Dual Universe folder, that the player specifically would have to put there, similar to how 3d models are handled with the scaffolding projector. That way, NQ does not become liable for any of the audio file distribution, but loses some of the control as well.

Allow editing of lua scripts in an external editor

(previously filed here)

Implementing some support for external editing would be a much better use of limited programming time than trying to enhance the in-game script editor.

There are various ways this could be done - one suggestion is given below, but there are other ways it could work.

---

The game should be capable of packing/unpacking the scripts attached to a controller into a file-based format (in a similar way to wrap.lua).

Any scripts that the user has permission to edit in-game should also be cached in the file format, using predictable file names and locations on disk, such that they don't change over time.

The game should monitor these files for changes, and update the scripts in-game when the external files have been edited.

This would allow script authors to edit their scripts using an external editor such as VS Code, with all the advantages that would bring (auto-completion, syntax colouring, linting, search & replace, etc).

As this is a feature primarily aimed at script authors, it could be enabled/disabled with a client setting, to avoid affecting performance for non-author users.

Databank Client/Server

(originally posted here)

In order to build UIs that allow players to cooperate or exchange information, we need a way to share data.

One way to do this would be to add some API to the normal databank elements, which allowed their contents to be published to a fictional in-game "cloud":

publishAs(globalID, mode) -- make the contents available as read-only, or read-write, using a unique id
subscribeTo(globalID) -- replace the local contents with those from a published databank

This could have some cost associated with it, to avoid excessive real-world storage requirements.

Alternatively, we could have some new "Databank Server" and "Databank Client" elements which behave like Databanks, or which have to be linked to real databanks, and provide shared access to them.

Again these could be very expensive to make/buy, and/or could have usage costs.

However the databanks are shared, they could be protected to be read-only or read-write, based on the existing permissions systems.

For the sake of realism, lore could explain how the contents are shared, and there could be time delays built in to simulate the time taken to send the data between planets / systems.

Reverse RDMS rights for Lua scripts

I think with the bad actor concerns around a lot of potential features and additions, there needs to be a crucial addition to the current RDMS: Rights for Lua scripts.

This could range from something as simple as being allowed to use emitters/receivers to allowing audioplayback or input capture. While implementing this in a streamlined manner would be no easy task, I think it is a necessary step forward to give players more of a choice in what they accept, while it would allow a vast improvement in Lua capabilities to improve the overall game experience.

API access for wallet (check balance / make payments)

Feature request for API access to the wallet in order to check balance (maybe even list single transactions) and trigger payments.
Possible application would be e.g. automated casinos.

Triggered payments should ofc be safe and alway visible and confirmed by the user (through the regular confirmation interface)
View to the balance should possibly restricted if the construct is owned by the user.

Support error reporting for required modules

If an error occurs in a module you've imported with require, the current reporting system just gives up.

Instead it should be possible to report the error, module and line number, as usual.

Whilst using require is obviously problematic for production, it's immensely useful during development.

Implement setFullScreen() for Screens

The new rendering API is funky. I'd love to use it to make consoles that you could use in an immersive way.

It would be great to have some sort of setFullscreen method on screen which aligned the camera directly in front of the screen and made it fill (or mostly fill) the user's view. It would also lock movement and free mouse and keyboard input.