Jump to content

DevBlog: Lua Improvements and Changes - Discussion Thread


 Share

Recommended Posts

Hello Noveans!

 

We would love to hear your feedback on the latest Lua DevBlog.


I'd also personally like to read you all¬†the following¬†quote:¬†¬†( You can't stop me @NQ-Pann!¬†ūüėܬ†)

 

‚Äú... quaternions appear to exude an air of nineteenth century decay, as a rather unsuccessful species in the struggle-for-life of mathematical ideas. Mathematicians, admittedly, still keep a warm place in their hearts for the remarkable algebraic properties of quaternions but, alas, such enthusiasm means little to the harder-headed physical scientist Novean.‚ÄĚ
‚ÄĒ‚ÄČSimon L. Altmann (1986)

 

 

Link to comment
Share on other sites

  • NQ-Deckard changed the title to DevBlog: Lua Improvements and Changes - Discussion Thread

This is a good start, perhaps centering the players view as well will come given we are talking alignment.

also perhaps you can fix the issue of when you undock the weight of the undocked ship is not reduced from the total mass of the construct for a person sitting in an active  command chair but another person in build mode would see the construct weight without the undocked ship. You need to check that the summed values of additional constructs docked like cross section are treated correctly. If i leave a tiny shp docked 10m to the left my cross section seems to increase by the additional ships position even though there is nothing between us.

Link to comment
Share on other sites

IS center of construct the center of the core grid , the center of the ship or the center of mass or the center of the  build construct(voxels) or a different center. Please clarify for all the functions as well as the player position

 

Link to comment
Share on other sites

Hi there, resident Lua programmer here... I have some questions probably a few others also have as well.

Questions
First Question:

Quote
  • <vec3>¬†core.getConstructOrientationForward()¬†: Returns the forward direction vector of the construct in construct local coordinates.
  • <vec3>¬†core.getConstructOrientationUp()¬†: Returns the up direction vector of the construct in construct local coordinates.
  • <vec3>¬†core.getConstructOrientationRight()¬†: Returns the right direction vector of the construct in construct local coordinates.

This would imply that it would be a constant based off the image. Did you mistakenly say "direction vector of the construct in construct local coordinates" when it should've been "direction vector of the active orientation unit in construct local coordinates"?

Second Question:

Quote
  • <vec3>¬†core.getConstructWorldOrientationForward()¬†: Returns the forward direction vector of the active orientation unit in world coordinates.
  • <vec3>¬†core.getConstructWorldOrientationUp()¬†: Returns the up direction vector of the active orientation unit in world coordinates.
  • <vec3>¬†core.getConstructWorldOrientationRight()¬†: Returns the right direction vector of the active orientation unit in world coordinates.

Is there one that is irrelevant of the active orientation unit?


Third Question:

Quote
  • <vec3>¬†unit.getMasterPlayerWorldPosition()¬†: Returns the position of the player currently running the control unit in world coordinates.

The master player data, is this still for body orientation and position, or are we getting the camera data? I suspect it's the former for now since this was depreciating the old functions.

 

Forth Question:

Was going to ask something else but didn't have anymore to ask lol.

 

End Remarks
 

I honestly wouldn't mind a full Lua refresh to make things less cluttered. Like, using three functions to get orientation and these long function names could be slimmed down a lot.

For instance:

<vec3,vec3,vec3> core.getConstructWorldOrientation() : Returns the forward, up and right direction vectors of the active orientation unit in world coordinates.

local forward,up,right = core.getConstructWorldOrientation()
--Wham! One function.


Lastly, despite me using quaternions, I agree with the removal of them. There needs to be consistency and the three vector orientation system is much easier to understand and is also extremely easy to convert to a rotation matrix.

Link to comment
Share on other sites

Hello to all,
 

Thanks for your feedbacks, I will try to answer your first questions and remarks.¬†ūüėČ


First, about quaternions @sysadrift. To clarify the situation, we decided to deprecate these functions for two major reasons:
 - to improve the general consistency of the Lua API
 - to improve the understanding and accessibility to the orientation of elements and players for the majority of players who are not necessarily familiar with the notion of quaternion.

I draw your attention to the fact that they are deprecated and not deleted; they will remain usable for a long time but will not be displayed on the CODEX anymore. Using them will simply display a message in the Lua chat reminding you that these functions are deprecated.


 

 

Secondly, About the functions :

  • unit.getMasterPlayerForward
  • unit.getMasterPlayerUp
  • unit.getMasterPlayerRight

They return the direction vectors of the player and not a position.

To be more concrete, the Forward vector will always return the vector representing the direction the player is facing.

Note: It is not about the camera orientation though @UnCheat, as it was before with the quaternion. Even though we know you would like more access to the player's camera.
 

 


Finally, as written on the devblog @Mucus , everything will refer to the center of the build zone.
 

Quote

Going forward we have standardized everything. Once these changes go live, all functions will be based on the reference frame of the construct whose origin is the center of the build zone. Further, in order to guarantee the functionality of the flight systems and to safeguard the gyro unit, we have integrated in a clearer way of representing orientation.

 

Link to comment
Share on other sites

So! Thank you for this complete feedback @EasternGamer, let me try to respond.

First question :
Here it is a mistake in the devblog; it is my fault ūüėē, I admit it. We will correct it, sorry.
It should be :

  • <vec3>¬†core.getConstructOrientationForward()¬†: Returns the forward direction vector of the active orientation unit in construct local coordinates.
  • <vec3>¬†core.getConstructOrientationUp()¬†: Returns the up direction vector of the active orientation unit in construct local coordinates.
  • <vec3>¬†core.getConstructOrientationRight()¬†: Returns the right direction vector of the active orientation unit in construct local coordinates.

 

Second question :
All the functions that you have mentioned are related to the active unit orientation, in the end you will have :

  • <vec3>¬†core.getConstructOrientationForward()¬†: Returns the forward direction vector of the active orientation unit in construct local coordinates.
  • <vec3>¬†core.getConstructOrientationUp()¬†: Returns the up direction vector of the active orientation unit in construct local coordinates.
  • <vec3>¬†core.getConstructOrientationRight()¬†: Returns the right direction vector of the active orientation unit in construct local coordinates.
     
  • <vec3>¬†core.getConstructWorldOrientationForward()¬†: Returns the forward direction vector of the active orientation unit in world coordinates.
  • <vec3>¬†core.getConstructWorldOrientationUp()¬†: Returns the up direction vector of the active orientation unit in world coordinates.
  • <vec3>¬†core.getConstructWorldOrientationForward()¬†: Returns the right direction vector of the active orientation unit in world coordinates.

The (existing) functions referring to the construct itself are the following:

  • <vec3>¬†core.getConstructWorldForward()¬†: Returns the forward direction vector of the construct in world coordinates.
  • <vec3>¬†core.getConstructWorldUp()¬†: Returns the up direction vector of the construct in world coordinates.
  • <vec3>¬†core.getConstructWorldForward()¬†: Returns the right direction vector of the construct in world coordinates.

 

Thirds question :
Already replied before.


Regarding your final point, we would do it, but adding multiple return links takes more work than it sounds. We have done it for the render screen API, we can consider it for the future.

 

Link to comment
Share on other sites

1 hour ago, eviltek2099 said:

if you know then why the restriction?

Probably some pushback with exploit concerns or it's not as clear and cut to expose. Either way, Lua changes are always welcome if they standardize and don't limit, but instead simplify the process or expand what you can do.

If we complain too much, it will send the wrong message to NQ that "players don't want Lua changes", therefore no good Lua updates. We should only complain about things that limit us for no decent reason, like the nerf for transponders. That's my 2 cents.

I look forward to the future of Lua here. And thanks @NQ-Ligo for the response. I see that the dev-blog updated to reflect what I spotted, nice. And thanks for clearing that up with the construct orientation.

Link to comment
Share on other sites

8 hours ago, NQ-Ligo said:

on the reference frame of the construct whose origin is the center of the build zone.

 

yes , next time keep it simple NQ or draw a diagram  @NQ-Ligo ,  players interface point of view. center of the build zone  is fine. thanks for the clarity

Link to comment
Share on other sites

Quote

we can't rework the whole Lua API without breaking most of your scripts. 

 

Sorry, but you can, you just need to add a versioning scheme to the API.

 

All existing scripts use v1. You could add a completely rewritten v2, and have a setting on the controllers where script authors can opt into v2.

 

Link to comment
Share on other sites

Thanks for documenting this.  Am looking forward to part 2 and the radar changes.  Will you be introducing any new things with the radar API or just telling us about the way it behaves at the moment?

Link to comment
Share on other sites

22 hours ago, NQ-Ligo said:

Even though we know you would like more access to the player's camera.

 

What about adding a single function that would take 3D world (or construct) coordinates and project them into 2D screen coordinates? It would cover most use cases (AR HUDs, custom location markers), and would also be faster than doing 3D projection math in Lua.
 

4 hours ago, Samedi said:

Sorry, but you can, you just need to add a versioning scheme to the API.

All existing scripts use v1. You could add a completely rewritten v2, and have a setting on the controllers where script authors can opt into v2.

 

Agreed. There are already at least 3 separate Lua APIs: 1) the control unit API, 2) the screen (render script) API, 3) the internal tutorial & achievement API. Adding one more (control unit API v2) shouldn't be impossible ;)

 

Quote
  • <vec3> core.getWorldVelocity(): Returns the construct's linear velocity, relative to its parent, in world coordinates.
  • <vec3> core.getWorldAbsoluteVelocity(): Returns the construct's absolute linear velocity in world coordinates.

 

For compatibility with existing scripts (and consistency with other core.getParent* functions), could core.getWorldVelocity() always return absolute linear velocity, and velocity relative to parent be returned by a new function core.getParentRelativeWorldVelocity()? Same for core.getVelocity().

Link to comment
Share on other sites

3 hours ago, hdparm said:

Agreed. There are already at least 3 separate Lua APIs: 1) the control unit API, 2) the screen (render script) API, 3) the internal tutorial & achievement API. Adding one more (control unit API v2) shouldn't be impossible ;)

 

Hah, yes. Obviously it would be work, but a v2 API would give the opportunity to really clean things up.

 

At the very least, there should be some sort of `system.getAPIVersion()` call. Given how dynamic Lua is, that would be enough (though not ideal). 

 

Not versioning a public-facing API is a bit of a schoolboy error tbh.

Link to comment
Share on other sites

Hi all!

Let me try to reply you ;) 

Multiple Lua API versions

7 hours ago, Samedi said:

Sorry, but you can, you just need to add a versioning scheme to the API.

 

All existing scripts use v1. You could add a completely rewritten v2, and have a setting on the controllers where script authors can opt into v2.

This may seem simple from an external point of view, but it is not. Indeed, we don't necessarily have the resources to rework the whole Lua API at the moment and maintain multiple versions, even if we would like to rework it completely, there are more priorities at the moment.

Anyway, be sure I've passed this point on to the rest of the team ;) . 



Next Devblog

6 hours ago, Zeddrick said:

Thanks for documenting this.  Am looking forward to part 2 and the radar changes.  Will you be introducing any new things with the radar API or just telling us about the way it behaves at the moment?

Thanks for your feedback! On this point I will be cruel I think, and will let you wait for the publication of part 2 :) . Sorry 


Suggestions

5 hours ago, Neonicks said:

Please, add lua scripter to player for smooth custom gui. Add map (F4) api and api for emitting/receiving messages to program boards/command seats.

To make sure I understand your point, when you say "add a Lua scripter for players to have custom GUIs", do you mean provide Lua libraries for GUIs that could be used by scripters to make GUIs more easily on screens? I can say that we have already discussed this, be sure that we will check your feedback and take it into account if we see that this could be a thing for players.

What do you mean by a Lua API for the map?

And if we consider the API to send/receive messages to the programming board, we have senders and receivers for that. Or maybe I missed your point.

 


Lua projection function

3 hours ago, hdparm said:

What about adding a single function that would take 3D world (or construct) coordinates and project them into 2D screen coordinates? It would cover most use cases (AR HUDs, custom location markers), and would also be faster than doing 3D projection math in Lua.

Could be considered, we've passed this point on to the rest of the team. Can't promise anything.

 

 
Function naming and consistency

3 hours ago, hdparm said:

For compatibility with existing scripts (and consistency with other core.getParent* functions), could core.getWorldVelocity() always return absolute linear velocity, and velocity relative to parent be returned by a new function core.getParentRelativeWorldVelocity()? Same for core.getVelocity().

In fact, that's exactly why we kept the return of the relative speed with core.getVelocity() and core.getWorldVelocity(), with that, your flight systems will still allow you to land on moving parent constructs. Whereas providing the absolute speed would have prevented you from doing so. With this choice, a ship parenting to a parent construct will have its speed set to relative, and can then stop on the parent by setting its speed to 0 relative to it. This is exactly what you have in game now.

 

In addition, we did not want to have too long functions. So we chose to use core.getAbsoluteVelocity() and core.getWorldAbsoluteVelocity() functions to give you the absolute speed.

All these choices have been made to allow compatibility with existing systems and not to make the API too heavy.

 

 



Anyway all, we try to done some work to provide you Lua API for all new features we added and we try to improve it on the time, listen your feedbacks to fix issues, and provide you more libs that could be interesting for you. I hope I have answered your questions and that you will like these changes.

Link to comment
Share on other sites

Drop LUA. Use WASM or JS. it's 2021 not 2003.

They're millions of people, tools (linters and ide), libraries, transpilers, etc that can produce code for WASM or JS.

 

Sure LUA is popular in gaming mainly because of World of Warcraft (WoW) addons system. But WoW is from 2003 not 2021. Back then PC were slower, with less RAM and CPU cores  and the JS ecosystem wasn't very big. LUA was a good choice back in 2003. It's not in the 2020s.

Progress have been made since then. JS came along and dominated. Now WASM it the next step. Build for the future not for 2003.

 

There are tons of UI code, physics code, atmo & space flight code, whatever code and libraries already developed. 

 

You're losing lot of skilled programmers and a huge existing base code by not using WASM for this game. Even JS is better than LUA nowadays because tons of stuff exist in JS and they're tons of transpilers to JS.

 

And we don't need an integrated 'editing' (IDE) system inside the game. WoW addons were highly popular but you couldn't code at all from the game itself. A skilled programmer won't suffer your basic in-game IDE, it's just a too bad DX (developer experience). It's ok for a few lines of code, beyond that it's just insufferable. Just drop it. Put your effort elsewhere. Provide an extension for VS Code for instance and a local validator/linter/simulator.

 

Get ride of in-game DRM for scripts too. DRM is killing this game. If you don't understand why then this game is doomed. WoW had no DRM for LUA and it was never a problem.

 

And like someone said, we need scripting for UI because the game UI is just a joke atm. So like with  WoW, we should able to rewrite the map, talents, markets, etc UI windows with our own. Just expose an API for these and let us do the work it will probably be better than the current game UI... (that's not really hard considering what we have...).

 

I may sound harsh but I'm pissed. This game had so much potential but got ruined by beginner mistakes like choosing LUA and implementing amateur UI. It's a shame.

Link to comment
Share on other sites

4 hours ago, Kirth Gersen said:

Get ride of in-game DRM for scripts too. DRM is killing this game. If you don't understand why then this game is doomed. WoW had no DRM for LUA and it was never a problem.

Imagine spending hundreds of hours of  work on a script in game that you would like to sell for a small bit of quanta. DRM enables that.

 

Remember. You don't need to enable DRM if you don't want to.

Link to comment
Share on other sites

11 hours ago, Kirth Gersen said:

Drop LUA. Use WASM or JS. it's 2021 not 2003.

They're millions of people, tools (linters and ide), libraries, transpilers, etc that can produce code for WASM or JS.

 

Sure LUA is popular in gaming mainly because of World of Warcraft (WoW) addons system. But WoW is from 2003 not 2021. Back then PC were slower, with less RAM and CPU cores  and the JS ecosystem wasn't very big. LUA was a good choice back in 2003. It's not in the 2020s.

Progress have been made since then. JS came along and dominated. Now WASM it the next step. Build for the future not for 2003.

 

There are tons of UI code, physics code, atmo & space flight code, whatever code and libraries already developed. 

 

You're losing lot of skilled programmers and a huge existing base code by not using WASM for this game. Even JS is better than LUA nowadays because tons of stuff exist in JS and they're tons of transpilers to JS.

 

And we don't need an integrated 'editing' (IDE) system inside the game. WoW addons were highly popular but you couldn't code at all from the game itself. A skilled programmer won't suffer your basic in-game IDE, it's just a too bad DX (developer experience). It's ok for a few lines of code, beyond that it's just insufferable. Just drop it. Put your effort elsewhere. Provide an extension for VS Code for instance and a local validator/linter/simulator.

 

Get ride of in-game DRM for scripts too. DRM is killing this game. If you don't understand why then this game is doomed. WoW had no DRM for LUA and it was never a problem.

 

And like someone said, we need scripting for UI because the game UI is just a joke atm. So like with  WoW, we should able to rewrite the map, talents, markets, etc UI windows with our own. Just expose an API for these and let us do the work it will probably be better than the current game UI... (that's not really hard considering what we have...).

 

I may sound harsh but I'm pissed. This game had so much potential but got ruined by beginner mistakes like choosing LUA and implementing amateur UI. It's a shame.

As JS programmer for a living I can say that LUA is ok. Thanks that we can script in DU. And I think that really skilled programmers do not care what language to script also LUA is easy to learn for beginners..
Only one thing is missing is DOM manipulation of screen HUD html...

Link to comment
Share on other sites

13 hours ago, Snipey said:

Imagine spending hundreds of hours of  work on a script in game that you would like to sell for a small bit of quanta. DRM enables that.

 

Remember. You don't need to enable DRM if you don't want to.


OK, so there are two things here.  Firstly, LUA in DU is not like the LUA in WOW.  In DU the lua is part of a construct which can be killed, cored and taken by someone else.  And without DRM *the person who takes the construct gets your scripts* when they kill your ship.  Or they might get the scripts belonging to whoever gave you them, etc.

However DRM doesn't really enable you to sell scripts at all (outside of certain special situations where you trust another player a lot) because it doesn't work for scripting.  The DRM owner of a script is whoever deployed the original construct and built the ship.  It's not the person who wrote the script.  So as a script writer you either become a ship builder too and sell ships or you're SOL when it comes to selling scripts because you can't have any DRM protection at all on them.  You can't even put PvP scripts you write on your own PvP ships unless you built them from scratch because you have to ask the original owner to enable DRM, then every time you want to change your own script you have to ask them to come do it again.  Or you can fly without DRM and if someone kills you then they get to take your PvP script and they can sell it to other people if they want.

 

The whole thing is miserable.  I'm waiting for NQ to do it properly before I even think about selling scripts.  Until then my scripts are for me only.
 

Link to comment
Share on other sites

18 hours ago, Kirth Gersen said:

Drop LUA. Use WASM or JS. it's 2021 not 2003.

 


Every time I write LUA for DU I wish they'd chosen JS instead.  LUA is just wierd, I regularly use about 10 different programming languages and none of them are like LUA when it comes to the basic syntax (which seems to derive from Pascal?).  WASM is an interesting concept, but I don't know how easy it is to extend a WASM engine with plugins so you can implement things like the element object API, etc and have it invoked from whatever language compiled to WASM?  With WASM you might be able to have LUA compiled to it so you could keep compatibility with existing scripts.

But don't you think that this is just a product of DU's age?  Wasn't the project started in 2012 when LUA was a much smarter choice?  Sometimes when developing software you have to keep running with the things you already made and build on top of those rather than re-making things you already made.  Do you think NQ should spend a large amount of time changing out their scripting engine now rather than implementing new game features or fixing the in-game systems they already have?  And is it really worth making people re-write scripts and possibly learn a whole new language?

IMO this is something to re-visit later when the game is finished and making money ...

Link to comment
Share on other sites

Quote

<vec3> radar.getConstructWorldPos(<int> cid) : Returns the position of the given construct in world coordinates if in range and if the active transponder tags match.

Could radar.getConstructWorldPos(id) be extended to return position of any static (or stationary) construct in range? Popular flight scripts are already trilaterating construct positions based on distance (for collision avoidance), so it would mainly improve code efficiency/complexity.

Link to comment
Share on other sites

Hey Guys,

 

I have tried the following code in lua:
 

list = radar.getConstructIds()

 

And the game only replies with "attempt to call a nil value (field 'getConstructIds')"

 

Could it be that these features are not implemented in the game yet?

 

Thanks for your reply,

FireDemon

Link to comment
Share on other sites

  • NQ-Pann unpinned this topic

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...