theopenspaceprogram / new-ospgl Goto Github PK

View Code? Open in Web Editor NEW

37.0 37.0 5.0 8.87 MB

A space exploration game in OpenGL. Devblog: https://tatjam.github.io/index.html

License: MIT License

C++ 57.70% C 40.00% CMake 0.04% Lua 1.83% GLSL 0.36% F# 0.07%

gamedev openspaceprogram space space-game

new-ospgl's People

Contributors

Stargazers

Watchers

Forkers

ghimli frankfanslc bartoszkedziorek venuskan slight6

new-ospgl's Issues

Can't run application

I'm on Arch Linux, gcc 10

[INF] Starting OSP with settings = "settings.toml", resource path = "./res/", user data path = "./udata/"
[renderer]
	type = "windowed"
	scale = 0.75000000000000000
	height = 768
	width = 1366
	[renderer.quality]
		secondary_shadow_size = 512
		sun_terrain_shadow_size = 1024
		sun_shadow_size = 1024

[INF] Package 'OSP Core 0.0.1' ('core' initialized as 'core')
[INF] Package 'OSP Default Navball 0.0.1' ('default_navball' initialized as 'navball')
[INF] OpenGL Version: 4.6 (Core Profile) Mesa 20.0.7
[INF] GLSL Version: 4.60
[INF] OpenGL Vendor: Intel
[INF] OpenGL Renderer: Mesa Intel(R) UHD Graphics 620 (KBL GT2)
[DBG] Loaded asset 'core:shaders/debug.vs'
[DBG] Loaded asset 'core:shaders/simple_sprite.vs'
[DBG] Loaded asset 'core:shaders/font.vs'
[INF] Loading package core
[DBG] Adding part category from pkg 'core' with path 'core:categories/command.toml'
[DBG] Adding part category from pkg 'core' with path 'core:categories/engines.toml'
[DBG] Adding part category from pkg 'core' with path 'core:categories/all.toml'
[INF] Loading package navball
[ERR] Condition 'Invalid package given' failed
terminate called after throwing an instance of 'std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >'
fish: “./ospgl” terminated by signal SIGABRT (Abort)

Proper definition of "wiring" and "plumbing" connections

Logical Connections (Formerly Wiring)

Wiring is done in the wiring interface of the editor, where you can see in 3D the machines in the vehicle.
Wiring allows creating logical connection between machines
Machines may query a "logical group" about connections in this logical group. The group doesn't need to represent a physical system
Examples:
- Control commands: This is what wiring is used for already in OSPGL
- KSP style fluid simulation (allow it to be implemented by mods for players who want a simpler model)
- Connections to simulated in-game computers so they can fetch data only from certain connected machines.

Physical Connections (Formerly Plumbing)

Done in the plumbing editor, where machines are laid out in a 2D canvas. Machines may be connected using ports.
Allows simulating physical systems, exterior to the machines themselves, that somehow connect the machines together
Machines may have a set of ports, which allow interaction with the simulated physical system. These ports may be connected together.
Internal machines (formerly plumbing machines) may be created which may be placed on any part in the vehicle
The behavior of the simulated system may be implemented in C++ or Lua
Examples:
- Plumbing: Already implemented in C++
- Mechanical linkages: Machines may offer
- Electrical simulation: Machines have electrical ports which may be connected together and a simple circuit solver applied.
To avoid the plumbing editor from getting extremely cluttered, the user may select which physical system are shown. For example, if the user disables the electrical system, all machines which have only electrical ports become "ghosted", and so on.
Finally, certain physical systems may be grouped together in pages. Some sane defaults are keeping mechanical linkages and plumbing together, and a separate page for electrical connections.
This does impose a limitation: Machines must use the same symbol for all of the different physical system. This could make some machines which require a lot of ports in different systems have a very big editor symbol.

Symmetry is not affected by this, as the same concepts apply. If a physical system is mirrored one way, all the others must be in the same way!

Implementation guide

Implement logical groups (should be pretty easy, mostly renaming and some API changes):
- Editor GUI to select which group are you editing
- Auto-grouping (autowiring) must be adjustable per group!
Generalize plumbing to allow general physical connections
Expose the needed functions for physical systems to be implemented in Lua
(Maybe) Port the fluid system to Lua (which will be way more elegant as the C++ implementation is ugly because of static typing)
- Some performance testing is needed before doing this, as the fluid system could be very CPU heavy! If Lua is too slow for this task (unlikely using LuaJIT) then it will remain implemented in C++, at the expense of modding...
Implement mechanical linkages at the same time the plumbing editor is modified to show arbitrary physical groups
Implement the electrical system (low priority)

Once this is done, very complex vehicles may be simulated with OSPGL, which means that designing them will also be pretty complex! This also opens modders to modify these systems if simpler gameplay is desired.

Bug in Cubemap

If specular and irradiance map resolutions are different PBR breaks, this should be easy to fix. The error must be in Cubemap.cpp

Fix tangents

For some reason tangent mapping leads to ugly gaps in the normal map of the mesh.
This may be an issue with Blender exporting the tangents, or maybe an issue with the importing, we could try generating them in the importer code instead of relying on Blender, although the error may be in the shaders.

Remove MSVC project files. Use only cmake (Visual Studio natively supports CMake)

Port the editor to lua

This is not as hard as it seems as a lot of the C++ code will be shortened a lot in lua, and the "thinking" is already done.

Risky use of veh->get_children_of() in symmetry

If symmetry starts behaving very weirdly, for example, by removing pieces that the user has not removed or similar, this function may be the culprit. It doesn't guarantee ordering of the children, while symmetry kind of assumes it does. This is probably fine, but it would be a good idea to investigate!

Bitmap font for everything (optionally)

This requires two big things:

A font which has the unicode support we need and has small characters (at max 12 pixels height or so)
Changing all the code to use bitmap fonts (should be pretty easy)
Adjusting default sizes of UI elements so they make more sense with the new font
Making a "font agnostic" set of functions for creating widgets so they automatically use the bitmap / truetype modes

This will achieve a way smaller and crisp GUI (kind of like Project Zomboid?), which could be useful for players with smaller screen or just anybody who wants to really use all screen real estate.

This should be optional because having really tiny GUI is not liked by everybody.

Performance of overriding ipairs()

We must measure the performance hit of this code here:

new-ospgl/src/lua/LuaCore.cpp

Line 184 in 833093b

 to.script("local function _ipairs(t, var)\nvar = var + 1\nlocal value = t[var]\nif value == nil then return end\nreturn var, value\nend\nfunction ipairs(t) return _ipairs, t, 0 end"); 

If it's not satisfying (it probably is, but LuaJIT can have some surprises), then std::vectors must be accessed using slightly non lua style syntax. Instead of:

for index, value in ipairs(vector)

you would use

for index, value in vector:pairs()

This is still the case for std::unordered_map and similar as these cannot be fixed this way and would require changes to the sol library.

Render oceans as a GPU sphere

Oceans are mostly spherical (or ellipsoidal) so we could just draw a single quad and generate the sphere directly on the GPU. Other water bodies would use the old system

Allow specifying sizes for child_1 in canvas

Right now we only allow size specification in pixels for child_0 because of how the code was structured originally, it should now be possible to specify size for child_1.

CMake improvements

Here, use this CMakeLists.txt file as inspiration

##
# // Copyright information goes here
##
#####################################################################
# Minimum cmake version requirement
#####################################################################
CMAKE_MINIMUM_REQUIRED(VERSION 3.9)

#####################################################################
# Tell CMake this is a C++ project
#####################################################################
PROJECT(OpenSpaceProgram CXX)

#####################################################################
# Generate a compile_commands.json file that can be consumed by other tools.
#####################################################################
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

#####################################################################
# Build system options
#####################################################################
OPTION(OSP_BUILD_SANATIZER      "Build with the address sanatizer" OFF)
OPTION(OSP_BUILD_DOXYGEN        "Build documentation" OFF)
OPTION(OSP_BOOST_STATIC_RUNTIME "Statically link with boost runtime" ON)

#####################################################################
# Preprocessor defines for code that needs to care about these build options.
#####################################################################
IF(OSP_BUILD_SANATIZER)
  ADD_DEFINITIONS(-DOSP_BUILD_SANATIZER)
ENDIF()

IF(OSP_BUILD_DOXYGEN)
  ADD_DEFINITIONS(-DOSP_BUILD_DOXYGEN)
ENDIF()

IF(OSP_BOOST_STATIC_RUNTIME)
  ADD_DEFINITIONS(-DOSP_BOOST_STATIC_RUNTIME)
ENDIF()

IF(CMAKE_BUILD_TYPE MATCHES "Release")
  ADD_DEFINITIONS(-DOSP_BUILD_RELEASE)
ENDIF()

IF(CMAKE_BUILD_TYPE MATCHES "Debug")
  ADD_DEFINITIONS(-DOSP_BUILD_DEBUG)
ENDIF()

IF(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
  ADD_DEFINITIONS(-DOSP_BUILD_COMPILER_CLANG)
ENDIF()

IF(CMAKE_CXX_COMPILER_ID MATCHES "GNU")
  ADD_DEFINITIONS(-DOSP_BUILD_COMPILER_GCC)
ENDIF()

#####################################################################
# This variable can be used by other CMakeLists files to reference the directory structure.
#####################################################################
SET(OSP_ROOT ${CMAKE_CURRENT_SOURCE_DIR} CACHE INTERNAL "")

#####################################################################
# Minimum language standard requirements.
#####################################################################
SET(CMAKE_C_STANDARD 11)
SET(CMAKE_C_EXTENSIONS OFF)
SET(CMAKE_C_STANDARD_REQUIRED ON)

SET(CMAKE_CXX_STANDARD 17)
SET(CMAKE_CXX_EXTENSIONS OFF)
SET(CMAKE_CXX_STANDARD_REQUIRED ON)

#####################################################################
# Static analysis options
#####################################################################
STRING(APPEND CMAKE_C_FLAGS   " -Wall -Wextra -fno-omit-frame-pointer")
STRING(APPEND CMAKE_CXX_FLAGS " -Wall -Wextra -fno-omit-frame-pointer")

#Turn on -Weverything, but then disable various noisy warnings.
STRING(APPEND CLANG_COMPILE_FLAGS " -Weverything -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-padded -Wno-undefined-func-template -Wno-unused-template")
STRING(APPEND CLANG_COMPILE_FLAGS " -Wno-deprecated -Wno-documentation -Wno-documentation-deprecated-sync -Wno-documentation-unknown-command -Wno-abstract-vbase-init")
STRING(APPEND CLANG_COMPILE_FLAGS " -Wno-switch-enum -Wno-covered-switch-default -Wno-missing-prototypes -Wno-sign-conversion -Wno-float-conversion -Wno-shorten-64-to-32")
STRING(APPEND CLANG_COMPILE_FLAGS " -Wno-shadow -Wno-shadow-field-in-constructor -Wno-shadow-uncaptured-local -Wno-inconsistent-missing-destructor-override -Wno-extra-semi-stmt")
STRING(APPEND CLANG_COMPILE_FLAGS " -Wno-global-constructors -Wno-exit-time-destructors  -Wno-weak-vtables -Wno-undef -Wno-disabled-macro-expansion -Wno-used-but-marked-unused")
STRING(APPEND CLANG_COMPILE_FLAGS " -Wno-gnu-string-literal-operator-template")

STRING(APPEND GCC_COMPILE_FLAGS " -Wno-psabi")

IF(OSP_BUILD_SANATIZER)
  STRING(APPEND GCC_COMPILE_FLAGS " -fstack-protector-all -fsanitize-address-use-after-scope")
  STRING(APPEND GCC_COMPILE_FLAGS " -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=pointer-compare -fsanitize=pointer-subtract -fsanitize=leak")
  STRING(APPEND GCC_COMPILE_FLAGS " -fsanitize=undefined -fsanitize=shift-base -fsanitize=shift-exponent -fsanitize=integer-divide-by-zero -fsanitize=unreachable")
  STRING(APPEND GCC_COMPILE_FLAGS " -fsanitize=vla-bound -fsanitize=null -fsanitize=return -fsanitize=signed-integer-overflow -fsanitize=bounds -fsanitize=bounds-strict")
  STRING(APPEND GCC_COMPILE_FLAGS " -fsanitize=alignment -fsanitize=float-divide-by-zero -fsanitize=float-cast-overflow -fsanitize=nonnull-attribute")
  STRING(APPEND GCC_COMPILE_FLAGS " -fsanitize=returns-nonnull-attribute -fsanitize=bool -fsanitize=enum -fsanitize=vptr -fsanitize=pointer-overflow -fsanitize=builtin")

  STRING(APPEND CLANG_COMPILE_FLAGS " -fstack-protector-all -fsanitize-address-use-after-scope")
  STRING(APPEND CLANG_COMPILE_FLAGS " -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=leak")
  STRING(APPEND CLANG_COMPILE_FLAGS " -fsanitize=undefined -fsanitize=shift-base -fsanitize=shift-exponent -fsanitize=integer-divide-by-zero -fsanitize=unreachable")
  STRING(APPEND CLANG_COMPILE_FLAGS " -fsanitize=vla-bound -fsanitize=null -fsanitize=return -fsanitize=signed-integer-overflow")
  STRING(APPEND CLANG_COMPILE_FLAGS " -fsanitize=alignment -fsanitize=float-divide-by-zero -fsanitize=float-cast-overflow -fsanitize=nonnull-attribute")
  STRING(APPEND CLANG_COMPILE_FLAGS " -fsanitize=returns-nonnull-attribute -fsanitize=bool -fsanitize=enum -fsanitize=vptr -fsanitize=pointer-overflow -fsanitize=builtin")

  # Only activate object-size sanatizer on release builds. It has no effect on optimization level 0.
  IF(CMAKE_BUILD_TYPE MATCHES "Release")
    STRING(APPEND GCC_COMPILE_FLAGS   " -fsanitize=object-size")
    STRING(APPEND CLANG_COMPILE_FLAGS " -fsanitize=object-size")
  ENDIF()
ENDIF()

IF(CMAKE_C_COMPILER_ID MATCHES "Clang")
  STRING(APPEND CMAKE_C_FLAGS " ${CLANG_COMPILE_FLAGS}")
ENDIF()
IF(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
  STRING(APPEND CMAKE_CXX_FLAGS " ${CLANG_COMPILE_FLAGS}")
ENDIF()

IF(CMAKE_C_COMPILER_ID MATCHES "GNU")
  STRING(APPEND CMAKE_C_FLAGS " ${GCC_COMPILE_FLAGS}")
ENDIF()
IF(CMAKE_CXX_COMPILER_ID MATCHES "GNU")
  STRING(APPEND CMAKE_CXX_FLAGS " ${GCC_COMPILE_FLAGS}")
ENDIF()

STRING(APPEND CMAKE_C_FLAGS_DEBUG   " -ggdb3")
STRING(APPEND CMAKE_CXX_FLAGS_DEBUG " -ggdb3")

STRING(APPEND CMAKE_C_FLAGS_DEBUG   " -gz -O0")
STRING(APPEND CMAKE_CXX_FLAGS_DEBUG " -gz -O0")

#####################################################################
# Link time optimization, results in faster code, and smaller binaries.
#####################################################################
IF(CMAKE_BUILD_TYPE MATCHES "Release")
  CMAKE_POLICY(SET CMP0069 NEW)
  INCLUDE(CheckIPOSupported)
  CHECK_IPO_SUPPORTED(RESULT lto_supported OUTPUT error)

  IF( lto_supported )
    MESSAGE(STATUS "IPO / LTO enabled")
    SET(CMAKE_INTERPROCEDURAL_OPTIMIZATION TRUE)
    ADD_DEFINITIONS(-DOSP_BUILD_LTO)
  ELSE()
    MESSAGE(STATUS "IPO / LTO not supported: <${error}>")
  ENDIF()
ENDIF()

#####################################################################
# Doxygen documentation for developer reference.
#####################################################################
IF(OSP_BUILD_DOXYGEN)
  # check if Doxygen is installed
  FIND_PACKAGE(Doxygen)
  IF(DOXYGEN_FOUND)
    # set input and output files
    SET(DOXYGEN_IN ${CMAKE_CURRENT_SOURCE_DIR}/doc/Doxyfile.in)
    SET(DOXYGEN_OUT ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile)

    # request to configure the file
    CONFIGURE_FILE(${DOXYGEN_IN} ${DOXYGEN_OUT} @ONLY)
    MESSAGE("Doxygen build started")

    # note the option ALL which allows to build the docs together with the application
    ADD_CUSTOM_TARGET(doc_doxygen ALL
                      COMMAND ${DOXYGEN_EXECUTABLE} ${DOXYGEN_OUT}
                      WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
                      COMMENT "Generating API documentation with Doxygen"
                      VERBATIM )
  ELSE(DOXYGEN_FOUND)
    MESSAGE("Doxygen need to be installed to generate the doxygen documentation")
  ENDIF(DOXYGEN_FOUND)
ENDIF()

#####################################################################
# Copy the Include What You Use mapping file (if it exists) that we have in the repository to the build directory.
#####################################################################
FILE (COPY "iwyu.imp" DESTINATION "${CMAKE_BINARY_DIR}")

#####################################################################
# Dependencies known to apply to more than one subproject.
#####################################################################
MESSAGE(STATUS "Configuring known common dependencies")

SET(Boost_USE_STATIC_LIBS   ON) # only find static libs
SET(Boost_USE_MULTITHREADED ON)

IF(OSP_BOOST_STATIC_RUNTIME)
  SET(Boost_USE_STATIC_RUNTIME ON)
ELSE()
  SET(Boost_USE_STATIC_RUNTIME OFF)
ENDIF()

FIND_PACKAGE(Boost 1.66.0 REQUIRED COMPONENTS system log program_options)

##
# If any networking stuff gets included
##
SET(OPENSSL_USE_STATIC_LIBS FALSE)
FIND_PACKAGE(OpenSSL REQUIRED)

#####################################################################
# Subdirectories that contain code to compile.
#####################################################################
ADD_SUBDIRECTORY(3rdparty)
ADD_SUBDIRECTORY(lib)
ADD_SUBDIRECTORY(exe)

Port all entities to lua and convert entity to lua only

Self explanatory, to be done soon as current entities are vehicle and building, which are really simple. Further entities would be written in lua from the start.

inefficent string concatination

const std::string fix_key = "_IKEY";
auto n_parse = SerializeUtil::load_string(fix_key + "=" + value);

change fix_key to std::string_view, or "static constexpr auto[]"
Concatinating strings like this is expensive. Take a look here: https://github.com/splinter-build/splinter/blob/15-default-values/src/string_concat.h

Mouse picking attachments

Leave the page up / page down keys to cycle attachments, but if a user hovers a part (or near it) draw attachments, and have the piece be picked up by clicked attachment / nearest attachment to click.

Universe.h issue

I get the following error during compilation:
/home/simon/new-ospgl/src/universe/Universe.h:83:13: error: parameter packs not expanded with ‘...’: 83 | T* n_ent = new T(args); | ^~~~~~~~~~~

Debian Building Issues

I can't get past this issue on Debian 10 x64 MATE:
Fetch.cpp:(.text+0x1313): undefined reference to std::filesystem::remove_all(std::filesystem::__cxx11::path const&)'`
Here is the full error:

[  0%] Building CXX object CMakeFiles/ospm.dir/ospm_src/Fetch.cpp.o
[  0%] Building CXX object CMakeFiles/ospm.dir/ospm_src/Main.cpp.o
[  0%] Building C object CMakeFiles/ospm.dir/ospm_src/dep/miniz.c.o
/home/daniel/Pulled/new-ospgl/ospm_src/dep/miniz.c:3079:9: note: #pragma message: Using fopen, ftello, fseeko, stat() etc. path for file I/O - this path may not support large files.
 #pragma message("Using fopen, ftello, fseeko, stat() etc. path for file I/O - this path may not support large files.")
         ^~~~~~~
[  0%] Linking CXX executable ospm
/usr/bin/ld: CMakeFiles/ospm.dir/ospm_src/Fetch.cpp.o: in function `Fetch::fetch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Fetch::OverwriteMode, bool)':
Fetch.cpp:(.text+0x1313): undefined reference to `std::filesystem::remove_all(std::filesystem::__cxx11::path const&)'
/usr/bin/ld: Fetch.cpp:(.text+0x1643): undefined reference to `std::filesystem::create_directories(std::filesystem::__cxx11::path const&)'
/usr/bin/ld: CMakeFiles/ospm.dir/ospm_src/Fetch.cpp.o: in function `std::filesystem::__cxx11::path::path(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, std::filesystem::__cxx11::path::format)':
Fetch.cpp:(.text._ZNSt10filesystem7__cxx114pathC2EONSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS1_6formatE[_ZNSt10filesystem7__cxx114pathC5EONSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS1_6formatE]+0x4f): undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: CMakeFiles/ospm.dir/ospm_src/Fetch.cpp.o: in function `std::filesystem::exists(std::filesystem::__cxx11::path const&)':
Fetch.cpp:(.text._ZNSt10filesystem6existsERKNS_7__cxx114pathE[_ZNSt10filesystem6existsERKNS_7__cxx114pathE]+0x14): undefined reference to `std::filesystem::status(std::filesystem::__cxx11::path const&)'
/usr/bin/ld: CMakeFiles/ospm.dir/ospm_src/Fetch.cpp.o: in function `std::filesystem::__cxx11::path::path<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::filesystem::__cxx11::path>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::filesystem::__cxx11::path::format)':
Fetch.cpp:(.text._ZNSt10filesystem7__cxx114pathC2INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES1_EERKT_NS1_6formatE[_ZNSt10filesystem7__cxx114pathC5INSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES1_EERKT_NS1_6formatE]+0x64): undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/ospm.dir/build.make:118: ospm] Error 1
make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/ospm.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

Also, I pulled like git clone --recurse-submodules https://github.com/TheOpenSpaceProgram/new-ospgl, and followed the exact instructions in the readme.

In-game lua computer

This needs a way to serialize a running lua state, including local variables and similar. This may not be possible with LuaJIT. In that case, we are left with three alternatives:

Have in-game computers require serialization code, which doesn't make much sense and is bad for players
Implement a lua version that's compatible with this: https://github.com/fnuecke/eris This would mean that computers would truly be isolated from the lua world and would interact with machines and such through APIs. Seems like a good option but may be "bloaty"
Don't have in-game lua computers. This means that any kind of computer would have to be an emulated architecture / interpreted language. Easiest option :P

Mods could later on implement, for example, emulators for other architectures, as this can easily be done in lua (with reasonable performance thanks to LuaJIT) so that's outside the scope of the engine.

Add dockerfile for building the app

I'm on linux, using linuxbrew I installed gcc@10 per the README, I am still unable to build the application

# same CC was used for prior cmake . (ran twice as documented)
❯ CC=/home/linuxbrew/.linuxbrew/bin/gcc-10 cmake --build .
[  0%] Built target fmt
[  5%] Built target glfw
[  6%] Built target minilua
[  7%] Built target buildvm
[ 21%] Built target liblua-static
[ 23%] Built target BulletSoftBody
[ 42%] Built target BulletCollision
[ 50%] Built target BulletDynamics
[ 53%] Built target LinearMath
Consolidate compiler generated dependencies of target OSPGL
[ 54%] Building CXX object CMakeFiles/OSPGL.dir/src/lua/LuaCore.cpp.o
In file included from /home/bbaker/new-ospgl/src/lua/LuaLib.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.cpp:1:
/home/bbaker/new-ospgl/dep/sol/sol.hpp: In function ‘void sol::detail::align_one(std::size_t, std::size_t, void*&)’:
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9724:51: error: ‘numeric_limits’ is not a member of ‘std’
 9724 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                   ^~~~~~~~~~~~~~
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9724:77: error: expected primary-expression before ‘>’ token
 9724 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                                             ^
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9724:80: error: ‘::max’ has not been declared; did you mean ‘std::max’?
 9724 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                                                ^~~
      |                                                                                std::max
In file included from /usr/include/c++/11/functional:65,
                 from /home/bbaker/new-ospgl/dep/sol/sol.hpp:1559,
                 from /home/bbaker/new-ospgl/src/lua/LuaLib.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.cpp:1:
/usr/include/c++/11/bits/stl_algo.h:3467:5: note: ‘std::max’ declared here
 3467 |     max(initializer_list<_Tp> __l, _Compare __comp)
      |     ^~~
In file included from /home/bbaker/new-ospgl/src/lua/LuaLib.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.cpp:1:
/home/bbaker/new-ospgl/dep/sol/sol.hpp: In function ‘void* sol::detail::align_usertype_pointer(void*)’:
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9749:51: error: ‘numeric_limits’ is not a member of ‘std’
 9749 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                   ^~~~~~~~~~~~~~
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9749:77: error: expected primary-expression before ‘>’ token
 9749 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                                             ^
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9749:80: error: ‘::max’ has not been declared; did you mean ‘std::max’?
 9749 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                                                ^~~
      |                                                                                std::max
In file included from /usr/include/c++/11/functional:65,
                 from /home/bbaker/new-ospgl/dep/sol/sol.hpp:1559,
                 from /home/bbaker/new-ospgl/src/lua/LuaLib.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.cpp:1:
/usr/include/c++/11/bits/stl_algo.h:3467:5: note: ‘std::max’ declared here
 3467 |     max(initializer_list<_Tp> __l, _Compare __comp)
      |     ^~~
In file included from /home/bbaker/new-ospgl/src/lua/LuaLib.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.cpp:1:
/home/bbaker/new-ospgl/dep/sol/sol.hpp: In function ‘void* sol::detail::align_usertype_unique_destructor(void*)’:
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9771:51: error: ‘numeric_limits’ is not a member of ‘std’
 9771 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                   ^~~~~~~~~~~~~~
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9771:77: error: expected primary-expression before ‘>’ token
 9771 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                                             ^
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9771:80: error: ‘::max’ has not been declared; did you mean ‘std::max’?
 9771 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                                                ^~~
      |                                                                                std::max
In file included from /usr/include/c++/11/functional:65,
                 from /home/bbaker/new-ospgl/dep/sol/sol.hpp:1559,
                 from /home/bbaker/new-ospgl/src/lua/LuaLib.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.cpp:1:
/usr/include/c++/11/bits/stl_algo.h:3467:5: note: ‘std::max’ declared here
 3467 |     max(initializer_list<_Tp> __l, _Compare __comp)
      |     ^~~
In file included from /home/bbaker/new-ospgl/src/lua/LuaLib.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.cpp:1:
/home/bbaker/new-ospgl/dep/sol/sol.hpp: In function ‘void* sol::detail::align_usertype_unique_tag(void*)’:
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9793:51: error: ‘numeric_limits’ is not a member of ‘std’
 9793 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                   ^~~~~~~~~~~~~~
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9793:77: error: expected primary-expression before ‘>’ token
 9793 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                                             ^
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9793:80: error: ‘::max’ has not been declared; did you mean ‘std::max’?
 9793 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                                                ^~~
      |                                                                                std::max
In file included from /usr/include/c++/11/functional:65,
                 from /home/bbaker/new-ospgl/dep/sol/sol.hpp:1559,
                 from /home/bbaker/new-ospgl/src/lua/LuaLib.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.cpp:1:
/usr/include/c++/11/bits/stl_algo.h:3467:5: note: ‘std::max’ declared here
 3467 |     max(initializer_list<_Tp> __l, _Compare __comp)
      |     ^~~
In file included from /home/bbaker/new-ospgl/src/lua/LuaLib.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.cpp:1:
/home/bbaker/new-ospgl/dep/sol/sol.hpp: In function ‘void* sol::detail::align_usertype_unique(void*)’:
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9816:51: error: ‘numeric_limits’ is not a member of ‘std’
 9816 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                   ^~~~~~~~~~~~~~
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9816:77: error: expected primary-expression before ‘>’ token
 9816 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                                             ^
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9816:80: error: ‘::max’ has not been declared; did you mean ‘std::max’?
 9816 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                                                ^~~
      |                                                                                std::max
In file included from /usr/include/c++/11/functional:65,
                 from /home/bbaker/new-ospgl/dep/sol/sol.hpp:1559,
                 from /home/bbaker/new-ospgl/src/lua/LuaLib.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.cpp:1:
/usr/include/c++/11/bits/stl_algo.h:3467:5: note: ‘std::max’ declared here
 3467 |     max(initializer_list<_Tp> __l, _Compare __comp)
      |     ^~~
In file included from /home/bbaker/new-ospgl/src/lua/LuaLib.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.cpp:1:
/home/bbaker/new-ospgl/dep/sol/sol.hpp: In function ‘void* sol::detail::align_user(void*)’:
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9833:51: error: ‘numeric_limits’ is not a member of ‘std’
 9833 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                   ^~~~~~~~~~~~~~
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9833:77: error: expected primary-expression before ‘>’ token
 9833 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                                             ^
/home/bbaker/new-ospgl/dep/sol/sol.hpp:9833:80: error: ‘::max’ has not been declared; did you mean ‘std::max’?
 9833 |                         std::size_t space = (std::numeric_limits<std::size_t>::max)();
      |                                                                                ^~~
      |                                                                                std::max
In file included from /usr/include/c++/11/functional:65,
                 from /home/bbaker/new-ospgl/dep/sol/sol.hpp:1559,
                 from /home/bbaker/new-ospgl/src/lua/LuaLib.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.h:2,
                 from /home/bbaker/new-ospgl/src/lua/LuaCore.cpp:1:
/usr/include/c++/11/bits/stl_algo.h:3467:5: note: ‘std::max’ declared here
 3467 |     max(initializer_list<_Tp> __l, _Compare __comp)
      |     ^~~
gmake[2]: *** [CMakeFiles/OSPGL.dir/build.make:930: CMakeFiles/OSPGL.dir/src/lua/LuaCore.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:309: CMakeFiles/OSPGL.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2

OSPM download from git repo

A system where ospm can download mods directly from a github repo (or other git hosts) would be really useful, similar to how some vim plugin managers work simply by specifying the path to the github repo of the plugin to install.

Multiple stars in atmospheres

Right now the rendering code for atmospheres only allows a single star.

Expose to lua FastNoiseC's cellular noise features

This requires thinking how to handle the lookup passing as it's a pointer.

Part groups

Part groups are created by the user, and are basically a way to categorize parts for the auto-wiring, and for overall organization of the vehicle.

Groups can be hidden in the editor (plumbing and attachment).

They may be selected to be applied to parts before they are added, by selecting the group from a drop down in the part list
They may be assigned to existing parts by right-click menu

A part group extends to all machines contained by the part, including plumbing machines. It could be interesting to actually have machine groups, but this may be extremely confusing for users, as a single part could end up in many machine groups.

Missing stdc++fs library include

new-ospgl/CMakeLists.txt

Line 20 in d417326

set(CMAKE_LD_FLAGS "${CMAKE_LD_FLAGS} -llua -ldl")

Add it with TARGET_LINK_LIBRARIES(targetnamehere stdc++fs)

Named threads

If threads are used for more tasks than planet generation, it would be appropriate to name them to make debugging easier.

GUI Scaling

Allow a setting on settings.toml that activates a high scale GUI for users with very big monitors.
This behavior should be implemented in skins, and also accessible from lua to allow modders to specify sane default sizes.

Installing ospgl via 'make install'

I was wondering if it is possible to install ospgl via the command 'make install', but when I do, it only installs assimp and lua related stuff. And I have done some research on how to implement an install target, but, I don't know how to include the resources that OSPGL references (ex. settings.toml). Any ideas?

Compile issue

/home/simon/new-ospgl/src/planet_mesher/mesher/PlanetTile.cpp:578:1: internal compiler error: Segmentation fault
  578 | }
      | ^

Allow machines to implement a panel in the plumbing GUI for adjusting certain settings

For example, junctions could have a checkbox to be 3-port or 4-port, instead of having two separate machines for each type. This is more ergonomic for the user

Think and develop the patching system

FILE REPLACEMENTS: Useful for models, textures, shaders, etc...
Mods may specify certain files to be "replaced" (virtually) by other. This includes .lua files and everything else. An example of how it could look like. This code would be executed during loading of the mod:

assets.replace("core:shaders/atmosphere.vs", "ourmod:shaders/atmosphere.vs")
assets.replace("core:shaders/atmosphere.fs", "outmod:shaders/atmosphere.fs")

What happens if two mods replace the same file? We may allow the mods or user to specify a load order for individual files which have conflicts, or for the mods themselves to specify a default ordering for certain files. (This allows the concept of a mod which makes two other mods compatible by adjusting the load orders!)

TOML PATCHES: Useful for config tunings

This is easy to implement and would allow patches to be applied to toml files, thus allowing easy alteration of configuration files.
We need to think of a way to establish order of execution of these "patch scripts", maybe something like:

-- (bigger_nozzles:bigger_nozzles.lua)
-- the second string is lua code, executed with "root" as the loaded toml file
assets.patch("test_parts:parts/engine/part_engine.toml", "root.machine[0].exit_radius = 4.0", {before="x2_nozzles"})

-- (realistic_bigger_nozzles:realistic_bigger_nozzles.lua)
assets.patch("test_parts:parts/engine/part_engine.toml", 
    "root.machine[0].exit_radius = root.machine[0].exit_radius * 0.65", 
    {after = ["bigger_nozzles"], before = ["x2_nozzles"]})

This would result in a nozzle size of 4.0 (bigger_nozzles, first) * 0.65 (realistic_bigger_nozzles) * 2.0 (x2_nozzles, last) if all mods were loaded. Impossible conditions could be detected, and dealt with accordingly. (Error message and maybe not executing the patch)
In this example, if bigger_nozzles was not present, realistic_bigger_nozzles would not be applied, as it explicitly states that it must execute AFTER bigger_nozzles.

This example also showcases how modders may make their mod compatible with another, without needing the other mod to change its code: "x2_nozzles" may blindly patch everything in this case.

LUA PATCHES: These should rarely be needed if mods are properly designed with configuration in mind

This can be handled by manually hooking / changing functions from lua (only for public functions) or completely replacing files with replace (if you need to change something local). Furthermore, we could implement a proper lua patching system (ie, it works in C++) which would affect a script every time it's loaded. Once more, we can only access public functions with this method:

-- (mod_1:machine.lua)
public_variable = 54
function do_something_public() ... end

-- (mod_2:patch.lua)
assets.hook_lua("mod_1:machine.lua", "do_something_public", our_function, {after:"mod_1"})
assets.replace_lua("mod_1:machine.lua", "do_something_public", other_function)
-- For a variable we want to control externally, we can use the power of metatables:
assets.replace_lua("mod_1:machine.lua", "public_variable", table_with_metamethods)

This exploits the fact that everything runs in the same lua context so it would NOT work for patching planet surface generation files!

Here, replacements conflicts would be handled in the same way as "replace" conflicts, and hooks use a similar conflict resoltion syntax to toml patches.

Add github actions based continuous integration

Reference other projects on how to do this.

For example, Ninja: https://github.com/ninja-build/ninja/tree/master/.github/workflows

Blurry font rendering

For some reason NanoVG text is looking a bit blurry. This probably has to do with the choice of font and hinting mode, but may not be straightforward to fix.

Godot engine?

Should this project be in the godot engine instead? Just thought of this.

Make machines have an editor location

This will improve editor usability as machines will have a logical position within the piece. We may leave the standard centered "polygon" mode for machines which have no position.

Implementation:
Add a new entry to the Machine class which indicates a marker assigned to said machine. This may not be present. The editor then must properly position the piece.
Visibility could be implemented piece-wise or machine-wise, this requires some testing to find the most comfortable solution.

OpenGL 3.3 Compatibility

This feature should be implemented using an extra entry on the game config which allows toggling on or off OpenGL 3.3 compatibility mode. As of now the only code using OpenGL 4 is the planet renderer.

Improve planet renderer drawing order

This file should be changed so that the drawing order makes more sense, ie, rendering first tiles closer to the player. This way there should be less overdraw. We can also improve it by rendering the ocean first if the player is over it to avoid overdrawing all the tiles underneath the player.

Symmetry

Some thinking into symmetry, which will be implemented in the coming commits:

Types of symmetry

Radial around piece: Pieces attached to the surface of a piece will get duplicated around the central axis of said piece, as long as the user has chosen this symmetry mode.
Radial around axis: Once this symmetry mode is chosen, the user must input an axis (think of how this would work in the GUI), which is used as the central axis for symmetry
Planar around piece: Same as before, but with planar symmetry around a given plane selected by the user from a list of axes specified by the piece. Only usable on certain pieces.
Planar around axis: Same as before, but the user specifies the axis around the piece (think how to implement the GUI)
Attachment list: This is not a true symmetry, but instead the user selects a list of attachment points and pieces are duplicated across them
Cluster: The user chooses a plane, radius and number of copies, and a "engine cluster" is built from the given piece.

Implementation

Each symmetry mode requires some custom GUI, both as widgets on the editor panel, and as 3D gizmos on the editor.
Symmetry is not directly stored in the vehicle, but in VehicleMeta.
Finally, wiring and plumbing will properly be duplicated if the user chooses so.

GUI

Symmetry will work by first choosing a symmetry mode, and then clicking an unattached root piece, which will make the symmetry apply to said piece and all children. Unattached root pieces will be highlighted during this editor mode.

Once a piece is affected by symmetry, any modification to it or its children will be mirrored, but if the piece itself is detached the symmetry will break, and all cloned pieces will disappear. Finally, the user may delete a symmetry group, but keep the symmetric pieces, via a button on the GUI.

Symmetry will be handled in the attach editor mode.

Localize any user-facing non-localized strings

This doesn't include terminal debug messages, only strings shown to the user via GUI.

The process is simple:

Find a bare string in the source code that is used in the GUI
Write an entry for it in core:locale.lua
Load the localized string using the GameDatabase functioons

Make middle click auto-center camera in all editor modes

This is a more intuitive usage. The plumbing editor should focus both the plumbing machine and the 3D view when middle clicking.

Fluid Simulation

We should simulate the fluids inside of the tanks and its motions through the vehicle on a more or less accurate way.
The system should avoid being "rocket-centric" as airplanes and other vehicles will also benefit from fluid simulation.

PhysicalMaterials define the physical properties of any material thing, such as what parts or planets are made of and the fuel inside tanks.

FluidTanks should offer a simple liquid-vapor equilibrium simulation, and should also implement some kind of "sloshing" dynamic and simulate ullage distribution.

Pipes are connections between fluid ports, they have physical significance and are connected between points of the vehicle so that they have a length and a radius. We can then use the Hagen-Poiseuille equation to approximate volumetric flow and then mass flow, assuming fully laminar flow, but simulating viscosity (*).

Temperature could be simulated only in tanks, or could also be included in all pipes. We should be able to simulate systems such as heat exchangers.

Conservation of Energy: We should try to conserve energy as best as we can while fluids are moving. KSP has a bunch of issues with this where you can use the fluid pumping mechanic to gain velocity.

(*) As a mixture of fluids may be flowing through the pipe, we should think what to do on this case. Simulating each fluid independently doesn't make much sense. For example, on a H₂ feeding pipe to a combustion chamber, H₂O backflow would be massive as the partial pressure of H₂O in the tank is 0. On reality, the incoming fluid prevents any backflow: The fluid flow should more or less be equal to that of the most viscous fluid, assuming that there is enough of it as to "block" the pipe.

Don't set link flags globally, set it per target with TARGET_LINK_LIBRARIES function

new-ospgl/CMakeLists.txt

Line 20 in d417326

set(CMAKE_LD_FLAGS "${CMAKE_LD_FLAGS} -llua -ldl")

Wiring panel

Here's a to-do list on how to build the wiring panel before release. This should allow very complex wire setups to be built relatively effortlessly.

Auto wiring

Wiring everything manually can be really boring, so we must allow an automatic wiring function. This can be implemented using a series of toggle-able auto-wiring modes, implemented as lua scripts. By default, we offer a simple auto-wiring mode:

Each added machine is checked against a condition, for example, whether it belongs to a certain group or contains a certain machine interface. If it does, it's wired with all of the following which are present:

A list of machines selected manually by the user
All machines which satisfy a certain condition, (same as the initial check)
Furthermore, machines may only build wires within their own group (without the need to manually specify which group in conditions)

Wires can be created bidirectionally by the wiring system, or in a certain direction (ie from added machine to target, or from target to the added machine).

To implement more advanced wiring functionality, the user can "stack" multiple scripts, all of which are run and the total wires added together. Furthermore, "auto wiring presets", which consist of a series of scripts and their configurations can be saved and loaded. Some defaults could be provided.
Finally, complex auto-wiring stuff could be implemented as a lua script with more complex logic.

Idea for a default wiring setup

Everything works within groups, so there should be only one capsule and staging controller per group. Maybe it's interesting to allow auto-wires to give warnings to the user?

Wire capsule machines directly to staging managing machines, and any "joystick" controllable machine (fins, engine gimbals, etc...)
Wire the staging manager to all machines with "activable" interface that has the "staging" tag (TODO: Implement interface tags too! See the related issue)
Other stuff is directly wired to the capsule so it can be controlled directly.

The wiring preset used should be controllable using a keyboard shortcut, and should be visible at all times in the attach and plumbing modes. (Plumbing is needed because machines can be created there too!)

Batch wiring

This allow working with many wires all at once, when auto-wiring is not practical / was forgotten to be enabled:

Wire selected machine to all other machines which satisfy a condition
Wire all machines which satisfy a condition with other machines that satisfy another set of conditions
Remove all wires which start in a given machine
Remove all wires which end in a given machine
Remove all wires which satisfy certain conditions
Remove all wires

Symmetry wiring

(Naming is not final!)
Eventually, symmetry will be implemented in the editor. There needs to be a way to control how are symmetric parts wired.

When a machine belonging to a symmetry group is wired to a part that doesn't belong to a symmetry group, all parts within the symmetry group are wired to the non-symmetric part. This may optionally be disabled from the wiring panel, and is bidirectional, the same happens if a non symmetric machine is wired to a symmetric machine.
When a part belonging to a symmetry group is wired to a part within the same symmetry group, there are two possible modes:
- Cyclic wiring: Only possible if using radial symmetry, the machines are wired in the same / reverse order of geometric placement
- All-to-all wiring: The default, all symmetric origin machines are wired to all symmetric target machines, over all possible pair permutations.
When a machine belonging to a symmetry group is wired to a machine within a different symmetry group:
- Exhaustive wiring: All symmetric start machines are wired to all symmetric end machines, over all possible pair combinations
- Pair wiring: All symmetric start machines are wired to all symmetric end machines, one-to-one, following geometric placement
- All origin wiring: All symmetric start machines are wired to the selected end machine (ignoring symmetry in the end group)
- All end wiring: The start machine (ignoring symmetry in start group) is wired to all symmetric end machines

Smarter GUI preparing

The current GUI prepare system is a mess, as made evident by my attempt to implement drop-down boxes. The solution to this problem is to do a total of 5 passes, with new functions instead of clumping everything together in prepare.

pre_prepare which allows overlay canvases to be added to the GUIScreen system.
widget position pass: position is called on all widgets, bottom-to-top, so the positions are assigned
prepare pass: prepare is called on all widgets, top-to-bottom with execute_user_actions = false so the UI can block 3D game elements
game pass: 3D game elements handle their inputs and may block using ext_block
input pass: prepare is called on all widgets, top-to-bottom, with execute_user_actions = true so actual GUI actions are executed only if ext_block = false

Furthermore, the GUIScreen system could keep track of all canvases, so that you don't need to manually call anything else than:

gui_screen->prepare_pass(); // this calls pre_prepare, position and prepare
// 3d input stuff here which may be blocked by GUI and may at the same time block it
gui_screen->input_pass(); // this calls prepare again, but with execute user actions

This system should be straightforward to implement and should work for pretty much all GUI situations.

Machine interface tags

There are some cases where a machine interface needs to carry a bit more information. For example, activable machines may be meant to be staged (such as the engine ignition), or activated at certain moments of the mission (for example, landing gears). In some cases, it may not be clear which one is appropriate (for example, a fluid pump).

This can be fixed by having machine interface specify a series of tags, which can give a default value but can also be modified by the user.

The purpose of these tags is to simplify greatly the auto-wiring mechanics. See #38

Make lua definition files for OSPGL API

This will allow lua language servers (such as sumneko_lua) to understand the API of the game and offer autocompletion.
This should be done once the API is a bit more established to avoid a lot of changes later on, but has to be done early so writing lua code is comfortable.

The definition files are basically a list of functions, objects and their documentation in lua format. They may be stored in another repo if needed, but it could be convenient to have them here too.

Use uniform blocks in most shaders

Instead of setting all the transform matrices (which are quite a few in our "double" world) every frame, we can create a uniform block and set that instead.

This should offer a performance improvement (albeit possibly minor) as instead of (5 * object) uniform sets, we would have a single call at the start of the frame. Implementation details here: https://learnopengl.com/Advanced-OpenGL/Advanced-GLSL

Fix gamestate loading spaghetti

There's a bit of a circular loading dependency when loading a gamestate, where entities require osp->game_state is already set during loading. Fix this by rearranging when the entities create the lua env (assign osp->universe, etc...) so that the load order makes more sense