Dimencia

Also... it should maybe allow people to choose a blueprint to use as their ship, which it builds for that VR session - to ensure players can still do niche things with scripts, instead of only being able to test flight scripts for traditionally-built ships. 
And if some script maybe needs tags on all its engines, you wouldn't have to re-tag them every time you enter a session if you have a blueprint with those tags (assuming tags are even saved in bps)
 
This would also allow players to 'try out' ships they have blueprints for but can't build yet (a rare situation, so maybe not all that useful)
 
For security reasons, in that case DRM should still apply to control units (until picked up and placed down again), so it couldn't be used to read scripts from a DRM'd bp
 
 
And, it should also probably allow you to choose a planet, if it doesn't already... I've never toyed with the Challenges tab.  But flight scripts need to be tested on each planet, and it is often very expensive and time consuming to do so
 
 
 
But... this also sort of ties in to a much larger idea that would solve a lot of problems and meet a long-standing request.... personal 'worlds' via VR, empty instances of the system for each player.  Maybe others can visit your personal world, maybe not.  Maybe everything is free in your personal world (creative), maybe not.  Maybe you can only deploy blueprints for free there, which avoids all the problems that creative makes while still preserving script testing purposes.  Maybe your personal world would be persistent, but if not, it'd still be extremely valuable for script testing
 
And if it ends up with any of those maybes, it could become a whole new avenue of gameplay; some people might prefer to just, build insane things in their creative VR world and share it with people.  The players who enjoy the main game wouldn't do it, of course, but those who get tired of the main loop would still have a way and a reason to keep playing

We'll see, I don't think I agree unless it's full-creative, and even then it's a maybe.  I think it will be rare because DU is a time-investment-based race of sorts; any time spent in VR is time you could have been making income in the real world.  Even if the VR world gave you everything up to and including creative mode, the people who would hang out there, are people who wouldn't have kept playing in the main world anyway
 
 
But you do definitely bring up a good point, because there's a very fine and arbitrary line between a sandbox to test lua scripts in, vs a creative mode, and all the arguments against creative do apply to a lua testing environment.  If they allow one, why not the other - and if that why not is good enough, then they probably shouldn't allow either one

With the return of element lifetimes the development of Lua flight scripts (e.g. flying_construct.conf) carries the risk of excessive costs.

The solution would be to provide a VR environment similar to that in the "Challenges" tab of the Surrogate Pod UI, but where the ships have no DRM restrictions on their controllers. The code loaded into those controllers should not be saved to the server, but copy & paste should be permitted. Loading of configuration from the lua/autoconf/custom folder should be allowed.

Offering a variety of ships would be great and if a variety of elements (radars, guns etc.) were available to modify the ships it would magnify the development possibilities.

Just spitballing a bunch of ideas for Ligo to consider with the new API changes.  Some are more viable than others, but my main thought was that there's all these new functions - but we can't use them because they require us to link to things.  Ship controllers can never reasonably link to all of any given element type, which is why the engine commands exist, so more things along those line would be great
 
Take them as you will, if anything can't be done then no big deal, but just posting it in case Ligo might see something useful
 
Element.getWorldPosition Core.getElementWorldPositionById Construct.getMaxSpaceBrakes, Construct.getMaxAtmoBrakes Modify System.lockView - Previously it didn't work if not sitting in a seat; but a frozen player should also be able to have their view locked - if it doesn't already work that way with the new API.  This is important for custom UIs to work with the new click controls, when not in a seat Construct.getMinimumStallAngles - Returns a vec3 of the smallest of all stall angles for the construct's airfoils along each of its local axes; for example, if someone is using both airfoils and ailerons for pitch, it would show the stall angle of the ailerons along that axis Construct.getMaximumStallAngles Construct.getLiftEfficiency(vec3 axis) - Returns a 0..1 value indicating the average efficiency of all airfoils along that axis, determined by currentLift/maxLift.  Can be used to optimize turns toward the highest efficiency, which implies the maximum speed/angle at which it can turn along that axis in the current conditions Might be better as Construct.getEngineEfficiency(taglist, vec3 axis), which could also work on airfoils Construct.getSustenationSpeed Modify Library.getPointOnScreen - take a local position Library.getWorldPointOnScreen Improve efficiency of getPointOnScreen - apparently it is less efficient than our current methods, regarding overloads Construct.getObstructionFactor(engineTagList) - returns the average(or total?) obstruction factor of all engines in the taglist Modify Construct.getCurrentBrake - Ensure it includes obstruction (if it doesn't already, I haven't been able to check).  So should any other 'current' engine readings, again, if they don't already Construct.getCurrentThrustAlongAxis Construct.getPitch, getYaw, getRoll - In degs or rads, and possibly return these values relative to the velocity vector when not near a gravity source, since at that point they have no meaning - or relative to galaxy center would work.  It would be nice to have a consistent value across all ships, instead of each AP possibly choosing a different way to calculate it Core.getWorldNorth - Returns a vector pointing north from the core for the current planet, normal to gravity, in world coordinates.  Currently we can sort of guess this by assuming the north pole is the point on the planet at the highest global Y (or is it Z?), but a tilted planet would mess that up, if there ever were one.  0 when not in planet influence Player.getRaycastObject - Gets some sort of info about what the player is currently looking at.  Particularly I'd like it to be able to detect whether or not the player is 'aiming' at another player, for VR shooting games, but construct info (looking at a ship in space), itemIds, and/or local element IDs could all be useful The main goal of detecting player 'hit' is so that these games could involve complex (real) arenas and rely on line of sight, rather than always being able to 'shoot' through walls
 

Just spitballing a bunch of ideas for Ligo to consider with the new API changes.  Some are more viable than others, but my main thought was that there's all these new functions - but we can't use them because they require us to link to things.  Ship controllers can never reasonably link to all of any given element type, which is why the engine commands exist, so more things along those line would be great
 
Take them as you will, if anything can't be done then no big deal, but just posting it in case Ligo might see something useful
 
Element.getWorldPosition Core.getElementWorldPositionById Construct.getMaxSpaceBrakes, Construct.getMaxAtmoBrakes Modify System.lockView - Previously it didn't work if not sitting in a seat; but a frozen player should also be able to have their view locked - if it doesn't already work that way with the new API.  This is important for custom UIs to work with the new click controls, when not in a seat Construct.getMinimumStallAngles - Returns a vec3 of the smallest of all stall angles for the construct's airfoils along each of its local axes; for example, if someone is using both airfoils and ailerons for pitch, it would show the stall angle of the ailerons along that axis Construct.getMaximumStallAngles Construct.getLiftEfficiency(vec3 axis) - Returns a 0..1 value indicating the average efficiency of all airfoils along that axis, determined by currentLift/maxLift.  Can be used to optimize turns toward the highest efficiency, which implies the maximum speed/angle at which it can turn along that axis in the current conditions Might be better as Construct.getEngineEfficiency(taglist, vec3 axis), which could also work on airfoils Construct.getSustenationSpeed Modify Library.getPointOnScreen - take a local position Library.getWorldPointOnScreen Improve efficiency of getPointOnScreen - apparently it is less efficient than our current methods, regarding overloads Construct.getObstructionFactor(engineTagList) - returns the average(or total?) obstruction factor of all engines in the taglist Modify Construct.getCurrentBrake - Ensure it includes obstruction (if it doesn't already, I haven't been able to check).  So should any other 'current' engine readings, again, if they don't already Construct.getCurrentThrustAlongAxis Construct.getPitch, getYaw, getRoll - In degs or rads, and possibly return these values relative to the velocity vector when not near a gravity source, since at that point they have no meaning - or relative to galaxy center would work.  It would be nice to have a consistent value across all ships, instead of each AP possibly choosing a different way to calculate it Core.getWorldNorth - Returns a vector pointing north from the core for the current planet, normal to gravity, in world coordinates.  Currently we can sort of guess this by assuming the north pole is the point on the planet at the highest global Y (or is it Z?), but a tilted planet would mess that up, if there ever were one.  0 when not in planet influence Player.getRaycastObject - Gets some sort of info about what the player is currently looking at.  Particularly I'd like it to be able to detect whether or not the player is 'aiming' at another player, for VR shooting games, but construct info (looking at a ship in space), itemIds, and/or local element IDs could all be useful The main goal of detecting player 'hit' is so that these games could involve complex (real) arenas and rely on line of sight, rather than always being able to 'shoot' through walls
 

One thing I would also love to see is something like:

controlUnit.enableEngineTorque(taglist, state)

as we now have engine.enableTorque(state) but this is not really useful due to links limitations.

Awesome update, the screens are really getting powerful
 
I'm most excited about the Item API, but I hope it gets a few extra things; notably, a field to indicate the blueprint ID for a given item, and a function to retrieve an Item ID from a core Element ID; i.e., a way to see what size that fuel tank is, without linking to it and without having to use its HP to estimate

Awesome update, the screens are really getting powerful
 
I'm most excited about the Item API, but I hope it gets a few extra things; notably, a field to indicate the blueprint ID for a given item, and a function to retrieve an Item ID from a core Element ID; i.e., a way to see what size that fuel tank is, without linking to it and without having to use its HP to estimate

Awesome update, the screens are really getting powerful
 
I'm most excited about the Item API, but I hope it gets a few extra things; notably, a field to indicate the blueprint ID for a given item, and a function to retrieve an Item ID from a core Element ID; i.e., a way to see what size that fuel tank is, without linking to it and without having to use its HP to estimate

This is better, but still doesn't address any of the problems (except the low core count), and seems like overkill for what should be a simple fix: Actually limiting players to 4 orgs per player, as intended. 
None of this is necessary if players can only be in 4 orgs; it would already solve the problem of infinite cores, and then the values of the existing system can be tweaked, instead of remaking the whole thing

This is better, but still doesn't address any of the problems (except the low core count), and seems like overkill for what should be a simple fix: Actually limiting players to 4 orgs per player, as intended. 
None of this is necessary if players can only be in 4 orgs; it would already solve the problem of infinite cores, and then the values of the existing system can be tweaked, instead of remaking the whole thing

Additional thoughts: Abuse is likely and possible
 
If I happen to know that some org, which is no longer active, will run out of slots, I could donate my own slots to that org.  Then whenever I feel that they won't login for 2 weeks, after the grace period, I revoke the slots I gave them and wait for their constructs to become mine, since only I know when they'll become available
 
Or another example, say I'm the only legate in an org that has some slots given by other players.  I go on vacation, or don't login to DU, for 2 or more weeks - Anyone aware of my vacation could move their slots to another org, then wait around and steal whatever becomes unclaimed (or just reallocate them to grief, and not steal anything)
 
This is giving random players way too much control over whether or not orgs can actually keep the things they built or not

Additional thoughts: Abuse is likely and possible
 
If I happen to know that some org, which is no longer active, will run out of slots, I could donate my own slots to that org.  Then whenever I feel that they won't login for 2 weeks, after the grace period, I revoke the slots I gave them and wait for their constructs to become mine, since only I know when they'll become available
 
Or another example, say I'm the only legate in an org that has some slots given by other players.  I go on vacation, or don't login to DU, for 2 or more weeks - Anyone aware of my vacation could move their slots to another org, then wait around and steal whatever becomes unclaimed (or just reallocate them to grief, and not steal anything)
 
This is giving random players way too much control over whether or not orgs can actually keep the things they built or not

My primary feedback is that it's unfair to refund only skill points that were already invested in construct management - when, realistically, if this had existed months or years ago, players would likely have already took these skills instead of others that they are now locked into
 
 
This is a common theme that NQ keeps doing; adding mining units?  Reset mining talents!
But that doesn't help people that didn't previously have mining talents, but now want them in their new form.  Just like resetting construct capacity talents from before, doesn't help anyone who wants the new talents and would have invested in them if they had always been like this
 
 
Big talent tree changes should involve full talent tree refunds

My primary feedback is that it's unfair to refund only skill points that were already invested in construct management - when, realistically, if this had existed months or years ago, players would likely have already took these skills instead of others that they are now locked into
 
 
This is a common theme that NQ keeps doing; adding mining units?  Reset mining talents!
But that doesn't help people that didn't previously have mining talents, but now want them in their new form.  Just like resetting construct capacity talents from before, doesn't help anyone who wants the new talents and would have invested in them if they had always been like this
 
 
Big talent tree changes should involve full talent tree refunds

Additional thoughts: Abuse is likely and possible
 
If I happen to know that some org, which is no longer active, will run out of slots, I could donate my own slots to that org.  Then whenever I feel that they won't login for 2 weeks, after the grace period, I revoke the slots I gave them and wait for their constructs to become mine, since only I know when they'll become available
 
Or another example, say I'm the only legate in an org that has some slots given by other players.  I go on vacation, or don't login to DU, for 2 or more weeks - Anyone aware of my vacation could move their slots to another org, then wait around and steal whatever becomes unclaimed (or just reallocate them to grief, and not steal anything)
 
This is giving random players way too much control over whether or not orgs can actually keep the things they built or not

Additional thoughts: Abuse is likely and possible
 
If I happen to know that some org, which is no longer active, will run out of slots, I could donate my own slots to that org.  Then whenever I feel that they won't login for 2 weeks, after the grace period, I revoke the slots I gave them and wait for their constructs to become mine, since only I know when they'll become available
 
Or another example, say I'm the only legate in an org that has some slots given by other players.  I go on vacation, or don't login to DU, for 2 or more weeks - Anyone aware of my vacation could move their slots to another org, then wait around and steal whatever becomes unclaimed (or just reallocate them to grief, and not steal anything)
 
This is giving random players way too much control over whether or not orgs can actually keep the things they built or not

Additional thoughts: Abuse is likely and possible
 
If I happen to know that some org, which is no longer active, will run out of slots, I could donate my own slots to that org.  Then whenever I feel that they won't login for 2 weeks, after the grace period, I revoke the slots I gave them and wait for their constructs to become mine, since only I know when they'll become available
 
Or another example, say I'm the only legate in an org that has some slots given by other players.  I go on vacation, or don't login to DU, for 2 or more weeks - Anyone aware of my vacation could move their slots to another org, then wait around and steal whatever becomes unclaimed (or just reallocate them to grief, and not steal anything)
 
This is giving random players way too much control over whether or not orgs can actually keep the things they built or not

My primary feedback is that it's unfair to refund only skill points that were already invested in construct management - when, realistically, if this had existed months or years ago, players would likely have already took these skills instead of others that they are now locked into
 
 
This is a common theme that NQ keeps doing; adding mining units?  Reset mining talents!
But that doesn't help people that didn't previously have mining talents, but now want them in their new form.  Just like resetting construct capacity talents from before, doesn't help anyone who wants the new talents and would have invested in them if they had always been like this
 
 
Big talent tree changes should involve full talent tree refunds

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

This is long overdue imo.  While some people might find ways around it, with the functionality 'removed', those people can be banned for their actions.  While many may keep their scripts private, the most problematic example of a nefarious script is one that transmits data between players - requiring trust of two or more players, that neither reports the other.  Orgs that use these sorts of scripts either have to never recruit people again, or be very careful about it, and even an old veteran who got mad at the game and org could report the org, getting all members banned
 
Risking a ban of an account that you've invested so much time into hardly seems worth it, and as a whole, very few people are willing to use bannable exploits, compared to the number of people willing to use vague grey area tools
 
Also, most workarounds mentioned are very detectable.  Anything that uses the lua, such as drawing QR codes or logging via invalid flush calls, is pretty obvious if NQ were to receive a report and check the lua on a player's control units - and might could even be detected automatically in some cases.  
 
 
 
Otherwise, very few legitimate uses will be impacted.  The logfiles themselves will still contain things like market data or MU data by the sound of it.  Something like physics data collection, or item/recipe data, can log to a string and into a screen instead, to be copied out on a case by case basis.  Logging from lua script to file every tick is no longer possible - but shouldn't be, because that results in some very inflated logfiles that can cause slowdowns for users in some cases, and if done maliciously, could result in filling up a user's entire disk.  Logging to a screen or databank would be more appropriate
 
 
 
I do agree with Arch, though; this is only one step in the right direction.  The logging as a whole needs to be trimmed drastically - they are massive, tend to have many meaningless lines that occur every tick with the same data, and a lot of the things logged can likely provide info that you wouldn't want people to extract from DU.  I think the best strategy isn't to make a list of things to remove from the logs; instead, make a list of things that actually should go there, and remove everything else

Damn you people are whiny.
 
This change is awesome.  Docking is simplified, not made harder - much better than the maneuver tool jankiness.  Though floating 'docked' ships may look a bit odd.  
The only form of 'boarding' DU has today is where you take an alt and logout on someone's ship when they're not online.  Which part of that is fun?  It is very nice that NQ has finally cleared that up, so people like Markee aren't constantly being harassed, and until we have AvA there's no downsides.  We may see some changes once AvA is in, who knows

Damn you people are whiny.
 
This change is awesome.  Docking is simplified, not made harder - much better than the maneuver tool jankiness.  Though floating 'docked' ships may look a bit odd.  
The only form of 'boarding' DU has today is where you take an alt and logout on someone's ship when they're not online.  Which part of that is fun?  It is very nice that NQ has finally cleared that up, so people like Markee aren't constantly being harassed, and until we have AvA there's no downsides.  We may see some changes once AvA is in, who knows

Damn you people are whiny.
 
This change is awesome.  Docking is simplified, not made harder - much better than the maneuver tool jankiness.  Though floating 'docked' ships may look a bit odd.  
The only form of 'boarding' DU has today is where you take an alt and logout on someone's ship when they're not online.  Which part of that is fun?  It is very nice that NQ has finally cleared that up, so people like Markee aren't constantly being harassed, and until we have AvA there's no downsides.  We may see some changes once AvA is in, who knows

Damn you people are whiny.
 
This change is awesome.  Docking is simplified, not made harder - much better than the maneuver tool jankiness.  Though floating 'docked' ships may look a bit odd.  
The only form of 'boarding' DU has today is where you take an alt and logout on someone's ship when they're not online.  Which part of that is fun?  It is very nice that NQ has finally cleared that up, so people like Markee aren't constantly being harassed, and until we have AvA there's no downsides.  We may see some changes once AvA is in, who knows