Hi, The attached port is minimally modified version of the hlsteam middleware for hashlink. This expands the games that can run by allowing access to API in goldberg_emulator, like achievements, cloud saves, etc (which are all emulated locally unlike the real Steam client does).
For a little context, until recently the approach to handle the dependencies of some of the commercial FNA or hashlink games on Steam API has been to use a collection of the stubbed middleware libraries in games/steamworks-nosteam. Those serve usually as a middle layer between the game and libsteam_api.so (on Linux). The stubs basically cut all calls to libsteam_api.so short. This approach has its shortcomings, as not all cases can be handled appropriately. In addition, this means installing and maintaining multiple different library files - at the moment there are 5 in steamworks-nosteam. With goldberg_emulator, the goal is to simplify the situation, that is let libsteam_api.so from goldberg_emulator handle most (all?) API emulation or stubs. At the same time, native middleware libraries can be used largely unmodified from their source. With hlsteam, this allows running several games that couldn't run previously: Northgard (newer versions now with most modes; even GOG version), Darksburg, Evoland Legendary Edition, Nuclear Blaze, and the demo of Wartales. If you have one of these games and want to try it, just remove all *.so* and *.hdll files from the game's directory, then use '$ hl' from the hashlink port to run. Going forward, my plan is to replace the other stubs in steamworks-nosteam with functioning versions where possible, as well as adding libCSteamworks.so which so far is mostly blocked by a stub of Steamworks.NET.dll. This should eventually make steamworks-nosteam unnecessary. I have tested the port with all the above mentioned games. It should even be possible to play over LAN, as that is one of the main purposes of goldberg emulator, but I haven't tested that part. ok?
hlsteam.tgz
Description: Binary data
