MORE INFORMATION ON LUA UPGRADES IN 1.4

[NQ-Wanderer]

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

[Yoarii]

Thank you, @NQ-Ligo

Edited June 1, 2023 by Yoarii

[Midacre]

But "under the covers" booleans are still 1 and 0. So this seems like an unnecessary breakage to me. We're not writing LUA applications for use outside the game. Why does LUA inside the game need this breaking change for compatibility with LUA outside the game?

[Resource]

NQ-Ligo via @NQ-Wanderer:

 

I thought the reason for the change was as to allow true, false, and nil
 

[Midacre]

If I have code like 

if (engine.isActive)
then
   ...

The change to boolean return would not break this code snippet.

 

However, if the code is

if (engine.isActive == 0)
then
   ...

The change will break it. 

 

Is that right?

Edited June 2, 2023 by Midacre

[Leniver]

4 hours ago, Midacre said:

Is that right?

 

Yes exactly.

[Leniver]

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

Some scripts are very sensitive and may discourage many players if they stop working. There are several examples, but among there is a huge change that ArchHud won't work anymore and will generate a lot of stress among some players.

Archegeo did an awesome job following the changes and testing them on PTS for the good of the community. He is not the only one in this case, but certainly the most known.
Not allowing us to test our script and being able to have a version fully functional on release force us to not enjoy the release and having to work on our scripts. In long term people get tired and just stop.

 

[Koffye]

Quote

"[...] 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"

 

[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.

18 hours ago, Midacre said:

But "under the covers" booleans are still 1 and 0. So this seems like an unnecessary breakage to me. We're not writing LUA applications for use outside the game. Why does LUA inside the game need this breaking change for compatibility with LUA outside the game?

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.

 

 

4 hours ago, Leniver said:

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

Some scripts are very sensitive and may discourage many players if they stop working. There are several examples, but among there is a huge change that ArchHud won't work anymore and will generate a lot of stress among some players.

Archegeo did an awesome job following the changes and testing them on PTS for the good of the community. He is not the only one in this case, but certainly the most known.
Not allowing us to test our script and being able to have a version fully functional on release force us to not enjoy the release and having to work on our scripts. In long term people get tired and just stop.

 

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

 

 

[Leniver]

4 hours ago, NQ-Ligo said:

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.

Thanks, I know you are doing your best.
I just wanted to point that.

[Yoarii]

On 6/1/2023 at 11:26 AM, NQ-Wanderer said:

I recommend including the "json.lua" library instead of "dkjson.lua" to avoid using the compatibility layer if you want to optimize your script.

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

[JayleBreak]

23 hours ago, Midacre said:

If I have code like 

if (engine.isActive)
then
   ...

The change to boolean return would not break this code snippet.

 

A value of 0 or 1 would evaluate to true in the if statement above, so the answer is: the code will not behave the same if changed to a boolean. But then, the original code was broken so...

[DaSpitz]

I can see the reasons for the changes from the perspective of NQ. However, with so much code in the game and a good chunk of it locked behind DRM while the owner/original coder may no longer be in game, this can potentially break and ground many constructs with no recourse.

A question would be is NQ going to accommodate opening up the DRM in these instances to allow for this code to be corrected/fixed or are the owners of the constructs in question pretty much left with a potato.

Disruptive changes like this really have no place in a released game where there are very real blockers preventing these issue to be resolved. NQ has a responsibility here and can't just walk away from that as far as I am concerned..
 

[Zeddrick]

On 6/3/2023 at 9:39 AM, DaSpitz said:

I can see the reasons for the changes from the perspective of NQ. However, with so much code in the game and a good chunk of it locked behind DRM while the owner/original coder may no longer be in game, this can potentially break and ground many constructs with no recourse.

A question would be is NQ going to accommodate opening up the DRM in these instances to allow for this code to be corrected/fixed or are the owners of the constructs in question pretty much left with a potato.

Disruptive changes like this really have no place in a released game where there are very real blockers preventing these issue to be resolved. NQ has a responsibility here and can't just walk away from that as far as I am concerned..
 

I don't think this is any different from things like the stacked element changes -- you could spend money on a construct and then NQ is happy to break that and send you back to the original builder for repairs.  The original builder might not want to help you, and then you're on your own.

It's not a very good way to encourage users to create content in a game which relies heavily on users creating and selling content.  I know of people who stopped shipbuilding because of the element stacking changes, for example.

You can un-DRM by picking up the element and re-dropping it.  Then you have to re-boost and re-apply the new version of the code from whoever wrote it.  If it isn't a standard LUA script you can download or buy you're SOL.

[Zeddrick]

On 6/3/2023 at 12:21 AM, JayleBreak said:

A value of 0 or 1 would evaluate to true in the if statement above, so the answer is: the code will not behave the same if changed to a boolean. But then, the original code was broken so...

You'd think it would be compatible, but Lua is a bit of a mad language though, why couldn't they have picked Javascript!

andy@smiley:~$ lua
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> function foo()
>> return 0
>> end
> function bar()
>> return false
>> end
> print(foo())
0
> print(bar())
false
> if not foo() then
print("yay")
>> end
> if not bar() then
print("yay")
end
yay
> if foo() == 0 then
print("yay")
end
yay
> if bar() == 0 then
print("yay")
end
> 

Looking at the list of changed functions, there are going to be a lot of upset people using DRM protected LUA scripts when this comes out! 
 

[CptLoRes]

But, but the game has been released for a long time now, so there should not be any more game breaking changes..  right?

[P4rty_Boy]

Just an idea here; not the most elegant solution, but it could help keep compatibilty while enjoying the benefits of 1.4

Instead of replacing functions such as unit.hasDRM with a boolean version, why not simply add a new function like unit.hasDRMBool that is optimized for lua 1.4.

Have a deprecated version of unit.hasDRM that do something like

 

function hasDRM(param)

     return (hasDRMBool(param) == true) and 1 or 0

end

 

For the whole list of function that will be impacted. That would give time to people to prepare, change their script & ensure it works before removing the old deprecated functions in a couple of months.

 

Just an idea. I must admit, I am a bit scared to long on day 1 of 1.4 and not being able to fly anywhere

 

 

 

[blundertwink]

On 6/4/2023 at 5:09 PM, CptLoRes said:

But, but the game has been released for a long time now, so there should not be any more game breaking changes..  right?

 

And to be real...something as basic as "how booleans work" is not something that should need to be touched post-release.

 

This excuse of "putting it off for so long to not break things" seems weird to me -- surely beta would have exactly been the time to break things to mitigate the need to do this post-release? 

 

Not sure I really buy the "necessity" of this change unless they've calculated that the improved performance will save them money (which seems like a motivator). 

 

This is an issue with sandbox persistent multiplayer games in general...Any change that fundamentally changes constructs or in-game scripting means effectively erasing a lot of work. It's a similar issue when they change how PvP components are balanced.

 

There will always need to be a balance between stability and breakages; I don't think NQ has found that balance yet. I don't think they've really patched this game any different on "release" than they did in beta...maybe even more carelessly with the lack of PTS. 

 

Granted it doesn't much matter with player counts this low, but hopefully they learn to find that balance with their other projects. 🤷‍♂️

[Midacre]

On 6/4/2023 at 2:28 PM, Zeddrick said:

why couldn't they have picked Javascript!

Be careful what you wish for.

[Midacre]

On 6/8/2023 at 7:51 PM, P4rty_Boy said:

Instead of replacing functions such as unit.hasDRM with a boolean version, why not simply add a new function like unit.hasDRMBool that is optimized for lua 1.4.

Because they upgraded the LUA "backend" to 1.4 and it doesn't do that anymore, so they'd have to code a new backend to do it the old way. 

[Zeddrick]

On 6/20/2023 at 1:40 PM, Midacre said:

Be careful what you wish for.

 

Javascript has inconsistencies, sure.  But array subscripts starting from 1?  It's not right.