Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide SDK 2013 versions of the native maps #1

Open
Rainyan opened this issue Sep 20, 2024 · 1 comment
Open

Provide SDK 2013 versions of the native maps #1

Rainyan opened this issue Sep 20, 2024 · 1 comment

Comments

@Rainyan
Copy link
Collaborator

Rainyan commented Sep 20, 2024

We should compile native SDK 2013 versions of the map files to avoid compatibility issues.

This could be a meta issue for combining all of the "Map X crashes" issues in the code repo.

Some considerations:

  • Can we host the official map binary BSP ports in this repo's neo/maps, in terms of copyright/licensing?
  • Can we legally host the corresponding VMF files in this repo's neo/mapsrc?
  • Do we have access/permission to use the original VMF's in the first place, or is decompiling the originals required?

If the answer to one or more of the above is "no", then we could either:

  • explore some kind of first-launch conversion based solution from the OG assets mount, but it would be less than ideal
  • have some kind of private repo for these assets, which isn't ideal either but it's an option
@blaberry
Copy link
Collaborator

Not really touching on the technical aspects of recompiling, as I trust you all better with that than myself, but on the legal aspects:

I think having a closed repo is an okay solution, though we have started the process of reaching out to the remaining team members, doing that is being tracked in the paperwork issues. If we're going by the original condition pushbak gave us for using the maps for NT related work, we're still doing that.

I feel like we've discussed the legal status of the assets in general a few times, but I haven't sat down and written a legal stance guideline. Not everything you might write in such a guideline is necessarily something you'd want to share publicly, so I'm happy to put some efforts towards writing that and sharing it with developers who have concerns. But in general I don't think the emphasis should be overly put on that as the main blocker.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants