ds3os VS sourcelink

__FILE__ is pain of my existence, recently contributed this code to run/build ds3os using nix instead of docker, where I hit issues with __FILE__

https://github.com/TLeonardUK/ds3os/blob/main/default.nix#L4...

Afaik, none of the big mods were updated after the game got updated in january. So none of them will work online. Maybe there is a chance with using the private server: https://github.com/TLeonardUK/ds3os but i dont know, you need to find out yourself.

Le projet est ici [https://github.com/tleonarduk/ds3os de numéro(https://github.com/tleonarduk/ds3os), il vous permet de jouer à Dark Souls 3 sur des serveurs communautaires et d'exécuter le vôtre.

Maybe you could try using a private server: https://github.com/TLeonardUK/ds3os but i dont know if this works tbh. Its pretty easy to use/test though.

Debatable. But for DS3 there is a private server. So there is that

Private servers: https://github.com/TLeonardUK/ds3os

Private Servers maybe?

The premise of the tool seems very useful: edit debug symbols and assert messages so that source code can be found by debuggers. But this description does not make it clear how this tool accomplishes the whole task:

> Why not fix the binary coming out of the build cache, so it points to the absolute path of the source files?

What is the absolute path? If you had a virtual file system that allowed you to construct a path to any file at a given commit, this would work great. But who does that other than Google? Or if you agree that every developer will check out the same source code repo at the same path, but the you have to have the right commit checked out.

Ideally you would want your binary to point back to your code repo, like SourceLink does.

https://github.com/dotnet/sourcelink

Reference https://github.com/dotnet/sourcelink/tree/main/src/Microsoft.Build.Tasks.Git

The tooling isn't quite there yet, but between SourceLink and EmbedUntrackedSources, it should be completely reasonable to be able to maintain trust (and eventually, easy, exact reproducibility) for projects that use source generation. Plus, AFAIK, for a package to truly be considered deterministic, all of the sources used for the build either must be tracked by source control, or embedded with the aforementioned flag.

It looks like your NuGet packages is missing symbols (the .pdb files next to .dll files). Symbols let folks map from compiled code back to source code. No symbols make it harder for users to debug your package. I'd recommend using Source Link for your project: https://github.com/dotnet/sourcelink

If you want to enable Source Link for the consumers of your NuGets, make sure you turn on deterministic builds using dotnet build /p:ContinuousIntegrationBuild=true.