Update: Latest 2.0.0-alpha-2 dev build should have fix for problem with 'day' tiles being updated on day/night maps.
On update queue: check '/dynmap pause' - see if your update processing is paused for any reason. If your tick rate is below about 18, we'll pause to prevent further performance impacts. See update-min-tps, fullrender-min-tps, and zoomout-min-tps for this. The 'invalid' stuff is just the persistence for which tiles on which maps are queued to be updated.
Trying to find time to move 2.0.0-alpha-2 forward: latest dev builds should now include a fix for a problem with login/webregister support, as well as support for using login support while using the MySQL map storage (including when remote).
I will take a look at the day/night map issue that has been reported.
Nice, I know some people have been waiting for this. For those of us using a shared file system anyway, is there any benefit for us to set Dynmap to use a local MySQL database? Performance or otherwise?
I haven't done enough performance analysis to say for sure: my instinct would be to say that, all things being equal, using MySQL will not be as performance optimal as the typical external web server (aka 'JSON file mode'): serving files is VERY cheap and efficient for a web server like apache, and storing data in distinct files is very fast for the mod code in the MC server. That said, the MySQL server has some benefit from all the data being in single (or a small number) of huge files that are generally kept open all the time by the server, and which tend to be aggressively cached for the sake of performance - without testing, I'm not sure how the balance will tend to break for typical systems and configurations. The PHP code is using persistent MySQL connections, so performance accessing the MySQL server locally should be quite good, and the keying/indexing on the tables should yield close to optimal efficiency with reading data. All things considered, it MAY be that the MySQL will use a bit more CPU (rarely a problem: MC servers tend to have more cores than MC tends to use, due to how much of the processing is still single thread bound) while somewhat reducing file system I/O (which can be more of a concern, given that rendered maps are often too big to be hosted on SSDs).
The main goals of the new storage driver code (currently SQLite and MySQL) are to offer alternatives for folks where:
1) Having huge numbers of small files is a problem (whether a real problem - e.g. partitions with inadequate inode counts - or merely one of perception)
2) (for MySQL) offering a path to allow proper remoting of the web server versus the MC server
3) (for MySQL) offering the option to have more than one MC server's maps combined on to a single web (this is still WIP, but I plan on having it done for the 2.0.0 GA)
**** Latest dev builds of Dynmap v2.0.0-alpha-2 now support remote web via MySQL ****
The latest dev builds of Dynmap v2.0.0-alpha-2 now support having all interaction between the web client and the MC server be through the MySQL database. What this means is that you can follow the normal procedure for using an external web server (Apache) via the 'JSON File Mode', and switch the storage to be through a MySQL database vs depending upon a shared file system, and opt to have the web server reside on a different system than the MC server. Here's a quick procedure:
2) Switch the storage configuration in configuration.txt to use MySQL (see https://github.com/webbukkit/dynmap/blob/master/src/main/resources/configuration.txt#L22 for where this is done). Feel free to use Google to find out how to create a MySQL database and an associated login to access it (I'll eventually have a wiki page with a walkthrough, but if you cannot figure this out, you probably should avoid using this option ) Note: most MySQL server configurations default to not allowing remote connections (i.e. only localhost), so you may need to alter my.cfg, as well as the permissions on the MySQL account (see http://www.rackspace.com/knowledge_center/article/mysql-connect-to-your-database-remotely for an example).
3) At this point, if things are working right, you can start up and render maps to be stored in the database. The normal 'webpath' (typically dynmap/web, unless you've edited the setting) will now be primed to be usable as a home directory for the web site.
4) To put the web on a remote web server, copy the whole tree from under the dynmap/web directory to the target server: if necessary, you may need to edit the contents of the standalone/MySQL_config.php file - particularly if the hostname needed to access the MySQL database is different (e.g. localhost vs something else). Note: if you EVER update Dynmap on the MC server, be sure to re-copy the web files to the remote server (and re-apply your configuration changes): do NOT assume mixed file versions will work (if they do, it'd be a surprise).
The present development build does NOT support web client login while using MySQL - this should be fixed in the next few days.
If you do split the web server and MC server, I'd suggest hosting the MySQL database on (or closer to) the web server. The reason for this is simple: once you've rendered the map, the traffic between the MC server and the MySQL database will be pretty low, and not particularly time-critical: traffic from your web will likely be higher (particularly if a lot of folks use your map), and will tend to benefit from being 'snappier' more (since its being used interactively).
**** Bukkit dev build for 2.0-alpha-1 now supports Bukkit/Spigot 1.7.10 ****
Once again, this is lightly tested, but should work for 1.7.10, while continuing to work for earlier (1.4.7 or later) servers.
I was just realized that and posted my comment over on github! Also, I renamed the jar file to mysql.jar and everything works.
I haven't tried sqlite though.
Thanks for your help and for looking into the issue!
EDIT:
Maybe also update the documentation to let people know about this! I was driving myself crazy yesterday trying to figure out why it would not work.
LOL - it IS a dev build! I'll get to the docs before I release it
I'm in the process of trying to get the MySQL support to the point where:
1) The external web server can be remote from the MC server: all interactions are MC<->DB<->web
2) More than one MC server can contribute worlds and players to the same DB, and the web can show the combination of the contributions (good news for the Bungee folks, I hope )
I am currently running a FTB Monster server and it seems that Dye Trees (by Reika) do not render in Dynmap. Is there a way to manually add the block or link it to a texture?
Here is an example of what I mean:
Any help or advice would be greatly appreciated!
EDIT:
I also think the the SQL implementation may be broken. I sent an issue report on github. I can't use either sqlite or mysql. It seems that with those options Dynmap never loads itself into minecraft, ie: typing dynmap into the console log returns an error for an unknown command.
EDIT 3: The dev. build of Dynmap fixed the issue with the leaves. I saw Mike's comment of github about an hour ago. But I still don't know if the SQL error has been fixed?
Forge (versus Bukkit and MCPC-Plus) does not come with the JDBC drivers needed for SQLite or MySQL (and I haven't done the work to handle automatic downloading of them yet - I believe there is a 'right' way to do it in Forge, but I haven't confirmed the specifics). In any case, you need to pull the following down and place them in the 'mods' directory to make it work presently:
Thanks for fixing PFAA so quickly.
I found an issue with a different mod this time though.
This mod is doing the same, rendering as black/transparent blocks.
When using the PFAA mod (geologica) black or transparent is rendered for their blocks. Is this a configuration issue on my end or a possible mod incompatibility? If it is a bug is this usually fixed within dynmap or the offending mod? I am using the 1.6.4 version from http://www.minecraft...stra-geologica/ . Also I would like to add that zan's map renders those blocks just fine.
I moved my game to a new box (from Windows to Linux) and at first it seemed to work, but I couldn't use any bukkit commands (at least, I tried /fly and it didn't work; I also tried using an Essentials Economy sign and it didn't respond). Sometimes the server wouldn't allow connections (they would time out with an ioexception iirc). I tried moving it to a different Windows box but it still behaved the same. Back on the original box it still works fine. You may be wondering why I'm here if bukkit in general breaks, right? Here's the deal, I disable dynmap and everything works hunkey-dorey. I enable it again, and everything else breaks.
I tried removing the dynmap folder, but got the same issues. I noticed that while I can't /fly (in the game it does nothing, in the logs it shows a bunch of errors like [Server thread/ERROR]: Command fly failed:
java.lang.NoClassDefFoundError: Could not initialize class sun.awt.SunToolkit ) I can use the dynmap commands fine.
I'll try using a different web server to see if offloading the web service from bukkit will do the trick, but wanted to throw this out in case anyone has any idea. At first I thought it was a memory issue because I went from a beefy box to a small one with only 2GB, but then I tested in a VM and found that with 16GB RAM I still had the same issue. Another possibility could be CPUs? In the physical box I have a single-core with hyperthreading, and in the VM I just gave one CPU (with one core). If you think it might be the limited CPU processing power I can try to fire up a multi-core VM but that will take some time 'cause I'd have to set up the OS all over again.
Thanks in advance!
Edit: after doing some research, I'm leaning towards suspecting the CPU. I should have mentioned the "new" box is actually older, just trying to move it to a lower-power box. This new one has an Atom processor (230, single-core 1.6GHz with hyperthreading). I'll dig around and see if I can find a slightly more powerful system. Might just be a matter of finding the right balance of power supplied -vs- electricity consumed for everything to work.
My first bet is that you don't have the PermGen set high enough - try adding -XX:MaxPermGen=128m to your JVM command line. 1.7.x Bukkit recommends this, as the size of 1.7.x's code and libraries leave little space for large mods, like Dynmap.
I tried to install Dynmap-1.9.4.1-forge-10.12.0 on my Minecraft server running under Ubuntu with the TerraFirmaCrate mod. I followed the direction of just copying the Dynmap jar file to the mods folder and restarting the Minecraft server.
This is the crash report that I received:
<code>---- Minecraft Crash Report ----
// I bet Cylons wouldn't have this problem.
Time: 5/20/14 10:34 PM
Description: Exception in server tick loop
java.lang.NoClassDefFoundError: org/apache/logging/log4j/LogManager
at org.dynmap.forge.DynmapPlugin$OurLog.<init>(DynmapPlugin.java:287)
at org.dynmap.forge.DynmapMod.<init>(DynmapMod.java:69)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at cpw.mods.fml.common.ILanguageAdapter$JavaAdapter.getNewInstance(ILanguageAdapter.java:174)
at cpw.mods.fml.common.FMLModContainer.constructMod(FMLModContainer.java:518)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:74)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:313)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:296)
at com.google.common.eventbus.EventBus.post(EventBus.java:267)
at cpw.mods.fml.common.LoadController.sendEventToModContainer(LoadController.java:201)
at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:181)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:74)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:313)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:296)
at com.google.common.eventbus.EventBus.post(EventBus.java:267)
at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:112)
at cpw.mods.fml.common.Loader.loadMods(Loader.java:511)
at cpw.mods.fml.server.FMLServerHandler.beginServerLoading(FMLServerHandler.java:99)
at cpw.mods.fml.common.FMLCommonHandler.onServerStart(FMLCommonHandler.java:350)
at net.minecraft.server.dedicated.DedicatedServer.func_71197_b(DedicatedServer.java:69)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:445)
at net.minecraft.server.ThreadMinecraftServer.run(SourceFile:583)
Caused by: java.lang.ClassNotFoundException: org.apache.logging.log4j.LogManager
at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:186)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 36 more
Caused by: java.lang.NullPointerException
at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:178)
... 38 more
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- System Details --
Details:
Minecraft Version: 1.6.4
Operating System: Linux (amd64) version 3.13.0-24-generic
Java Version: 1.7.0_51, Oracle Corporation
Java VM Version: OpenJDK 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 42142784 bytes (40 MB) / 86814720 bytes (82 MB) up to 1037959168 bytes (989 MB)
JVM Flags: 1 total; -Xmx1024M
AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
Suspicious classes: FML and Forge are installed
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
FML: MCP v8.11 FML v6.4.49.965 Minecraft Forge 9.11.1.965 6 mods loaded, 6 mods active
mcp{8.09} [Minecraft Coder Pack] (minecraft.jar) Unloaded->Constructed
FML{6.4.49.965} [Forge Mod Loader] (ForgeMod.jar) Unloaded->Constructed
Forge{9.11.1.965} [Minecraft Forge] (ForgeMod.jar) Unloaded->Constructed
tfc_coremod{0.78.16} [TFC[coremod]] (minecraft.jar) Unloaded->Constructed
Dynmap{1.9.4.1-88} [Dynmap] (Dynmap-1.9.4.1-forge-10.12.0.jar) Unloaded
terrafirmacraft{0.78.16} [TerraFirmaCraft] (TFC-0.78.16.jar) Unloaded
Profiler Position: N/A (disabled)
Is Modded: Definitely; Server brand changed to 'fml,forge'
Type: Dedicated Server (map_server.txt)
</code>
1.9.4.1 is for Forge 10.12.0 (MC 1.7.2) - you are running a 1.6.4 server. Use Dynmap-1.9.4-forge.9.11.1.jar
Is it possible to add an config option to use another service for the Player Heads on the dynmap? I would like to get them from http://cravatar.eu/ to use the 3D-Heads.
Thanks
Not presently, unless the skin files are the same format as standard ones: if they are, you can change the skin-url setting. Otherwise, you CAN put the files you want used in the <tilespath>/faces/32x32 directory, and set the 'fetchskins' setting to false (setting fetchskins to false blocks normal loading of skins). I will consider the option to have the images used be optionally an unprocessed version of the image loaded via the URL (so that something like the 3D ones you see on that URL you provided) might be usable.
I didn't mean entities thought, I'm more than satisfied with showing the blocks in the world. That's what I was refering to since dynmap doesn't show the blocks from Mo's Creatures with make the wyvern dimension only show the portal building (since that's made of quartz).
Ah - actually didn't realize Mo'Creatures had added blocks: that should be simpler to do, as you say
0
0
On update queue: check '/dynmap pause' - see if your update processing is paused for any reason. If your tick rate is below about 18, we'll pause to prevent further performance impacts. See update-min-tps, fullrender-min-tps, and zoomout-min-tps for this. The 'invalid' stuff is just the persistence for which tiles on which maps are queued to be updated.
0
I will take a look at the day/night map issue that has been reported.
1
I haven't done enough performance analysis to say for sure: my instinct would be to say that, all things being equal, using MySQL will not be as performance optimal as the typical external web server (aka 'JSON file mode'): serving files is VERY cheap and efficient for a web server like apache, and storing data in distinct files is very fast for the mod code in the MC server. That said, the MySQL server has some benefit from all the data being in single (or a small number) of huge files that are generally kept open all the time by the server, and which tend to be aggressively cached for the sake of performance - without testing, I'm not sure how the balance will tend to break for typical systems and configurations. The PHP code is using persistent MySQL connections, so performance accessing the MySQL server locally should be quite good, and the keying/indexing on the tables should yield close to optimal efficiency with reading data. All things considered, it MAY be that the MySQL will use a bit more CPU (rarely a problem: MC servers tend to have more cores than MC tends to use, due to how much of the processing is still single thread bound) while somewhat reducing file system I/O (which can be more of a concern, given that rendered maps are often too big to be hosted on SSDs).
The main goals of the new storage driver code (currently SQLite and MySQL) are to offer alternatives for folks where:
1) Having huge numbers of small files is a problem (whether a real problem - e.g. partitions with inadequate inode counts - or merely one of perception)
2) (for MySQL) offering a path to allow proper remoting of the web server versus the MC server
3) (for MySQL) offering the option to have more than one MC server's maps combined on to a single web (this is still WIP, but I plan on having it done for the 2.0.0 GA)
1
The latest dev builds of Dynmap v2.0.0-alpha-2 now support having all interaction between the web client and the MC server be through the MySQL database. What this means is that you can follow the normal procedure for using an external web server (Apache) via the 'JSON File Mode', and switch the storage to be through a MySQL database vs depending upon a shared file system, and opt to have the web server reside on a different system than the MC server. Here's a quick procedure:
1) Set up your dynmap for 'JSON File mode' - as shown here (https://github.com/webbukkit/dynmap/wiki/Setting-up-without-the-Internal-Web-Server)
2) Switch the storage configuration in configuration.txt to use MySQL (see https://github.com/webbukkit/dynmap/blob/master/src/main/resources/configuration.txt#L22 for where this is done). Feel free to use Google to find out how to create a MySQL database and an associated login to access it (I'll eventually have a wiki page with a walkthrough, but if you cannot figure this out, you probably should avoid using this option
3) At this point, if things are working right, you can start up and render maps to be stored in the database. The normal 'webpath' (typically dynmap/web, unless you've edited the setting) will now be primed to be usable as a home directory for the web site.
4) To put the web on a remote web server, copy the whole tree from under the dynmap/web directory to the target server: if necessary, you may need to edit the contents of the standalone/MySQL_config.php file - particularly if the hostname needed to access the MySQL database is different (e.g. localhost vs something else). Note: if you EVER update Dynmap on the MC server, be sure to re-copy the web files to the remote server (and re-apply your configuration changes): do NOT assume mixed file versions will work (if they do, it'd be a surprise).
The present development build does NOT support web client login while using MySQL - this should be fixed in the next few days.
If you do split the web server and MC server, I'd suggest hosting the MySQL database on (or closer to) the web server. The reason for this is simple: once you've rendered the map, the traffic between the MC server and the MySQL database will be pretty low, and not particularly time-critical: traffic from your web will likely be higher (particularly if a lot of folks use your map), and will tend to benefit from being 'snappier' more (since its being used interactively).
0
0
Once again, this is lightly tested, but should work for 1.7.10, while continuing to work for earlier (1.4.7 or later) servers.
0
Lightly tested (it IS a dev build!) - should be doing some more very soon, as I'm no longer travelling
http://mikeprimm.com/dynmap/builds/DynmapForge/Dynmap-HEAD-forge-10.13.0.jar
1
LOL - it IS a dev build! I'll get to the docs before I release it
I'm in the process of trying to get the MySQL support to the point where:
1) The external web server can be remote from the MC server: all interactions are MC<->DB<->web
2) More than one MC server can contribute worlds and players to the same DB, and the web can show the combination of the contributions (good news for the Bungee folks, I hope
1
Forge (versus Bukkit and MCPC-Plus) does not come with the JDBC drivers needed for SQLite or MySQL (and I haven't done the work to handle automatic downloading of them yet - I believe there is a 'right' way to do it in Forge, but I haven't confirmed the specifics). In any case, you need to pull the following down and place them in the 'mods' directory to make it work presently:
0
Geocraft should be in current dev build
0
The mod isn't supported in the current recommended builds - but I did add support to the latest dev builds for 1.6.4 and 1.7.2 this morning.
My first bet is that you don't have the PermGen set high enough - try adding -XX:MaxPermGen=128m to your JVM command line. 1.7.x Bukkit recommends this, as the size of 1.7.x's code and libraries leave little space for large mods, like Dynmap.
0
1.9.4.1 is for Forge 10.12.0 (MC 1.7.2) - you are running a 1.6.4 server. Use Dynmap-1.9.4-forge.9.11.1.jar
0
Not presently, unless the skin files are the same format as standard ones: if they are, you can change the skin-url setting. Otherwise, you CAN put the files you want used in the <tilespath>/faces/32x32 directory, and set the 'fetchskins' setting to false (setting fetchskins to false blocks normal loading of skins). I will consider the option to have the images used be optionally an unprocessed version of the image loaded via the URL (so that something like the 3D ones you see on that URL you provided) might be usable.
0
Ah - actually didn't realize Mo'Creatures had added blocks: that should be simpler to do, as you say