Smithbox Compatibility

[vawser]

Adds compatibility for Smithbox to the Soapstone Server cross-referencing.

[gracenotes]

Just looking at mod/tool updates now that the DLC is out (there was too much to do before DLC so I effectively declared bankruptcy on updates). The main concern I'd have supporting additional backends is from a client perspective, as it was already quite difficult to reason about communication between one pair of tools, like what happens if one tool updates and the other doesn't, and two backend implementations is even more edge cases.

As Smithbox maintainer, would you be committed to feature parity with DSMS for the server implementation (SoapstoneService.cs mainly)? There are still more types of metadata/map editor operations it would be nice to support, as well as better ways of incorporating game data into the DarkScript3 UI; if those are implemented in DSMS, will they be ported to Smithbox, and vice versa?

If DSMS/Smithbox are actually going to be 100% compatible here, they should probably use the same port, and I can extend SoapstoneLib to support this. It would be much more tricky if different servers supported different feature sets, at least for current scope of interoperability.

[ividyon]

FWIW SoapstoneLib needs a whole redesign that doesn't involve manually entering process names into the codebase IMO. Any Soapstone client should be able to connect to any Soapstone server instead of there being some kind of whitelist. It feels like it defeats half the purpose of the library to oppressively control access like this.

Before looking into it, I always imagined that it would just be a simple collection of events/signals, and a server that lets programs connect to it and send/receive said signals to/from one another through it.

[gracenotes]

SoapstoneLib can take any port, any process name, or both. There is no whitelist. Anyone can construct any KnownServer instance they want and connect to any server. The main reason for worrying about process names in the first place is because servers can use different ports - like if a port is already in use if you have multiple instances of an editor open, it will pick a random port - so it's a reliable way to find it. And especially if an unrelated program happens to be using that same port, doublechecking the process name ensures we aren't sending junk to it.

So clients can have configuration to connect to any port if they want. Especially if they just want to read metadata, SoapstoneLib has a uniform way to get certain types of metadata that's pretty interchangeable between different server implementations.

However, DarkScript3 doesn't want to connect to an arbitrary server implementation, it wants to connect to DSMS. Or an editor with feature parity with DSMS. Clicking on a tooltip that says "Open with DSMS" and then it just does nothing, because it's only a partial implementation, is not an acceptable user experience in my opinion. Reaching an agreement on this was part of the initial interop that was added. If a DSMS fork wants to interop in the same way, that should be fine as long as it can commit to what I asked above, within reasonable best-effort limits (as long as there's some intention to eventually update it with any changes, etc).

[vawser]

Just looking at mod/tool updates now that the DLC is out (there was too much to do before DLC so I effectively declared bankruptcy on updates). The main concern I'd have supporting additional backends is from a client perspective, as it was already quite difficult to reason about communication between one pair of tools, like what happens if one tool updates and the other doesn't, and two backend implementations is even more edge cases.

As Smithbox maintainer, would you be committed to feature parity with DSMS for the server implementation (SoapstoneService.cs mainly)? There are still more types of metadata/map editor operations it would be nice to support, as well as better ways of incorporating game data into the DarkScript3 UI; if those are implemented in DSMS, will they be ported to Smithbox, and vice versa?

If DSMS/Smithbox are actually going to be 100% compatible here, they should probably use the same port, and I can extend SoapstoneLib to support this. It would be much more tricky if different servers supported different feature sets, at least for current scope of interoperability.

Yes, I would be committed to keeping feature parity.