Make tool parameters accessible

[Meziu]

It has been a month or so that 3dslink hasn't been able to find my 3DS on the network. I've ignored the issue for a while, but now that tests are in too, it's really annoying (I have to run 3dslink separately with the address parameter). I can't understand if it's an OS problem, since it started when I switched to OpenSUSE, or a problem with my network, but I believe we should make those arguments available one way or another, especially server, which seems useful.

Edit: I didn’t mention something important. I actually believe these parameters are outside cargo-3ds‘ CLI scope. Maybe we should implement these integrations through .cargo/config.toml or other external sources.

[ian-h-chamberlain]

You may find this helpful for the broadcast issue, in case you have that specific port blocked or something: https://github.com/devkitPro/3dslink/pull/3/files

[Meziu]

Welp, @ian-h-chamberlain I looked into the OpenSUSE forums and I found a question about an issue with Yast Firewall. I disabled it and it works.

Still, this doesn't change the fact we are blocking access to those parameters completely. We could look into this when we have time, or put it off until cargo-3ds is rewritten (something I plan on doing, this tool is a mess).

[ian-h-chamberlain]

Fair point. My first thought was that we could have something like cargo 3ds run -- <3dslink-args...> (and same for test) but it wouldn't quite match the typical cargo invocation. The newest version of 3dslink seems to support full argv so we may want to reserve that and look at config or metadata, or other external sources, like you mentioned.

[AzureMarker]

We could add new flags, i.e. cargo 3ds run --3dslink-address <address>.

Though this would be more ad-hoc and not full pass-through.

Edit: Maybe support using an env variable like 3DSLINK_ARGS?

[ian-h-chamberlain]

We could add new flags, i.e. cargo 3ds run --3dslink-address <address>.

Actually, I think this is not a bad compromise... Anything after -- could be passed through to the binary, but we could add some 3dslink-specific flags like --argv0 and --address before the --, similar to other args to cargo run. Any "unrecognized" flags would just get passed through to cargo run like they do now, but the 3ds specific args would be "captured" and removed from the invocation.

All that said, we may want to expose cargo metadata etc as well, for example argv0 seems like the kind of thing you wouldn't usually change frequently at runtime...

[ian-h-chamberlain]

I think this was fixed with #26 but I just used the wrong keyword to auto-close, manually closing it now.