hdparm

This.

You're well on the path of going the way of Worlds Adrift.
 
You want to nerf industry because everyone is building their own 'Iphone' - fine - what are they going to do instead? What else is there to do instead? 
 
You want to add element destruction? Great - I'm with you. It needs to happen. But maybe just maybe pairing it with the removal of the Alt-F4 mechanic, removal of Discord support and on top of that nerfing production isn't the best idea? 
 
You think mining is too easy? Grea.....wait what....what? WHAT?! Have you mined in DU? How much? Look, ask anyone who has filled a 10L hub every two nights, there is nothing 'easy' about mining. It's boring. It's tedious. It's concentrated drudgery and one of the primary reasons I don't play DU anymore - but what it is not is 'easy' and never even in my most drunken state (and I admit I sure didn't mine sober) did I think that "Hey maybe if I couldn't link to my 10L hub mining would be better!" . In fact, when linking was broken, I just didn't play the game. 
 
Just the fact that JC thinks that linking is the issue with mining - not literally everything else - makes me lose all faith in his judgment. Of all the things wrong with mining - linking isn't  one of them. Nor is the lack  of "mining hazards"...
 
The community has over and over and over asked for constructs that can mine - empyrion style - give us drills we can put on hovers - give even bigger giant drills we can put on stationary constructs. Give us anything besides handmining because 'easy' it's not - it's at least 7th level of hell grade tedium - and 9th if you have to deal with phantom nodes and pending operations. Unless of course you take my approach, get drunk and watch netflix so that the next day you forget about how hellish mining for 6 hours straight was.
 
Unfortunately I've remembered enough of those nights over time to stop logging in to DU...and the upcoming changes and theroycrafting about the future of mining have made it extremely clear that JC does not play DU either...he may goof around in his castle - but he sure hasn't built a mega factory nor has he mined the ore to get the resources to build his giant fortress if he thinks all those things are too easy...
 
Seriously - JC just logs in - looks at all the stuff others built and his take away is that mining and mega factories are too easy? It took us weeks of drudgery......I can't even...
 
Edit: Also - cores not repairable?! Masterstroke....

As a backend / frontend developer myself for many years:
1) UI / UX for this game is... not made by designers but by engineers. In this regard it is horrible from a designer standpoint. Not to knock the work of the engineers but this is... not a game ui. I'm sorry. This is a product of a bygone era. Modular ui is generally cancer in a game. And when you're married to it, it spawns very very bad children.

2) LUA API is abysmally incomplete. Simple things like knowing what is in a container, or better yet, what is the actual capacity of a container WITH talents... is not a thing. Another example: for some odd reason getYaw() was removed from gyro api. And that was bloody useful... And the list here goes on and on and on. Features that are missing, features that disappeared, etc... Which leads to lots of arcane, frankly, bad code going around, some of which I myself wrote.

3) Market 15... was ... well.. that is a rather permanent face of NQ now. Not to mention poor communication. Not to mention grey rules that you twist in your own favor just to save face.

4) Game has no progression. Literally nothing to do. Players don't care, everyone is self sufficient. Markets are a joke, it's easy to get whatever you want pretty fast. Resources are uniform. All elements are the same regardless who made them, etc... everything becomes more of a chore rather than less, there is hardly any automation, and the stuff we do with LUA are just silly work-arounds that in the end are NOT automation. This game is the opposite of what MMOs generally are: the more time you spend in DU the more labor intensive and less automated things become.

5) Less Content, More Grind. NQ, especially JC keeps throwing around statements such as:  "we expected people to get to space from starting planet in X days" (took me 15 minutes, took other players even less). "Mining is too fast for our liking", "brakes are too effective".... these are all statements that lead me to believe JC didn't mine for his castle, and has probably never built an M or L core all by himself with his own in-game resources. All of this in summation is rhetoric that I interpret this way: We can't provide content fast enough, lets slow the game waaaaaaay down and make it more grindy, more time consuming, because well... uh... we don't have content for you...sorry. It would have been a LOT MORE helpful to the community if NQ actually was transparent as to what is going on there.
 
6) PVP. Geez.. so much to say here... a lot of it has already been said better than I could ever say it. Seems like from the get-go casuals weren't clued in to how to make transport ships viable for slowboating... like for example... putting some voxels on the boat for a start. There was so much whining about one shot kills that I believe NQ was pushed into the direction of not removing planet safezones. We need atmo pvp, we need interdiction, we need material variability, we need to fight for something. Radars need to be fixed. Guns widgets need rework (ui / ux is so terrible and non-ergonomic I can't believe this is 2020).
 
7) Lots more... but I will stop.

@Mornington Be careful what you are suggesting here without knowing the details.  But since you brought this up, I had already made it onto Lacobus past the blockade AND warned Infinity Corp about the blockade AND had already entered into negotiations with Whitemeat and the other "gunters" to join them in our efforts when I had announced to them that we were close to having the entire puzzle.  I took the risk personally instead of putting my org members in danger.
 
 
Don't assume you know what is going on with limited information from the interview. Its called strategy and diplomacy and both worked perfectly, with zero IC ships being destroyed, and a share of the Thoramine in our vault.
 
-Knoober
 

About
This is a basic autopilot script that can accelerate your construct towards a planet and later apply brakes to stop. Vertical space engines are used to control drift.
 
Requirements
Space brakes, 1.5+ g. Vertical space engines (pointing down), 0.3+ g. A remote controller or a separate hovercraft seat. Limitations
No manual piloting. Use another script to get to space and to land. No collision avoidance. Make sure there are no planets, moons, asteroids, space stations or pirates between you and the destination. Planet positions are stored in the script. If NQ moves the planets, the script will have to be updated. Set-up
With an auto-configuration schema (recommended)
Download this file to Game\data\lua\autoconf\custom in your Dual Universe installation directory. By default it's C:\ProgramData\Dual Universe\Game\data\lua\autoconf\custom Right-click the control unit (a remote controller or a hovercraft seat) and select "Update custom autoconf list". This needs to be done only once. Right-click the control unit and select "Actions for this element", "Run custom autoconfigure", "Basic Space Autopilot". With a pasteable script configuration
Open this link and copy everything to clipboard. Right-click the control unit (a remote control or a hover seat) and select "Actions for this element", "Paste Lua configuration from clipboard". The game should display a "Lua script loaded" message. If it did not, restart the game and copy the script configuration again. Link the core (required) and fuel tanks (optional) to the control unit. Credits
Many planet positions were provided by @meigrafd from Hyperion.
The script was bundled (amalgamated from multiple .lua files) using amalg.
 
Change log
2020-09-23. Fixed heavy constructs not accelerating past 29997 km/h. A radar widget will be displayed if a PVP radar is linked (not available on remote controllers). Tested in r0.22.2.
2020-09-16. Posted the first version outside the NDA forums section. Tested in r0.21.6.

Would like some kind "Restore Landscape Tool" ... i.e. able to terraform landscape, plant more trees, ponds etc.   Right now
just digging and flattening is like taking a sledge hammer to your territories.  Why not have tools much like you have to make building
to restore some of the landscape (in one's own Territory of course).

You keep calling it an exploit.
 
Pressing B isn't an exploit.

So steal a ship using exploits - no problem. Steal a base using exploits - no problem. Take everything using RDMS? No problem - unless ts market. Not like.
 

Scoopy here (guy who was ban hammered)
 
We knew we probably were gonna get in trouble after our heist. I didn't think it would be a permanent ban especially due to:
 
 
on top of this, I did report this!  see another reply below (the attached image broke)

Can we get a dislike button?

Been thinking about posting this for a while but thought NQ would have done something already.
 
Going to post this as politely as I can but the support giveaways are a COMPLETE JOKE.  50% of people are lying, this is obvious because they say things like:

"I crashed when coming into atmosphere, logged back in and my ship was destroyed" - bullshit, you crash your ships stops what they actually means is "I have a really heavy ship, I crashed the game coming into atmosphere because i couldnt slow down, logged back in with zero momentum and my massively overweight ship fell like a rock"

"I just died on XXXXX insert planet and have magically teleported to Ailoth, can you port me back" = I was mining and tried to use the force respawn to cheese back to my ship, but didnt check my node before I used this soft exploit
 
This is causing a LOAD of problems, firstly you are completely shielding these new players from any survival elements of the game, experienced players know to fly with good scrap and extra fuel.  New players arent learning these lessons because when they make mistakes (and most ARE player mistakes) they get freebies.

The worst part about all this is that they are making a huge section of gameplay / career paths completely redundant.  In alpha there were loads of players planning to set up as repair / refuel crew or taxi services, I have reached out to several of these to see how business is and there ISNT ANY.  The game has limited career paths as it is (without really knowing the game) these are some of the more obvious ones and you are making them irrelevant.  The longer this goes on the worse it will get.

My solution - send out an email saying that the daily quanta is being continued but it is being called BETA SUPPORT INCOME, it is paid to ensure players have funds in case of emergency.  You then reach out to verified support services orgs and bring them into support via some additional channel, where you can send people who need there services.
 
This needs to be done soon, as you are making a massive rod for your own back by giving this crutch to new players (although seen several vets abusing it too).

It is content.
 
It is an Easter egg.
 
It is being compared to RPO because it is a recent movie and a book brought to the forefront because of the recent movie.  
 
It is part of the lore of the game.  We are no longer around Earth, we are still learning about this star system, and it is obvious that there is a story here, we just don't know what yet.
 
So get out and explore and learn maybe we can unfold this mystery.

OUTDATED. NOT UPDATED SINCE v0.23.0
 
This is the result of running the globals dumping script in-game on constructs that had various elements attached to them.
 
Some exposed functions were called with pcall. The first value indicates whether the call was successful, the second is the actual function return value. All functions that return a vector return it as a table, not as a vec3 structure. Usually such functions will be called like this: local worldGravity = vec3(core.getWorldGravity()). Boolean values are returned as a number 0 or 1, and not as true or false.
 
Element events are not listed here, as they cannot be detected by the dump.lua script. See the codex in-game (press F1) or outside the game (C:\ProgramData\Dual Universe\Game\documentation\web_codex.html) for event and function descriptions and other information.
 
Anti-Gravity Generator
r0.21.0
 
Control unit
r0.23.0
Programming board exposes fewer functions compared to cockpit and seat. The control unit has references to linked elements, which are also available as local variables in each event handler. Event handlers defined in the script editor also get placed inside it. Here the control unit is a hovercraft seat that has 2 linked fuel tanks, a radar and a core.

Core
r0.23.0
Static cores have fewer functions compared to dynamic cores.
 
Databank
r0.21.2
 
Elements with a state
r0.21.2
Detection areas, laser detectors and manual buttons expose the same functions. Their state is accessed using getState().
 
Elements with a toggle-able state
 r0.21.2
Force fields, ship doors, landing gears and manual switches expose the same functions. The state is accessed using getState() and can be changed by activate(), deactivate() or toggle().

Emitter
r0.23.0
 
Engine
r0.21.0
Space engines, atmospheric engines, ailerons, air-brakes, retro-engines and adjustors expose the same functions. Usually engines are controlled through unit.setEngineCommand and do not require linking to the control unit.
 
 Fuel container
 r0.23.0
 
Gyro
 r0.21.2
 
Industry
r0.23.0
 
Item container
 r0.23.0
 
Library
r0.21.2
 
Light
r0.23.0
 
PVP radar (atmospheric and space)
r0.22.0

Radar
not available to craft or buy; for atmosphere and space radars see PVP radar instead
 
Receiver
r0.23.0

Screen
r0.21.2
 
System
r0.23.0
 
Telemeter
r0.21.2
 
Warp Drive
r0.23.0
 
Weapon
r0.21.0

Unofficial Lua changelog
r0.23.0
Changes since r0.22.4:
All elements New functions: getMaxRestorations(), getRemainingRestorations(). Anti-Gravity Generator setBaseAltitude(altitude) no longer works inside the system flush() event. Container (Fuel and Item) New event: storageAcquired(). New functions: acquireStorage(), getItemsList(), getItemsVolume(), getMaxVolume(). Control unit New function: getMasterPlayerRelativeOrientation(). Restored function: setupControlMasterModeProperties(controlMasterModeId,displayName). Core New functions: getElementIndustryStatus(localId), getSchematicInfo(schematicId). Emitter and Receiver Range increased to 1000 m. Industry New functions: getCurrentSchematic(), setCurrentSchematic(id). Light New functions: getRGBColor(), setRGBColor(r,g,b). System New event: inputText(text). New functions: getFov(), getScreenHeight(), getScreenWidth(), getWaypointFromPlayerPos(), setWaypoint(waypointStr). Warp drive Removed function: activateWarp(). r0.22.4
Changes since r0.22.0:
Core New functions: getElementPositionById(localId), getElementRotationById(localId), getElementTagsById(localId). Other global.lua is now inside game.ung and cannot be edited by players. Editing existing files in Game/data/lua should no longer trigger the EQU8 anti-cheat. r0.22.0
Changes since r0.21.3:
PVP radar New functions:  getConstructName(id), getConstructPos(id), getConstructSize(id), getConstructType(id), getEntries(), getRange(), hasMatchingTransponder(id). The getConstruct* functions return "unreachable" or { 0, 0, 0 }, even for construct information that's available in getData(). New events: enter(id), leave(id). r0.21.3
Changes since r0.21.2:
Other package.loadlib has been disabled. r0.21.2
Changes since r0.20.0:
Anti-Gravity Generator New function: getBaseAltitude(). PVP radar getData() no longer returns construct positions. Other pcall and xpcall can no longer be used to avoid the CPU instruction limit.

OUTDATED. NOT UPDATED SINCE v0.23.0
 
This is the result of running the globals dumping script in-game on constructs that had various elements attached to them.
 
Some exposed functions were called with pcall. The first value indicates whether the call was successful, the second is the actual function return value. All functions that return a vector return it as a table, not as a vec3 structure. Usually such functions will be called like this: local worldGravity = vec3(core.getWorldGravity()). Boolean values are returned as a number 0 or 1, and not as true or false.
 
Element events are not listed here, as they cannot be detected by the dump.lua script. See the codex in-game (press F1) or outside the game (C:\ProgramData\Dual Universe\Game\documentation\web_codex.html) for event and function descriptions and other information.
 
Anti-Gravity Generator
r0.21.0
 
Control unit
r0.23.0
Programming board exposes fewer functions compared to cockpit and seat. The control unit has references to linked elements, which are also available as local variables in each event handler. Event handlers defined in the script editor also get placed inside it. Here the control unit is a hovercraft seat that has 2 linked fuel tanks, a radar and a core.

Core
r0.23.0
Static cores have fewer functions compared to dynamic cores.
 
Databank
r0.21.2
 
Elements with a state
r0.21.2
Detection areas, laser detectors and manual buttons expose the same functions. Their state is accessed using getState().
 
Elements with a toggle-able state
 r0.21.2
Force fields, ship doors, landing gears and manual switches expose the same functions. The state is accessed using getState() and can be changed by activate(), deactivate() or toggle().

Emitter
r0.23.0
 
Engine
r0.21.0
Space engines, atmospheric engines, ailerons, air-brakes, retro-engines and adjustors expose the same functions. Usually engines are controlled through unit.setEngineCommand and do not require linking to the control unit.
 
 Fuel container
 r0.23.0
 
Gyro
 r0.21.2
 
Industry
r0.23.0
 
Item container
 r0.23.0
 
Library
r0.21.2
 
Light
r0.23.0
 
PVP radar (atmospheric and space)
r0.22.0

Radar
not available to craft or buy; for atmosphere and space radars see PVP radar instead
 
Receiver
r0.23.0

Screen
r0.21.2
 
System
r0.23.0
 
Telemeter
r0.21.2
 
Warp Drive
r0.23.0
 
Weapon
r0.21.0

OUTDATED. NOT UPDATED SINCE v0.23.0
 
This is the result of running the globals dumping script in-game on constructs that had various elements attached to them.
 
Some exposed functions were called with pcall. The first value indicates whether the call was successful, the second is the actual function return value. All functions that return a vector return it as a table, not as a vec3 structure. Usually such functions will be called like this: local worldGravity = vec3(core.getWorldGravity()). Boolean values are returned as a number 0 or 1, and not as true or false.
 
Element events are not listed here, as they cannot be detected by the dump.lua script. See the codex in-game (press F1) or outside the game (C:\ProgramData\Dual Universe\Game\documentation\web_codex.html) for event and function descriptions and other information.
 
Anti-Gravity Generator
r0.21.0
 
Control unit
r0.23.0
Programming board exposes fewer functions compared to cockpit and seat. The control unit has references to linked elements, which are also available as local variables in each event handler. Event handlers defined in the script editor also get placed inside it. Here the control unit is a hovercraft seat that has 2 linked fuel tanks, a radar and a core.

Core
r0.23.0
Static cores have fewer functions compared to dynamic cores.
 
Databank
r0.21.2
 
Elements with a state
r0.21.2
Detection areas, laser detectors and manual buttons expose the same functions. Their state is accessed using getState().
 
Elements with a toggle-able state
 r0.21.2
Force fields, ship doors, landing gears and manual switches expose the same functions. The state is accessed using getState() and can be changed by activate(), deactivate() or toggle().

Emitter
r0.23.0
 
Engine
r0.21.0
Space engines, atmospheric engines, ailerons, air-brakes, retro-engines and adjustors expose the same functions. Usually engines are controlled through unit.setEngineCommand and do not require linking to the control unit.
 
 Fuel container
 r0.23.0
 
Gyro
 r0.21.2
 
Industry
r0.23.0
 
Item container
 r0.23.0
 
Library
r0.21.2
 
Light
r0.23.0
 
PVP radar (atmospheric and space)
r0.22.0

Radar
not available to craft or buy; for atmosphere and space radars see PVP radar instead
 
Receiver
r0.23.0

Screen
r0.21.2
 
System
r0.23.0
 
Telemeter
r0.21.2
 
Warp Drive
r0.23.0
 
Weapon
r0.21.0

OUTDATED. NOT UPDATED SINCE v0.23.0
 
This is the result of running the globals dumping script in-game on constructs that had various elements attached to them.
 
Some exposed functions were called with pcall. The first value indicates whether the call was successful, the second is the actual function return value. All functions that return a vector return it as a table, not as a vec3 structure. Usually such functions will be called like this: local worldGravity = vec3(core.getWorldGravity()). Boolean values are returned as a number 0 or 1, and not as true or false.
 
Element events are not listed here, as they cannot be detected by the dump.lua script. See the codex in-game (press F1) or outside the game (C:\ProgramData\Dual Universe\Game\documentation\web_codex.html) for event and function descriptions and other information.
 
Anti-Gravity Generator
r0.21.0
 
Control unit
r0.23.0
Programming board exposes fewer functions compared to cockpit and seat. The control unit has references to linked elements, which are also available as local variables in each event handler. Event handlers defined in the script editor also get placed inside it. Here the control unit is a hovercraft seat that has 2 linked fuel tanks, a radar and a core.

Core
r0.23.0
Static cores have fewer functions compared to dynamic cores.
 
Databank
r0.21.2
 
Elements with a state
r0.21.2
Detection areas, laser detectors and manual buttons expose the same functions. Their state is accessed using getState().
 
Elements with a toggle-able state
 r0.21.2
Force fields, ship doors, landing gears and manual switches expose the same functions. The state is accessed using getState() and can be changed by activate(), deactivate() or toggle().

Emitter
r0.23.0
 
Engine
r0.21.0
Space engines, atmospheric engines, ailerons, air-brakes, retro-engines and adjustors expose the same functions. Usually engines are controlled through unit.setEngineCommand and do not require linking to the control unit.
 
 Fuel container
 r0.23.0
 
Gyro
 r0.21.2
 
Industry
r0.23.0
 
Item container
 r0.23.0
 
Library
r0.21.2
 
Light
r0.23.0
 
PVP radar (atmospheric and space)
r0.22.0

Radar
not available to craft or buy; for atmosphere and space radars see PVP radar instead
 
Receiver
r0.23.0

Screen
r0.21.2
 
System
r0.23.0
 
Telemeter
r0.21.2
 
Warp Drive
r0.23.0
 
Weapon
r0.21.0

This is the output of a script that dumps all global variables. Lua coders may find this somewhat useful.
 
The script was run in r0.21.2 on a hovercraft seat that has 2 fuel tanks and a radar linked. Some functions were called with pcall. The first value indicates whether the call was successful, the second is the actual return value or the error message.
 
 
To see only elements' functions, visit this topic.
 
Dumping script
The script used for dumping is based on something I found on Stack Overflow, with some extensions.
 
In unit start(): https://gist.github.com/d-lua-stuff/180707c172382d06d2c80213a1638f66
In system update():
coroutine.resume(dumping_coroutine) The script will run for a few seconds and then automatically turn off. Output is saved to Dual Universe 's log files in %LOCALAPPDATA%\NQ\DualUniverse\log
 
Dump analyzer
To avoid having to look through the logs manually, a Python script was written. It extracts the output of the globals dumping script from Dual Universe's log files, and creates separate files for dumped globals and for members of each linked element.
 
Usage:
pip install six python dump_analyzer.py C:\Path\To\Log\File.xml Change log
2020-09-01. Posted the first version outside the NDA forums section.

OUTDATED. NOT UPDATED SINCE v0.23.0
 
This is the result of running the globals dumping script in-game on constructs that had various elements attached to them.
 
Some exposed functions were called with pcall. The first value indicates whether the call was successful, the second is the actual function return value. All functions that return a vector return it as a table, not as a vec3 structure. Usually such functions will be called like this: local worldGravity = vec3(core.getWorldGravity()). Boolean values are returned as a number 0 or 1, and not as true or false.
 
Element events are not listed here, as they cannot be detected by the dump.lua script. See the codex in-game (press F1) or outside the game (C:\ProgramData\Dual Universe\Game\documentation\web_codex.html) for event and function descriptions and other information.
 
Anti-Gravity Generator
r0.21.0
 
Control unit
r0.23.0
Programming board exposes fewer functions compared to cockpit and seat. The control unit has references to linked elements, which are also available as local variables in each event handler. Event handlers defined in the script editor also get placed inside it. Here the control unit is a hovercraft seat that has 2 linked fuel tanks, a radar and a core.

Core
r0.23.0
Static cores have fewer functions compared to dynamic cores.
 
Databank
r0.21.2
 
Elements with a state
r0.21.2
Detection areas, laser detectors and manual buttons expose the same functions. Their state is accessed using getState().
 
Elements with a toggle-able state
 r0.21.2
Force fields, ship doors, landing gears and manual switches expose the same functions. The state is accessed using getState() and can be changed by activate(), deactivate() or toggle().

Emitter
r0.23.0
 
Engine
r0.21.0
Space engines, atmospheric engines, ailerons, air-brakes, retro-engines and adjustors expose the same functions. Usually engines are controlled through unit.setEngineCommand and do not require linking to the control unit.
 
 Fuel container
 r0.23.0
 
Gyro
 r0.21.2
 
Industry
r0.23.0
 
Item container
 r0.23.0
 
Library
r0.21.2
 
Light
r0.23.0
 
PVP radar (atmospheric and space)
r0.22.0

Radar
not available to craft or buy; for atmosphere and space radars see PVP radar instead
 
Receiver
r0.23.0

Screen
r0.21.2
 
System
r0.23.0
 
Telemeter
r0.21.2
 
Warp Drive
r0.23.0
 
Weapon
r0.21.0

There is a new element I've never seen before (on a ship with a small space engine but its NOT the small engine): 
Element class: SpaceEngineSmallGroup
getFuelRate : function: 000001AEB273EEA0
getSignalIn : function: 000001AEB273EC00
toggle : function: 000001AFD57776A0
isOutOfFuel : function: 000001AEB273EBD0
getObstructionFactor : function: 000001AEB273F2C0
getDataId : function: 000001AFD576FF00
getMass : function: 000001AFD57716D0
activate : function: 000001AFD5771E20
unit : table: 000001AEF8256710
distance : function: 000001AEB273EDE0
setThrust : function: 000001AFD5777580
getMaxThrust : function: 000001AFD57777F0
getMinThrust : function: 000001AFD57794A0
getIntegrity : function: 000001AFD5770260
show : function: 000001AFD576FC30
hide : function: 000001AFD576FE70
torqueAxis : function: 000001AEB273F200
getThrust : function: 000001AEB273F110
getData : function: 000001AFD5770110
load : function: 000001AEB273F230
getMaxHitPoints : function: 000001AFD57702F0
setSignalIn : function: 000001AEB273F1D0
getFuelConsumption : function: 000001AEB273F1A0
setTags : function: 000001AEB273ED50
hasBrokenFuelTank : function: 000001AEB273F3E0
getElementClass : function: 000001AFD57718B0
getT50 : function: 000001AEB273EE40
export : table: 000001AEF82561D0
getTags : function: 000001AEB273F170
getState : function: 000001AFD5777430
isObstructed : function: 000001AEB273F140
getFuelRateEfficiency : function: 000001AEB273F380
thrustAxis : function: 000001AEB273F320
getHitPoints : function: 000001AFD5770290
getId : function: 000001AFD5771640
getWidgetType : function: 000001AFD5770590
getCurrentFuelRate : function: 000001AEB273ED20
getMaxThrustEfficiency : function: 000001AFD5779D40
getMaxThrustBase : function: 000001AFD57777C0
deactivate : function: 000001AFD5777E50
I'm guessing this is an aggregate of all space engines (my setup had only one). Sadly, it disappears if there is no link to the engine.

About
This is a basic autopilot script that can accelerate your construct towards a planet and later apply brakes to stop. Vertical space engines are used to control drift.
 
Requirements
Space brakes, 1.5+ g. Vertical space engines (pointing down), 0.3+ g. A remote controller or a separate hovercraft seat. Limitations
No manual piloting. Use another script to get to space and to land. No collision avoidance. Make sure there are no planets, moons, asteroids, space stations or pirates between you and the destination. Planet positions are stored in the script. If NQ moves the planets, the script will have to be updated. Set-up
With an auto-configuration schema (recommended)
Download this file to Game\data\lua\autoconf\custom in your Dual Universe installation directory. By default it's C:\ProgramData\Dual Universe\Game\data\lua\autoconf\custom Right-click the control unit (a remote controller or a hovercraft seat) and select "Update custom autoconf list". This needs to be done only once. Right-click the control unit and select "Actions for this element", "Run custom autoconfigure", "Basic Space Autopilot". With a pasteable script configuration
Open this link and copy everything to clipboard. Right-click the control unit (a remote control or a hover seat) and select "Actions for this element", "Paste Lua configuration from clipboard". The game should display a "Lua script loaded" message. If it did not, restart the game and copy the script configuration again. Link the core (required) and fuel tanks (optional) to the control unit. Credits
Many planet positions were provided by @meigrafd from Hyperion.
The script was bundled (amalgamated from multiple .lua files) using amalg.
 
Change log
2020-09-23. Fixed heavy constructs not accelerating past 29997 km/h. A radar widget will be displayed if a PVP radar is linked (not available on remote controllers). Tested in r0.22.2.
2020-09-16. Posted the first version outside the NDA forums section. Tested in r0.21.6.

About
This is a basic autopilot script that can accelerate your construct towards a planet and later apply brakes to stop. Vertical space engines are used to control drift.
 
Requirements
Space brakes, 1.5+ g. Vertical space engines (pointing down), 0.3+ g. A remote controller or a separate hovercraft seat. Limitations
No manual piloting. Use another script to get to space and to land. No collision avoidance. Make sure there are no planets, moons, asteroids, space stations or pirates between you and the destination. Planet positions are stored in the script. If NQ moves the planets, the script will have to be updated. Set-up
With an auto-configuration schema (recommended)
Download this file to Game\data\lua\autoconf\custom in your Dual Universe installation directory. By default it's C:\ProgramData\Dual Universe\Game\data\lua\autoconf\custom Right-click the control unit (a remote controller or a hovercraft seat) and select "Update custom autoconf list". This needs to be done only once. Right-click the control unit and select "Actions for this element", "Run custom autoconfigure", "Basic Space Autopilot". With a pasteable script configuration
Open this link and copy everything to clipboard. Right-click the control unit (a remote control or a hover seat) and select "Actions for this element", "Paste Lua configuration from clipboard". The game should display a "Lua script loaded" message. If it did not, restart the game and copy the script configuration again. Link the core (required) and fuel tanks (optional) to the control unit. Credits
Many planet positions were provided by @meigrafd from Hyperion.
The script was bundled (amalgamated from multiple .lua files) using amalg.
 
Change log
2020-09-23. Fixed heavy constructs not accelerating past 29997 km/h. A radar widget will be displayed if a PVP radar is linked (not available on remote controllers). Tested in r0.22.2.
2020-09-16. Posted the first version outside the NDA forums section. Tested in r0.21.6.

About
This is a basic autopilot script that can accelerate your construct towards a planet and later apply brakes to stop. Vertical space engines are used to control drift.
 
Requirements
Space brakes, 1.5+ g. Vertical space engines (pointing down), 0.3+ g. A remote controller or a separate hovercraft seat. Limitations
No manual piloting. Use another script to get to space and to land. No collision avoidance. Make sure there are no planets, moons, asteroids, space stations or pirates between you and the destination. Planet positions are stored in the script. If NQ moves the planets, the script will have to be updated. Set-up
With an auto-configuration schema (recommended)
Download this file to Game\data\lua\autoconf\custom in your Dual Universe installation directory. By default it's C:\ProgramData\Dual Universe\Game\data\lua\autoconf\custom Right-click the control unit (a remote controller or a hovercraft seat) and select "Update custom autoconf list". This needs to be done only once. Right-click the control unit and select "Actions for this element", "Run custom autoconfigure", "Basic Space Autopilot". With a pasteable script configuration
Open this link and copy everything to clipboard. Right-click the control unit (a remote control or a hover seat) and select "Actions for this element", "Paste Lua configuration from clipboard". The game should display a "Lua script loaded" message. If it did not, restart the game and copy the script configuration again. Link the core (required) and fuel tanks (optional) to the control unit. Credits
Many planet positions were provided by @meigrafd from Hyperion.
The script was bundled (amalgamated from multiple .lua files) using amalg.
 
Change log
2020-09-23. Fixed heavy constructs not accelerating past 29997 km/h. A radar widget will be displayed if a PVP radar is linked (not available on remote controllers). Tested in r0.22.2.
2020-09-16. Posted the first version outside the NDA forums section. Tested in r0.21.6.

This is the output of a script that dumps all global variables. Lua coders may find this somewhat useful.
 
The script was run in r0.21.2 on a hovercraft seat that has 2 fuel tanks and a radar linked. Some functions were called with pcall. The first value indicates whether the call was successful, the second is the actual return value or the error message.
 
 
To see only elements' functions, visit this topic.
 
Dumping script
The script used for dumping is based on something I found on Stack Overflow, with some extensions.
 
In unit start(): https://gist.github.com/d-lua-stuff/180707c172382d06d2c80213a1638f66
In system update():
coroutine.resume(dumping_coroutine) The script will run for a few seconds and then automatically turn off. Output is saved to Dual Universe 's log files in %LOCALAPPDATA%\NQ\DualUniverse\log
 
Dump analyzer
To avoid having to look through the logs manually, a Python script was written. It extracts the output of the globals dumping script from Dual Universe's log files, and creates separate files for dumped globals and for members of each linked element.
 
Usage:
pip install six python dump_analyzer.py C:\Path\To\Log\File.xml Change log
2020-09-01. Posted the first version outside the NDA forums section.

About
This is a short script that prints base max thrust of linked engines. It can serve as an example, and may also be used to detect which engines do not have a technician buff applied to them.
 
Set-up
Place a programming board. Link up to 10 engines to the programming board. In the Lua editor (right-click, "Advanced", "Edit Lua code") create a unit start() event handler with this code: -- detect linked engines local engines = {} for key, value in pairs(unit) do if type(value) == "table" and type(value.export) == "table" then -- `value` is an element and `key` is the slot name if value.getThrust and value.getMaxThrust then -- `value` is an engine engines[#engines + 1] = value end end end -- get engine names local engineNames = {} for _, engine in ipairs(engines) do -- engine name is available in its widget data -- for other elements `core.getElementNameById` would have to be used instead local dataJson = engine.getData() local data = json.decode(dataJson) engineNames[engine] = data.name or "???" end -- sort engines by name table.sort(engines, function (engine1, engine2) return engineNames[engine1] < engineNames[engine2] end) -- print engines and their base max thrust system.print("Linked engines: " .. #engines) for _, engine in ipairs(engines) do local name = engineNames[engine] local maxThrustBase = engine.getMaxThrustBase() system.print(string.format("%s: %.0f N", name, maxThrustBase)) end unit.exit()  
Click "Apply" in the Lua editor, exit build mode and activate the programming board. You should see base max thrust printed in the Lua chat tab.  
Change log
2020-09-13. Posted the first version (tested in r0.21.5).