Need to reorganize addons with custom resources

[Hypernoot]

As you know, there's the possibility that add-ons can use their own resources. However, it has also bad consequences, as the in-game editor is coming. The custom resources bleed into the default ones, so there's actually no way how to recognize the default Super Tux resources with the custom resources. That way, a contributor might use a resource that belongs to an add-on without knowing that.

Maybe it would be possible to tweak the editor so that it won't display any add-on stuff, but this wouldn't be good as well. We should still keep the possibility of having add-ons those contain only resources (like sprites, music …) those can be used in other add-ons. Therefore the editor should still display them, but the contributors should be able to distinguish them.

I think, we should also get rid of possible collisions, when one file is defined twice or more times in various add-ons. And also the add-ons shouldn't collide with the default Super Tux resources. It's true that the contributors can know what resources Super Tux already has, but what if we wanted to make a new file that is named the same?

We have still all add-ons in our control, so I'd suggest:

• Put images those are closely-related to a single add-on: levels/<addon>/images/
• Put images those are meant to be used by other level sets as well: images/custom/<addon>/

And analogically with other types of resources.

What do you think?`

[brmbrmcar]

Addon resources doesn't seem to change the previous editors. I don;t understand how it would need to be changed in that respect. It just stays in the zip, right?

[LMH0013]

Having a "standard" for custom resources is a good idea, although I'd suggest keeping it simple and located in a single spot instead of two. Basically assume all custom-content to be addon dependent. I know we can have addons that use resources from other addons but currently there is no mechanism to reliably handle addons dependent on other addons. I am pretty sure nothing falls into that category right now, although I do know that there are addons that both use the same resource. I know this is not as efficient, but frankly we need reliable stability more. Plus, it's too easy for two different level designers to use the same resource name inadvertently, best keep them entirely separate.

Custom content from addons in the past has made it into the main repo causing conflicts, especially if that content gets updated or changed. Having a standard would help prevent this. Although we will still have efficiency issues when content gets adopted, but again I'd rather see it be robust first.

Reorganizing the current addons is probably not worth the effort at the moment since you're likely to break things and spend a fair amount of time fixing them. However, looking forward these issues could be addressed in the editor preemptively. In fact, they probably should be because if a new editor is going to be used it really should be significantly better than the current one. I would suggest that the editor be able to do the following:

• Handle levels at the addon scale, starting from a worldmap (or not) to editing the individual levels, then packaging it as an addon correctly with all custom resources saved in a unique yet consistent manner. This will solve all manner of issues with addons and submitting custom levelsets.
• This means that the editor should be able to differentiate individual custom content from the core content and organize it as such so that users are not confused. In fact, the editor should not even load custom content unless it is being actively used as part of the addon being worked on. Make it so cross-addon content does not work by default, and certainly not at the initial design phase.
• The editor should also be able to automatically set and handle all the file pathing for custom content without paths needing to be manually entered. This is essential to avoiding conflicts, having that content work correctly, and keeping content organized in a consistent manner. Not only do addons need unique locations individualized for the addon, but they should also probably be individualized to the specific version of the addon as well so as to prevent older versions of the content from being an issue.

If it is easy to handle with the editor, then conflicts should be avoided by default and everything will be nicely organized. This issue will basically take care of itself with a little foresight and thoughtful programming. If you impose an organizational scheme that has to be done manually expect to have to tweak and/or modify every levelset that uses custom content that gets submitted. It's bad enough getting level designers to package addons correctly, if the new editor handles this sort of thing then our lives will be considerably simpler.

[maths22]

See my new addon-mountpoint branch (SuperTux/supertux@70ef5e2)

This adds the "format" field to the addon.nfo file to support backwards compatibility, and will automatically mount anything with a format of 1 or greater to "custom/{addon-id}" Please let me know what you think.

[Hypernoot]

@LMH0013 An option for uploading levels could come later, I think we plan something like this. The editor is already able to list the file system, Maybe there will be a problem with hiding the add-on stuff, but we should provide a both-side check anyway. I think, we should have an extra meeting exceptionally for this.

@maths22 I like this format, just keep in mind that all paths to custom resources in the add-ons will have to be changed. However, it's true that we'd have to do it anyway.

[Hypernoot]

So now the editor advertises the players to turn off all old add-ons, so when someone ignores it, then it's his problem. For the people who hasn't seen it so far, there's also an option to disable those add-ons in that warning, so it's easy for the people.

I'd like to transform all add-ons into the new format. There's no problem with many of them, I could even do that. There are some add-ons those use own resources. It's not urgent, because they could stay the way they are, but we should do something with them by the time. There are two options. Eventually, we can pick one option and then change it by the time.

Option	Advantages	Disadvantages
Integrate the images into the add-on, as it is now, just change the paths where needed	It's quite easy, everything needed is already programmed.	Other add-ons can't use the same resources. When they do, there will occur duplications. However, the resources can't collide at least.
Make resources-only add-ons	Two add-ons can use the same resources, no collisions can occur. Also newly crated add-ons could use these resources. This also increases the quality of the resources, because we can accept the resources-only add-ons only when they are good enough. It wouldn't be possible to accept bad resources just because of a few levels.	Add-on dependency is not programmed so far but wouldn't be hard.