Remove SS14 related content

[Peptide90]

Description

Given this fork is brand new, we need to remove all references to SS14 throughout, including entities that are specific to SS14 and cannot be reused.

Where possible, leave examples of entities rather than straight removing everything, and also where possible, change names, sprites and descriptions of existing stuff that can be reused.

Additional context

Feel free to do this folder at a time or subject at a time.

[hecksadecimal]

Is remaining compatible with upstream improvements not a concern? This approach does not feel especially modular.

[Peptide90]

Is remaining compatible with upstream improvements not a concern? This approach does not feel especially modular.

Not sure I follow. We will still pull the latest changes periodically but largely without pulling changes to the resources folder except where necessary. It'll be a lot of work to maintain but that's the same for all forks.

Unless there's a better way you propose? Github isn't my forte and managing a diverging fork won't be the easiest.

[hecksadecimal]

Well my concern is that any upstream sync you will want to do will have unnecessary overhead in how they have to be merged and checked. A more standard way of going about this would be to create a folder containing all of this server's unique content, and leave everything else as unchanged as it can possibly be. It saves you from merge conflict hell. This problem compounds the more upstream improves.

There will likely be a point where you won't want to sync with upstream anymore and instead do more targeted ports of the features, but given the rapid development going on upstream I feel like making syncing harder than it has to be would be a bit of a detriment at this stage.

Nyanotrasen is a good example to look at. Inside their content folders, they got 'Nyanotrasen' folders they put their own stuff in. In the cases where this is not enough and something about the SS14 content needs to change, then the lines can be clearly marked with a comment indicating what server-specific feature the changes are for.

[Peptide90]

Well my concern is that any upstream sync you will want to do will have unnecessary overhead in how they have to be merged and checked. A more standard way of going about this would be to create a folder containing all of this server's unique content, and leave everything else as unchanged as it can possibly be. It saves you from merge conflict hell. This problem compounds the more upstream improves.

There will likely be a point where you won't want to sync with upstream anymore and instead do more targeted ports of the features, but given the rapid development going on upstream I feel like making syncing harder than it has to be would be a bit of a detriment at this stage.

Nyanotrasen is a good example to look at. Inside their content folders, they got 'Nyanotrasen' folders they put their own stuff in. In the cases where this is not enough and something about the SS14 content needs to change, then the lines can be clearly marked with a comment indicating what server-specific feature the changes are for.

Got it, so isolate all of our resources to a specific folder then we can just pull all of SS14s content and if needed ignore stuff we don't need. I'll look into doing this later, thanks.

My only concern is packaging a lot of stuff we don't need so will need to look into selectively pulling.

[hecksadecimal]

Selectively pulling isn't really something that git supports, it'd take quite a bit of picking by hand for each sync if you do it that way, but you could maybe find a way to make the build tools themselves ignore things that aren't in use when making a package. That said though, it might not actually be that much of a concern given the launcher's delta compression on content updates, and the fact that most content is just markup files and very tiny sprites.