B4nd1t

I hope NQ hasn't forgotten about this. I still want to get my t-shirt and my pets^^

I'm just sad. What is the point? We need something like DU-Creators but ingame. Not a limited space in an NQ building to visit. There are so many player build shops and showrooms. Make a hub to advert and link them! Not this crappi crap crap thing. 
 
One step forward, two steps backward. Classic NQ. 
Soon we will talk about NQing something for "good idea, bad execution". 

NQ why are you managing things that we as players could also do, dont waste your time on things like this. Put more efford in balancing and economy problems then in smt that WE as a community could do the same. If you want to give us a place for advertisment give us a pinboard or so as a menu point, where we can post ads, events, org recrutment... (maybe with a price for some quanta a week. 

As mentioned  
 

Oh.. right... so 64 slots would be enough if there will be 10k+ active players at release? 😅

So much for player driven. Is this what NQ spends their time on? Something inferior to that players have already created years ago?

No no no no. This is all backwards. DU is supposed to be PLAYER-driven, not NQ-driven.

I'm just sad. What is the point? We need something like DU-Creators but ingame. Not a limited space in an NQ building to visit. There are so many player build shops and showrooms. Make a hub to advert and link them! Not this crappi crap crap thing. 
 
One step forward, two steps backward. Classic NQ. 
Soon we will talk about NQing something for "good idea, bad execution". 

Noveans,
 
First, we wish to thank everyone for all of your feedback and questions about the topic Shedding Light on a Novaquark Internal Discussion.
 
We wanted to let everyone know that the internal discussions are still in process and currently ongoing with all of the pros and cons mentioned in the thread above. This is a big decision and we want to do what is right for Dual Universe, as well as our current and future players.
 
We have been reading all of your feedback and questions, and they have been extremely useful in our internal discussions. As soon as a decision is made, we will pass that information to you. We appreciate your patience and support as we continue to explore and investigate the best possibilities for Dual Universe. Thank you!
 
In addition, we will soon have information about the Kickstarter Rewards, as well as DACs to share, so please keep watch for that!
 
 

 
New Community Podcast 
 
We know that you have many questions about many Dual Universe topics on your mind. Next week, we will be starting a new podcast where we will be bringing your questions to our Novaquark team for answers. 
 
How does it work? Good question! 
 
If you have a question about Dual Universe (game mechanics, lua, FTUE - these are just some examples of topics to ask about), then head over to our Community Questions Submission Form and enter your question(s) there. Once submitted, just listen to the upcoming podcasts and your question may be included there. We look forward to hearing from you!
 

It's not much, and since there are no survival mechanics, it's unlikely to have much game mechanic impact.... BUT it would bring a lot of immersion into the game.

 

It's not much, and since there are no survival mechanics, it's unlikely to have much game mechanic impact.... BUT it would bring a lot of immersion into the game.

 

I hope NQ hasn't forgotten about this. I still want to get my t-shirt and my pets^^

It's not much, and since there are no survival mechanics, it's unlikely to have much game mechanic impact.... BUT it would bring a lot of immersion into the game.

 

NQ-Nyota,
As a player that started just after Beta started and had logged on and played every single day up until this thread started (I have not logged on since-possibly permanently done depending on this decision) I am happy to provide my feedback. Note that I have paid for my subscription(s), and did not have any free beta keys. Find what I believe are the main issues and recommendations below. Just a thought to keep in mind however....anything you do confers advantage to someone. That includes a full wipe. You can't wipe organization discord channels you don't control, so a full wipe absolutely provides MASSIVE advantage to existing large orgs simply because they are already organized and can pool resources to rebuild faster than anyone else possibly could. Nothing you can do will prevent that in any way from happening. For the 'full wipe' crowd, I think some honestly believe that is best, I can respect that, but some are advocating that strictly so they can dominate some aspect (e.g. PvP) of the game where having a large cooperative player base will vastly outperform anyone else that tries to compete regardless of wipe status, but even more so after a full wipe. You need to balance some degree of leveling with the need to keep some part of your existing player base by not making it to hard for single players or smaller orgs to restart or they will give up and go away.
Issues:

1 Talent Points: Given a paid subscription, wipe of talent point is a non-starter for me. Since I have paid for the subscription, you would be removing value that can only be obtain through payment of real-world money over time. I could MAYBE see the argument for removing talent points for free beta keys, but any removal of talent points would feel, to me at least, like theft. Other people obviously feel differently about that, but that issue is a non-negotiable from my perspective, at least for anyone that has been paying for a subscription. 

2. Territory/Quanta reset: I can understand quanta wipe, I can understand territory reset where  players need to reclaim territory. Both of those are reasonable, and probably necessary at this point given some extremely poor decisions (e.g. WTF on auto-assigning 5 HQ tiles....most of the junk that needed cleaning up belonged to players that had less than 5 tiles anyway, so you destroyed any positive effect of the rent and cleanup mechanics with that one....sorry that was a terrible decision, made at the last minute). 

3. Schematics: The only reason I can think of that you now want to remove schematics is that someone did the math like I did and went 'whoa' when they saw the number for how long it would take to restart any reasonable economy or even create the capability to build most elements if everything was wiped and you had to restart the economy from scratch. With the mission nerfs you are putting in, there simply won't be enough quanta in game to finance schematic purchases to rebuild factories fast enough, at least before any new players get frustrated and bail. With the new resource distribution and lack of a 'grindable' mining mechanic elements that are now common and inexpensive would be nearly impossible to build for weeks or months, at least in any quantity. The small number of players and large orgs that might do so would effectively have a near monopoly on advanced through exotic elements (including you know warp drives and warp cells) and would get WAY richer than most are now. Sooooo, you remove schematics so more people can build by taking the brakes off, but run into the same situation pre-schematics where no one really needs to participate in an active market. 

4. Economy restart: You have backed yourself into the corner on this one with the resource distribution and auto-miners with Demeter. A number of people pointed this out in the pre-Demeter comments, but apparently you all missed that. The only change that was made was to allow the DSAT to be build with lower tier ore which makes it theoretically possible to restart the economy, just very very slow. Had you made the recipe for autominers to only rely on ore from 1 tier down from what the miner mines (that was recommended pre-Demeter) a economy bootstrap would be MUCH faster. Restarting the economy from a complete wipe will be VERY time consuming, even without schematics and any benefit you hope to gain from new players at launch is likely to evaporate quickly since there simply won't be easily available stuff. This is a hard game to master and is only viable for new players in many cases with help from existing players/orgs OR the availability of relatively cheap parts/elements on the market. Have you looked at a factory progression/restart from a complete wipe to building warp beacons? I have, I know I could do it, but I am seriously questioning why I would want to as it would be in no way fun or enjoyable, just a painful slog to get back to the bare minimums. It requires layers of bootstrapping. See item 3 on schematics....removing schematics probably puts this in the realm of weeks and that is just because of build times delaying progression and assumes ore is actually available in quantity, which i am not sure of.  However, regularly availability in the markets for anything higher than 'uncommon' elements could easily be months due to scarcity and price gouging for what is available. I would be shocked if the first warp drives that hit the market were priced under 10M each, and it stayed that way for some time. Keeping schematics puts this likely at months, if not the better part of a year unless you dropped schematic prices to almost nothing. A small number of players will be able to ramp up SOME production in either case, but there will be no common or reasonably priced availability for most elements for a LONG time. Orgs that band together will go quicker, but it will still be weeks or months before their internal needs are met.  Just building the industry units to build more industry units to build higher tier industry units will take a long time any way you cut it. The ONLY way you have left to get higher tier ore is asteroid mining, at least until there is enough availability to start putting out autominers, but even then there won't be nearly enough in operation to meet demand for weeks or months, which means huge inflation and price gouging and the same people that are currently rich getting rich again with no effective change.

Bottom line here, your tone in the devblog clearly indicated that a full wipe was the preferred decision of whomever wrote it. (Yes we have all used the 'present non-viable/flawed options first' then the preferred choice last approach to shape a decision process. Whoever wrote the post did exactly that, whether they realized it or not) but I don't think you understand how non-viable a complete wipe is given the current factory and resource mechanics.

5. Player advantage: I am going to be blunt here, in the immortal words of one of my org mates: "Did you win DU yet?". If you don't get it you don't get it, but this was supposed to be an open world sandbox game with persistent creations but it is also an MMO. People that want to acquire stuff will do so, no matter what, but most of your creative player base just wants to build stuff and have Friday night races and such. Be careful when you 'remove advantage' since the starting point with the current game is NOT anything like the starting point when Beta started. If you remove all the 'stuff' from the economy, well, see item 4 above. Bit of a potential nightmare there, probably the quickest way to kill the game for good. A lot of veteran players will feel betrayed and not come back, and the economy restart....well it might not restart, at least not the way you think it will, which will bleed off any new players quicker than you think is possible. What you should really be focusing on is enabling new players, not looking for ways to nerf existing players, or at least some balance of the two. You have a hard call here, but you seriously need to think about balancing the benefits new players get from the large number of existing players willing to help them out, because those existing players HAVE resources and the time to help and are not scrambling to build the next tier autominer against the 'level playing field' you seem to want to create where everyone is scrambling for limited resources for potentially months. Any leveling you do accomplish will be short lived at best, and I honestly don't know if it will provide some marginal benefit or kill the game within 6 months. Also, 'removing advantage' really does not work. It will only benefit a small number of large orgs that will be able to immediately pool resources and will simply dominate everything, and single players will be left worse off than before. By 'removing advantage' you run the risk of actually giving ALL the advantage to a small number of large orgs, which is probably why a good quantity of the people that advocate for a full wipe are doing so, they know that your approach to 'leveling the playing field' will give them (or their org...you know who they are) a HUGE advantage over everyone NOT part of a large org. Well, everyone else could also band together you say....but what about the new players that don't know they need to do that. There is no simple answer here, but actually zeroing out what you apparently perceive as advantages, simply gives certain player groups their own MASSIVE advantages. Bottom line, whatever you do, some people or groups will start with massive advantages, but if you get to extreme with trying to level things, you will alienate a significant portion of the dwindling hardcore player base and they will leave, while the playing field will be even less 'even' than it was before.

6. Trust: You don't have it with your existing player base. New players get:
time mark 10:34. Unfortunately, this the only 'up and coming space sim' video where I have even seen DU even mentioned, and the mention is not good in this case.  I also have a hard time disagreeing with TheYamiks on this one, as much as I would like to do so. This contributes to frustration and fatigue on your existing player base and will drive off any hope of new players. There is a strong perception that when you do listen to players it is to a very small minority of very vocal players in the official discord echo chamber. When is the last time you actually put out a player base wide survey with meaningful questions to your entire player base? (That is clearly a rhetorical question, the answer being 'never') There are the occasional pop up surveys in-game that don't really cover anything substantive, but that is really it. Example, from all prior communications, the party line has always been along the lines of, we will avoid a wipe at all costs, but if we do, veteran/beta players will keep something and I am pretty sure talent points were explicitly part of that something or at least heavily implied. Yet that was CLEARLY not my takeaway from this dev note, which dropped talent points squarely in the 'advantages we need to nerf' category. It was also pretty clearly preferring a full wipe the way the  pros/cons were shaped to make that appear the only viable solution. That is why since last week I no longer log in every single day like I did for more than a year and a half, and depending on what your decisions are here, I may not ever log in again. All my subscription(s) have now had auto-renew turned off for this simple reason, I don't trust NQ to do what they say. I am not unrecoverable as a customer, but you need to convince me it is worth my time to come back.
 
Recommendations:

1. Talent points: leave them alone or reset them into a pool that can be re-assigned, at least for paid subscriptions. Harder call on free beta keys, but at least an option to convert to a paid account is probably in order there. Will they provide an 'advantage', sure, but not that huge of one in most areas. If you are doing an economy reset, your industrial players will absolutely need every single talent point they can get if you want the economy restarted within months vice a year. The ONLY place there might be an 'advantage' issue is the PvP specific talents. Training single weapon or function talent trees for PvP functions would likely be possible before the parts become readily available to take advantage of them anyway. The large PvP orgs would likely WANT you to wipe talent points since they have a large enough player base to quickly rebuild specialized talents and will simply dominate everyone anyway within 2-4 weeks no matter what you do here. 

2. Territory/Quanta reset: Unfortunately, I think you have to do this and wipe territories and quanta. Had you NOT auto-assigned HQ tiles to effectively inactive players, or used a better approach to cleaning up dynamic constructs it might have been possible to keep territories, but NQ messed that up hard and I don't think there is any other option there. Quanta is a harder question. Due to the previous mechanics, you likely need to get most of it out of the game, BUT with the mission nerfs, if schematics are left in, there is a problem for ramping up the economy again if you don't include new quanta injection. Unless you are adding purchase bots back in to the markets for things other than tier 1 ore, capital injection into a restarting economy is going to be an issue.  I don't  know that there is a good answer there, so nuking territories and quanta from orbit is probably as viable as any other approach and I don't think there really is a 'good' solution here, only different levels of 'bad'.

3. Schematics. I think you screwed yourself and all of us on this one. With the current resource distribution and more limited quanta injection due to mission nerfing, leaving them in at anything like the current costs significantly delays any sort of economy restart. However, there is a need for a mechanic that requires capital investment in industry, otherwise there won't be an economy, and people will just build their own stuff. If you leave them in, reduce costs significantly and for gods sake just allow them to be purchased on any market, making people run around to different planets for schematics does nothing useful other than waste time and annoy people. If you remove them, the way resources are distributed now will probably provide the short term 'brakes' that limit everyone from building their own factory. That MIGHT be enough in the long term, I don't claim to know the answer there, but nuking them MIGHT be OK but I am wary of that as to simple an answer to a complex question.

4. Economy restart/peoples stuff: This one is problematic. However, there could be a partial solution. If you allow each player to bring over a limited volume of items that they select, this could mitigate somewhat the economy jumpstart issue. Allowing everyone to bring unlimited items would be terrible, but if each player can select some volume that can be retained, this possibly addresses economy restart. If each player got a 'magic container' of fixed volume or even say a Sm or XS static core they could pack to their preference this would allow a economic restart much quicker, and how 'successful' each player would be is dependent on the choices they make on what to bring. I am not sure what the correct volume would be, but probably no more than you be able to pack into a Med core WITHOUT allowing containers, or a SM or XS allowing containers. Would some players get ahead doing this, of course, that that is going to happen no matter what, and part of that would depend on how good their decision were on what to bring. Could someone pack 20 warp drives (or even 100) and get rich....maybe unless everyone else did the same thing, and lets be honest, 100 warp drives would be a drop in the bucket on what the demand would be after a reset and how rich would they get when no one had any money to start? Miners would bring autominers over, industrialists would bring industry machines over, ship parts would be available in some quantity. As long as the total volume for each account is limited, whatever comes over is it until a new industrial base is created, so some people would have an 'advantage' but a limited one at best. If you pack your volume with industry machines, you can have a factory up quicker, assuming someone else brought miners and is mining resources for you. If you pack your volume with warp drives, you get an immediate influx of cash, to the extent that people have cash to spend, but no long-term benefit after that. If someone wants to use their volume to bring over a bunch of space engine XL, great, but those take up a lot of volume, so there would simply not be a lot anyone could bring if the volume is limited so it is self-limiting based on the number of paid accounts. It will disproportionally advantage large orgs, but that is going to happen anyway with a full wipe, so this would at least allow single players or smaller orgs to avoid a from-nothing bootstrap and possibly encourage people to stay that would otherwise leave. This would introduce more diversity of products and get different sectors of the economy working faster than a one-size-fits-none standard starter pack for veteran players and would be an almost interesting mini-game in itself....kind of: :"you have to pack one bag to live on a desert isle for a year, what do you bring? Choose wisely" where any advantage that is accrued is based almost solely on peoples game play type and decisions. If you feel it is necessary to balance that for new players, give them a standard starter kit which the new FTUE is essentially doing anyway but don't give that to veteran players or make it an option for them to do one or the other. That probably levels things about as well as possible while adding enough diversity to engage different player types, restart some of the economy faster,  and retain at least some of the people that will simply not come back with a full wipe.

And ?
 
 

I hope NQ hasn't forgotten about this. I still want to get my t-shirt and my pets^^

I supposed there are more to the list I think... There are these items shown in the price table, although I am not sure if any of these have changed...
 
 
 

Following our policy of being as transparent as possible and to keep everyone informed, we want to give you some insight about the internal discussions the Novaquark team has on the delicate topic on whether we’re going to have a wipe or not, and under which form. The discussions are numerous, as there is no easy answer and we have to take into account all of the pros and cons for each possible solution. We also have been taking into account the players discussions which have happened - and for some, are still happening - on Discord and our official forum. On one hand we have you, our early backers and players, who supported us for quite some time now, and we want to renew our thanks for being so patient and passionate about Dual Universe. On the other hand, we have the constraints of making the game appealing to new players.
 
Please note: By “new players”, we mean players who’ve just heard about Dual Universe, but we also have many backers that have chosen not to participate during Alpha and Beta, so they can begin playing once the game has reached a polished enough state with game mechanics.
 
SO, WHAT ARE THE PARAMETERS WE HAVE TAKEN INTO ACCOUNT?
 
We know that players have repeatedly asked for an answer to this question. It has been on the table for many months, if not since the Beta opened. The team has been discussing many options on the topic and we’ve gone back to the drawing board many times. Here is an overview of the factors that we are taking under consideration:
 
A reset would be an opportunity to remove things that have been deemed very unpopular by the already existing community, such as the schematics. The only way to remove them in a clean way without causing too many disturbances in the economy is clearly when the in-game economy has been just reset.
 
Many tests/adjustments during Beta have impacted the in-game economy, leading to have some players getting extremely rich way faster than intended, due to an intensive use of some features in their early stage, such as the mission system (and that's understandable, as the situation is part of a normal process in the development of a game). However, it's also common practice in the game development process to usually have some kind of reset when critical milestones are reached, and resetting the economy to have a healthy start once the game has been stabilized and the game features have become more balanced makes sense.
 
As you, our current experienced players, will have quite an advantage compared to the new players on many levels (game knowledge, talent points, wealth, constructs already owned), there's a need to make things a bit more balanced to give a fighting chance to the wave of new players that will join the Community later.
 
We also want to give all the players (new players as much as a big part of the early backers who have waited for the game to be in a fairly polished state) to have the opportunity of the right start.
 
In case of a wipe, finding a way for our veteran players to allow them to keep (or rebuild quickly) their favorite constructs, without creating any loophole for players to bypass the reset (and defeat the purpose of why it’s done).
 
Some planets currently do not have the quality and polished state the Novaquark team wants to give them. We also have seen that a part of the Community has the same opinion on the topic, and this is why the dev team has been planning a revamp for the planets which haven’t received one already.
 
WE CONSIDERED SEVERAL ALTERNATIVES SO FAR TO REACH THESE GOALS:
 
- Doing no wipe at all.
 
Pros:
Satisfying for some of our long-time builders and traders Cons:
Unsatisfying for players wanting to discover the game and start with a more polished version of the game. Does not allow to remove Schematics properly. Does not allow to revamp the old planets properly. Does not allow the rebalancing of the economy properly. Potentially keeping bugs related to very old Constructs.  
 
- Making a partial wipe where the economy would be wiped, but not the Constructs, which would keep all player-made creations intact, with also in mind to prevent some players from storing resources on said Constructs to circumvent the reset of the economy.
 
Pros:
Relatively satisfying for some of our long-time builders. Cons:
Extremely complex to put in place properly without the known loopholes interfering (such as piling up Resources and Elements on existing Constructs before a wipe and removing them after to sell them). Unknown loopholes could break the wanted healthy economic reset. Does not allow to revamp the old planets properly. Potentially keeping bugs related to very old Constructs.  
 
- Having a “legacy” live server and a new live server, where only the blueprints made before the new server opening would be transferred to the new live server.
 
Pros:
Could prevent any wipe with this solution while managing issues the dev team is trying to solve. Cons:
Opens a number of new issues server-side. Would split the Community.  
 
- Having a full wipe (except blueprints) with solutions to make old time players able to rebuild their favorite Constructs quickly through various means.
 
(Here are a few examples of discussed ideas to reach this goal: for our veteran backers, starting pool of talents points and/or quanta, resource multiplier event right after the reset, etc.).
 
Pros:
Prevents loopholes for an economic reset compared to a partial wipe. Most efficient, proper way to remove schematics. Most efficient, proper way to handle a planet revamp. Cons:
Some possibilities discussed could be seen as an unfair advantage.
Keep in mind, if the above solution is decided on, that an improved version of the Blueprint / Construct deployment tool available to all players will be implemented in-game at the time (or maybe even before) such a solution would be applied to the game.
Such improved version will enable players to have:
A preview of the Construct before deploying the said Construct from a blueprint (this feature should be available with Athena release). An ability to auto-align the preview of the Construct on an already deployed Construct (this feature should be available a bit later after Athena release).
   
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
Though this may seem to be a long explanation, it’s a (very) short description of everything the Novaquark team has discussed so far on this topic. So stay tuned, and we thank you again for your patience and support. As mentioned before, our decision will not be made on a whim, but will be made considering and pondering all of the factors mentioned above.
 
Let us know your thoughts on all this here!

Hello @EasternGamer!
 
That was quite the read.
 
Although we do already have very similar plans on the drawing board, it is unlikely that this will happen soon as it will likely have to go hand in hand with a larger Lua change for which we simply do not have an ETA at this time. And it's also not something that can be implemented at any point as it involves some major changes that would mean refactoring and "fixing" just about every single Lua script that currently exists in the game.
 
As such, although we agree with the idea and would eventually like to do something along these lines. It is very unlikely it will be before release.

Intro
With the recent dev-blogs, I feel like there's been a change in attitude with Lua. Before, we basically never got changes to it or the changes were very minimal/incomplete. (*cough* character orientation *cough*)
But, now that we're adding a bunch of functions to Lua, so much so that it's starting to get cluttered with really long function names, I think a general structure change should occur. A perfect example is camera data.

Structure Change
The core unit, control unit and system basically are filled to the brim with functions that don't really related to them, especially system.
 
So, here I go with what I believe should happen:
The creation of a "Construct" default slot. (No links required)
The creation of a "Player" default slot. (No links required)
The creation of a "Database" default slot. (No links required)
The creation of a "Elements" default slot. (No links required)

Construct Slot (moved to)
This slot will handle everything to do with the construct, and only the construct. As the first dev-blog has shown, a fair number of things are irrelevant of the core, thus it doesn't quite make sense that we should still access the core for them.

For example, world orientation of the construct is irrelevant to the core, and even ordinary orientation is irrelevant to the core since it is based off the orientation unit, a gyro or core.
However, data which is more core-related remains, like direct calculations/measurements that you would imagine the core making (velocity, acceleration etc.).
 
Player Slot (moved to)
This slot will handle everything to do with the master player, the player who has executed the control unit. As you can guess, a fair number of functions are placed on the unit because of this. But, it sort of makes little sense beyond the fact that the player activated, not to mention to access any player related info, they want to prefix every function with MasterPlayer, a perfect example of how absurdly long it is getting is unit.getMasterPlayerWorldForward(), now tack on camera to it... unit.getMasterPlayerCameraWorldForward(). You get the point.
 
Database Slot (moved to)
This will consolidate any thing that essentially accesses a database, static or otherwise, for instance getting the player name, position, etc. It will be similar to the Lua version in our files, but be entirely made of native code, instead of Lua. This should help with Database.lua's semi-redundancy and inefficiency, aside from code length contraction.
 
Elements Slot (moved to)
This will consolidate any general element function that is normally accessed by the core. This will remove the need to basically prefix stuff with getElementDATAById(uid)
Instead, you will simple say getDATAById(uid) or getDATA(uid)
 
Keys
Bad Name* (Italics, suffixed by one or more light yellow asterisks, name requires a change for consistency reasons)  ? Dev Blog Addition (Bold, prefixed by "New" emoji) moved to (Colour coded, moved to another slot) Suggested Addition (Bold, green)
Core
getData() getConstructMass() getConstructIMass() getConstructCrossSection() getMaxKinematicsParametersAlongAxis(taglist,crefaxis) getConstructWorldPos() getConstructId()  ? getConstructName()  ? getOrientationUnitId() getWorldAirFrictionAngularAcceleration() getWorldAirFrictionAcceleration() spawnNumberSticker(nb, x, y, z, orientation) spawnArrowSticker(x, y, z, orientation) deleteSticker(index) moveSticker(index, x, y, z) rotateSticker(index, angle_x, angle_y, angle_z) getElementIdList() getElementNameById(uid) getElementTypeById(uid) getElementHitPointsById(uid) getElementMaxHitPointsById(uid) getElementMassById(uid) getElementPositionById(uid) ? getElementForwardById(uid) ? getElementUpById(uid) ? getElementRightById(uid) getElementIndustryStatus(uid)* getElementTagsById(uid) getSchematicInfo(schematicId) getAltitude()  ? getCurrentPlanetId() g()** getWorldGravity()*** getWorldVertical()**** getAngularVelocity() getWorldAngularVelocity() getAngularAcceleration() getWorldAngularAcceleraton() getVelocity() getWorldVelocity()  ? getAbsoluteVelocity()  ? getWorldAbsoluteVelocity()***** getWorldAcceleration() getConstructWorldOrientationForward() getConstructWorldOrientationRight() getConstructWorldOrientationUp() getConstructOrientationForward() getConstructOrientationRight() getConstructOrientationUp() getPvPTimer() getPlayersOnBoard()****** getDockedConstructs()******* isPlayerBoarded(pid) isConstructDocked(pid) forceDeboard(pid) forceUndock(cid) getBoardedPlayerMass(pid) getDockedConstructMass(cid) getParent() getCloseParents() getClosestParents()  ? getParentPosition()  ? getParentWorldPosition()  ? getParentForward()  ? getParentUp()  ? getParentRight()  ? getParentWorldForward()  ? getParentWorldUp()  ? getParentWorldRight() dock(pid) undock() setDockingMode(mode) getDockingMode() getCoreStress() getMaxCoreStress() getCoreStressRatio() All Events *getElementIndustryStatus() -> getElementIndustryStatusById()
**g() -> getLocalConstructGravityIntensity()
***getWorldGravity() -> getConstructWorldGravity()
****getWorldVertical() -> getWorldGravity()
*****getWorldAbsoluteVelocity() -> getAbsoluteWorldVelocity()  (Swapping the Absolute Prefix with the World prefix sounds better and is probably more consistent)
******getBoardedPlayerIds()
*******getDockedConstructIds()
 
System
getActionKeyName(actionName) showScreen(bool) setScreen(content) createWidgetPanel(label) destroyWidgetPanel(panelId) createWidget(panelId, type) destroyWidget(widgetId) createData(dataJson) destroyData(dataId) updateData(dataId, dataJson) addDataToWidget(dataId, widgetId) removeDataFromWidget(dataId, widgetId) getMouseWheel() getMouseDeltaX() getMouseDeltaY() getMousePosX() getMousePosY() getThrottleInputFromMouseWheel() getControlDeviceForwardInput()* getControlDeviceYawInput() getControlDeviceRightLeftInput()** lockView(state) isViewLocked() freeze(bool) isFrozen() getTime() getActionUpdateDeltaTime() getPlayerName(pid) getPlayerWorldPos(pid)   ? getOrganizationName(oid)   ? getOrganizationTag(oid) getWaypointFromPlayerPos() setWaypoint(waypointStr) getScreenHeight() getScreenWidth() getFov() print(msg) logInfo(msg) logWarning(msg) logError(msg) All Events *getControlDeviceForwardInput ->getControlDevicePitchInput
**getControlDeviceRightLeftInput ->getControlDeviceRollInput
 
ControlUnit
exit() setTimer(timerTagId, period) stopTimer(timerTagId) getAtmosphereDensity() getClosestPlanetInfluence() ? getMasterPlayerPosition() ? getMasterPlayerWorldPosition() ? getMasterPlayerWorldForward() ? getMasterPlayerWorldUp() ? getMasterPlayerWorldRight() ? getMasterPlayerForward() ? getMasterPlayerUp() ? getMasterPlayerRight() getMasterPlayerId() getMasterPlayerMass() getMasterPlayerParent() ? getMasterPlayerOrgIds() setEngineCommand(...) setEngineThrust(taglist, thrust) setAxisCommandValue(axis, commandValue) getAxisCommandValue(axis) setupAxisCommandProperties(axis, commandType, targetSpeedRanges) setupControlMasterModeProperties(controlMasterModeId, displayName) getControlMasterModeId() cancelCurrentControlMasterMode() isAnyLandingGearExtended() extendLandingGears() retractLandingGears() isMouseControlActivated() isMouseDirectControlActivated() isMouseVirtualJoystickActivated() isAnyHeadlightSwitchedOn() switchOnHeadlights() switchOffHeadlights() isRemoteControlled() activateGroundEngineAltitudeStabilization(targetAltitude)* getSurfaceEngineAltitudeStabilization()* deactivateGroundEngineAltitudeStabilization()* computeGroundEngineAltitudeStabilizationCapabilities()* getThrottle() setSignalIn(plug, state) getSignalIn(plug) All Events *I got no idea what to replace those with, but the names are just weird, what's a surface engine, ground engine? Function name is super long.
 
Construct
getWorldOrientationForward() getWorldOrientationRight() getWorldOrientationUp() getOrientationForward() getOrientationRight() getOrientationUp()  getWorldPos() getId() ? getName() ? getOrientationUnitId() getMass() getIMass() getCrossSection() getLocalGravityIntensity()  
Elements
 getIdList() getNameById(uid) getTypeById(uid) getHitPointsById(uid) getMaxHitPointsById(uid) getMassById(uid) getPositionById(uid) ? getForwardById(uid) ? getUpById(uid) ? getRightById(uid) getIndustryStatusById(uid) getTagsById(uid) getElementById(uid)  
Player
getId() getMass() getParent() ? getOrgIds() lockView(state) isViewLocked() freeze(bool) isFrozen() getFov() getHorizontalFov(bool) getVerticalFov(bool) getHeadlampState() setHeadlampState(bool) isSeated() getSeatId() getCameraView() getCameraWorldForward() getCameraWorldUp() getCameraWorldRight() getCameraWorldPos() getCameraLocalForward() getCameraLocalUp() getCameraLocalRight() getCameraLocalPos() ? getBodyPosition() ? getBodyWorldPosition() ? getBodyWorldForward() ? getBodyWorldUp() ? getBodyWorldRight() ? getBodyForward() ? getBodyUp() ? getBodyRight()  
Database
 getPlayerName(pid) getPlayerWorldPos(pid) ? getOrganizationName(oid) ? getOrganizationTag(oid) getSchematicInfo(schematicId) getPlayerById(pid) getMasterPlayer() getOrganization(oid) getConstruct(cid)  
 
 
Camera Data Explanation
The camera data is pretty straight forward. I made an code example and explanation before this mess, I'll just paste that here lol.
 
local player = player --> A tab which virtually represents the "player", it holds player related events and functions. local isSeated = player.isSeated() --> Returns true or false if the player is seated or not. local seatId = player.getSeatId() --> Returns the player seat ID if seated, otherwise nil. local headlampState = player.getHeadlampState() --> Returns the boolean of the avatar headlamp, on or off. player.setHeadlampState(not headlampState) --> Inverts the headlamp state. local camView = player.getCameraView() --> Returns 0 for first-person, 1 for third-person and 2 for fixed third-person. -- Consideration to have is that you can get into third person while using the normal avatar using an emoji. -- Why it is useful is so you can change the HUD you intend on using depending on if you're in those seperate views and if you should listen to mouse input for UI, etc. local camWorldUp = player.getCameraWorldUp() --> Returns the camera up vector in world coodinates. local camWorldForward = player.getCameraWorldForward() --> Returns the camera forward vector in world coodinates. local camWorldRight = player.getCameraWorldRight() --> Returns the camera right vector in world coodinates. local camLocalUp = player.getCameraLocalUp() --> Returns the camera up vector in local coodinates, relative to the build grid. local camLocalForward = player.getCameraLocalForward() --> Returns the camera forward vector in local coodinates, relative to the build grid. local camLocalRight = player.getCameraLocalRight() --> Returns the camera right vector in local coodinates, relative to the build grid. local camLocalPos = player.getCameraLocalPos() --> Returns the camera position in local coordinates relative to the build-grid (construct) center. local camWorldPos = player.getCameraWorldPos() --> Returns the camera position in world coordiantes. --<! Optionally, you could add a relative world position function which is relative to the construct center, but in world coordinates. Though, I feel it would be very niche !>-- --- Lastly, local camHFov = player.getCameraHorizontalFov(true/false) --> Returns the horizontal fov with a boolean parameter to determine if it is returned as a radian or degree format. local camVFov = player.getCameraVerticalFov(true/false) --> Returns the vertical fov with a boolean parameter to determine if it is returned as a radian or degree format.  
 
Final Structure (No Formatting, mainly for glancing to see roughly the impact)
 
Core
getData() getMaxKinematicsParametersAlongAxis(taglist,crefaxis) getWorldAirFrictionAngularAcceleration() getWorldAirFrictionAcceleration() spawnNumberSticker(nb, x, y, z, orientation) spawnArrowSticker(x, y, z, orientation) deleteSticker(index) moveSticker(index, x, y, z) rotateSticker(index, angle_x, angle_y, angle_z) getAltitude()  getCurrentPlanetId() getConstructWorldGravity() getWorldGravity() getAngularVelocity() getWorldAngularVelocity() getAngularAcceleration() getWorldAngularAcceleraton() getVelocity() getWorldVelocity()  getAbsoluteVelocity() getAbsoluteWorldVelocity() getWorldAcceleration() getPvPTimer() getBoardedPlayerIds() getDockedConstructIds() isPlayerBoarded(pid) isConstructDocked(pid) forceDeboard(pid) forceUndock(cid) getBoardedPlayerMass(pid) getDockedConstructMass(cid) getParent() getCloseParents() getClosestParents() getParentPosition() getParentWorldPosition() getParentForward() getParentUp() getParentRight() getParentWorldForward() getParentWorldUp() getParentWorldRight() dock(pid) undock() setDockingMode(mode) getDockingMode() getCoreStress() getMaxCoreStress() getCoreStressRatio() All Events  
System
getActionKeyName(actionName) showScreen(bool) setScreen(content) createWidgetPanel(label) destroyWidgetPanel(panelId) createWidget(panelId, type) destroyWidget(widgetId) createData(dataJson) destroyData(dataId) updateData(dataId, dataJson) addDataToWidget(dataId, widgetId) removeDataFromWidget(dataId, widgetId) getMouseWheel() getMouseDeltaX() getMouseDeltaY() getMousePosX() getMousePosY() getThrottleInputFromMouseWheel() getControlDevicePitchInput() getControlDeviceYawInput() getControlDeviceRollInput() getTime() getActionUpdateDeltaTime() getWaypointFromPlayerPos() setWaypoint(waypointStr) getScreenHeight() getScreenWidth() print(msg) logInfo(msg) logWarning(msg) logError(msg) All Events  
ControlUnit
exit() setTimer(timerTagId, period) stopTimer(timerTagId) getAtmosphereDensity() getClosestPlanetInfluence() setEngineCommand(...) setEngineThrust(taglist, thrust) setAxisCommandValue(axis, commandValue) getAxisCommandValue(axis) setupAxisCommandProperties(axis, commandType, targetSpeedRanges) setupControlMasterModeProperties(controlMasterModeId, displayName) getControlMasterModeId() cancelCurrentControlMasterMode() isAnyLandingGearExtended() extendLandingGears() retractLandingGears() isMouseControlActivated() isMouseDirectControlActivated() isMouseVirtualJoystickActivated() isAnyHeadlightSwitchedOn() switchOnHeadlights() switchOffHeadlights() isRemoteControlled() activateGroundEngineAltitudeStabilization(targetAltitude) getSurfaceEngineAltitudeStabilization() deactivateGroundEngineAltitudeStabilization() computeGroundEngineAltitudeStabilizationCapabilities() getThrottle() setSignalIn(plug, state) getSignalIn(plug) All Events  
Construct
getWorldOrientationForward() getWorldOrientationRight() getWorldOrientationUp() getOrientationForward() getOrientationRight() getOrientationUp() getWorldPos() getId() getName() getOrientationUnitId() getMass() getIMass() getCrossSection() getLocalGravityIntensity()  
Elements
 getIdList() getNameById(uid) getTypeById(uid) getHitPointsById(uid) getMaxHitPointsById(uid) getMassById(uid) getPositionById(uid) getForwardById(uid) getUpById(uid) getRightById(uid) getIndustryStatusById(uid) getTagsById(uid) getElementById(uid)  
Player
getId() getMass() getParent() getOrgIds() lockView(state) isViewLocked() freeze(bool) isFrozen() getHorizontalFov(bool) getVerticalFov(bool) getHeadlampState() setHeadlampState(bool) isSeated() getSeatId() getCameraView() getCameraWorldForward() getCameraWorldUp() getCameraWorldRight() getCameraWorldPos() getCameraLocalForward() getCameraLocalUp() getCameraLocalRight() getCameraLocalPos() getBodyPosition() getBodyWorldPosition() getBodyWorldForward() getBodyWorldUp() getBodyWorldRight() getBodyForward() getBodyUp() getBodyRight()  
Database
getPlayerName(pid) getPlayerWorldPos(pid) getOrganizationName(oid) getOrganizationTag(oid) getSchematicInfo(schematicId) getPlayerById(pid) getMasterPlayer() getOrganization(oid) getConstruct(cid)  
 
 
Ending Notes
It has taken me literally the entire day doing this, and even then I feel like I've missed a lot because I was literally looking at the entirety of Lua.
I was planning on explaining all the changes and stuff, but my head is about to explode from doing this the entire day so not gonna. Lol.

Tbh, if they implemented even a single one of these slots, I would be happy. I don't expect most of it to change.
I would also, personally, like if these changes came out gradually, if any. I think if camera angles are added though, we must at least get the player slot, or similar global variable because of how long the variable names will end up getting.
 
Obligatory @NQ-Ligo and @NQ-Deckard, I wish you find this helpful, even if you don't add even 1% of it xD

Oh, and oops. Kinda broke the "one idea" rule... it's kinda a super idea though. Hope whoever od

Transfer engines to... mhmm... engines and let them be linkable to an exhaust. The exhaust get obstruction areas and all linked engines lose there obstruction areas. 

I saw a similar idea before, and kinda like it. It would give us some more freedom and possibilities for our ship designs.

And I would also add my own suggestion in this regard, but doing that inside an own thread.

Oh yes, possible. But there are consideration why the transparent glass honeycombs are delayed in implementation. alas.
I want them, too - badly. And created several suggestions about them here.

I also suggested about glass panels, that they could merge borderlessly with each other instead of blocking each other, and that even an XS size would become available.

And I support your suggestion of rounded or bent glass panels of various sizes and types, even of domes, half-round or 1/3 round or 1/4 round (means: fully half-round or more flat).
 

A proper hybrid engine like that would be cool, and quite useful in cutting down how many links some things need, but I suspect we will be stuck just using rockets for that for quite some time to come.

Transfer engines to... mhmm... engines and let them be linkable to an exhaust. The exhaust get obstruction areas and all linked engines lose there obstruction areas.