webbukkit / dynmap

A set of Minecraft mods that provide a real time web-based map system for various Minecraft server implementations.
https://www.reddit.com/r/Dynmap/
Apache License 2.0
2.05k stars 419 forks source link

Request: Can I rewrite dynmap into a Nukkit plugin? #1877

Closed Snake1999 closed 5 years ago

Snake1999 commented 8 years ago

Hello. As is known to all, minecraft pocket edition is more and more popular, but mojang does not have a server software, and multiplayer game out of LAN seems to be impossible. What we Nukkit Team build a server software called Nukkit, licensed in LGPL, written in Java with a plugin API, to make minecraft PE multiplayer game possible, more interesting, and more powerful. Our plugin developers are building lots of basic plugin for Nukkit, and we have an idea that rewrite dynmap plugin into a nukkit plugin. I'm sending this request to developers of dynmap, in order to get permission and help, for dynmap users grow larger, and for more freedom managing a server. Sincerely, Peter Jiang @ Nukkit Team

Note: more info on Nukkit, see https://github.com/Nukkit/Nukkit

mikeprimm commented 8 years ago

You're welcome to attempt a port - the code is structured with 95% of the logic in the neutral DynmapCore repo (which is common across Forge versions, Bukkit, Canary, etc), so for most MC servers, grabbing and beating on the appropriate wrapper code (the 'dynmap' or 'DynmapForge' repositories) is sufficient to accomplish a port. I don't know how different the block IDs are for Pocket Edition, though, which would impact the models and textures files, as well (since these have the well-known IDs in them).

Snake1999 commented 8 years ago

Here, MCPE have a completely different ID and META than what PC is, however, I'll try it :D

mikeprimm commented 8 years ago

It SHOULD be just changing the numbers in the models.txt and texture.txt files, for the most part - the code already supports version conditionals for those files, as well as supporting using block names versus ID numbers (which the more recent versions - since 1.7, IIRC, favor for identifying blocks, even though vanilla blocks always have stable ID numbers). I'll give that part a looks - I may be able to put in the right sort of conditionals for the 'common' code, so that you can just focus on the wrapper/shim code particular to the Nukkit API (which will be the bigger work).

On Tue, Feb 2, 2016 at 10:43 PM, Peter Jiang notifications@github.com wrote:

Here, MCPE have a completely different ID and META than what PC is, however, I'll try it :D

— Reply to this email directly or view it on GitHub https://github.com/webbukkit/dynmap/issues/1877#issuecomment-179003890.

--Mike

Subject-4 commented 6 years ago

@Snake1999 is this still in the works or discontinued?

Snake1999 commented 6 years ago

This is done in commercial version of Nukkit, but not yet available in community version @LagHD We've got a new project to do. How time flies!

K1ller0561 commented 5 years ago

any news about dynmap for nukkit? I am fan about dynmap and want to have this plugin for this :D

Psy-Virus commented 5 years ago

If this is still a thing, please open a feature request by filling out the provided form. Then Mike will probably decide if it's worth doing.

RemiG0 commented 4 years ago

Is there anything more about Nukkit port of Dynmap? Will it be available for the community?

mikeprimm commented 4 years ago

I'd be willing to accept a PR for adding support - Dynmap is 95% common code across all current MC implementations, and a 'rewrite' would really just wind up being a fork of a whole lot of code that other folks just don't know how to support, with the result being that that community would wind up asking me for that support. At this point, my next platform addition is going to be FabricMC 1.15.2. I have put some time in, on an unrelated project, on Bedrock Edition, so I've gained some experience with the fundamentals there - I haven't looked much into Nukkit's own API and modding model, particularly as it applies to the custom block support and behavior pack support that Bedrock now has, and am a bit on the fence as to whether to try to support Bedrock Edition via 'modding' (i.e. a Nukkit mod, trying to accomplish it in concern with behavior pack scripts) or via an external rendering platform (i.e. supporting reading the world format data directly without being 'in' the server).

silas0526 commented 1 year ago

Has dynmap been ported yet?

JurgenKuyper commented 1 year ago

Not that I know off

mikeprimm-mirific commented 1 year ago

Ditto here - I've had folks ask to do ports on two occasions over the past 8 years or so, but I've never heard back from them once I agreed that it was OK for them to pursue it (I don't particularly want to add it to the code base, since unlike the existing platforms - which all have vanilla java edition in common, limiting just how divergent things can get - Nukkit is quite independent of both JE and the BE server implementations, but if it were well done as a PR, I'd certainly at least consider it).

Far as I can tell, original Nukkit is DOA, but has been replaced with NukkitX - but I have no insight into how many servers are using it, but my impression is not enough to justify the additional work and support overhead for us to do it. Don't take it personally - it's just we're supporting 30k+ active servers on spigot/paper and about 10k active servers between fabric and forge, so adding something to the support matrix needs to be a big enough community to justify the work (which is why Sponge, Magma, Folia and the myriad of other forks that have come and gone over the years are not officially supported - the work to add, test, and support each is about the same for each one, while the community is rarely big enough to justify the division of effort from the platforms with large installed bases). But this is also why we're Apache Public License - anyone who wants can fork it, just don't use the Dynmap trademark - that's there to protect our reputation and the trust earned over the past 12 years we've been delivering this plugin, and make clear that that fork is not supported by us (which is important, since my experience is that 90% of the forks of mods done by folks other than their original team are abandoned within a year - often sooner...)