- 欢迎来到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)
如何使用=
在无内部网页服务器环境使用
This page assumes
- You are reasonably experienced with the standalone web server you are using.
- You have the standalone web server and CraftBukkit running on the same machine.
- Your Web Server supports PHP. (Only needed for web-to-Minecraft chat)
- If you are on Linux, you should know how to use the terminal and chmod.
Change the following:
- class: org.dynmap.InternalClientUpdateComponent sendhealth: true allowwebchat: true webchat-interval: 5 #- class: org.dynmap.JsonFileClientUpdateComponent # writeinterval: 1 # sendhealth: true # allowwebchat: false
To:
#- class: org.dynmap.InternalClientUpdateComponent # sendhealth: true # allowwebchat: true # webchat-interval: 5 - class: org.dynmap.JsonFileClientUpdateComponent writeinterval: 1 sendhealth: true allowwebchat: false
To disable the internal updating mechanism and enable the json-file updating mechanism. This will write to the file standalone/dynmap_world.json in your web-path at an interval that is specified with writeinterval.
Copy your files in plugins/dynmap/web to a directory of your webserver. Change configuration.txt so that it points with both tilespath and webpath to the paths where you placed the web-files. For *nix
# The path where the tile-files are placed. tilespath: /path/to/web/server/dynmap/web/tiles
The path where the web-files are located. webpath: /path/to/web/server/dynmap/web
Or for Windows
The path where the tile-files are placed. tilespath: c:\\path\\to\\web\\server\\dynmap\\web\\tiles
The path where the web-files are located. webpath: c:\\path\\to\\web\\server\\dynmap\\web
Now restart your Minecraft server. Join your Minecraft server and place a few blocks (randomly) to trigger dynmap to generate tiles for your map. You can also type dynmap fullrender worldname in your server console to render the whole world with the name worldname.
Now refresh your browser. It should now display online players on http://mywebserver/dynmap/, keeping them up-to-date.
Troubleshooting
If you don't see any tiles on the map, check the tiles directory to see whether they get actually generated. If there are no tiles, it is likely that Minecraft does not have rights to write the tiles in the web-path directory your chose. Another possibility is that you have not filled in tilespath correctly.
If you don't see any players or don't see the players moving, go to http://mywebserver/standalone/dynmap_world.json (where world is the name of your world). You should see some code and hitting refresh every few seconds should change that code (the servertime should be updated). If this file is not there or you don't see the file changing, you likely have filled in the wrong webpath in the configuration.
In Linux, if web-to-mc-chat does not work, you also need to chmod the 'standalone' folder to 775 or 777:
$ chmod -R 775 standalone This is to allow sendmessage.php to create the jsonfile. This is needed because its your Web Server creating the file and not the minecraft server.
If web-to-mc-chat does not work on IIS, you likely need to install PHP.
在Linux环境使用
This page assumes:
- Your Minecraft-server directory to be: /opt/minecraft_server/.
- You have the latest CraftBukkit installed.
- Your Minecraft server is hosted at localhost.
To install and test dynmap:
- Copy the file dynmap.jar and the folder dynmap to /opt/minecraft_server/plugins/.
- (Re)start your Minecraft server.
- Join your Minecraft server.
- Place a few blocks.
- Open up your browser.
- Navigate to http://localhost*:8123/.
You should see your map with your name in the top-left. Once you click on your name, the map will pan to your location and your should see a part of the map that has been generated.
Publishing
If you want the map to be accessible for others, you have two options:
- Forward an external port to your internal minecraft server with TCP port 8123. For more information on port-forwarding: http://portforward.com/.
- Host the map partly on your big webserver. Note that the webserver must already have access to the Minecraft server. See below.
Big Webservers
If you are hosting a Apache or lighttpd server, you might want to be able to get to the Dynmap-map from the same url as your website. Like http://www.yourwebsite.com/dynmap/ instead of http://www.yourwebsite.com:8123/. If this is the case, you can pick your webserver from the list below.
- apache2 under Debian/Ubuntu: Setting up Dynamic Map with Apache2 under Debian
- apache/httpd under Arch Linux: Setting up Dynamic Map with apache/httpd under Arch Linux
- lighttpd under Arch Linux: Setting up Dynamic Map with lighttpd under Arch Linux
- nginx Setting-up-with-Nginx-server-on-Centos (courtesy of LukeHandle)
在Windows环境使用
This page assumes:
- Your Minecraft-server directory to be: D:\minecraft_server\.
- You have the latest CraftBukkit installed.
- Your Minecraft server is hosted at localhost.
To install and test dynmap:
- Copy the file dynmap.jar and the folder dynmap from the zip-file to D:\minecraft_server\plugins\.
(Re)start your Minecraft server.
- Join your Minecraft server.
- Place a few blocks.
- Open up your browser.
- Navigate to http://localhost:8123/.
You should see your map with your name in the top-left. Once you click on your name, the map will pan to your location and your should see a part of the map that has been generated.
Publishing
If you want the map to be accessible for others, you have two options:
- Forward an external port to your internal minecraft server with TCP port 8123. For more information on port-forwarding: http://portforward.com/.
- Host the map partly on your big webserver. Note that the webserver must already have access to the Minecraft server. See below.
Big Webservers
If you are hosting a IIS or any other webserver, you might want to be able to get to the Dynmap-map from the same url as your website. Like http://www.yourwebsite.com/dynmap/ instead of http://www.yourwebsite.com:8123/. If this is the case, you can pick your webserver from the list below.
- IIS: Setting up Dynamic Map with IIS using URL rewrite and ApplicationRequestRouting (thanks to Kekec852!)
- IIS: Setting up Dynamic Map with IIS
(This is not really a list eh? If you have another server and know how to configure it, please add it to the wiki)
在虚拟主机环境使用
In general, this does not work, as the providing of tile files by Dynmap for serving by the host's web server typically requires file system access (versus the FTP or SFTP based file delivery most hosting services allow). Below are some links to unofficial procedures that some of our users have successfully used with specific hosting solutions:
Dynmap On Xenon Hosting Service, courtesy of mavbear
插件设置
Here we'll describe how the configuration is structured and how to edit the configuration.
The configuration in the file plugins/dynmap/configuration.txt which is in YAML format. 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.
Just as a reference, you can view the default configuration here: https://github.com/webbukkit/dynmap/blob/recommended/src/main/resources/configuration.txt.
The configuration consists of 4 parts in the following order: components, global settings, world-templates and worlds. The global settings change behaviour of the rendering and the (internal) webserver of Dynmap. It should be obvious how these work. An example of a global setting is:
- How often a tile gets rendered (in seconds).
renderinterval: 1 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
The components-section looks a like:
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: ... 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').
部件配置
世界及模板设置
高清地图配置
基于Forge的支持
基于CraftBukkit外其他服务端的支持
命令
命令列表 |
---|
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 还有许多页面没有搬运,会尽快补充请谅解