- 欢迎来到Minecraft插件百科！
- 对百科编辑一脸懵逼？帮助:快速入门带您快速熟悉百科编辑！
- 因近日遭受攻击，百科现已限制编辑，有意编辑请加入插件百科企鹅群：223812289
Dynmap
| 外文名 | Dynmap |
| 插件类型 | Spigot / CraftBukkit |
| 最新版本 | v1.5.5.7 |
| 兼容服务端 | 全版本 |
| 前置插件 | Vault |
| 源地址 | http://dev.bukkit.org/bukkit-plugins/Dynmap |
- 点击此处开始翻译。
- 如本模板出现在原文存档页面，请注意更新主页面后，仍需要去除此处该模板。
- 如当前页面已经没有需要翻译的内容，请删去待翻译模板。
- 有标题的大篇幅文章，如果短时间内无法全部翻译，请先把所有的标题翻译出来，以便之后的贡献者选择与翻译章节内容。
简介
Dynmap是一个可以用网页浏览的、像谷歌地图一样的动态地图插件。Dynmap的网页结构是建立在整个MineCraft游戏之外的，非常实用和易用，Dynmap也可应用于基于Apache类软件的网页。
Dynmap可以用不同的渲染图层渲染你的服务器世界地图, 有些适合于展示, 有些有着更多的地图细节。
这个插件的原始项目是由 k-zed.开发给 hMod 的。
插件的部件可供你按照自己的需要添加/删除功能，使用Dnymap支持的部件,包括聊天泡泡, 网页-游戏聊天, 和可配置的标记, 标签, 下换线。
功能
- 每个游戏世界深度可设置的地图
- 实时更新：地图总是和服务器世界实时同步，当你打开着你的网页时更新一直会显示
- 玩家和他们的头像在地图上可见
- 地图上的聊天信息可见 (显示在聊天泡泡或者聊天框里)
- 地图浏览者能和游戏内的玩家聊天
- 实时Minecraft时间在地图上可见
- 实时Minecraft季节在地图上可见
- WorldGuard, Residence, Towny 和 Factions regions 插件都能在地图上可见 (需要相应版本的 Dynmap-* 补丁)
总的来说高度可配置和可定制化
安装
复制dynmap-*.jar 进你的补丁文件夹. 如果用于更新, 删除之前安装的 dynmap-*.jar - 你不需要删除任何补丁/地图文件夹或者它的文件。
如果你正在运行一个独立网页服务器 (比如 Apache) 你可能需要先复制文件'plugins/dynmap/web/' 到你的http-root的一个文件夹，里然后再执行此教程。升级时，请确保你也升级了被复制的文件。
首次使用
当你开启 CraftBukkit 时, 你应该可以在浏览器里跳转到 http://yourserverip:8123/（http://你服务器的IP:8123/）。 如果你是用你现在正在使用的PC来运行 CraftBukkit, 你可以跳转到 http://localhost:8123/。
你应该能够看到在游戏内的玩家。 需要注意的是此时地图还未被渲染, 所以背景应该是黑色的。
如果你计划使用高清渲染, 现在你就可以着手做这件事了。开启configuration.txt顶端的 'deftemplatesuffix: hires' 。更多关于deftemplatesuffix的信息可在基础补丁设置查看。
如果你只是想让Dynmap有效, 在游戏里使用这个命令 /dynmap fullrender。 wiki上有更多关于命令和权限的内容。
地图此时应该会显露出来，给它一些时间。程序信息之后会显示 Dynmap 正在工作 (Dynmap is working) 和 渲染已完成 （render is completed)。
相关
Bukkit论坛 (已失效） Bukkit项目页面 IRC: irc://irc.esper.net/#dynmap (via web)
如何使用
在无内部网页服务器环境使用
本页适用于
- 你对你正在使用的独立网页服务器有着有丰富的经验
- 你的CraftBukkit和独立网页服务器运行在同一个机器上
- 你的网页服务器支持PHP（用于网页-Minecraft 聊天）
- 如果是基于Linux环境，你应该知道如何使用terminal（终端）和chmod（命令）。
以下代码
- class: org.dynmap.InternalClientUpdateComponent sendhealth: true allowwebchat: true webchat-interval: 5 #- class: org.dynmap.JsonFileClientUpdateComponent # writeinterval: 1 # sendhealth: true # allowwebchat: false
改变为:
#- class: org.dynmap.InternalClientUpdateComponent # sendhealth: true # allowwebchat: true # webchat-interval: 5 - class: org.dynmap.JsonFileClientUpdateComponent writeinterval: 1 sendhealth: true allowwebchat: false
用于取消内部（internal）更新机制，开启json-file更新机制。 这样做会将其写入你的网页路径文件standalone/dynmap_world.json，并指定向writeinterval。< br/> (?)(This will write to the file standalone/dynmap_world.json in your web-path at an interval that is specified with writeinterval.)
复制你的文件进网页服务器中的plugins/dynmap/web。更改configuration.txt让其指向到你*nix放置网页文件的地方，同时包括tilespath及webpath。
tile-files放在路径 .tilespath: /path/to/web/server/dynmap/web/tiles
webpath放在路径 .webpath: /path/to/web/server/dynmap/web
或者，在Windows环境下
tile-files放在路径 c:\\path\\to\\web\\server\\dynmap\\web\\tiles
webpath放在路径 c:\\path\\to\\web\\server\\dynmap\\web
现在重启你的Minecraft服务器，加入你的Minecraft服务器随机放置一些方块以触发dynmap的tiles。你也可以在后台输入dynmap全渲染（fullrender）世界名来用新的世界名渲染世界。
现在重启你的浏览器，在http://mywebserver/dynmap/上会显示你的在线玩家并保持更新。
故障处理
如果你没有看到任何tiles(地块）显示在地图上，检查tiles（地块）目录，看看他们有没有真正的启动。如果里面没有tiles（地块），可能是Minecraft没有权限将tiles（地块）写入你选择的web-path地址。另一个可能是你的tilespath没有填写正确。
如果你没有看到任何玩家或者没有看到玩家在移动，前往 http://mywebserver/standalone/dynmap_world.json (把 world 替换为你的世界的名字)。每隔几秒，你应该可以看到一些代码刷新，（比如服务器时间应该在一直更新），如果你没有看到这个文件，或者看看不到文件有任何刷新和改变，你可能在配置文件里填错了webpath的地址。
在Linux环境下，如果网页-Minecraft 聊天（web-to-mc-chat）不工作，你需要对775或者777独立文件进行chmod。
chmod -R 775 standalone
这样做可以允许sendmessage.php 创建 jsonfile. 这个步骤是必须的，因为是你的网页服务器创建的文件，而不是minecraft服务器创建文件。
如果网页-Minecraft 聊天（web-to-mc-chat）在IIS不工作, 你可能需要安装 php.
在Linux环境使用
阅读本页面的前提是:
- 你的Minecraft服务器放在: /opt/minecraft_server/ 。
- 你安装了最新的CraftBukkit。
- 你的Minecraft服务器开在在本地（localhost)。
安装与测试dynmap的步骤为:
- 复制文件dynmap.jar和dynmap文件夹至/opt/minecraft_server/plugins/。
- （重）开启你的Minecraft服务器。
- 加入你的Minecraft服务器。
- 放置几个方块（译者注：即Blocks）。
- 打开你的浏览器。
- 前往http://localhost*:8123/。
在左上角你应该能看到你的地图和名字。点击了你的名字，地图会跳转到你的位置，就能看到一部分已启动的地图了。
向公众开放
如果你想让其他人也能使用地图，有两个方法可以实现：
- 用TCP端口8123指向一个外部端口到你的内部Minecraft服务器，更多关于端口映射的信息请前往： http://portforward.com/ 查看
- 将你的大型网页服务器作为部分地图的主机。特别需要注意的是，网页服务器必须已有权使用Minecraft服务器，详见以下指导。
大型网页服务器
如果你正使用Apache或者Lighttpd服务器作为主机，若想让Dynmap地址与你网页地址url一致（译者注：即关联网页url），如 http://www.yourwebsite.com/dynmap/ 而不是 http://www.yourwebsite.com:8123/。你可以使用以下列表的网站服务器地址
- 在Debian/Ubuntu系统的apache2环境下设置: 在Debian下用 Apache2 设定你的Dynamic Map
- 在Arch Linux系统的apache/httpd环境下设置: 在Arch Linux用apache/httpd 设定你的Dynamic Map
- 在Arch Linux系统的lighttpd环境下设置: 在Arch Linux用lighttpd 设定你的Dynamic Map
- 在Centos系统的Nginx环境下设置:nginx Setting-up-with-Nginx-server-on-Centos (LukeHandle的courtesy)
在Windows环境使用
本页面适用于:
- 你的Minecraft服务器路径为D:\minecraft_server\。
- 你安装了最新的CraftBukkit 。
- 你的Minecraft服务器主机在本地。
安装和测试:
- 从压缩文件中复制文件dynmap.jar 和dynmap的文件夹并粘贴至D:\minecraft_server\plugins\.
- 启动或是重启你的Minecraft服务器。
- 加入你的Minecraft服务器
- 放置几个方块
- 打开浏览器
- 前往http://localhost:8123/。
在左上角你应该能看到你的地图和名字。点击了你的名字，地图会跳转到你的位置，就能看到一部分已启动的地图了。
向公众开放
如果你想让其他人也能使用地图，有两个方法可以实现：
用TCP端口8123指向一个外部端口到你的内部Minecraft服务器，更多关于端口映射的信息请前往： http://portforward.com/ 查看 将你的大型网页服务器作为部分地图的主机。特别需要注意的是，网页服务器必须已有权使用Minecraft服务器，详见以下指导。
大型网页服务器
如果你正使用IIS或者其他环境下的服务器作为主机，若想让Dynmap地址与你网页地址url一致（译者注：即关联网页url），如 http://www.yourwebsite.com/dynmap/ 而不是 http://www.yourwebsite.com:8123/。 你能在下面给出的列表中挑选你要用的网站服务器
- IIS: 在IIS环境下用 URL 设置Dynamic Map,rewrite and ApplicationRequestRouting (thanks to Kekec852!)
- IIS: 在IIS环境下用 URL 设置Dynamic Map
(这还算不上一个列表嘛?如果你有另一台服务器并知道如何去配置它，请将其添加至Wiki)
在虚拟主机环境使用
总的来说，在虚拟主机环境下无法使用， Dynmap提供的主机网页服务器标题文件需要文件系统权限.(相对于FTP或者SFTP基础的文件,它们的大多数主机传输服务是被允许的). 以下是一些链接到非官方创作者的地址,一些我们的用户成功将其用来作为特定的hosting解决方案.
Dynmap On Xenon Hosting Service, courtesy of mavbear
插件设置
在这里，我们将描述如何结构化你的配置，以及如何编辑配置。
配置文件存放于 plugins/dynmap/configuration.txt ，为YAML格式。它是一个被indentation定义的等级制结构。Indentation 在配置文件里不能包含任何的标签，只包含空格。it has a hierarchical structure that is defined using indentation. The indentation in the configuration may NOT contain any tabs, only spaces. 这也意味着你需要准确的将正确的空格数量填入配置行之前。This also means that you need to be sure to put the correct number of spaces in front of configuration-lines.
你可以参考这个地址的默认配置：https://github.com/webbukkit/dynmap/blob/recommended/src/main/resources/configuration.txt.
设置文件包括四个部分： 组件（components）, 全局设置(global settings), 世界模板与世界（world-templates and worlds）。全局设置改变渲染和Dynmap网页服务器（交互）行为。易看出，这些部件是如何运行的。给出一个全局设置（global setting）的例子如下：
- tile得到渲染的频率（单位：秒）
renderinterval: 1 （渲染区间：1） 注意：版本为v0.20时，默认配置文件是被分开的， Note: As of v0.20, the default configuration.txt file has been split, with the templates: section being moved to the templates/ directory and the worlds: section being moved to the worlds.txt file. Users are NOT required to change their existing configuration.txt - templates or worlds defined in configuration.txt are still processed, and templates found there supersede those of the same name from the templates/ directory. It is recommended the existing users, at their convenience, move their worlds: section (if they have one defined) from configuration.txt to worlds.txt, to prevent future impacts on that configuration due to future updates of configuration.txt. Likewise, it is suggested that existing users move their templates: section from configuration.txt to a new file, templates/custom-templates.txt.
Components
组件部分一般看起来是这样的:
components:
- class: org.dynmap.ClientConfigurationComponent
- class: org.dynmap.InternalClientUpdateComponent sendhealth: true allowwebchat: true webchat-interval: 5
...
Each component can be thought of as an separate feature of Dynmap, which can be disabled and enabled individually. Some components depend on others, but we won't get into that. Each component starts in the configuration with a - class: 每个组件可以被当做是一个独立的Dynmap功能，即可以被独立的打开或者关闭。一些组建依靠其他的组建（运行），但是我们不能一一详细说明这些具体情况。每个组建的设置（名字）都以 - class： 为开头
... followed by the properties of that component.
以组件特性为结束（名）。
As an example we're going to disable the component that handles chat-balloons. This component looks like this: 这里给出一个例子，我们想关闭聊天泡泡组件，这个组件看起来会是以下这个样子： ...
- class: org.dynmap.ClientComponent type: chatballoon focuschatballoons: false
...
We can disable it by just deleting these lines, but a safer way is to comment them. For this example I've added the lines before and after the component to give a better impression: 我们可以直接删掉这几行信息，即直接关闭这个组件。但是更安全的方法是将他们变为注释（译者注：即加上#使其变为注释，失去原有功能）。比如说，在组件前后我加上几行注释，这样是更好的“关闭组件”的方法。 ...
- class: org.dynmap.ClientComponent type: chat #- class: org.dynmap.ClientComponent # type: chatballoon # focuschatballoons: false - class: org.dynmap.ClientComponent type: chatbox showplayerfaces: true messagettl: 5
... Be sure to have still the correct number of spaces in front of the #. After saving the configuration, reloading Dynmap and refreshing the browser, chat balloons won't pop up anymore. The same method can be used to enable already disabled components.
For details on all components, and their settings, see Component Configuration.
Worlds and templates
In the configuration you'll also see a worlds section (since 0.20, this is found in the worlds.txt file; previously, it was found near the bottom of the configuration,txt file). This section can be left empty - Dynmap will automatically find all worlds defined for a server, and provide them with a default map configuration, based on using templates, as defined in the templates: section. Since 0.20, the templates definitions have been moved from configuration.txt into separate files found in the templates/ directory, but otherwise function as they have previously.
For a comprehensive description of all world settings, see World And Template Settings.
Templates
By default there are three templates: normal, nether and skylands. The template that is chosen for a certain world depends on the environment of the world - normal for normal worlds, nether for nether worlds, skylands for skyland worlds. As of 0.20, these definitions are found in files under the templates/ directory, with filenames corresponding to the template's name: templates/normal.txt, templates/nether.txt, and templates/skylands.txt, respectively.
In 0.20, the names of the templates chosen can be modified by using the deftemplatesuffix setting in configuration.txt. If defined, the name of the template used for a world with a given environment will have a hyphen followed by the value of the deftemplatesuffix setting added: so, setting deftemplatesuffix to hires causes the template normal-hires to be used for normal worlds, nether-hires to be used for nether worlds, and skylands-hires to be used for skylands worlds. This allows dynmap (and other users) to supply matched "sets" of templates, with a common suffix, that can be easily selected using the deftemplatesuffix setting. In 0.20, 3 sets of templates are provided:
the default (normal,nether,skylands)
lowres template set (normal-lowres, nether-lowres, skylands-lowres - which provide HD maps with the 'lowres' resolution - about 2x the default maps)
hires template set (normal-hires, nether-hires, skylands-hires - which provide HD surface maps with the 'hires' resolution - about 8x the default maps - and 'lowres' versions of the flat and cave maps)
In all cases, the template definition can be found in the file under the templates/ directory with the corresponding name, plus .txt (e.g. normal-hires is found in templates/normal-hires.txt).
Worlds
Next to the templates we also have a worlds section in the configuration. As of 0.20, the preferred location for this section is the worlds.txt file. Here we can specify options for each individual world. We'll describe the uses by examples.
Basically each world has a few default values. title is set to the name of the world, template is set to the environment of the world (with a hyphen and the value of the deftemplatesuffix appended, if deftemplatesuffix is defined in configuration.txt) and enabled is by default true (the meaning of these values are explained below). The template of the world can override these values, but the properties in the world-section can in turn override the values of the template.
If you have 3 worlds with the names world, nether and alternative, and you want to show them in a particular order, you can put the following in your configuration:
worlds:
- name: world - name: alternative - name: nether
So that they are ordered like world, alternative, nether.
To change the title of a certain world that is shown on the map, you can add a title property for that world:
worlds:
- name: world title: "My Super Awesome World" - name: alternative - name: nether
Of course you can do this for all your worlds.
If you want to disable a certain world, for example the world alternative, you can do so by adding the property enable: false:
worlds:
- name: world title: "My Super Awesome World" - name: alternative enabled: false - name: nether
You can also use this property in your templates to (for example) disable all worlds of a certain environment.
If you want to change some of the properties for one specific world, you can do so specifying that property. This includes the maps: property, so you can specify the maps for a specific world:
- name: world
title: "My Super Awesome World"
center:
x: 100
y: 64
z: 0
maps:
- class: org.dynmap.flat.FlatMap
name: flat
title: "Flat"
prefix: flat
colorscheme: default
This will, for this particular world, set the center of the world to (100,64,0) and shows only flatmap in the sidebar.
Finally if you have multiple worlds that have the same configuration in common, you can add a template to the templates: section (or, better yet, as a custom template file under the templates/ directory) and specify for those worlds in particular the name of that template.
templates:
mycustomtemplate:
enabled: true
maps:
- class: org.dynmap.flat.FlatMap
name: flat
title: "Flat"
prefix: flat
colorscheme: ovocean
... worlds:
- name: world template: mycustomtemplate - name: nether template: mycustomtemplate - name: alternative
Here world and nether both use the mycustomtemplate template, but alternative will still use the normal template (since alternative has an normal environment in this example).
As you can see above, for each FlatMap or KzedMap map, a certain colorscheme can be set. The colorschemes can be found in plugins/dynmap/colorschemes/, as seen here https://github.com/webbukkit/dynmap/tree/recommended/colorschemes. An overview of how these look like can be found here Color Schemes.
As of 0.20, a new type of map definition has been provided - the HDMap. This map type, besides supporting higher resolution map rendering and use of texture packs, also supports all existing FlatMap and KzedMap features, but with more flexibility (allowing customized direction of view, angle of view, scale, etc). For details on configuring HDMaps, see HD Map Configuration.
基础补丁设置
These settings are the top-level settings defined within the configuration.txt file. These settings, in general, cover the common behaviors of the plugin, independent of specific components, worlds, or maps. For component settings, see Component Configuration.
The core settings defined include the following:
- deftemplatesuffix : this optional setting, a string value, is used to modify the names of the templates associated with worlds. If undefined, normal worlds use the normal template, nether worlds use the nether template, and 'the end" worlds use the the_end template. When defined and non-blank, the name of the template used will be the default name, followed by and underscore, followed by the value of the deftemplatesuffix setting (e.g. if deftemplatesuffix is set to XXX, normal worlds will use the template normal_XXX instead of normal, nether worlds will use nether_XXX, ans 'the end' will use the_end_XXX). See HD Map Configuration for more details. Default template sets are included for vlowres, lowres, hires, and "" (blank).
- display-whitelist : if false (default), users are assumed to be visible until they've specifically been set to hidden using the /dynmap hide command. If true, users are assumed to be hidden until they've specifically been set to visible using the /dynmap show command.
- renderinterval : this setting, a floating point value in seconds, is used to control how often tiles needing to be updated (due to changes by players, for example) are processed. Setting this too low can cause extra load on the server, due to recalculation of repeatedly updated tiles. Default is 0.5 seconds. Most servers will perform without issue down to 0.2 seconds.
- renderacceleratethreshold : this setting, an integer, defines the size of the tile update queue allowed before the rate that tiles are processed shifts from the rate in renderinterval to the rate in renderaccelerateinterval. This is intended to prevent large tile backlogs from accumulating (which can happen when players are causing large amounts of new map territory to be generated) without requiring routine updates to be processed at a quick pace.
- renderaccelerateinterval : this setting, a floating point value in seconds, is used as the renderinterval value when the length of the tile update queue exceeds renderacceleratethreshold tiles in length.
- tiles-rendered-at-once : this setting controls the maximum number of update tiles that will be rendered concurrently. If not defined, the value defaults to 1/2 the number of processor cores. Settting this to lower values can reduce peek CPU use when large tile update load occur (from newly generated chunks, for example).
- usenormalthreadpriority : this setting, when set to true, causes the render threads to run with normal priority (versus minimum priority). This can help render performance on busy Windows boxes (preventing rendering from starving on busy boxes), but may result in competition for CPU with other processes. Most Linux JVMs ignore priority.
- zoomoutperiod : this setting, an integer value in seconds, specifies how often update processing of zoomed-out tiles is done. This done to prevent unneeded regeneration of the tiles due to repeated changes by players (such as when mining). Default value is 60 seconds.
- enabletilehash : this setting, a boolean, is used to enable the use of tile content hash codes, which are used to avoid re-encoding tiles that have not changed in value after re-rendering (such as due to changes in blocks that are not visible on the tile). This reduces processing load, zoom-out processing, and communications traffic with web clients.
- render-triggers : this setting, a list of strings, is used to enable various mechanisms for detecting the need to generate or update map tiles. The defined triggers are as follows:
- chunkloaded : this trigger causes tiles to be updated based on the loading of map chunks. This trigger is no longer recommended - use chunkgenerated instead, as chunkloaded can cause significant and unnecessary tile recalculation. Retired in v0.31.
- playermove : this trigger causes tiles to be updated based on the movement of players. This trigger is not recommended, as it will cause significant and unneeded tile recalculation.
- playerjoin : this trigger causes tiles to be updated around the position where a player logs in.
- blockplaced : this trigger causes tiles to be updated when a player places a block (recommended).
- blockbreak : this trigger causes tiles to be updated when a player breaks a block (recommended).
- leavesdecay : this trigger causes tiles to be updated when leaves decay due to the cutting of a tree (recommended)
- blockburn : this trigger causes tiles to be updated when a block is destroyed by fire (recommended)
- blockfaded : this trigger causes tiles to be updated when a block has faded (such as melted snow or ice) (recommended)
- blockspread : this trigger causes tiles to be updated when a block has spread (lava or water) (recommended)
- chunkgenerated : this trigger causes tiles to be updated when new map chunks are generated (recommended)
- pistonmoved : this trigger causes tiles to be updated when pistons extend or retract (recommended)
- explosion : this trigger causes tiles to be updated when blocks are destroyed by an explosion (recommended)
- blockfromto : this trigger causes tiles to be updated when blocks are flowing into new blocks (lova, water) (recommended)
- blockphysics : this trigger causes tiles to be updated when blocks move due to physics events (falling gravel, water, lava, sand) (recommended)
- structuregrow : this trigger causes tiles to be updated when saplings grow into trees, or mushrooms grow into giant mushrooms.
- blockgrow : this trigger causes tiles to be updated when blocks grow, such as crops and mushrooms
- blockredstone : this trigger causes tiles to be updated when redstone currents change on a block (be very careful with this if you have redstone machines that run constantly)
- webpage-title : this setting, a string, is used to specify the title for the Dynmap maps web page. If not specified, it will attempt to use the 'server-name' property from server.properties. If that is undefined or set to 'Unknown Server', the title will default to 'Minecraft Dynamic Map'.
- tilespath : this setting, a string, specifies the path (either relative to the Dynmap plugin directory, or absolute) of where map tiles are to be generated (and where they are found by the internal web server).
- webpath : this setting, a string, specifies the root path for the internal web server. All files served by the internal web server (with the exception of the map tiles) are based on this path. The path can be relative to the Dynmap plugin directory, or absolute.
- webserver-bindaddress : this setting, an IP address, controls which network interfaces the internal web server will bind to. The default, 0.0.0.0, will cause the server to bind to ALL interfaces (which should be correct for most configurations). Setting to 127.0.0.1 will cause it to bind to only the localhost (which may be appropriate if an external web server located on the same box is being used). Other values need to match the address of the interface ON THE BOX (not public addresses outside a firewall or proxy).
- webserver-port : this setting, an integer, specifies which port the internal web server binds to. This defaults for 8123. Note: many operating systems require a process to run with root privileges in order to bind to a port below 1024.
- max-sessions : this setting, an integer, sets the limit on the number of concurrent sessions that the internal web server will allow to be active (limiting the resources used by the sessions and threads associated with those sessions). Default value is 30.
- http-response-headers : this setting, a set of attribute/value pairs, provides a way to have the internal web server include custom header values in all HTTP responses. The values under the attribute are formatted with the header field ID as the attribute ID, and the value of the header field as the string value of the attribute. For example:
- http-response-headers:
Access-Control-Allow-Origin: "http://mydomain.com" X-Another-Header: "Another Header Value"
- disable-webserver : if set to true, the internal web server is disabled (this requires using an external web server, and the JSONFileClientUpdateComponent). Other configuration options require this setting to be false.
- allow-symlinks : if set to true, the directories under webpath or tilespath are allowed to contain symbolic links. If false, the internal web server will not follow symbolic links (this is a recommended practice that is followed by nearly all external web servers).
- timesliceinterval : this setting, a floating point in seconds, specifies a minimum time period between tile processing during /dynmap fullrender processing. Default value is 0.0 (no delay). Non-zero values can be used to reduce server load during full-renders, but will significantly lengthen processing time.
- maxchunkspertick : this setting, an integer, limits the number of map chunks loaded during a given server tick (50ms). As loading of map chunks is the main source of load on the Bukkit server's main thread, this can be used to limit any lag that may be resulting from map processing.
- progressloginterval : this setting, an integer, is the interval used for reporting progress on fullrender requests. The default (and minimum) value is 100.
- parallelrendercnt : this setting, an integer, is optional, and can be used to allow full-render processing to be done by more than one thread. The setting indicates the number of concurrent threads that will be used, and should be limited to the number of physical cores on the server (or less). Note: setting this will result in much more intensive CPU use, some additional memory use. Caution should be used when setting this to equal or exceed the number of physical cores on the system.
- updaterate : this setting, an integer in milliseconds, specifies how often the web clients should poll the server for updates (whether it be tile updates, chat messages, or player position updates). Setting this to a higher value can reduce web server traffic.
- fullrenderplayerlimit : this optional setting defines an option for suspending fullrender/radiusrender processing when the number of active player logins reach or exceed a given limit. Default is 0 (disabled), while a setting of 1 will result in fullrender/radiusrender processing being suspended while any players are logged in.
- showplayerfacesinmenu : this setting, a boolean, is used to control whether to show online players in the tray meny on the web clients. Default is to show the players (true).
- sidebaropened : this setting, a string, is used to optionally pin the sidebar menu permanently open ('true'), pinned by default ('pinned') or closed by default ('false'). Default is false.
- joinmessage : this setting, a string, is used to control the message reported in web chat when a player logs in to the server. The substitution macro, %playername%, is used to provide the player's name.
- quitmessage : this setting, a string, is used to control the message reported in web chat when a player logs off ofthe server. The substitution macro, %playername%, is used to provide the player's name.
- spammessage : this setting, a string, is used to control the message reported to web chat users that attempt to send messages too often.
- webprefix : this setting, a string, is used to provide a prefix for chat messages received from web clients. The escape sequence '&color;' can be used in place of the Bukkit color escape sequence.
- websuffix : this setting, a string, is used to provide a suffix for chat messages received from web clients. The escape sequence '&color;' can be used in place of the Bukkit color escape sequence.
- showlayercontrol : this setting, a boolean, is used to control whether the layer control is shown (setting this to false will cause it to not be shown, even if marker layers are defined). Default is true.
- check-banned-ips : this setting, a boolean, is used to control whether the internal web server checks the banned-ips.txt file to block access to the web client by banned IP addresses.
- persist-ids-by-ip : if true, player IP addresses and the associated player IDs are persistent, and will be saved on server shutdown and reloaded on server startup (allowing known IP address to player ID associations to accumulate). Default is true (0.29 or later).
- defaultzoom : this setting, an integer, specifies the default zoom level for the web client when it is first loaded by a user.
- defaultworld : this setting, a string, specifies the name of the default world for the web client when it is first loaded by a user.
- defaultmap : this setting, a string, specifies the name of the default map for the web client when it is first loaded by a user.
- followzoom : this optional setting, an integer, specifies the default zoom level for the web client when a player is selected to be followed.
- followmap : this ootional setting, a stirng, specifies the name of the default map for the web client to switch to, if needed, when a player is selected to be followed
- verbose : this setting, a boolean, controls how verbose the messages are for the Dynmap plugin during startup. Setting to false will significantly reduce reported messages and details.
- hideores : this setting, a boolean, controls the option to hide any ore blocks, making them appear the same as solid stone (preventing maps from being used to find exposed ores). Default is false.
- better-grass : this setting, a boolean, controls the option to render the sides of grass and snow blocks as they are done with the BetterGrass client mod (if set to true). Default is false.
- smooth-lighting : this setting, a boolean, provides the default setting for the smooth lighting option on all maps supporting the feature. Setting it to 'true' is a convenient way to enable smooth lighting on all maps that can use it. The setting is also defined on a per-shader basis, which can be used to control the feature on an individual map level. Enabling this feature will add approximately 10% to rendering processing cost.
- use-generated-textures: this setting, if defined and set to 'true', will cause texturepack based HD map renders to use generated textures for water, lava, and fire equivalent to those used by the Minecraft client. If false, the legacy textures in the texture.png and misc/water.png are used (pre-0.29 behavior). Setting this will require a full map render to see the proper results.
- correct-water-lighting: this setting, if defined and set to 'true', will cause texturepack based HD map renders to process lighting of water equivalently to the Minecraft client. If false, the legacy behavior - which results in darker water - is used (pre-0.29 behavior). Setting this will require a full map render to see the proper results.
- fetchskins : this setting, a boolean, controls whether the server will attempt to fetch skins for players during login. If set to false, no skins are fetched, and the default skin is assumed for all players. Default is true.
- refreshskins : this setting, a boolean, controls whether faces and other images derived from a player's skin are refreshed each login. If set to false, existing files are never refreshed (which can be useful if faces are locally managed or updated by the server administrator or another plugin). Default is true.
User Login Security Settings for Web Interface
The support for login-based security on the web interface can be controlled through the following settings:
- login-enabled : this setting, a boolean, enables login security support (if the setting is defined and set to 'true').
- login-required : this setting, a boolean, forces all web users to log in, in order to access the web interface (if the setting is defined and set to 'true').
部件配置
The interface for Dynmap is defined via a set of components. Not all components can be enabled at once, and some are required. Details on the defined compnents, and their attributes, are in the following sections.
Core Client Components
The following components defined the core of the client's interface with the Dynmap server. The Client Configuration Component, and at least one of the Client Update Components is required for any client functionality.
Client Configuration Component
This component is defined by the following lines in the components section:
- class: org.dynmap.ClientConfigurationComponent
This component is required, and has no settings.
Internal Client Update Component
This component defines the primary interface for the web client via Dynmap's internal web server (which must be enabled for this component to function). It defines URLs for the client to use under the http://address:port/up/ path, including both fetching configuration data, and fetching map updates, player status and chat messages. The component is configured via the following lines in the components section:
- class: org.dynmap.InternalClientUpdateComponent sendhealth: true sendposition: true allowwebchat: true webchat-interval: 5 hidewebchatip: false trustclientname: false use-player-login-ip: true require-player-login-ip: false block-banned-player-chat: true webchat-requires-login: false webchat-permissions: false includehiddenplayers: false hideifshadow: 15 hideifundercover: 15 hideifsneaking: false protected-player-info: false
The settings are defined as follows:
- sendhealth : this controls whether or not the health data for players is reported to the web client. If it is disabled, other components that report player health will not have the needed data to do so, but player health information is also safe from being inspected. If enabled, health information may still be hidden for players located on specific worlds via the sendhealth: false setting on those worlds.
- sendpostiion : this controls whether or not the position data for players is reported to the web client. If it is disabled, other components that report position will not have the needed data to do so, but player position information is also safe from being inspected. If enabled, position information may still be hidden for players located on specific worlds via the sendposition: false setting on those worlds.
- allowwebchat : this setting controls whether or not the interface to allow chat messages to be sent from the web client to the server is enabled. If false, no web messages may be sent from the client.
- webchat-interval : this controls the minimum period, in seconds, between consecutive chat messages from a given web client.
- hidewebchatip : if set to true, this causes web chat messages to be reported via generic names versus the IP address of the sender.
- trustclientname : if set to true, this causes the hostname/IP reported by the web client (which may be falsified) to be reported as the sender's address (versus using the address seen by the web server).
- use-player-login-ip : if set to true, web chat messages will be matched with current or previous player IDs having connected from the same IP address - if a match is found, the most recent player ID is used to identify the sender of the web chat message. Default is true (0.29 or later)
- require-player-login-ip : if use-player-login-ip is true, and this setting is true, web chat messages not matching a current or previous player connection address will be ignored. Default is false (0.29 or later).
- block-banned-player-chat : if use-player-login-ip is true, and this setting is true, web chat messages that match a previous player address of a currently banned player will be ignored. Default is true (0.29 or later). Note: does not work with plugins that implement their own ban independent of Bukkit/Minecraft's ban (currently, this is true of CommandBook).
- webchat-requires-login : if login-enabled is true, and this setting is trye, web chat messages can only be sent from web users that have successfully logged in.
- webchat-permissions : if defined and set to 'true', web chat requests tied to players (via login or ID-by-IP) will be checked for the dynmap.webchat permission, with those not possessing the permission being denied the right to send. This requires a permission system that supports reading permissions for offline players - currently PermissionsEx and bPermissions - in order to work for web users that are not currently logged in using the Minecraft client, as well.
- includehiddenplayers : if set to true, players that are hidden (via the /dynmap hide command) will be reported to the UI as online, but with their position, health, and messages still hidden. They will appear in the player list.
- hideifshadow : if set to a value below 15, each player's position and health are hidden if the light level of the current location of the player is at or below the given value (0=total darkness, 4=under sky at night, 15=full daylight).
- hideifundercover : if set to a value below 15, each player's position and health are hidden if the current position of the player is under cover. Due to a current Bukkit limitation (pending acceptance of a pull request we issued), any block will obstruct the view of the player (once updated, this will shift to be based on the relative shadow level of the location - corresponding to how much the location would be in shadow during full daylight).
- hideifsneaking : if set to true, players that are sneaking will be hidden.
- protected-player-info : if set to true, access to player position and health information is protected. Players without the dynmap.playermarkers.seeall permission (operators have this by default) will only see their own player marker, while those with the permission will see all player positions. If this setting is not provided, or is false, all player position and health information is available to all map viewers.
JSON File Client Update Component
The alternative to using the internal web server is for all communications between Dynmap and the web client to be done via files served through an external web server. As this is done with files formatted using JSON (JavaScript Object Notation), this mode of operation is often referred to as "JSON File Mode". This mode allows the internal web server to be disabled, and is the alternative to using the Internal Client Update Component (only one of them may be enabled at a time). The component is defined by the following lines in the components section:
- class: org.dynmap.JsonFileClientUpdateComponent writeinterval: 1 sendhealth: true sendposition: true allowwebchat: false webchat-interval: 5 hidewebchatip: false trustclientname: false use-player-login-ip: true require-player-login-ip: false block-banned-player-chat: true webchat-requires-login: false webchat-permissions: false includehiddenplayers: false hideifshadow: 15 hideifundercover: 15 hideifsneaking: false protected-player-info: false
The definitions of the attributes are the same as the corresponding attributes in the Internal Client Update Component. The additional attributes are as follows:
- writeinterval : this is the period, in seconds, used by the component for writing updated configuration and map update files to the webpath/standalone directory. These are the files loaded by the web client via the external web server to receive the map configuration, as well as notifications of map updates, player position and health data, and chat messages.
Markers Component
This component, added in v0.22, provides built-in support for map markers, both through the /dmarker commands and through an API published for use by other plugins. The component is configured via the following lines in the components section:
- class: org.dynmap.MarkersComponent type: markers showlabel: false enablesigns: false showspawn: false spawnicon: world spawnlabel: "Spawn" showofflineplayers: false offlinelabel: "Offline" offlineicon: offlineuser offlinehidebydefault: true offlineminzoom: 0 maxofflinetime: 30 showspawnbeds: false spawnbedlabel: "Spawn Beds" spawnbedicon: "bed" spawnbedhidebydefault: true spawnbedminzoom: 0 spawnbedformat: "%name%'s bed"
The settings for the component include the following:
showlabel : if defined and set to true, this causes the labels for map markers to be shown all the time, versus only being shown when the user's mouse is hovering over the icon.
enablesigns : If defined and set to true, this enables support for defining markers using signs. If enabled, and if the player has the dynmap.marker.sign privilege, a player can make a marker by creating a sign with '[dynmap]' as the first line, with the label being derived from the first non-blank line after that (that is not a setting). The icon will be the 'sign' icon, unless one of the lines is 'icon:'. The marker set for the marker will be the default 'markers' set, unless one of the lines is 'set:'. Once accepted, the '[dynmap]' line and any settings lines will be blanked, leaving the sign with the label line and any remaining lines. Destroying the sign will delete the corresponding marker.
showspawn : if defined and set to true, this causes the spawn points of each world to be shown with an appropriate marker (the default being the 'world' marker) and label (the default being "Spawn").
spawnicon : if defined, provides the ID of the icon to use for the spawn points (if showspawn is true). Default is 'world'.
spawnlabel : if defined, provides the label for the spawn point markers (if showspawn is true). Default is "Spawn".
showofflineplayers : if defined and set to true, a marker layer is defined to show the positions of offline players (markers will be added as players log off).
offlinelabel : Label used for the offline player marker layer - default is 'Offline'
offlineicon : Name of the marker icon used for offline players - default is 'offlineuser'
offlinehidebydefault : if defined and set true, offline marker layer is hidden by default. Default is 'true'.
offlineminzoom : if set to non-zero, this specifies the minimum zoom in level before offline player markers are displayed.
maxofflinetime : if set above zero, this specifies the number of minutes after a player logs off before their offline icon should be removed (<= 0 means never). All offline player markers are reset on a server restart, independent of this setting.
showspawnbeds : If defined and set to true, a marker layer is defined to show the positions of the online players' spawn beds (markers will be removed when players log off).
spawnbedlabel : Label for player spawn bed marker layer, if enabled. Default is "Spawn Beds".
spawnbedicon : Icon to use for any spawn bed markers. Default is 'bed' marker.
spawnbedhidebydefault : If true, spawn bed marker layer will be hidden, by default.
spawnbedminzoom : If set to non-zero, this specifies the minimum zoom in level before spawn bed markers are displayed.
Server-Side Chat Components
These components control the server-side implementation of chat, including the sending of chat messages from the server to the client, as well as particulars of how chat messages from the client to the server are delivered to players on the server. Only one of these components should be defined at a time.
Simple Chat Component
This component implements access to the standard Bukkit/Minecraft server's chat channel. When active, all chat messages are shared with the web client, and all messages received from the web client are sent to all players on the server (as well as all other web clients). This component is configured via the following lines in the components section:
- class: org.dynmap.SimpleWebChatComponent allowchat: true
The settings for the component include:
allowchat : if enabled, this setting determines if chat messages on the server are to be sent to the web clients. If set to 'false', no chat messages are sent to the web clients.
HeroChat Chat Component (Deprecated - not functional with HeroChat 5)
The HeroChat plugin implements channels and other behaviors that require special treatment. This component interfaces with HeroChat, and allows the selection of which HeroChat channels have their messages reported to the web clients, and which channel messages from the web clients are reported on. This component is configured via the following lines in the components section:
- class: org.dynmap.herochat.HeroWebChatComponent
herochatwebchannel: Global
herochatchannels:
- Global
The settings for the component are as follows:
herochatwebchannel : this is the name of the HeroChat channel that will be used for any chat messages received from the web clients. Default value is 'Global'
herochatchannels : this is the list of HeroChat channel names that will be monitored for chat messages, which will then be shared with the web clients. Zero or more channels may be listed. The default is a single channel list containing 'Global'.
Client-Side Chat Components
These components control the behavior and availability of the components of the web client used to support sending and receiving of chat messages. These components depend upon the corresponding server-side components being enabled and allowing the requested functions. The components can be defined individually or in any combination.
Chat Client Component
This component enables the input field for chat messages, allowing the users to enter and send chat messages to the server from the web client. It is defined by the following lines:
- class: org.dynmap.ClientComponent type: chat allowurlname: false
The component supports the following settings:
allowurlname : if true (and if trustclientname is true in the corresponding ClientUpdateComponent), the user of the web console can supply a chat name using the chatname URL parameter.
Chat Balloon Client Component
This component implements support for pop-up balloon messages, with the balloon being placed above the location of the sending player on the map, if any. The component is defined via the following lines in the components section:
- class: org.dynmap.ClientComponent type: chatballoon focuschatballoons: false
The component supports the following settings:
focuschatballoons : if enabled, this causes the map to pan to the chat balloon, if it is not currently visible on the map. Note that placement of the word balloons requires that the position data for the speaking player is known, which may not be the case if sendposition: false has been set for the player's current world, or globally via the active Client Update Component.
Chat Box Client Component
This implements the box for viewing chat messages received from players on the server, as well as from other web clients. The component is defined via the following lines in the components section:
- class: org.dynmap.ClientComponent type: chatbox showplayerfaces: true messagettl: 5 scrollback: 100 sendbutton: false
The settings for this component are as follows:
showplayerfaces : if enabled, the face icons for the player that sent a given chat message will be shown next to the message.
messagettl : this controls the number of seconds that a received chat message is shown on the screen before fading. If scrollback is defined, this setting is ignored.
scrollback : if defined, this specifies the number of messages to keep in the scrollable message list. If specified, messages will not age out (messagettl is ignored) and will only be dropped as the number of messages exceeds the scrollback count.
sendbutton : if defined and set to true, this causes a send button to appear on the web UI, allowing messages to be sent without requiring the pressing of the return key.
Map Controls Components
These define additional map content, such as player markers, clocks, logos, etc. Any set of these components can be defined.
Player Markers Component
This component is used to show player positions and names as markers on the displayed map. The player's position can only be shown if it is available (see the sendposition setting, above). The component is defined by the following lines in the components section:
- class: org.dynmap.ClientComponent type: playermarkers showplayerfaces: true showplayerhealth: true showplayerbody: false smallplayerfaces: false hidebydefault: false layerprio: 0 label: "Players"
The settings for the component include the following:
- showplayerfaces : if enabled, this causes the client to attempt to load the custom skin for the player (if any) and to show the face portion of that skin as the icon for the player. Otherwise, a small generic marker is shown instead.
- showplayerhealth : if enabled, the client will attempt to show health and armor attributes for the player, as two rows of small icons below the player's name. This requires that the player's health information be available (see sendhealth, above).
- smallplayerfaces : if enabled, player faces are shown (assuming showplayerfaces is true), but at 1/2 the normal size (equivalent to the small generic markers used when showplayerfaces is false).
- showplayerbody : if enabled, whole body icons will be show instead of just faces. Only applicable if showplayerfaces is true and smallplayerfaces is false.
- hidebydefault : this optional parameter, if defined and set to true, changes the default visibility state for the map layer with the player markers to be hidden. The layer can still be made visible with the layer control on the web client UI.
- layerprio : this optional parameter provides an ordering weight for the layer in the layer selection control, which orders from lowest to highest layerprio (and then alphabetically for equal priority layers). Default is 0.
- label : this optional parameter provides the label used for the layer selection control for this layer set. Default is 'Players'.
Digital Clock Component
This is used to display a simple digital clock, corresponding to the time on the world being displayed. The component is defined by the following lines in the components section:
- class: org.dynmap.ClientComponent type: digitalclock
Only one clock component can be enabled at a time.
Time Of Day Clock Component
This is a more sophisticated clock component, showing day and night via sun and moon icons that rise and set to match the time in the world being shown. The component is defined via the following lines in the components section:
- class: org.dynmap.ClientComponent type: timeofdayclock showdigitalclock: true showweather: true
The settings for the component include the following:
- showdigitalclock : if enabled, the digital clock is displayed (in addition to the sun and moon display)
- showweather : if enabled, an icon is shown to indicate weather (rain, thunder) on the world being shown by the map.
Coord Component
This component is used to show the world coordinates corresponding to the position of the mouse pointer. The component is defined via the following lines in the components section:
- class: org.dynmap.ClientComponent
type: coord
label: "Location"
hidey: false
show-mcr: false
The settings for the component are as follows:
label : this allows control of the label used on the control presenting the coordiates. Default is 'x,y,z'.
hidey : this option, if defined and set to true, makes the coordinate control only show X,Z coordinates.
show-mcr : this option, if defined and set to true, causes the display of the Mincraft Region file ID for the current location.
Logo Component
This component is used to allow an optional logo and link to be shown on the map. The component is defined via the following lines in the components section:
- class: org.dynmap.ClientComponent
type: logo
text: "Dynmap"
linkurl: "http://forums.bukkit.org/threads/dynmap.489/"
The settings for the component are as follows:
- text : the label shown for the logo
- linkurl : the URL associated with the link tied to the displayed label
Link Component
This component is used to provide a 'link to' button on the web UI. This button, when clicked, will navigate the view to a URL with all the needed settings to preserve the world, map, zoom, and coordinates of the current view - allowing a view to be shared, bookmarked, or otherwise linked. The component is defined via the following lines in the components section:
- class: org.dynmap.ClientComponent
type: link
There are no settings currently defined.
世界及模板设置
There are an extensive set of configurable settings for controlling the map and interface definitions for the worlds on a user's server. Nearly all of these settings are also settable on templates - which is appropriate, since templates are essentially a collection of settings used to define any settings not defined for the worlds that use them.
Logically, any defined world will have a default set of settings, derived from the template that is associated with its environment type (normal, nether, skylands) - the settings are inherited from the template of the same name as the environment, by default. If the deftemplatesuffix is defined, the name of the template inherited from is modified by appending a hyphen ('-') and the value of the setting. So, setting deftemplatesuffix to hires causes the template automatically used by a normal world to be normal-hires, and for nether worlds to be nether-hires.
Beyond the values inherited from the template, settings for a given world can always be provided by defining a section for the world in the worlds: section (in worlds.txt, or in configuration.txt). When a section exists for a given world, any setting provided there will override any corresponding setting inherited from the world's template.
With the exception of the world's name and maps, all other world settings are optional and have defined defaults, and the maps are typically provided through templates. Consequently, a world definition under the worlds: section can consist of nothing but the world's name:
worlds:
- name: world1 - name: world2
This can be used to control the order of the worlds, as defined worlds are always listed in their order of definition, and automatically selected worlds are listed after those.
An example of a more comprehensive set of world settings are shown below:
worlds:
- name: world
title: "My Great World"
enabled: true
template: mycustomtemplate
sendposition: true
sendhealth: true
fullrenderlocations:
- x: 100
y: 64
z: 2000
visibilitylimits:
- x0: -1000
z0: -1000
x1: 1000
z1: 1000
hiddenlimits:
- x0: 100
z0: 0
x1: 200
z1: 0
hidestyle: stone
center:
x: 0
y: 64
z: 0
bigworld: false
extrazoomout: 0
maps:
- class: org.dynmap.flat.FlatMap
....
The available settings are defined as follows:
- name : this defines the name of the world within Bukkit, and must be unique. This can not be inherited from a template.
- title : if defined, this string is used as a human-friendly label for the world. The default value is blank.
- enabled : if defined, this allows mapping for a given world to be enabled (by setting true) or disabled (by setting false). All worlds are enabled by default, so defining a worlds entry for a world and setting enabled to false is the only way to prevent a world from being displayed and mapped.
- template : if defined, this overrides the name of the template used to provide the default settings for the world. If not set, the default is based on the world's environment (normal, nether, or skylands), with a '-' and the deftemplatesuffix value added if deftemplatesuffix is defined. This value cannot be inherited from a template.
- sendposition : if defined and set to false, this allows the option to have the position information for any players located on this world to be hidden on the UI, even if such information is enabled otherwise. Setting this attribute to true will NOT cause player information to be displayed if the global sendposition setting is false. If not defined, this setting defaults to true.
- sendhealth : if defined and set to false, this allows the option to have the armor and health information for any players located on this world to be hidden on the UI, even if such information is enabled otherwise. Setting this attribute to true will NOT cause player information to be displayed if the global sendhealth setting is false. If not defined, this setting defaults to true.
- fullrenderlocations : if defined, this list of world coordinates (each consisting of an x, y, and z coordinate) defines a set of additional locations (beyond x=0, y=64, z=0, or the player's current location, if a /dynmap fullrender command is issued by an in-game player) to be used to seed a full-render. Logically, fullrender is implemented like a flood fill in a paint program - if a map has gaps in its areas of defined chunks, such as can happen if maps are explored via teleporting or portals, a fullrender seeded from one point may not reach all the patches of the world that have been generated: adding example locations within the other patches to the fullrenderlocations list will cause those patches to be rendered, as well.
- visibilitylimits : if defined, this list of rectangles can be used to restrict the area of the world to be rendered: areas outside of these rectangles will not be rendered with accurate map data, but instead some form of filler will be used (depending on the hidestyle setting, below). If the list is empty (the default), no limits are implemented, and maps will be rendered to the edge of the generated chunks for the world. Each rectangle consists of two coordinate pairs - x0, z0, and x1, z1. As of 1.5-alpha-3, circular areas can also be defined, by providing an x, z value for the center and a r value for the radius, in blocks.
- hiddenlimits : if defined, this list of rectangles that are the opposite of 'visibilitylimits' - they define specific areas of the world to be hidden (rendered based on the hidestyle setting, below). If both 'visibilitylimits' and 'hiddenlimits' are defined, the 'visibilitylimits' are applied first (determining which areas are visible), and then the 'hiddenlimits' are used to further restrict that. Each rectangle consists of two coordinate pairs - x0, z0, and x1, z1. As of 1.5-alpha-3, circular areas can also be defined, by providing an x, z value for the center and a r value for the radius, in blocks.
- hidestyle : If the visibilitylimits and/or hiddenlimits settings have restricted the visible areas of a world, the hidestyle setting is used to control how the chunks of map data being hidden are presented. 3 settings are supported: stone, which causes a stone plain to fill the hidden areas; ocean, which causes a deep ocean to fill the hidden areas; or air, which causes the hidden area to be empty (like the edge of the generated portion of the world map). The default value is stone.
- center : If defined, this provides the default center-of-focus for the view of the maps of this world. The coordinate includes the x, y and z coordinate of the center point, in world coordinates. If not defined, the center defaults to the spawn point for the given world.
- bigworld : If defined, this enables the use by the FlatMap and KzedMap map types of an alternate file system structure, better suited to use by large worlds that may have tens or even hundreds of thousands of tiles. HDMaps always use this format, and are not affected by this settings. The default value is false, while a value of true enables the alternate layout. If the setting is changed, a /dynmap fullrender will be needed to initialize the new layout.
- extrazoomout : If defined, this specifies how many additional levels of zoom out the maps for this world should have, beyond their default. This results in both offering more levels of zoom on the map viewer, and in additional levels of map tiles being generated (based on the original tiles generated for the maps): each level is 2 x 2 the scale of the previous level, so 4 tiles on one level become 1 tile with less resolution on the next. Enabling this setting, by setting the value to an integer above 0, will add from 25% to 33% to the number of tile files, and total disk space used, by the maps for the given world, but will allow easier navigation of mid-sized to large worlds. The default value is 0 (no extra zoom out).
- maps : if defined, the maps section provides all the definitions for the maps to be rendered for the world, in the order that they are presented on the map viewer. If defined in a world's section in worlds:, any map definitions provided by the world's template are replaced. For details on map definition, see Map Configuration and HD Map Configuration.
高清地图配置
With their introduction in v0.20, the HDMap map type provides a new, more flexible, and (arguably) more complex means of defining and customizing the maps a user can make available on their server. Several details on how HDMaps are defined and structured are intended to offset the additional complexity - but it is important to understand the basic "theory of operations" behind an HDMap definition, in order to know what you need to do to get what you want out of your maps (and not have to work any harder than necessary to get it).
Getting Started Quickly: Enabling the default HD templates
- Dynmap includes 3 sets of templates, each providing map definitions for the various types of worlds (normal, nether, and the_end). To select between the three template sets, edit the configuration.txt file, and change the setting of the deftemplatesuffix setting (found near the top of the default configuration.txt file). The currently defined values for this setting include:
- deftemplatesuffix: "" : This causes dynmap to use the 'classic' default templates - these are low resolution and very quick to render, but are far from the most attractive maps. The template files used for this mode are templates/normal.txt, templates/nether.txt, and templates/the_end.txt. This was the default for 0.23 and earlier.
- deftemplatesuffix: vlowres : this selects the "very-low-res" HD maps. These maps are similar to the 'classic' defaults (a surface map, an isometric view from the south-east, and a cave map), but they are rendered using the HD renderer. Also, by default the standard Minecraft texture pack will be used to color the blocks, yielding a much more accurate representation of the map. The template files used for this mode are in templates/normal-vlowres.txt, templates/nether-vlowres.txt, and templates/the_end-vlowres.txt. As of 0.24, these are the default templates.
- deftemplatesuffix: lowres : this selects the "low-res" HD maps. These maps are similar to the 'classic' defaults (a surface map, an isometric view from the south-east, and a cave map), but they are rendered using the HD renderer with about 2-3x the resolution of the "classic" maps. Also, by default the standard Minecraft texture pack will be used to color the blocks, yielding a much more accurate representation of the map. Rendering these maps will take 4-6 times as long as the default 'classic' maps, and about 4x the disk space. The template files used for this mode are in templates/normal-lowres.txt, templates/nether-lowres.txt, and templates/the_end-lowres.txt.
- deftemplatesuffix: hires : this selects the "high-res" HD maps. These maps are the same as the lowres HD maps, except that the surface map (the isometric map) is much higher resolution (4x higher than on lowres, about 8x higher than classic), and rendered from a lower view angle (30 degrees from horizontal versus 60 degrees). The resulting view is VERY nice, but will take quite some time to render (approximately 16x the render time of the lowres map, and about 64x that of the classic map), and much more space (about 16x that of lowres, 64x that of classic). The template files used for this mode are in templates/normal-hires.txt, templates/nether-hires.txt, and templates/the_end-hires.txt.
Once a template set has been selected, the maps can be further customized by editing the template files in use. The following sections describe all the details needed to fully control the map definitions.
The Basics: How to add an HDMap to templates or worlds
Defining an HDMap is, at the high level, the same as it is for the existing map type. As with other maps, an HDMap definition is provided under the maps: section of either a template (in either configuration.txt or one of the files in the templates/ directory) or in a world definition under the worlds: section (in either configuration.txt or the worlds.txt file). The following is a complete example of an HDMap definition:
maps:
- class: org.dynmap.hdmap.HDMap name: myhdmap title: "My HD Map" prefix: hdm1 perspective: iso_S_90_lowres shader: stdtexture lighting: default
- As with all maps, an HDMap definition needs 3 basic parameters:
- A class: setting - this identifies the general type of map: for HDMaps, this is org.dynmap.hdmap.HDMap
- A name: setting - this is a unique name for the map (unique among the other maps on a given world). This is used for identifying the map, including when selecting the map using the defaultmap setting, or in the URL parameters.
- A prefix: setting - if not provided, the name setting is used for this. This is used as part of the file and directory names used for the map - so it also needs to be unique among the other prefix values for the other maps on a given world.
Now, the settings specific to HDMaps are used to define three specific aspects of how a map is drawn:
- How do we determine what we see in the scene?
- How do we decide how to color what we see?
- What effect does lighting have on the colors we see?
With HDMaps, the answer to these three questions is determined by the next three settings:
- The perspective: setting provides the name of the perspective definition we use to show the map. The perspective controls the type of projection (currently, only an isometric projection), the direction of view into the map (both angle from North, and angle from horizontal), and the scale of the view (how many pixels per block edge).
- The shader: setting provides the name of the shader definition we use to color the map - how we decide the color of what the -perspective- shows us. This can include shaders that work with specific Minecraft Texture Packs, shaders that use the legacy colorschemes (like those used on the FlatMap and KzedMap definitions), shaders that present biome-based coloring, or shaders for cave rendering.
- The lighting: setting provides the name of the lighting definition we used to modify the colors of the map, based on lighting conditions. This can include rendering shadows, rendering night views, or both night and day views.
To simplify the configuration of these settings, Dynmap comes with a number of predefined perspectives, shaders, and lightings. These definitions can be modified, if needed, or used as examples to allow creation of new definitions specific to a user's needs.
Predefined Perspectives
There are quite a few predefined perspectives, which can be found in perspectives.txt. The names of the predefined settings follow a strict naming pattern, to make it easier to tell which setting to use:
projection _ direction _ angle _ scale
Where:
- projection is the type of viewpoint: currently, only iso (isometric) is supported.
- direction is the direction of view: each of the 8 cardinal directions are supported (N, NE, E, SE, S, SW, W, NW)
- angle is the angle from horizontal of the view: 30 (30 degrees) and 60 (60 degrees) are supported for all cardinal directions, 90 (90 degrees - top-down) is defined for N (from North), S (from South), E (from East) and W (from West) view directions.
- scale is the scale of magnification or detail of the view: vlowres corresponds to 2 pixels per block edge (similar to KzedMap resolution), lowres corresponds to 4 pixels per block edge (about 2x the KzedMap resolution), medres corresponds to 8 pixels per block edge, and hires corresponds to 16 pixels per block edge.
Full List of Predefined Perspectives
Predefined shaders
The predefined shader settings (which are found in shaders.txt) include the following:
- default : the default shader, which uses the standard Minecraft Texture Pack for coloring maps
- defaultscheme : this uses the 'default' colorscheme (as defined in colorschemes/default.txt) for coloring maps
- ovocean : this uses the 'ovocean' colorscheme (as defined in colorschemes/ovocean.txt) for coloring maps
- flames : this uses the 'flames' colorscheme (as defined in colorschemes/flames.txt) for coloring maps
- sk89q : this uses the 'sk89q' colorscheme (as defined in colorschemes/sk89q.txt) for coloring maps
- biome : this uses the biome types for coloring the maps
- temperature : this uses the biome temperature data for coloring the maps
- rainfall : this uses the biome rainfall/humidity data for coloring the maps
- no_transparency : this uses the 'default' colorscheme (as defined in colorschemes/default.txt) for coloring maps, and disables all transparency processing (water, glass, leaves are solid)
- cave : this renders the 'cave view' - showing the boundaries between non-air and air below the ground, color coded from green to blue, based on depth
- stdtexture : this uses the standard Minecraft Texture pack (in texturepack/standard/) to color the maps
- stdtexture-nobiome : this uses the standard Minecraft Texture pack (in texturepack/standard/) to color the maps, but disables biome-based shading of grass and leaves
- topo : this creates a color-coded topographical map, based on altitude : oriented around 128 high generated worlds
- topo256 : this creates a color-coded topographical map, based on altitude : scaled to 256 high worlds
- topo-noplants : this creates a color-coded topographical map, based on altitude : oriented around 128 high generated worlds, with all normal plants and trees hidden
- topo256-noplants : this creates a color-coded topographical map, based on altitude : oriented around 256 high generated worlds, with all normal plants and trees hidden
Predefined lightings
The predefined lighting configuration, which can be found in lightings.txt, include the following:
- default : this is the default: no special processing, no shadows, full daylight
- shadows : this uses full daylight, with shadow and emitted light processing enabled
- night : this uses standard moon-light, with shadow and emitted light processing enabled
- brightnight : this uses an extra bright moon-light (which makes unlit terrain more visible), with shadow and emitted light processing enabled
- nightandday : this causes two sets of tiles to be rendered, one for daytime (corresponding to the shadows settings) and one for night (corresponding to the night settings), which will be automatically presented based on what the time of day is on the corresponding world
- brightnightandday : this is the same as nightandday, except the night tile set is rendered using the same settings as brightnight.
The choice of perspective has a VERY significant impact on both the ultimate size of the map rendered, and the quality of the rendered map. Specifically, the -scale- will radically impact this: as each block on a map will be shown with more pixels, the number of tiles needed to render will go up as the -scale- goes up. lowres maps will involve about 4x as many tiles as a KzedMap (since its about 2x the resolution horizontally and vertically - 2 x 2 = 4). medres is twice the resolution, so another 4x the number of tiles (or 16x from Kzed), hires is twice the resolution again - so 64x the KzedMap tile population! -hires- maps look VERY nice, but be prepared for the initial -fullrender- of the map to take some time (hours to a day or more for larger maps). Low view angles (the 30 degree angle) results in fewer tiles that take a bit more processing to render (a low view angle means more chunks of map needed to render a given tile - as the view cuts more -across- the map than a more vertical view does). Other settings - -shader- and -lighting- have little to no impact on map size, and very small impacts on render time.
Customizing perspectives, shaders, and lightings
For details on defining custom perspectives, shaders or lightings, see the following pages:
Once a custom perspective, shader or lighting is defined, maps can use them by name, the same as any of the predefined configurations.
Additional HDMap Settings
HDMaps support a number of additional, optional settings, that allow more control of how the map is presented and used by the user. These settings include:
- title : this setting controls the presentation label on the web interface for the map.
- icon : this setting allows control of the URI of the image file used for the map icon on the web interface. If not defined, the value used is images/block_name.png.
- background : this setting provides a color value for the background on the map. Color values are formatted as typical for CSS styles: #rrggbb. If undefined, the background is black (#000000).
- backgroundday : this setting provides a color value for the background of the map during daytime - it overrides the background setting, if defined, when daytime maps are shown. Formatting is CSS style: #rrggbb. Only applicable to night-and-day type maps.
- backgroundnight : this setting provides a color value for the background of the map during nighttime - it overrides the background setting, if defined, when nighttime maps are shown. Formatting is CSS style: #rrggbb. Only applicable to night-and-day type maps.
- mapzoomin : this setting controls the number of zoom-in steps offered for the map beyond the 'native' resolution of the map. These zoom levels stretch the map without showing more map data - the same pixels are shown larger (2x bigger for one step, 4x for two steps, 8x for three steps, etc). By default, the value is 2 (allowing 2 extra zoom ins, corresponding to 2x and 4x).
- image-format : this setting controls the format of the tiles generated for the map. The default is PNG, which is a lossless compression format that maximizes quality, but can yield large files that use significant bandwidth. JPG is a lossy compression option that can trade quality for file size. At very high quality levels, JPG will still tend to be significantly smaller than PNG - 2x is common - with little loss of quality. Lower quality levels can still yield very good map quality and MUCH lower file sizes (6x-10x). The supported values are:
- png : lossless (but potentially big) PNG (this is the default)
- jpg : good quality JPG (85% quality) - same as jpg-q85
- jpg-q75 : fair quality JPG (75% quality)
- jpg-q80 : fair quality JPG (80% quality)
- jpg-q85 : good quality JPG (85% quality)
- jpg-q90 : good quality JPG (90% quality)
- jpg-q95 : very good quality JPG (95% quality)
- jpg-q100 : very good quality JPG (100% quality)
Note: As JPEG does not support transparency, the background color for the tiles is rendered into the tiles (particularly for pixels that pass through the scene to the background). If the backgroundday or backgroundnight colors are changed, all tiles will need to be rerendered. Also, if the day and night colors are not the same, a night-and-day enabled lighting option (e.g. the nightandday or brightnightandday lightings) must be used to generate the two tile sets needed (each with the corresponding night and day backgrounds).
对基于MinecraftForge的mod的支持
The following specific mods are supported, although some older versions may not function, and some blocks in current versions may not yet be supported:
- Advanced Machines for IC2
- Advanced Power Management for IC2
- Advanced Solar Panels for IC2
- BetterWorlds
- BuildCraft
- Charging Bench for IC2
- Compact Solars for IC2
- ComputerCraft
- Equivalent Exchange 2
- Ender Storage
- ExtraBees
- Extrabiomes XL (v2.x and v3.x)
- Extrabiomes - Bunyan
- Forestry (updated in 1.4)
- Forgotten Nature
- Greg's Lighting
- IndustrialCraft 2
- Iron Chest
- LC Trees++
- Millenaire
- MystCraft
- Metallurgy 2
- NetherOres
- RailCraft
- Red Power 2
- SuperSlopes
- TerraFirmaCraft
- ThaumCraft
- Thermal Expansion
- Tubestuff
- Twilight Forest
- XyCraft
基于CraftBukkit外其他服务端的支持
Dynmap不仅仅只支持CraftBukkit. 有关最新可用版本都可以在这里找到.以下有现在主要支持的三个平台:
- Bukkit Dynmap (https://github.com/webbukkit/dynmap/)
- DynmapForge (https://github.com/webbukkit/DynmapForge/)
- DynmapSpout (https://github.com/webbukkit/DynmapSpout/)
Spigot
Spigot完全支持Bukkit版Dynmap.
MinecraftForge
Various version of MinecraftForge are supported, via the DynmapForge project. As with all Forge mods, each supported version requires its own binary, and upgrading Forge to a new version will require upgrading to the appropriate version of the DynmapForge mod. In both the case of upgrades and initial installation, the following procedure used for installation:
- Download the corresponding ZIP file, appropriate for the MC version.
- Unzip the ENTIRE ZIP file, including all subdirectories, into the base directory of the server (NOT the mods directory).
- If upgrading, delete the older 'Dynmap-x.y.zip' from the 'mods' directory.
MCPC+
Current versions of MCPC+ (v1.4.7 or later) are ONLY supported via the DynmapForge mods for the corresponding Forge version. The CraftBukkit version is NOT supported. To install, follow the above procedure. In order to support compatibility with Bukkit-based mods that use the API for the Bukkit-based Dynmap, you can download and install the DynmapCBBridge mod (found here. This is a Bukkit plugin, so must be installed in the 'plugins' directory, and is ONLY supported on Forge-based servers that also provide Bukkit compatibility (MCPC+ and BukkitForge).
BukkitForge
The BukkitForge mod, which is a Forge-based mod that adds Bukkit API compatibility to a Forge server, is NOT supported by the Bukkit version of Dynmap. It IS supported via the DynmapForge deliverable, and can provide API compatibility to other Bukkit-based plugins that use the Dynmap API by installing the DynmapCBBridge plugin. Installation procedures are the same as for MCPC+, above.
Tekkit Classic
Tekkit Classic, and the older MCPC (no plus - for v1.2.5), were supported via the Bukkit version of Dynmap. These should continue to function using version of the Bukkit Dynmap that continue to support v1.2.5.
Tekkit-Lite
Tekkit-Lite is supported via DynmapForge, not Bukkit Dynmap. Follow all procedures appropriate for Forge.
Spout
The Spout server is supported in a development mode via the DynmapSpout project (the ongoing refactoring of Spout has made proper production support impractical so far). Installation on Spout is the same procedure as used for Bukkit (unzip into the plugins directory). Note: This is for Spout (the server), not SpoutPlugin (the Bukkit plugin). SpoutPlugin is supported via the Bukkit Dynmap.
Moving a Bukkit Dynmap installation to a Forge Dynmap installation
To migrate an existing Bukkit configuration to a Forge server (including MCPC+ or BukkitForge), do the following:
- Move the /plugins/dynmap directory (and all its contents and subdirectories) to /dynmap on the Forge server
- Edit configuration.txt: replace the lines for 'render-triggers' with the following:
render-triggers:
- blockupdate
#- blockupdate-with-id
#- lightingupdate
- chunkpopulate
- chunkgenerate
#- none
- Delete /plugins/dynmap.jar
- Follow the installation procedure, above, for installing/upgrading the appropriate Forge version
命令
| 命令列表 |
|---|
| Hiding and showing players /dynmap hide: Hides the player from the map. /dynmap render: renders one tile of the map where you are standing. |
用dmap配置地图和世界
As of v0.31, dynmap provides the option of configuring many of the features of maps and worlds using console commands issued by a user with operator privileges or via the server console. When any of the editing commands are used, the existing configuration will be transferred into the 'worlds.txt' file (whether or not the existing maps were based on worlds.txt or on the default templates). New worlds will still be initialized using templates, but once the configuration has been migrated to 'worlds.txt', further updates to the templates will not automatically be reflected to the existing worlds. Also, all map editing commands are limited to HDMap maps - legacy KzedMap and FlatMap maps cannot be edited using /dmap commands.
To start, the /dmap editing commands (all the commands besides the /dmap worldlist, /dmap maplist, /dmap perspectivelist, /dmap shaderlist, or /dmap lightinglist commands) cannot be used while map rendering is active. So, to start, the operator must issue the '/dynmap pause all' command. This will suspend all fullrender and update render processing - DO NOT FORGET TO UNPAUSE PROCESSING WHEN DONE, USING '/dynmap pause none`. FAILING TO UNPAUSE WILL PREVENT PROCESSING, AND RESULT IN A GROWING BACKLOG OF PROCESSING, WITH THE ASSOCIATED MEMORY USE.
Once rendering is paused, the /dmap commands can be used to add, remove, reorder, or modify existing map definitions. The order and many of the settings for the list of worlds can also be controlled. The following are a sample of the sorts of actions that can be done:
- To disable/hide a world: /dmap worldset _worldname_ enabled:false
- To reset a world's settings and maps to its default template: /dmap worldreset _worldname_
- To reset a world's settings and maps to a specific template (replacing all existing maps): /dmap worldreset _worldname_ _templatename_
- To make a world first in the list of worlds: /dmap worldset _worldname_ order:1
- To set the title of a world: /dmap worldset _worldname_ title:_"title string"_
- To hide the reporting of player positions and health on a world: /dmap worldset _worldname_ sendposition:false sendhealth:false
- To set the default center position of a world to the player's current location: /dmap worldset _worldname_ center:here
- To set the default center position of a world to a given location: /dmap worldset _worldname_ center:_X_/_Y_/_Z_
- To set the number of extra zoom out levels of a world to N: /dmap worldset _worldname_ extrazoomout:_N_
- To list the maps for a given world: /dmap maplist _worldname_
- To delete a map from a given world: /map mapdelete _worldname_:_mapname_
- To add a new map to a given world (with a given title, perspective, shader, and lighting): /dmap mapadd _worldname_:_mapname_ title:_"map-title"_ perspective:_perspective-id_ shader:_shader-id_ lighting:_lighting-id_
- To edit the order/position of a map in the list of maps for a world to be Nth: /dmap mapset _worldname_:_mapname_ order:_N_
- To edit the title of a map: /dmap mapset _worldname_:_mapname_ title:_"new-title"_
- To change the perspective of a map (new scale, new point of view): /dmap mapset _worldname_:_mapname_ perspective:_perspective-id_
- To change the filename prefix of a map: /dmap mapset _worldname_:_mapname_ prefix:_prefix_
- To set the icon file for a map (relative path under 'webpath' - e.g. images/block_skylands.png) : /dmap mapset _worldname_:_mapname_ icon:images/block_skylands.png
- To set the map zoom in level for a map to N: /dmap mapset _worldname_:_mapname_ mapzoomin:_N_
- To change the image format used for a map to JPG: /dmap mapset _worldname_:_mapname_ img-format:jpg
- To change the default cave map to use the new 'textured cave view': /dmap mapset _worldname_:_mapname_ shader:stdtexture-cave
- To list the available perspectives: /dmap perspectivelist
- To list the availale shaders: /dmap shaderlist
- To list the available lightings: /dmap lighinglist
- To set a map to appear on the same line as maps of another world: /dmap mapset _worldname_:_mapname_ append-to-world:_another_worldname_
Note: any attributes settable using 'mapset' can also be set on a new map using 'mapadd'.
As with other map edits, many of these changes will require the modified map to be re-rendered to fully implement the changes.
Once all map edits are completed, remember to run '/dynmap pause none` to resume normal render processing.
权限
| 权限列表 |
|---|
| SuperPerms-based access control, including specific support for PermissionsEx, BukkitPermissions, bPermissions, and classic Permissions. The following nodes are defined: dynmap.render - allows /dynmap render command |
网页UI登陆支持和权限
Dynmap offers the option of limiting the availability of the information that can be access through the web user interface. To enable login support, the following setting must be configured in configuration.txt:
login-enabled: true Once enabled, user accounts can be registered. Registration can be done by users themselves (using the /dynmap webregister command), if the users have the dynmap.webregister permissions. Alternately, registration can be done by administrators on behalf of users using the /dynmap webregister <userid> (which requires the dynmap.webregister.other permission). In either case, the user is supplied with a passcode, which can then be used on the web interface login panel to create a web user account.
Once defined, the web user account will use the permissions associated with the Minecraft user account to control access through the web interface.
If desired, the web interface can be restricted to only logged in users. To do this, set the setting:
login-required: true Otherwise, guest access to the interface is permitted - which will only allow access to unprotected features.
Web Interface Restriction Options
World Protection
If the operator wants to restrict access to all map data on a specific world, this can be done by setting the 'protected' attribute on the world in worlds.txt (or, equivalently, by setting it using the command /dmap worldset <world-id> protected:true). Once set, only logged in users that also have the permission dynmap.world.<world-id> will be able to see any of the maps for the world .
Map Protection
If the operator wants to restrict access to specific maps on specific worlds, this can be done by setting the 'protected' attribute on the map in worlds.txt (or, equivalently, by setting it using the command /dmap mapset <world-id>:<map-id> protected:true). Once set, only logged in users that also have the permissions dynmap.map.<world-id>.<map-id> will be able to see the protected map. Note: if the map and the world are both protected, both permissions are needed.
Chat Protection
If the operator wants to restrict access for sending messages from the web interface, this can be done by setting the 'webchat-permissions' setting on the ClientUpdateComponent. Once set to 'true', only logged in users that have the dynmap.webchat permission are allowed to send chat messages from the web interface.
Player Positions and Information
If the operator wants to restrict visibility of the position and status of players, this can be done by setting the 'protected-player-info' setting on the ClientUpdateComponent. Once set to 'true', only logged in users that have the dynmap.playermarkers.seeall permission will be able to see the position and/or health information of all visible players. Logged-in players without the permission will only see their own position, while guests will see no players.
网页UI参数
The URL used to launch the web user interface supports a number of parameters, which may be used to override the default view presented to the user. This can be used to launch the UI with a given world or map selected, a given zoom level selected, and/or have the map centered on a given set of world coordinates.
The parameters are provided as a sequence of attribute-value pairs, with each parameter formatted as follows:
attribute-id=value
The base URL must have a question-mark (?) before the first parameter, and each additional parameter must be separated from the previous one by an ampersand (&). So, if the default URL for the map web is:
http://mygreatserver:8123/
then, launching the site with the world named 'fred' selected, and with the map 'surface' being shown, would be formatted as:
http://mygreatserver:8123/?worldname=fred&mapname=surface
If you're using an external server, the same format applies - add '?' and the corresponding parameters, seperated by ampersands:
http://mycoolapacheserver.com/dynmap?worldname=fred&mapname=surface
The parameters available are as follows:
- worldname - this specifies the name (not the title) of the world to be selected. If not provided, the first world defined will be shown (unless defaultworld has been set in configuration.txt, in which case that world is shown).
- mapname - this specifies the name (not the title) of the map to be selected. If not provided, the first map for the selected world is shown (unless defaultmap has been set in configuration.txt, in which case that map is shown).
- zoom - this specifies the zoom level to be selected (0 = highest zoom out). If not provided, a zoom level of zero is used (unless defaultzoom has been set in the configuration.txt).
- x - this specifies the X coordinate (in the coordinate system of the world being shown) of the center point of the map view. If not specified, this defaults to the value of the x attribute of the center attribute of the selected world (typically 0).
- y - this specifies the Y coordinate (in the coordinate system of the world being shown) of the center point of the map view. If not specified, this defaults to the value of the y attribute of the center attribute of the selected world (typically 64).
- z - this specifies the Z coordinate (in the coordinate system of the world being shown) of the center point of the map view. If not specified, this defaults to the value of the z attribute of the center attribute of the selected world (typically 0).
- nopanel - if defined and set to 'true', the sidebar menu on the map will be removed
- chatname - if defined and set to a string, the web UI will pass this value as the suggested name of the sender for any chat messages. This will only be accepted by the internal web server if the 'trustclientname' setting has been set to true, in addition to the 'allowurlname' parameter for the 'chat' component. Supported on 0.28 and later.
- playername - if defined and set to a player's account name, the web UI will initialize following the position of the given player, if the are online when the UI starts, or come online sometime after.
- hidechat - if defined and set to 'true', the web UI will disable all chat input and output components (balloons, input fields, and chat box).
- nogui - if defined and set to 'true', the web UI will disable ALL controls, panels and the like, just presenting the map layer itself.
- nocompass - if defined and set to 'true', the compass rose on the UI will be hidden (v2.2-alpha-1)
使用标记
Dynmap supports mechanisms for adding content to maps, above what is rendered by the maps. This content is collectively referred to as Markers, and consist of markers (marker icons), marker areas, and marker poly-lines.
Marker Sets
Markers are collected and organized as collections, referred to as Marker Sets. Each Marker Set is a labelled layer, selectable using the web UIs layer selector. Every marker is contained within a specific marker set. By default, there is always at least one marker set, labelled Markers, that will be used to contain any markers that are not specifically assigned to another marker set. Deleting a marker set will delete all markers within the set.
New marker sets can be created using the /dmarker addset <markerset-label> or /dmarker addset id:<markerset-id> commands. Additional parameters can be used to refine the set's behavior: prio:<N> is used to control the order of the layer in the layer control, relative to other sets; hide:<true|false> is used to control whether the set is visible (checked) or hidden (unchecked) by default; 'minzoom:` is used to make the markers in the set hidden until a specific zoom level is selected.
Settings on existing marker sets can be altered using the /dmarker updateset <markerset-label> or /dmarker updateset id:<markerset-id> commands, with prio:<N>, hide:<true|false> or newlabel:<new-label> as parameters.
As of 0.32, the setting 'showlabels:` is supported. This setting, when true or false, enables or disables the visibility of marker labels (disabled visibility causes labels to only show when the mouse cursor is hovering over the marker). The value null uses the global default behavior (defined by the showlabels setting in the markers component in configuration.txt.
Marker sets (except for the default marker set, Markers) can be deleted using the /dmarker deleteset <markerset-label> or /dmarker deleteset id:<markerset-id> commands.
Marker
Markers are the most common map markers - simple icons with an associated label and/or an associated description popup. Each marker has a defined location in world coordinates (X, Y, Z and a world ID), a marker icon ID, a label, and an optional description. The marker icon ID can be one of the standard marker IDs (shown at the bottom of this page), or can correspond to an installed icon (see Marker Icons section, below).
Markers can be added one of a couple of ways:
- /dmarker add <marker-label> icon:<icon-id> set:<markerset-id> - this must be issued by a logged-in player, and will cause a marker to be defined at the player's current location. If set is not provided, the marker will be created in the default marker set, Markers. If icon is not defined, the default marker icon is used (default, a house).
- /dmarker add id:<marker-id> <marker-label> icon:<icon-id< set:<markerset-id> - Same as above, except that the unique ID of the marker is specified.
- Using a sign: If the enablesigns setting on the markers component is true, users with the appropriate privilege (dynmap.marker.sign) can create markers using specially labelled signs. To use these, the first line of the sign MUST be [dynmap]. After that, any non-blank line will be included in the label of the marker, except for lines formatted as set:<markerset-id> (which allows the marker to be added to a specific marker set) or icon:<icon-id> (which allows the marker to be set to use a specific icon - if not specified, the icon sign is used). If the marker is successfully created, the sign's text will erase the [dynmap], set: and icon: lines. If the sign is later deleted, the corresponding map marker is deleted.
Once created, markers can be edited using one of a couple of commands:
- /dmarker movehere <marker-label> set:<markerset-id> or /dmarker movehere id:<marker-id> set:<markerset-id>: This will move the existing marker to the player's current location. Note: the markerset-id is required to select a marker not in the default marker set (markers).
- /dmarker update <marker-label> set:<markerset-id> icon:<icon-id> newlabel:<new-label> or /dmarker update id:<marker-id> set:<markerset-id> icon:<icon-id> newlabel:<new-label>. Note: the markerset-id is required to select a marker not in the default marker set (markers) - the marker set ID is not editable.
Markers can be deleted using the /dmarker delete <marker-label> set:<markerset-id> or /dmarker delete id:<marker-id> set:<markerset-id> command.
Existing markers, and their attributes, can be shown using the /dmarker list set:<markerset-id> command.
Marker Icons
Marker Icons are image resources used to provide the images for markers. Dynmap supplies a number of standard marker icons, shown below, that are always present and defined, and are not deletable. The list of availabile icons can be found by running the /dmarker icons command.
New marker icons can be installed by doing the following:
- Copy the image file, in PNG format, to the bukkit server's file system. The image in the file should be 8x8, 16x16 or 32x32 pixels in size.
- Run the command /dmarker addicon id:<icon-id> <icon-label> file:<path-to-image-file> - if successful, the image file will be imported (so it doesn't need to be left where it was first copied).
To update the image for an existing icon, run the /dmarker updateicon id:<icon-id> newlabel:<new-label> file:<path-to-image-file>.
To delete an existing image, run the /dmarker deleteicon id:<icon-id>.
Area Markers
Area markers are used to place 2-D or 3-D outlines on the world maps. The area defined by an area marker is defined by a sequence of 2 or more X,Z coordinates, defining a rectangle (if 2 points, they are opposite corners of the rectangle) or a polygon (if 3 or more points, they define the ordered sequence of points for the polygon, with the last point connecting to the first). Optionally, the minimum and maximum Y coordinates can be supplied, to extend the 2-D shape into a 3-D volume (flat on the top and bottom).
The appearance of the edges of the outline can be controlled by setting the color attribute (#RRGGBB), line weight (0-N), and opacity (0.0-1.0). The appearance of the filled area within the outlines can be controled by setting the fill color attribute (#RRGGBB), and fill opacity (0.0-1.0).
To create an area, a list of corners needs to be supplied. Corners can be entered as follows:
- Running /dmarker addcorner to add the player's current position as a corner.
- Running /dmarker addcorner <x> <y> <z> or /dmarker addcorner <x> <y> <z> <world> to add a specific coordinate as a corner.
If needed, the corner list can be reset using the /dmarker clearcorners.
Once all the corners are entered, an area marker can be created using the /dmarker addarea <area-label> set:<markerset-id> or /dmarker addarea id:<area-id> <area-label> set:<markerset-id> commands. Additional attributes can be set with these commands, or later updated using the /dmarker updatearea id:<area-id> set:<markerset-id> or /dmarker updatearea <area-label> set:<markerset-id> command. These settings include:
- color - outline color (#RRGGBB format)
- fillcolor - fill color (within the outlines) (#RRGGBB format)
- 'opacity` - Opacity of the outline strokes (0.0 = transparent, 1.0 = solid)
- 'fillopacity` - Opacity of the filled color areas (0.0 = transparent, 1.0 = solid)
- weight - Stroke weight of outline (0=minimum, higher=thicker)
- ytop - Y coordinate of the top of the area (default=64)
- ybottom - Y coordinate of the bottom of the area (default=64)
Note: The corners in an existing area cannot currently be updated - delete the existing area and add a new area to update these. Also, the corner list is reset after they are used to create a new area using the /dmarker addarea command.
To delete an area marker, use the /dmarker deletearea id:<area-id> set:<markerset-id> command.
Existing areas, and their attributes, can be shown using the /dmarker listareas set:<markerset-id> command.
Circle Markers
Circle markers are used to place 2-D circular (or elliptical) outlines on the world maps. The area defined by a circle marker is defined by a center point (x, y, z) and either a radius (for a circle, via radius setting) or an X vs Z radius (for an ellipse, via radiusx and radiusz setting).
The appearance of the edges of the outline can be controlled by setting the color attribute (#RRGGBB), line weight (0-N), and opacity (0.0-1.0). The appearance of the filled area within the outlines can be controled by setting the fill color attribute (#RRGGBB), and fill opacity (0.0-1.0).
A circle marker can be created using the /dmarker addcircle <circle-label> set:<markerset-id> or /dmarker addcircle id:<circle-id> <circle-label> set:<markerset-id> commands. Additional attributes can be set with these commands, or later updated using the /dmarker updatecircle id:<circle-id> set:<markerset-id> or /dmarker updatecircle <circle-label> set:<markerset-id> command. These settings include:
- x - X coordinate of center (default is current location of player issuing command)
- y - Y coordinate of center (default is current location of player issuing command)
- z - Z coordinate of center (default is current location of player issuing command)
- radius - radius of circle (default is 1)
- 'radiusx' - radius of ellipse on X axis (default is 1)
- 'radiusz' - radius of ellipse on Z axis (default is 1)
- world - world of center (default is current location of player issuing command)
- color - outline color (#RRGGBB format)
- fillcolor - fill color (within the outlines) (#RRGGBB format)
- 'opacity` - Opacity of the outline strokes (0.0 = transparent, 1.0 = solid)
- 'fillopacity` - Opacity of the filled color areas (0.0 = transparent, 1.0 = solid)
- weight - Stroke weight of outline (0=minimum, higher=thicker)
To delete a circle marker, use the /dmarker deletecircle id:<circle-id> set:<markerset-id> command.
Existing circles, and their attributes, can be shown using the /dmarker listcircles set:<markerset-id> command.
Poly-Line Markers
Poly-line markers are used to place a sequence of connected line segments on the world maps. Each poly-line marker is defined by a sequence of 1 or more X,Y,Z coordinates, along with a label, an optional description popup, and associated line color, weight, and opacity settings.
The appearance of the lines can be controlled by setting the color attribute (#RRGGBB), line weight (0-N), and opacity (0.0-1.0).
To create a poly-line, a list of corners needs to be supplied. Corners can be entered as follows:
- Running /dmarker addcorner to add the player's current position as a corner.
- Running /dmarker addcorner <x> <y> <z> or /dmarker addcorner <x> <y> <z> <world> to add a specific coordinate as a corner.
If needed, the corner list can be reset using the /dmarker clearcorners.
Once all the corners are entered, a poly-line marker can be created using the /dmarker addline <line-label> set:<markerset-id> or /dmarker addline id:<line-id> <line-label> set:<markerset-id> commands. Additional attributes can be set with these commands, or later updated using the /dmarker updateline id:<line-id> set:<markerset-id> or /dmarker updateline <line-label> set:<markerset-id> command. These settings include:
- color - outline color (#RRGGBB format)
- 'opacity` - Opacity of the outline strokes (0.0 = transparent, 1.0 = solid)
- weight - Stroke weight of outline (0=minimum, higher=thicker)
Note: The corners in an existing poly-line cannot currently be updated - delete the existing poly-line and add a new poly-line to update these. Also, the corner list is reset after they are used to create a new poly-line using the /dmarker addline command.
To delete an existing poly-line, use the /dmarker deleteline id:<line-id> set:<markerset-id> command.
Existing lines, and their attributes, can be shown using the /dmarker listlines set:<markerset-id> command.
自定义方块定义
Dynmap supports a data-driven method for defining support for new Minecraft Blocks, which may be used to support customized block types, such as those provided via certain plugins and client modifications. These definitions are VERY sensitive to the internal implementation of the Dynmap ray tracer, and may change or become obsolete on future releases with little or no notice - when practical, this will be avoided, but do understand this before investing too heavily in this.
How blocks are rendered
The rendering of block in Dynmap is accomplished via a number of distinctive mechanisms, reflecting the needs of the different types of blocks defined by Minecraft and by its mods. In all cases, the rendering of a block consists of two core elements: a model defining the shape of the block to be rendered, and a set of textures used to apply color to the various surfaces of that shape. Thanks to the very 'blocky' nature of Minecraft, the majority of blocks are shaped like simple cubes: consequently, most blocks do not need a custom model, and can instead be assumed to be a simple solid cube.
Support files for custom blocks defined by add-on mods are provided through the definition of two files for each mod: one defining the texture mapping (following the naming convention '*-texture.txt', and placed in the 'renderdata' directory (or in a subdirectory under that directory)), and a second defining the models for blocks that are not simple cubes (following the naming convention '*-models.txt', and also placed in the 'renderdata' directory, or a subdirectory). For mods that have nothing but simple cubes, no *-models.txt file is required (as the model for any block without a model defined is assumed to be a simple cube).
Creating Texture and Model Definition Files
- For features common to both texture and model definitions files, see Common Features for Texture and Model Definition Files
- For details on the format of texture definition files, see Texture Definition Files
- For details on the format of model definition files, see Model Definition Files
Defining Blocks
- To define a simple, solid cube block, see Defining a Simple Block
- To define a cuboid block, see Defining a Cuboid Block
- To define a block based on a custom block renderer, see Defining a Block using a Custom Block Renderer
- To define a block based on a volumetric block model, see Defining a Block using a Volumetric Block Model
用Wavefront OBJ格式传输世界数据
As of v1.9.3, Dynmap has incorporated support for generating and exporting externally renderable files in Wavefront OBJ format. This feature, inspired by the standalone jmc-2-obj tool, allows operators within the server (or, optionally, from the server console) to select and export portions of their world data as model files that can then be imported into various tools that support Wavefront OBJ format - including Blender (a free, open source rendering and animation suite), Cinema 4D, Maya, 3D Studio Max, and others. These exported models can be render, using these packages, in ways that Dynmap does not support (including advanced lighting, reflections, and the like). As the OBJ output produced by Dynmap is very similar to that which mcobj or jmc-2-obj would produce, guides and wikis for importing and processing output from these tools are likely to be useful for Dynmap OBJ output.
The definition and execution of the export process is controlled using the new /dynmapexp command. This command allows setting of a number of attributes controlling the export:
- x0, y0, z0 : these are the minimum X, Y, and Z coordinates of the cuboid/rectangular prism to be exported
- x1, y1, z1 : these are the maximum X, Y, and Z coordinates of the cuboid/rectangular prism to be exported
- world : this is the name of the world to be exported from
- byChunk : if set to true, this causes the generation of an object for all the blocks in a given chunk
- byBlockID : if set to true, this causes the generation of an object for all the blocks of a given block ID
- byBlockIDData : if set to true, this causes the generation of an object for all the blocks of a given block ID and metadata value
- byTexture : if set to true, this causes the generation of an object for all the block faces using a given texture
- shader : This specifies the shader to be used as a source for the textures for the export. By default, 'stdtexture' is used. Only Texture Pack based shaders are currently supported.
The subcommands for the /dynmapexp command include:
- /dynmapexp set : this allows setting of the export attributes (above). Additional and pairs can be specified on the same command (e.g. /dynmapexp set x0 0 y0 0 z0 100)
- /dynmapexp radius : this command can only be used by a player in-game: it allows specifying of an export on the current world, with a radius of from the player's current position (in the X and Z axes), and from Y=0 to Y=255 vertically.
- /dynmapexp info : displays the current values of the export attributes
- /dynmapexp pos0 : this command can only be used by a player in-game: it sets the x0, y0, z0, and world attributes to the current position of the player.
- /dynmapexp pos1 : this command can only be used by a player in-game: it sets the x1, y1, z1, and world attributes to the current position of the player.
- /dynmapexp reset : resets the export attributes to their default
- /dynmapexp export : this initiates an export, creating a file named .zip in the export directory on the server (this defaults to a directory named 'export' under the dynmap directory, but can be changed using the 'exportpath' setting in configuration.txt). This process runs asynchronously, and can take from a few seconds to many minutes to complete, depending upon the size of the area selected for export.
- /dynmapexp purge : this deletes an previous export from from the export directory.
Once completed, an exported ZIP file will contain the following:
- A minecraft.obj file, containing the exported model (this can potentially be VERY big)
- A .mtl file, containing the material library (corresponding to the minecraft textures) used for coloring the model in minecraft.obj
- A directory, containing the texture files used by the material library
- To use the file, extract the ZIP file and load the 'minecraft.obj' file into the rendering tool.
其他
为了展示API，同时也为了协助管理这个已经非常庞大的补丁，我们已经开始了为Dynmap增加额外补丁的进程。所有这些工作都依赖于经由API的Dynmap和接口，只有对这些功能感兴趣的人们才会添加这些附加功能，这些功能有:
dynmap-mobs: 在dynmap地图上提供指定生物的实时位置。
dynmap-residence: 继承 'regions' （地区）以支持Residence在Dynmap中的使用, 实时更新Residence的改变。
Dynmap-WorldGuard: 继承 'regions' （地区）以支持WorldGuard 在Dynmap中的使用, 实时更新WorldGuard的改变。
Dynmap-Towny: 继承 'regions' （地区）以支持Towny在Dynmap中的使用, 实时更新Towny的改变。
Dynmap-Factions: 继承 'regions' （地区）以支持Factions在Dynmap中的使用, 实时更新Factions的改变。
Dynmap-CommandBook: 使用CommandBook，添加对显示/home和/warp 位置的支持。
Dynmap-Essentials: 使用Essentials，添加对显示/home和/warp 位置的支持。
Dynmap-GriefPrevention: 添加对显示Grief Protection claims（保护占领）的支持。
Dynmap2CraftIRC3: 通过CraftIRC，将Dynmap的网页聊天与IRC相结合。
Dynmap-SimpleClans: Dynmap的网页聊天与SimpleClans 相结合。
Dynmap-HeroChat: 结合Herochat v5.5+ 与Dynmap。
Dynmap-PhysicalShop
Dynmap-pyLandmarks
Dynmap-PreciousStones: 结合PreciousStones 与Dynmap。
Dynmap-AdminCmd: 结合AdminCmd与Dynmap。
Dynmap-PlayerWarp
Dynmap-Citizens: 结合Citizens与Dynmap。
开发者相关
Dynmap 插件由多个部件组成，用于支持多平台服务器，同时为了让我们的“已发布API”能被更好的理解。组成dynmap插件的必须部件 （用于Bukkit的Dynmap 补丁）在下文列出：
DynmapCoreAPI - 这是用于Dynmap的 neutral API 平台: 插件开发者能以此作为 Dynmap与任何平台的接口（通过指向dynmap 补丁实例 org.dynmap.DynmapCoreAPI 实现）
DynmapCore - 这是Dynmap的 server-neutral 核心: 几乎所有Dynmap的网页和渲染逻辑都在这（尽我们所能的放进去）。 这样开发的结果就是不可运行 - 所以他们都被放进了 'dynmap' 及其他部件开发里(例如 'DynmapSpout', 是用于 Spout 服务端的).
dynmap-api - 这是dynmap专用于Bukkit（Bukkit-specific）的 API 库 - 它定义了 org.dynmap.DynmapAPI 的接口,包括对 Bukkit-specific 的调用。 还包括 DynmapCoreAPI ( DynmapCoreAPI 是 DynmapAPI 的拓展), 即将补丁实例为 'dynmap' 之后指向 org.dynmap.DynmapAPI 然后接入公共接口。
dynmap - 这个部件让 dynmap-for-Bukkit 真正的可用, 只包含了不可运行为server-neutral的代码。
兼容性
The following mods are known to support dynmap integration without needing an add-on:
DeathTPPlus xWarp Vanish No Packet Ultimate Core Also, for the best response to questions and such, please post comments to our main forum thread - http://www.minecraftforum.net/topic/1543523-dynmap-dynamic-web-based-maps-for-minecraft/. Once again, having more than one place just isn't helpful, and this is where the 'Dynmap Community' already operates.
被公开的信息
This plugin utilizes Hidendra's plugin metrics system, which means that the following information is collected and sent to mcstats.org:
A unique identifier The server's version of Java Whether the server is in offline or online mode The plugin's version The server's version The OS version/name and architecture The core count for the CPU The number of players online The Metrics version
How to compile Dynmap 还有许多页面没有搬运,会尽快补充请谅解