Collab with the enhanced macOS/Linux port?

[jcotton42]

A few years back Ryan Gordon made some updates to the Linux and macOS versions of D3, but never brought those changes to the Windows version https://www.patreon.com/posts/project-descent-33611585.

It might be worth reaching out and seeing about integrating those changes. I don't know of a way to contact them outside of Patreon though.

[kevinbentley]

Good catch. I'm pretty sure we have some conflicting changes and fixes in there. We had some interaction with Ryan back when Jeff and I worked on the 1.5 fixes, but I'd love to work with him to resolve everything and integrate it into the open source code.

[icculus]

I need Interplay's permission to release my changes, as they own them; signing papers about this point was a condition of publishing the Mac/Linux builds on Steam. But I would definitely like to collaborate, as I have a bunch of stuff already solved, like 64-bit support, updated Linux and Mac stuff, Ogg Theora movies, etc.

Does Hervé Caen know about this repository? And is he going to be extremely upset if I bring it to his attention by asking him if I can publish my work too?

[kevinbentley]

Parallax owns the copyright for Descent 3 and Matt Toschlog authorized the release of this code. I'm not sure what the legal situation with Interplay is, I know they only had the rights to publish and sell Descent 3, not ownership of the code. I don't know if that changed somewhere along the lines, but the last thing I've seen published on the matter is here:
https://www.gog.com/forum/general/descent_12_descent_3_removed_from_sale/post1420, which states that Interplay has never owned the copyright, only the trademark. Then there's the whole dispute over their payment of royalties.

[icculus]

What a mess. :/

Okay, I'll email Hervé later today and see if he'll let me release my changes. It couldn't hurt to ask, right?

[kevinbentley]

Also, bear in mind that this source does not include any of the game files, so a person would still need to purchase the game to play anything built with this code.

[bryanperris]

Since some of the original copyrighted mission files provided their own custom compiled library, will the source behind those DLLs become open sourced? If not, how will this project handle being backwards compatibility?

[kevinbentley]

That's a good question. I'll have to find the source for those files. They are just c++ code that was compiled into the mission file from what I remember. I should have it somewhere.

[bryanperris]

Does the code behind those mission files just count as D3 source code? Once that C++ code has been ported into the future scripting solution, I would imagine D3 just needs compute a hash of the DLL after loading a mission and detecting embedded DLLs, then load in the matching scripted counterpart based on the matching hash.

[kevinbentley]

I think so. I'm going to talk with Jeff about this later tonight. He has a better memory than I do. Part of the reason I like the wasm route is that we could compile level scripts into a wasm dll that would be platform agnostic.

[icculus]

I'll have to find the source for those files.

I have them, if nothing else pops up.

(EDIT: And about 20,000 lines of diffs to get them to compile on modern compilers, lol. sob)

[bryanperris]

When you compile source targeting wasm, it generates just .wasm files, which you host from a web server, as for turning those into shared libraries, that might be more complicated. I can see one way of doing it just by embedding .wasm file into the library, but doesn't seem practical. You still need the wasm runtime in the D3 core, and it would have to extract out the .wasm file out of the library and into memory in order to start executing it.

[kevinbentley]

@bryanperris Yes, but instead of creating bindings to something like AngelScript, you create the bindings to the wasm runtime. Then you can let people bundle their mission code as a binary, but since the wasm runtime in in a sandbox, you don't have to worry about malicious code. Sort of how https://wasm4.org/ works.

I recognize that my idea may be ambitious. I'm not saying it has to be done that way. I just like the concept.

[bryanperris]

I completely understand what you envision here, and support it, I meant more why not embed the .wasm file directly into the mission file rather as some DLL file containing a .wasm module. For java, its compiled immediate code just live in .jar files. For C#/.NET, the compiler does generate a DLL or EXE (ignoring dotnet here), but inside of these assemblies, it is just metadata an CIL. The only reason they are DLLs or Exe's is just because of Microsoft's decision, technically that is not needed.