Rapidly swapping loadouts apparently could crash lobbies, sending everyone back to orbit.

The & is the html escape code for an ampersand (&) symbol, which is used to separate query params in a url – it appears like this has been re-encoded so the single & in the URL becomes & by something breaking the link. If you change all of the &s to $ it works. it’s not really an “amp” link in the “Google Amp” meaning.

Also after posting this comment, it appears to be Lenny’s url encoding, I think I’ve fixed it but if not, remove the amp; from the 3 sections of the url you see it and it’ll work

Sure, they obviously are dropping the ball here, just trying to explain what they might mean by “thoroughly tested” and why it’s not succeeding

This is all assumption from me, but I think a lot of testing would likely be diagnostic machines and specialized testing – not actually playing games. I would assume it’s something like plugging in, confirming the parts all meet spec after whatever the refurb is. That spec is probably more around frequencies, power use, temperatures.

Obviously that’s not good enough if they’re sending out these clearly broken refurbs.

Looks like the mount definitions require the :ro (or maybe :rq?) at the end unlike regular docker volumes, that was the issue.

What’s required to map a folder into one of the containers (i.e. retroarch)? I’ve attempted to edit config.toml to include it, but the main wolf container immediately crashes on boot due to interrupt code 11. There’s no other error messages, just a binary stack trace.

The folder exists. I’ve tried directly mounting the host path as well as mounting it into Wolf-Wolf-1 and using the local path, but nothing works. Even perfectly mirrored paths don’t work. Wolf appears to be running as root so I don’t think it’s a permissions error? I can certainly access the folders. They are a locally mounted NFS, but I’ve used this with dozens of containers without issue.