NQ-Ligo

We haven't had a chance to look into it yet, it doesn't seem necessary at first glance since you can just write on a screen, without even worrying about rendering with setHTML ; so more than 50 000 characters. Which is for us the main alternative for the moment. Anyway, I'll discuss it with the team to see if we'll add a setting in the game settings. Nothing decided yet.

Hi guys ! First of all, thank you all for the warm welcome to the VPT. We've been working for a while now, trying to make it as ergonomic and intuitive as possible, we hope it will live up to your expectations when you test it yourself with Panacea. I take the liberty of intervening on this non-Lua devblog for questions related to it, and thus to answer your question @EasternGamer Having the ability to export/import with Lua or without, a bunch of voxels was considered but we were faced with a lot of quick and hard to prevent automation possibilities, copyrights ...etc. The game could have quickly become an import show of all kinds of 3d models. So we decided not to implement it.

Printing in other channels could be problematic as it could allow players to spam players ...etc. And even more so if it can be executed with non-explicit execution. It can be an idea to consider ? This is the kind of small things we could potentially add. To consider. Anyway this thread is not reserved for suggestions Anyway, I'm always open to read some suggestions on a thread in the suggestion/idea box part of the forum. Thanks

Hi all! After reading your feedback, we have noted that the removal of log functions was having a big impact on you. So after some internal discussions to find a solution based on your suggestions that would meet your expectations but would not be too heavy to implement, we have made a decision. We plan to add with Panacea, the ability to copy to your clipboard the content of a chat channel, and clean it up. It is certain that this will not provide a nice solution for the problems related to the lack of data export to virtual currency systems. We have some ideas for this but it won't be for a while unfortunately. Hopefully this announcement will allay your concerns NQ-Ligo

The Mining Unit API will be available soon, but will not for the Panacea release unfortunately.

Hi all!I will try to answer your first questions. Don't worry, I'll do some more passes tomorrow. No possibility to copy content out of the game? @Ashford @Helediron@Wolfram We know that these log functions are used by some people legitimately to get data out of the game, but it has never been the only way to copy data. But it was the only way to get data directly out of the game automatically. In your case, you can use a screen and log on it. Currently you still have setHTML which will allow you to write very easily on it, without even worrying about the number of characters if your goal is just to copy the data out of the game at the end. You write your log in it, once finished you edit the content of the writing and copy the whole content. I know that many players will express their concern at the removal of these log functions, even if their use was legitimate. However, it is important to understand that this is a decision that was made after much consideration and the balance was quickly tipped in favour of total removal. And any suggestion such as adding a Lua-only log file or segmentation of the logs, does not solve the problems as automation or drive overload. And even the fact it's executed explicitly only, it do not prevent automations and some exploits and leaks. I'm not sure either that being able to select the Lua chat and copy it is a solution either, or even more practical than a screen anyway. However, we will see with the team if a better solution is possible, there is no perfect solutions currently. On a personal note this time, I would suggest adding to your systems to allow your users or you, the developer, to connect a screen that serves as a console. A bit like you do with a car, it's a closed system, a black box, but it can provide us with controller or error data through their control port. What about reading the log ? We see the logs as a tool for community projects, such as an external community market platform, so we want to keep the logs as accessible and readable as possible. Therefore, we try to remove sensitive information from them as we did in the case of Market Orders. However, it is possible that some of the information may not have been considered dangerous at first sight. In this case, please let us know @Archaegeo . We would rather "secure"/"censor" the data on the lgos, than have to remove them completely. Of course, I can't guarantee that in the future this will be assured, if it becomes unavoidable we will get to that point. But that is not our goal. More possibilities for the game camera? @EasternGamer First of all, thank you for your topic, I have read it and it is interesting. It's the kind of thing we could consider in the potential future, but as you said it can be complex and even more so to secure it. I'd like to say that I'm looking forward to seeing what you do with it and see what we can do or not. Thank you for these suggestions though, they are complex suggestions, so it's hard to say whether or not this is something we could or would want to do right now. Sound API, missing volume control. @Archaegeo Indeed, this is something that is currently missing. The volume of the sound played will only depend on its base amplitude and the audio settings of the game. This is something we'd like to add, but to be honest, it requires some deep changes to be done. Anyway, as mentioned in the devblog, this is a first iteration that may evolve in the future. I hope that these answers will help you all the same and help you to understand the situation on the logs, on some aspects, they are globally complex subjects.

Hi @TobiwanKenobi and others, We are investigating this issue, we have made an update to reduce the instability of the obstruction value which was a bug causing your ship's engines to randomly change the obstruction over time even in mid-air. However, it seems that the obstruction has another problem; this one. We can't give an ETA, especially since the team is taking a break for the holidays. But be sure it's in our bug list we're investigating.

Hello LoardFrost, That's normal, the Lua is only executed on the client side. And there is no problem with that. Industries still works when you are offline, but your monitoring can't work when you are offline. If you were to run Lua on the server, that means that the server has to be aware of everything that's going on in the world, items, players, industry operation, links to other items;...etc all the time, and that's for all the scripts, and you add to that all the server requests between the server and the player when the player is logged in; that's clearly too much. If you set up your industry, manually or with Lua in MAINTAIN mode, it will still work. Anyway, in the principle, the gameplay of the industry is made to require some player interaction, like changing the schema...etc or using a Lua system but requiring the player to be present.

Hi Jake, We are well aware of this issue, it is an issue that came up after we fixed a major problem that was causing client crashes. To be honest, when we say "it may take a while to fix", it does, it requires reworking the parser we have in place. Unfortunately, it won't be possible to fix this before our break, which will do everyone a lot of good for a full recovery. Nevertheless, it remains a major problem that we are keeping in mind, if that makes you feel better. Of course, I can't give any date sorry.

With the update we just publish, you can know connect the radar to any controller. The radar can now be connected to all controllers. You can only use radar for PvP on restricted links or you will not be able to identify or engage a target with it.

Hi @Zeddrick, Indeed, for this update, we focused on improving consistency and access to the information provided by the json in an easier way. Adding any kind of information, when it's related to combat is a bit of a ... tricky subject. Humm... thanks for the suggestion, it could be easy to add ... anyway, I need to discuss with the team if we want to give this information; consider edges cases and potential exploits and balance Lua/no-Lua ...etc. I can't promise you anything obviously.

Some issues may slip through our cracks during our testing, but be sure this update has been tested and reviewed for some time. For the date I will just to tell you : soon, we avoid giving precise dates. About the offline documentation, be sure I will check that with the team, can't promise anything.

Hi JayleBreak! To answer your questions: 1. Yes exactly 2. The thickness is the actual thickness where the density of the atmosphere is less than 0.0001, reach 0. So "when space engines can reach maximum thrust"; that's when you are in the real space void. We check the suggestions done on upvote don't worry.

I invite you @AstronIsTaken and all others who will read it to take time to expose clearly and detailled enough what you would like to see added around the Lua. It's interesting, even if I can't give you any promise Keep in mind the dev time in your suggestion obviously ... Thanks

Because of your question and considering that some players seems not know that, but database.lua library is already in the game folder. It's an old library which hasn't been updated since a long time, it was important at the occasion to update it. This library is simply a collection of functions compiling all API functions you got, to return a structure containing all informations. You will not get any informations for crafting, like skills ...etc .

This is the organization tag, not the transponder tag. The tag of an organization is defined when you create an organization and is a string of 3 to 4 characters.

Lua ATLAS I agree with you @hdparm, but keep in mind that some of this data is only server side or computed, so we want to avoid server requests. Considering that the stellar body information is static, it is easy to keep a local atlas generated, so we took that choice. Also, we don't want to add more lua functions returning JSON, we know it's heavy in terms of performance and CPU overhead limit. Suggestions and polls I know that sometimes you may feel that opinions or suggestions are not necessarily listened to, but be sure that we are always interested in knowing what is considered important for our players at the moment. Also, don't forget that we are always working and what you will see today will have been designed, developed and tested for a few months before. So on this subject, I'll just say that we are keeping a close eye on these kinds of surveys. Although many things can be complicated to consider in terms of resources or technical involvement etc. we are looking at the suggestions whatever it is.

Hi everyone ! As some of you, and others will discover, we released the third and last part of the devblog. Let me expose you some points before check your feedbacks. The atlas library has been done with a similar structure with what the community is used to have. It can respond to your major use cases and let you save characters and space on your databanks. We may consider adding the API later. The event library; I know many of you were expecting an API to be able to subscribe to item events. But that's not what we offered, and we never promised it. Indeed, this library was designed to help players to create or manage events in pure Lua, for inter-constructions communication, custom event management interfaces ...etc. And at the same time, as a first example of a local library to see if you would like to have more Lua libraries or deeper libraries, like GUI libraries or something else. Keep in mind that even though we have good Lua developers in this community, a lot of the community is not necessarily familiar with how a GUI works for the example. So you may find this unnecessary, and that's fine. The examples provided are simple, and may even expose some "ridiculous" code blocks ... "ridiculously" simple, like the event handling on the button example. But this is normal, as we want to keep the examples simple and clear for all players.

As I said, we will not remove it As all functions on the Radar API which didn't changed or events ...etc.

Hi all!First of all, thank you for the feedback, and we apologize for the delay in publishing part 3. As my dear colleague @NQ-Deckard explained on discord, we encountered some potential problems, and so we preferred to take the time to check it out instead of announcing something and coming back to it later.Planet positions and size ... an Atlas ? If you let me do, I will tell you that patience is rewarded, don't worry. ? Radar API changes: To be concrete, we have stipulated explicitly in the change log if a function is deprecated or not. In this case, getData will remain don't worry, especially considering it is a common function for all elements. We prefer not to give specific dates, but we will say that the third part will be published soon. Radar API and JSON: I completly see your issue Zeddrick, even if I would love to completly obliterate the JSON in Lua API and return structures, we can't do that for the moment. Anyway, in your case, considering that we tried to provide you with access to all the information accessible in the getData JSON, you should be able to save yourself parsing and concatenation steps on the JSON as a string or decoding the JSON . You could build your structure directly on a Lua table and encode it in JSON at the end of the processing to integrate it in the widgets. I realize that all this is not ideal though and that a structure would be better.

Hi all! Let me try to reply you Multiple Lua API versions 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 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 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 Could be considered, we've passed this point on to the rest of the team. Can't promise anything. Function naming and consistency 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.

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.

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.