@kickingandscreamin
Our map chat was working fine with 1.9.3 and then we changed from forge to mcpc+. After this update it was necessary to use the bridge for the marker permissions.
I did a few tests today (all with mcpc+):
I gave all players permission to use /dmarker add XXX
1.9.4 with bridge:
- webchat broken
- /dmarker add XXX works
1.9.4 without bridge:
- webchat works
- /dmarker add XXX broken
(for OPs all commands work work everytime but ... OP:D)
hope that is helping out a bit
Without bridge, there is no way to access the security settings, so any command that doesn't default to being public is limited to operators (so your players not being able to use /dmarker is quite expected and unavoidable, without using the forge-specific permissioons file stuff (permissions.yml)).
With the bridge, we defer to getting messages to send to web chat from the Bukkit-based chat messages - which are cancellable by Bukkit mods. We need to respect that to avoid sending messages that bukkit plugins have chosen to block (e.g. muting in Essentials) or restrict (specific channels in Factions or Towny or the like). Without the bridge, we get chat events 'raw' from forge, and cannot respect such actions by Bukkit plugins (for better or worse). Some plugins that manipulate chat messages do so by cancelling the normal message, and then sending text to the 'right' players themselves - these guys break us, with little that we can do to fix it. For example, Factions does this if relationship color coding is on (as the message needs to be 'tailored' for each recipient, versus being a common broadcast), but can be fixed by disabling the relationship coloring option.
As always. Dynmap is awesome. I do however wonder if you ever will add support for Mo's Creatures. Since it's such an old mod it would be nice. Atm it doesn't support the Wyvern Lair blocks, sadly.
I've been wanting to do a Forge version of my Dynmap-Mobs mod, which would allow for supporting mapping of generic entities (which could then be configured to handle Mo'Creatures mobs) - just haven't had the time.
I was hoping to get some information on the 'inhabited' shader that was released in 1.9.2.
I only became aware of this feature today through reddit and was curious on the implementation. Based on the information I was able to find it sounds like this is added as a new render within your world. If that is the case then you would need to have separate renders for the 30, 60 and 90 views (if you wanted multiple) which greatly increases the disk space needed (I'm using ~100gb right now).
Is it possible to have this as an overlay to the existing renders rather than a separate render?
Just use a lower resolution perspective - iso_SE_60_vlowres, for example.
*** Pre-announcement of upcoming Dynmap 2.0 features and changes ***
I'm in the process of doing a rather extensive refactoring of the core Dynmap code - particularly with regard to how rendered maps are stored and updated. This will eventually result in additional, often-requested alternatives for the storage of rendered maps, including as large, single file SQLLite-style databases and in remote traditional database like MySQL. As part of this refactoring, I am formally retiring and removing the 'legacy' map types - that is, the 'FlatMap' and 'KzedMap' types that have not been the default map type (which is HDMap) for over 2 years now. The standard profiles supporting these (which were only used if the 'defprofilesuffix' setting was commented out) will be replaced by HDMap near-equivalents - and will require those maps to be re-rendered after the upgrade. As these maps have not been default since around August, 2011, I'm relatively sure this will be of minimal impact to 99% of users.
If you are one of the few folks using the legacy map formats, you may wish to consider migrating yourself before applying the Dynmap v2.0 upgrade (when it is available).
Once completed, the 'abstraction' of the map storage mechanism will allow for both the creation of new map storage options in the future (e.g. Amazon S3), as well as supporting alternate server topologies:
Multiple MC servers contributing maps to a single storage server (remote or otherwise)
External web servers presenting from a storage server (remote or otherwise)
Both of the above combined, allowing multiple server to appear on the same combined web
The existing "tree of files" storage method will continue to be supported indefinitely, and will likely continue to be the default (as putting data into a database generally make it take more space, not less, and is often more incremental backup hostile (unless you've got a good database backup configured)). Ergo, existing configurations and renderings of HDMaps (independent of resolution) will NOT require updating or re-rendering.
In any case, I'll be maintaining the builds of the 2.0 code on its own branch and its own builds until I feel it is stable enough to be worth making available to folks for testing: there will continue to be a 1.9.5 development branch, in the mean time, that will continue to be relatively stable. I don't know whether there will be a formal v1.9.5 release, at present - it really depends upon how the v2.0 work continues to progress, and how quickly I can re-establish stability there.
honestly in all of modding, there are so many (countless) blocks that dynmap won't render as anything but a black square (multiple years this bug has existed, i think?) that i've long since given up on it ever working properly and just resigned to the fact that dynmap, albeit missing large portions and vital structures of the world is still far better than none.
and to mike, i understand why it doesn't render some blocks, but you have to give up on making a specific texture for every block dynmap doesn't recognize if you ever want this to work in a common sense fashion, it's really that simple, to put it simply, that new blocks need human interaction IS THE BUG of which i speak.
it's tolerable, but honestly quite a huge issue and amazing no progress has really been made for such a long time.
Please feel free to submit a pull request to address this "bug", or feel free to use one of the other map mods that does handle it (wait....there aren't any.....I wonder why?). I could explain why this cannot be done, but I expect the effort would be wasted.
Removing dynmap.jar resolves the issue and minecraft starts without error.
I have tried removing all settings and letting it re-install the config from scratch, but no luck.
What should I do?
Thanks
Problem you have there is a misbehaving Bukkit API ( getOfflinePlayer(String name) ) being called by Essentials, due to a request from Dynmap-Essentials (which makes the call in order to get the Home locations for the players). Nothing to do with dynmap, per se, except that removing it breaks Dynmap-Essentials (which keeps it from calling Essentials and preciptating the problem you are seeing). I suspect the issue is due to the 'brilliant' change towards UUIDs versus player names for player accounts. I'd definitely suggest being sure you've got the latest, greatest Essentials support (in case they've worked around this) - worst case, either remove Dynmap Essentials or disable the 'Homes' layer. It looks like the getOfflinePlayer() call can now precipitate network communications via the Mojang servers that is not safe to do on the server thread, but since the call isn't made by Dynmap Essentials (it asks for user data from Essentials, who then decides they might need to call Bukkit), there is nothing we could do to fix or avoid the issue.
I updated from our dev versions on MCPC+ to the release above, but signs stopped working. I verified that enable signs is set to true and did not change, so I was wondering if there is anything specific I could check for MCPC+. The World Border was also removed, but that is a minor issue. Thanks for any suggestions.
Log would probably help..Looks like a possible naming issue with the Bridge? Confirmed it is a .jar file, but it says it is not able to load it.
[INFO] Mapping loaded 5 packages, 8495 classes, 28815 fields, 56825 methods, flags 1fdd6
2014-04-20 20:12:13 [INFO] Loaded inheritance map of 792 classes
2014-04-20 20:12:15 [SEVERE] Could not load 'plugins\DynmapCBBridge-1.9.4.jar' in folder 'plugins'
org.bukkit.plugin.InvalidPluginException: java.lang.ClassNotFoundException: Failed to remap class org.dynmap.bukkitbridge.DynmapCBBridgePlugin
at org.bukkit.plugin.java.JavaPluginLoader.loadPlugin(JavaPluginLoader.java:194)
at org.bukkit.plugin.SimplePluginManager.loadPlugin(SimplePluginManager.java:307)
at org.bukkit.plugin.SimplePluginManager.loadPlugins(SimplePluginManager.java:231)
at org.bukkit.craftbukkit.v1_6_R3.CraftServer.loadPlugins(CraftServer.java:231)
at cpw.mods.fml.common.event.FMLServerAboutToStartEvent.<init>(FMLServerAboutToStartEvent.java:29)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at cpw.mods.fml.common.LoaderState.getEvent(LoaderState.java:84)
at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:112)
at cpw.mods.fml.common.Loader.serverAboutToStart(Loader.java:817)
at cpw.mods.fml.common.FMLCommonHandler.handleServerAboutToStart(FMLCommonHandler.java:309)
at net.minecraft.server.dedicated.DedicatedServer.func_71197_b(DedicatedServer.java:222)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:630)
at net.minecraft.server.ThreadMinecraftServer.run(ThreadMinecraftServer.java:16)
Caused by: java.lang.ClassNotFoundException: Failed to remap class org.dynmap.bukkitbridge.DynmapCBBridgePlugin
at org.bukkit.plugin.java.PluginClassLoader.remappedFindClass(PluginClassLoader.java:539)
at org.bukkit.plugin.java.PluginClassLoader.findClass0(PluginClassLoader.java:456)
at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.java:234)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.bukkit.plugin.java.JavaPluginLoader.loadPlugin(JavaPluginLoader.java:183)
... 15 more
Caused by: java.lang.NoClassDefFoundError: org/dynmap/DynmapAPI
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at org.bukkit.plugin.java.PluginClassLoader.remappedFindClass(PluginClassLoader.java:527)
... 22 more
You're running a broken dev build of Dynmap Forge, from the looks of it.
Edit: Crap - build of DynampCBBridge on CurseForge is bad - uploading fix ASAP
If you are on MCPC+ without any Dynmap add-on mods, is there a reason you would need the MCPC+ version, or could you choose to use the bukkit version instead? I am considering moving back to the bukkit version for Dynmap to restore sign functionality, provided it is an option.
Sign functionality is working on the current development builds for Dynmap 1.9.4 + the 1.9.4 DynmapCBBridge, In any case, Bukkit Dynmap doesn't work on MCPC+.
Workaround for player->web chat problem with MCPC+ v1.7.2
Note: the current builds of MCPC+ have an issue that can result in a crash when user's logoff and the 'showofflineplayers' option is set to 'true' (it is 'false', by default) - particularly, a MethodNotFoundException on a MC utility class method. Current options are a) disable it, or use the current development build for DynmapFprge-1.7.2 (see OP for link). Problem seems to be particular to MCPC 1.7.2.
There is no reason, I'm just not up-to-date. ... but the error has been around for a long time
Resource pack - you must be using something custom, as this does not happen on thousands of other servers running the same code with the same Bukkit or Forge.
Hi there, I have the following problem:
The water on my map appears very transparent, so it is already black in the Ocean.
I use the version 1.9.1 on "HIRES"
Where can I change this? I can't find it!
Thanks for the help in advance.
What RP are you using? Also, is there a reason you aren't using the current recommended (1.9.2?)
Second. Every time I see anything from the WesterosCraft server it's depressing.
Third. I'm not sure if I'm aware of all the implications, but if it creates a blender model I think it is then possible to take that file, embed that in an html page and then be able allow people to freely rotate and zoom on the model. I may have to try to squeeze in another module for our website if that is the case.
Sorry - I'm an admin on WesterosCraft, so it tends to be my 'go to' for showing Dynmap doing pretty stuff
In any case, yes - the OBJ export generates a ZIP file containing what essentially is a CAD model for a selected portion of your world that is fully self-contained: it includes all the 'faces' needed to define the shapes in the world, and all the 'materials' (as defined by the appropriate image files - often processed versions of them - from the Resource Packs and/or mods) needed to paint those faces. The net result, when loaded in a tool that supports the format, is a big, complex 'object' that you can combined with other elements (lighting, cameras, other objects) to allow you to view and/or render them all in 3D space. Here's a screen shot of the imported Baelor OBJ file in Blender -
Basically, from here, its just another 3D model that you can use in your rendering or animation package.
Now DynMap show the normal maps but none of my MystCraft worlds. I tried to delete worlds.txt to get a new empty but my MystCraft worlds still doesn't show up. How can i debug why they are not showing up? I could see them before.
copy from lof file:
I have about 10 MystCraft worlds but I can't see any of them anymore in DynMap.
Enter the worlds - we cannot really 'see' them until they've been loaded (at least once since dynmap has been properly installed).
0
Without bridge, there is no way to access the security settings, so any command that doesn't default to being public is limited to operators (so your players not being able to use /dmarker is quite expected and unavoidable, without using the forge-specific permissioons file stuff (permissions.yml)).
With the bridge, we defer to getting messages to send to web chat from the Bukkit-based chat messages - which are cancellable by Bukkit mods. We need to respect that to avoid sending messages that bukkit plugins have chosen to block (e.g. muting in Essentials) or restrict (specific channels in Factions or Towny or the like). Without the bridge, we get chat events 'raw' from forge, and cannot respect such actions by Bukkit plugins (for better or worse). Some plugins that manipulate chat messages do so by cancelling the normal message, and then sending text to the 'right' players themselves - these guys break us, with little that we can do to fix it. For example, Factions does this if relationship color coding is on (as the message needs to be 'tailored' for each recipient, versus being a common broadcast), but can be fixed by disabling the relationship coloring option.
I've been wanting to do a Forge version of my Dynmap-Mobs mod, which would allow for supporting mapping of generic entities (which could then be configured to handle Mo'Creatures mobs) - just haven't had the time.
0
0
Just use a lower resolution perspective - iso_SE_60_vlowres, for example.
0
I'm in the process of doing a rather extensive refactoring of the core Dynmap code - particularly with regard to how rendered maps are stored and updated. This will eventually result in additional, often-requested alternatives for the storage of rendered maps, including as large, single file SQLLite-style databases and in remote traditional database like MySQL. As part of this refactoring, I am formally retiring and removing the 'legacy' map types - that is, the 'FlatMap' and 'KzedMap' types that have not been the default map type (which is HDMap) for over 2 years now. The standard profiles supporting these (which were only used if the 'defprofilesuffix' setting was commented out) will be replaced by HDMap near-equivalents - and will require those maps to be re-rendered after the upgrade. As these maps have not been default since around August, 2011, I'm relatively sure this will be of minimal impact to 99% of users.
If you are one of the few folks using the legacy map formats, you may wish to consider migrating yourself before applying the Dynmap v2.0 upgrade (when it is available).
Once completed, the 'abstraction' of the map storage mechanism will allow for both the creation of new map storage options in the future (e.g. Amazon S3), as well as supporting alternate server topologies:
- Multiple MC servers contributing maps to a single storage server (remote or otherwise)
- External web servers presenting from a storage server (remote or otherwise)
- Both of the above combined, allowing multiple server to appear on the same combined web
The existing "tree of files" storage method will continue to be supported indefinitely, and will likely continue to be the default (as putting data into a database generally make it take more space, not less, and is often more incremental backup hostile (unless you've got a good database backup configured)). Ergo, existing configurations and renderings of HDMaps (independent of resolution) will NOT require updating or re-rendering.In any case, I'll be maintaining the builds of the 2.0 code on its own branch and its own builds until I feel it is stable enough to be worth making available to folks for testing: there will continue to be a 1.9.5 development branch, in the mean time, that will continue to be relatively stable. I don't know whether there will be a formal v1.9.5 release, at present - it really depends upon how the v2.0 work continues to progress, and how quickly I can re-establish stability there.
0
Please feel free to submit a pull request to address this "bug", or feel free to use one of the other map mods that does handle it (wait....there aren't any.....I wonder why?). I could explain why this cannot be done, but I expect the effort would be wasted.
0
Initial released binary was broken (uploaded the wrong binary :<).
Fixed binary is here - http://minecraft.curseforge.com/mc-mods/dynmapcbbridge/files/9-v1-9-4/ - sorry for the mixup!
0
Problem you have there is a misbehaving Bukkit API ( getOfflinePlayer(String name) ) being called by Essentials, due to a request from Dynmap-Essentials (which makes the call in order to get the Home locations for the players). Nothing to do with dynmap, per se, except that removing it breaks Dynmap-Essentials (which keeps it from calling Essentials and preciptating the problem you are seeing). I suspect the issue is due to the 'brilliant' change towards UUIDs versus player names for player accounts. I'd definitely suggest being sure you've got the latest, greatest Essentials support (in case they've worked around this) - worst case, either remove Dynmap Essentials or disable the 'Homes' layer. It looks like the getOfflinePlayer() call can now precipitate network communications via the Mojang servers that is not safe to do on the server thread, but since the call isn't made by Dynmap Essentials (it asks for user data from Essentials, who then decides they might need to call Bukkit), there is nothing we could do to fix or avoid the issue.
You're running a broken dev build of Dynmap Forge, from the looks of it.
Edit: Crap - build of DynampCBBridge on CurseForge is bad - uploading fix ASAP
0
Version 1.9.4:
0
Sign functionality is working on the current development builds for Dynmap 1.9.4 + the 1.9.4 DynmapCBBridge, In any case, Bukkit Dynmap doesn't work on MCPC+.
0
- For use with DynmapForge v1.9.3 (all versions)
- Support player display name colors on MCPC+
- Workaround for player->web chat problem with MCPC+ v1.7.2
Note: the current builds of MCPC+ have an issue that can result in a crash when user's logoff and the 'showofflineplayers' option is set to 'true' (it is 'false', by default) - particularly, a MethodNotFoundException on a MC utility class method. Current options are a) disable it, or0
1
Resource pack - you must be using something custom, as this does not happen on thousands of other servers running the same code with the same Bukkit or Forge.
1
What RP are you using? Also, is there a reason you aren't using the current recommended (1.9.2?)
1
Sorry - I'm an admin on WesterosCraft, so it tends to be my 'go to' for showing Dynmap doing pretty stuff
In any case, yes - the OBJ export generates a ZIP file containing what essentially is a CAD model for a selected portion of your world that is fully self-contained: it includes all the 'faces' needed to define the shapes in the world, and all the 'materials' (as defined by the appropriate image files - often processed versions of them - from the Resource Packs and/or mods) needed to paint those faces. The net result, when loaded in a tool that supports the format, is a big, complex 'object' that you can combined with other elements (lighting, cameras, other objects) to allow you to view and/or render them all in 3D space. Here's a screen shot of the imported Baelor OBJ file in Blender -
Basically, from here, its just another 3D model that you can use in your rendering or animation package.
1
Enter the worlds - we cannot really 'see' them until they've been loaded (at least once since dynmap has been properly installed).
That's a good guess - I'll try to give it a look tonight.