Jump to content

LUA API additions


Dakanmer
 Share

Recommended Posts

Some things are missing from LUA API that I think should be there:

  • Get docked construct name by ID
    • Currently you can only get its ID, except through radar. This function should be available as a general parent construct function, not just radar.
  • Get docked construct position/orientation by ID
    • These functions exist for getting the parent's position/orientation, but not the docked construct
  • Get active waypoint
    • If the player has a waypoint active, return it as a ::pos string, just as with the function to get waypoint from player position.
  • A category for "database" in the codex
    • Some functions use database to get information, like database.getConstruct and database.getPlayer(ID).
  • Categories for other function types that aren't listed but can be used, if there are any others (like database), or updating existing categories with functions that aren't listed but exist
    • Self explanatory. People can't use functions if they don't know they even exist, what they do, or how to properly call them
Edited by Dakanmer
Minor addition for clarity
Link to comment
Share on other sites

Some more API that should be included:

  • Warp drive API
    • Currently can only do warp.activate(). Should be able to do deactivate and allow for setting/getting warp destination, as well as warp cell cost. If it's displayed on the widget, it should be something players can use in scripts
  • Warp beacon API and/or perms
    • Currently no way to manually decide who gets to use the beacon and who doesn't
Link to comment
Share on other sites

  • 3 weeks later...

Hi @Dakanmer

Let me reply to your proposals in order of your list :

  • Get docked construct name by ID
    • This is a gameplay choice, we always wanted to keep this aspect of needing a sensor to get information outside the construction. Just like a telemeter for example. So the use of a radar is a gameplay choice. However considering it's "docked" construct ... potentialy 🤔
  • Get docked construct position/orientation by ID
    • Same that the first point.
  • Get active waypoint
    • Can be a privacy/security issue to get the waypoint of the player, could be used to track other players destinations. 🤔 Even if we put that on explicit use only this issue still relevant. To consider ...
  • A category for "database" in the codex
    • Will see if we can add it to the codex (which is auto generated and do not parse Lua libs).
  • Categories for other function types that aren't listed but can be used, if there are any others (like database), or updating existing categories with functions that aren't listed but exist
    • Same, I see the point as Navigator ...etc Same than the previous point.
  • Warp drive API
    • Setting the warp destination is a bit complex, considering it's not a position but a warp beacon or planet. It adds some consideration as "How the player get the destination ?" "How do we designate a destination ?" ...etc An other point is automation on that point.
    • Getting warp destination, same issues, but not really for the automation, but for the "How".
    • Warp cell cost ? Absolutely nothing against on that point ; a function getWarpCost, getWarpAvailableCells (or something like that 😅 )
    • Deactivate ... automation possibility 🤔
  • Warp beacon API and/or perms
    • RDMS API is a complex subject.
    • What do you expect as API ? There is no action to do on the element without Lua, so we don't see what to add on Lua.
  • Clear waypoint
    • Hmmm, no real problem in mind. So it could be added.

Do not hesitate to ping me, else I can miss some useful topics like that ;) 

Link to comment
Share on other sites

On 4/25/2022 at 9:13 AM, NQ-Ligo said:
  • Warp beacon API and/or perms
    • RDMS API is a complex subject.
    • What do you expect as API ? There is no action to do on the element without Lua, so we don't see what to add on Lua.

I'm not sure what API might be useful as a scripting noob, so I can't offer suggestions. I wanted to keep the possibility for API open as a suggestion, though, in case other people had ideas. RDMS would be great, though. Having a public beacon network, or even one requiring a subscription (players/orgs pay a recurring fee for use of existing networks owned by other players/orgs) would make it so every org didn't have to make their own, especially with the limit on the number of orgs a player can be part of. If one of the ideas is to get people to specialize on things so that everyone isn't doing everything, then that would be a big one.

Quote
  • Get active waypoint
    • Can be a privacy/security issue to get the waypoint of the player, could be used to track other players destinations. 🤔 Even if we put that on explicit use only this issue still relevant. To consider ...

This one was more about being able to get the waypoint without having to go into the map and copy it. Opening the map is always lag-inducing, making it sometimes dangerous to open at all (including/especially PVP areas like asteroids and the like). Even having a right-click option to copy/clear the current waypoint would be great. I've seen the clear waypoint in a video, but there's no explanation for how to do it, I haven't been able to replicate it, etc. Adding it to API would just be icing.

 

Thanks for responding. Usually it's a wall of demoralizing silence from NQ.

Link to comment
Share on other sites

On 4/25/2022 at 6:13 PM, NQ-Ligo said:

Setting the warp destination is a bit complex, considering it's not a position but a warp beacon or planet. It adds some consideration as "How the player get the destination ?" "How do we designate a destination ?" ...etc An other point is automation on that point.

Maybe allow LUA access to the list of beacons/planets currently in the users' map?

 

On 4/25/2022 at 6:13 PM, NQ-Ligo said:

Can be a privacy/security issue to get the waypoint of the player, could be used to track other players destinations. 🤔 Even if we put that on explicit use only this issue still relevant. To consider ...

Maybe add a game setting, disabled by default, that allows the player to grant access to it? If the setting is disabled, just return a tuple of {false, "::pos{0,0,0,0,0}"}

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...