1.6.8

• Reintroduced automatic generation of library documentation
• Added __parse_file_as_manifest to get manifest data from a file
  • This was added to reduce clutter within other MV2 functions, as well as allowing other files to be parsed this way as well
• Patchup fix for crash for WebTranslate due to the sheer number of API calls that are sent during each operation call to it.
  • A future patch will add better failsafes and will cache data properly to only require large calls to the API every few days or weeks
• The number of crewmembers that can board a derelict has been increased to 24 to account for modded ships
• Added __dynamic_crew_expander to NodeAccess.gd
  • Creates a scene file in the provided folder that can be used as a valid extension to the derelict conversation scene at res://comms/conversation/subtrees/DIALOG_DERELICT_RANDOM.tscn
  • Second max_crew variable used to control the desired number of crew that the generated scene provides. If 24 or less, it fails due to this library already providing support for that many crew members.
  • Returns the file path to the generated scene to allow the mod to do what it likes with it. If the function failed, returns an empty string instead
• Added easter egg. Completely useless, but it's just there.
• Refactored EquipmentDriver to a more dynamic system:
  • Fixes several issues with some equipment (namely consumables, MPUs, and RCS) breaking when being added via this system
  • The legacy system can still be used, however it requires enabling use_legacy_equipment_handler in the config file
  • The legacy system does not fix the issue with prior equipment, however if it sees enough use, I am willing to make the fix if necessary
  • This change requires modders to update their mods to take into account the different method and time which data is loaded
  • Mods now need a folder in the root of their mod folder named HEVLIB_EQUIPMENT_DRIVER_TAGS (for example, res://VelocityPlus/HEVLIB_EQUIPMENT_DRIVER_TAGS). This folder will be looked into for files containing data stored in constants.
    • Data for equipment is stored in a script file named ADD_EQUIPMENT_SLOTS.gd, each equipment item is it's own constant variable. The name of the constant doesn't matter, however the formatting for each constant should be the same as a standard entry with the legacy system
    • Data for slots is stored in a very similar manner, only difference is it being stored in a script named ADD_EQUIPMENT_ITEMS.gd. Same goes for constant names not mattering.
    • Data for equipment tags is stored in a script named EQUIPMENT_TAGS.gd. This time the constant name does matter, and should start as const EQUIPMENT_TAGS = {.... The content of this constant is the usual dictionary format.
    • Data for slot tags is likewise similar, being stored in a script named SLOT_TAGS.gd, and also having a constant of the same name (const SLOT_TAGS = {...). Again, content of this constant is in the usual dictionary format.
• Added multiple functions to Equipment.gd to aide with the new dynamic equipment driver system