Difference between revisions of "Talk:GSoC Addon Dependencies"

m (5 revisions imported)
m (Matthew moved page GSoC Addon Dependencies to Talk:GSoC Addon Dependencies without leaving a redirect: This is a discussion page)
(No difference)

Latest revision as of 00:00, 7 September 2016

Currently, when an artist creates an add-on package (a kart, track or battle arena), their contribution is completely encapsulated within a single archive file for download. This presents a few problems:

  • Assets may be stored with multiple add-ons
  • Users must download the same files multiple times
  • Duplicate data must be stored on the server multiple times

This is particularly prevalent with music that artists include with their track or battle arena packages. A dozen artists may all include the same music track, with a size of 4MB, and we would have to store all dozen or more copies independently.

In order to resolve this problem, a dependency system could be implemented for add-ons. In the use case above, music would be stripped out of an add-on download, and stored as a separate package. Each add-on that uses this music track would reference the music package. When a user uploads new content, their upload would automatically be scanned for files which already exist on the server, and the add-on package would be modified to correctly reference the existing content and a dependency link would be created. In the case of a new asset, the music file would be added to the music database and other artists would be free to use it.

There are two main components of this project:

  1. The Addons server (live at addons.supertuxkart.net) upload logic must be improved to scan addons for duplicate data, and to create asset packages that make use of the dependency system. This could include music, texture packs, object packs, or other resources. Artists should be able to independently upload music, texture or object packs and they would be subject to the same style of moderation currently in place. Users should be able to view an index of these asset packages from the web interface.
  2. The game client must be augmented to understand addon dependencies. This would include downloading the dependency, but also knowing when a dependency package is no longer in use to uninstall it. The UI could be augmented to list dependencies, and UI changes would be needed to indicate that some dependency needs updating.

The code in this area of the addon website is particularly messy. Any work in this area could require a great deal of restructuring. As well, backwards compatibility should be preserved where possible.


  • PHP(OO)
  • C++
  • (My)SQL


  • Glenn De Jonghe (unitraxx)
  • Fallback: Stephen Just