Policy: Uploads which are not usable with main/trunk OpenTTD #105
There are uploads on Bananas which don't work with main/trunk OpenTTD, as they require features in non-main versions such as patchpacks. This is a policy query about how these and similar content in future should/shouldn't be addressed.
At the moment these show up in the content list when queried from main/trunk OpenTTD, and can be downloaded, however they don't work when trying to use them.
(Scripts and NewGRFs where any extra functionality is optional and not required should just work without the user needing to be informed. The majority of NewGRFs which use extra features should do this.)
This seems non-ideal for main/trunk users and could result in user support issues.
Some examples of uploads on Bananas:
The text was updated successfully, but these errors were encountered:
The intention of BaNaNaS 1.5 is to also support forks and patchpacks, called "branches".
Not implemented are:
Current user experience from a patchpack user POV: (personal view)
Current user experience from a vanilla user POV: (personal view)
So, I think, content for forks does not really worsen the current situation.
Maybe we should add "JGRPP" as "branch" to the upload client already, even though the download client won't filter on it?
As @frosch123 said everything I would have said, I just want to add on this snippet.
Personally, and I think the "branches" support shows I am not alone in this, I consider a patchpack as much OpenTTD as vanilla. As such, this really is a non-issue as far as I am concerned. Even if we have to make some changes to the protocol or service, just let me know what you would like to change, and I will make it happen. Well, within reason of course :P
tldr: this really is a non-issue as far as I am concerned :)
PS: I absolutely love your post.
beep beep this is your IRC sync bot.
Extend this packet to contain a list of ("branch", "version") tuple. Example
This will give all content that is compatible with "official >= 12.0" or "jgrpp > 0.42.2".
That would make "branches" in bananas-api useful, and we can add "jgrpp" to it.
This way there is a minimal change to the protocol, enabling this feature.
I'd have no objections to this. Sounds like a good change.
At the moment trailing bytes in CLIENT_INFO_LIST are explicitly checked for here: https://github.com/OpenTTD/bananas-server/blob/main/bananas_server/openttd/receive.py#L83-L84
Right, ran into a small problem: what does it mean if a branch is not mentioned in
JGRPP would send:
What I suggest we do, is not weight all branches equally. If the
Any input from either of you would be greatly appreciated :D
I wrote out some scenarios:
Entry that is compatible with JGRPP and official:
Entry that is JGRPP only:
(mentioning a branch
Entry that is JGRPP only, from version 0.42.0:
Entry is 12.0 compatible:
(for JGRPP client,
I would go for different rules:
This avoids giving "official" any special meaning.
Applying that to your scenarios: (and some more)