Read by Council Community Content (pre-rails separation)

[Achriel]

Over the course of StarMade evolution we have hit certain defining milestones, perhaps the largest of which is rails as the pervious docking/turret system became obsolete. To that end I think we need to separate the older designs from the newer ones in Community Content.

The reason being new players will be rails people, having no experience with the old system. The shipyards and other systems will make these older designs unusable (though all can probably be retrofitted on personal machines in creative mode). I don't want to lose access to these wonders of construction but a 'filter' of sorts is probably a good idea.

How Schine can implement this I'm not sure, perhaps leave it to the creators to 'update' their descriptions and 'check' a Rails Compatible box to be included in the filtered list.

 

[Achriel]

Poked around a bit more and I think Skins also have a 'line' between the old and new style, Logic between docking changes (as with ships and stations), Texture packs (probably a few lines but I don't know much about these). I'm not sure about Mods as all, that could get trick or needs a review option as 'Working' in current release (or what version it does work in).

 

[kiraen]

It would be much simpler to indicate which version is required/it was made for/with.

 

[Achriel]

It would be much simpler to indicate which version is required/it was made for/with.

Yes, and that's probably a good idea having the version included in the Community Content information. However that still leaves over 3000+ ships for someone to figure out which version they are (many could be deduced by last update date). Maybe information (version) is in the schematic but even then it wouldn't apply to Mods or skins. There may also be instance in future changes that require some type of notation (like AI used or not), Primary/Secondary colours (another of my suggestions) or a load of other possibilities.

With the availability of a Modding community we are going to develop 'forks' and major variations over time. Tags can solve most possibilities (RP, fuel, ammunition) but like MineCraft success can mean greater diversity rather than homogenization.

 

[jayman38]

For now, it will probably need to be based on date. That would be good for archiving ancient designs. (Archived as in slower to download, but still available for download.)

It would be super-neat if the uploading system could scan the blueprint directly and auto-build a series of tags, based on what the blueprint actually contains. (We can't rely on individual contributers to document their contributions properly.) This still wouldn't address mods, unless the import system could identify "mod" IDs that are not in the vanilla game, and set a tag of "modded". If block IDs are replaced, this could produce inaccurate tags.