Kickstart this repo

[insraq]

Following the discussion here greenheartgames/greenworks#306 , here's the plan to kickstart this repo.

• Move CI to use this repo @Armaldio
• Check compatibility with Steamworks SDK v1.53a on Windows @insraq
• Move missing stuff from greenheartgames/greenworks @insraq (Maybe @Spacetech can help as well)
• Clean up documentations, add TypeScript definitions (there's already one) - volunteers?

If during the above work, anyone feels that greenheartgames/greenworks is a better base to work on instead of this fork, we can switch to that one as well.

[Armaldio]

I can convert every js file to a typescript file

[Spacetech]

Happy to see things moving forward 👍

My 2 cents regarding which fork to work off of: It really depends on what folks are more comfortable doing.

The main reason to go with mine is that the NAPI conversion is done and it's compatible with Steamworks v1.53a (currently shipping in my games depots on all OS's).
However the fork is old so a lot of the changes done in greenworks are missing in it. For example, reorganizing the large api file into separate ones is not in my fork. There's also various apis that are missing.

So the choices are:

1. Reorganize my fork and get it up to date with the existing greenworks
   1. General file reorganization - split the api file into separate parts, like what was done in the original repo.
   2. Go through greenworks commits and find what apis are missing. To stay organized, we could file issues for each of the missing things.
2. Migrate the existing greenworks repo to NAPI
   1. This would involve updating bindings in every file, updating how the async workers work, etc.

For option 1 - Once the main api file is split into multiple files, it should involve a bunch of smaller, mostly separate changes, where we re-implement the missing apis.
For option 2 - I kinda view this as a single large work item. It takes time and you need to know how NAPI / node bindings work.

My view: I'm not interested in doing the NAPI conversion a second time 😓 , so someone else should take up the mantle for that if option 2 is chosen. I'm happy to code review it though!

[Armaldio]

I think we should also move this issue to discussions and use projets to plan things

[Gurigraphics]

The main reason to go with mine is that the NAPI conversion is done and it's compatible with Steamworks v1.53a (currently shipping in my games depots on all OS's). However the fork is old so a lot of the changes done in greenworks are missing in it.

I generated with your project the "greenworks-win64.node" for Electron and NW.js.
But, I couldn't use it. Which version of Electron and NW.js is supported?

Also, I created a repository with a template from NW.js.
https://github.com/Gurigraphics/NWjsTemplate
You can edit the json and choose any version. And then simply use the command: npm run win, npm run linux, etc,
This downloads and generates the executable automatically with custom icons.
This makes easier to be able to change versions constantly.

Something like this could be available in this repository for NW.js and Electron.
However, NW.js have or had a small problem with Steam Overlay. Maybe better is use Electron.

[Spacetech]

I generated with your project the "greenworks-win64.node" for Electron and NW.js. But, I couldn't use it. Which version of Electron and NW.js is supported?

Can you explain what issues you saw when trying to use it?

My game is running on Electron 16.0.5. Any electron version that supports NAPI should work. I don't know which ones off the top of my head, maybe Electron version 12 and above? I have not tried to use NW.js with the module. Steam overlay with recent Electron versions on Windows has been working well for me. I generally move to new Electron versions quickly as I want to stay up to date with the latest chromium version.

The build command I run is something like node-gyp rebuild --target=$version --arch=x64 --dist-url=https://atom.io/download/electron, where $version is the electron version (16.0.5). It's worth noting that the specific version you build with is not that important because it's NAPI, so it should support multiple Electron versions as long as you build it to some minimum level.

[Gurigraphics]

Can you explain what issues you saw when trying to use it?

Thanks for the answer. The error was this:

Uncaught Error: A dynamic link library (DLL) initialization routine failed

Then, replacing this new greenworks-win64.node by the old greenworks-win64.node, it works again.

[Spacetech]

Uncaught Error: A dynamic link library (DLL) initialization routine failed

Did you also copy over the steam_api64.dll of Steamworks version that was used in the greenworks build? If it still doesn't work, I would recommend opening a new issue for that. This discussion is getting a bit side tracked 😄

[Gurigraphics]

Did you also copy over the steam_api64.dll of Steamworks version that was used in the greenworks build? If it still doesn't work, I would recommend opening a new issue for that. This discussion is getting a bit side tracked 😄

Probably yes. Steamworks_sdk_153a: sdkencryptedappticket64.dll, steam_api64.dll
Anyway, another day I try again. If it doesn't work, I'll open the issue. Thanks

[Armaldio]

@Spacetech @Gurigraphics Please, open a separate issue, thanks

[Armaldio]

So, guys, what are you working on ?
I've started working on the CI

Can I have some feedback here

[ceifa]

What do you guys think about add greenworks on npm? So we can have a better version management and add files to be ignored on publish.

[sleepingpandagames]

What do you guys think about add greenworks on npm? So we can have a better version management and add files to be ignored on publish.

I do believe this is a really cool idea, but I'm not sure if Valve will allow that.

I asked on the Steamworks forum if it would be okay to host SDK files on a public repository.
Here is the link to the post.

I'll keep an eye on this.
If I still have no anwser from Valve after a few days, then I'll contact them directly.

In the meantime, @Armaldio, if you want I can send you the latest SDK versions you need via e-mail.

[Armaldio]

1. Publishing greenworks on npm mean only publishing .node addons & .js files. SDK will not be available.
   SDK is only used to build the .node files

2. Greenworks is already used on npm. We either have to contact the owner to take ownership or to publish to @greenworks/greenwork (prefered for consistency with GH org)

In the meantime, @Armaldio, if you want I can send you the latest SDK versions you need via e-mail.

It seems a regular account (which I have) is able to download the steamworks SDK, so I have the files ;)

[insraq]

Sorry for the lack of updates. I have just had a chance to skim through the whole codebase - it seems that Spacetech's fork is really old and is missing several APIs (and have some extra). I wonder whether it makes sense to move forward with Greenworks's repo instead?

@Armaldio Apart from a newer (and maybe better) API, are there other benefits of using NAPI instead of NAN, especially w.r.t CI setup? For me, I am inclined to add the missing feature onto Greenwork's repo and postpone the migration to NAPI - after all, most game developers won't benefit directly from the API migration and it's a lot of extra work.

[Armaldio]

Isn't the missing APIs are a matter of copy pasting ?

1. I have already put some time on this repo to migrate and improve CI
2. I think it's better to add missing APIs directly to NAPI instead of migrating them later
3. People will not have to worry about compiled addon version with NAPI
   That's the whole point. With the old nan, I have to compile to multiple versions, the setup is hard and some versions doesn't compile at all or require hacks. Also, only LTS/supported versions of runtimes are supported. With NAPI, wider ranger of versions are supported. Even deprecated runtimes.