RE: player_api ?
sirrobzeroone opened this issue · comments
More just a thought for discussion of the mt-mods team.
the player_api is just about integral to any basic game which someone may wish to create which revolves around having some form of 3d in game avatar - I'm being very general there :).
At the moment the player_api mod is bound/stuck with the mtg game which is currently under a maintenance only fix status. Numerous people (myself included) have tried to make changes to the base mtg player model which results in a bit of dependency hell when it comes to working out which other mods support which features. Not at all suggesting extra animations be added to player_api but more basic run of the mill items - Bell07 had a go at merging all base characters into an updated player_api but then hit a wall when MTG got placed into maintenance only mode:
-
Support for the MC 1.8 skin format (essentially double layer skin which gives you that extra layer to add hair whisps or clothing pieces too - skinsdb currently adds this but it would seem to belong in the base player_api as an option.
-
I know 3 pixel wide arms have also been discussed but not sure anyone has progressed anything not sure if part of that might not be because player_api is stuck in maintenance only mode?
-
Some as yet unforeseen feature could come along in the base engine and it would not be possible to add new functionality to the player_api mod to make use of that, at least not in a centralised semi-coordinated way.
Just sort of flagging this issue here as I don't know where else to note it, just seems like player_api is fairly important mod but there's no real way for anyone to feed improvements into the mod now. Might be out of scope for the mt-mods team but as mentioned above player_api just seems a little stuck in development limbo at the moment. MTG could easily pickup new versions of player_api in the future if it continues to be distributed with MT
@bell07 - Just tagging you as I know you have an interest in this space as well :)
not mentioned here, player_api's licensing issue, it is licensed LGPLv2.1+ which is a viral license, forcing devs to use its license or higher, instead of something like mit, bsd, etc which is better for imbedding in other projects as it doesnt infect the project
not mentioned here, player_api's licensing issue, it is licensed LGPLv2.1+ which is a viral license, forcing devs to use its license or higher, instead of something like mit, bsd, etc which is better for imbedding in other projects as it doesnt infect the project
This is in the license conditions:
c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
I'm not a lawyer, does this mean if you embed this, for example, as a submodule in your game that your game has to be licensed under the same license too?
In any case: i don't think anyone would be opposed to fork that under the mt-mods umbrella
Didn't even think of the licence issue very good point wsor4035. BuckarooBanzay would clause 5 in LGPLv2.1 be applicable in this case ie player_api is referenced as a library as it's not compiled as part of the exe?
Could C55 agree to change the licence terms for the code to say MIT or would we need all contributors to agree? I have no clue how that works....maybe found this? - PHPOffice/PhpSpreadsheet#140
Either way it would be nice to get it under the mt-mods umbrella :)
For reference: my work is at https://github.com/bell07/minetest-player_api_modpack. Basically I enhanced the player_api for common skinning tasks, (Skin definition including per-player model, skins-list, and skins modifier API) to allow all skin related mods work proper together in a compatible way. The repo contains mods I ported to the new enhancements and removed all "if skinmod1, elseif skinmod2..." hacks.
MC 1.8 skin format is optional in mod multiskin_model, but required for 3d_armor and clothing.
I archived the work since minetest/minetest_game#2122 was rejected with no reason and another PR minetest/minetest_game@6623dec was merged, and I lost motivation to update my fork.
NAL, but if your linking player api as a submodule into your game, the game repo itself for example could be MIT, but the package if listed on cdb would have to be lgplv2.1+ or higher since that actually includes it.
Package license requirement is not really that clear and some say it has to do with what would be seen as linking while most do not see any problem with compiled packages (like CDB or any other installers that include software with all libraries).
https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic (there meaning of "linking" is what causes troubles with packaging script-like languages that you wont normally compile into object or binary form and that's what makes it controversial)
Packaging itself and license requirements for package is controversial topic, even leading Linux distribution projects cannot come to agreement on that issue with some open source licenses but I think most read it as non issue when it comes to combining with LGPLv2+.
NAL, but if your linking player api as a submodule into your game, the game repo itself for example could be MIT, but the package if listed on cdb would have to be lgplv2.1+ or higher since that actually includes it.
Found this stackoverflow question: https://softwareengineering.stackexchange.com/questions/240633/is-licensing-an-issue-for-git-submodules
doesn't look like linking (in the sense of hyperlinking) or using as a submodule should be a license issue
using a mod and even overriding its behavior doesn't violate the AGPL which is much more restrictive than LGPL. those who repeat that are victims of google propaganda.