I've been working on 1.4-alpha-1, specifically for 1.4.6, and specifically to try to improve the update rendering performance Forge lacks the update hooks that Bukkit has, so having the 'fine grained' triggers we have in the Bukkit version isn't currently practical - we know when something changes, or may have changed, but not why. Essentially, we're hooked in to the path used by the server to notify the client of block changes and chunk updates - unfortunately, some mods are overly generous about using these notifications, and the fact that the block was 'updated' doesn't necessarily mean it needs to be repainted by us: but we don't, in general, know without redrawing the tile. BuildCraft Pipes are particularly nasty this way - truckloads of updates from pipes that are moving stuff, none of which really calls for a redraw on our part. The 1.4-alpha-1 will include a mechanism for ignoring updates to 'chatty' blocks like these - at the expense of possibly not redrawing the block some times that may call for it. I've added the 'ignore-updates' setting on a number of particularly nasty offenders, and it has dramatically improved the routine update rate I see on my industrial server. The alpha will also include some render-trigger controls - and some more optimizations on the use of those triggers. I'll probably not do alpha-1 for all Forge platforms: I want to look at doing some more spins on this tuning before propagating it across the older Forge versions.
Thanks for the response. I'll be looking for that update, and will give feedback on how it does.
I've been working on 1.4-alpha-1, specifically for 1.4.6, and specifically to try to improve the update rendering performance Forge lacks the update hooks that Bukkit has, so having the 'fine grained' triggers we have in the Bukkit version isn't currently practical - we know when something changes, or may have changed, but not why. Essentially, we're hooked in to the path used by the server to notify the client of block changes and chunk updates - unfortunately, some mods are overly generous about using these notifications, and the fact that the block was 'updated' doesn't necessarily mean it needs to be repainted by us: but we don't, in general, know without redrawing the tile. BuildCraft Pipes are particularly nasty this way - truckloads of updates from pipes that are moving stuff, none of which really calls for a redraw on our part. The 1.4-alpha-1 will include a mechanism for ignoring updates to 'chatty' blocks like these - at the expense of possibly not redrawing the block some times that may call for it. I've added the 'ignore-updates' setting on a number of particularly nasty offenders, and it has dramatically improved the routine update rate I see on my industrial server. The alpha will also include some render-trigger controls - and some more optimizations on the use of those triggers. I'll probably not do alpha-1 for all Forge platforms: I want to look at doing some more spins on this tuning before propagating it across the older Forge versions.
If you didn't know, you can request new hooks for forge on their site.
If you didn't know, you can request new hooks for forge on their site.
LOL - yep - as a Bukkit-Bleeding team member, I'm actually as likely to try to put together a PR with the changes - hate asking other folks to do work for me But, thanks for the pointer.
I'll be pushing 1.4-alpha-1 out tonight for Forge 1.4.6 - any requests for other Forge versions?
When I uploaded the files to install dynamap. (Sorry I am a noob to this plugin) It told me to go to (myserverip:8123) Yes, I know to replace the "myserverip" part with the actual IP. When I do that it just brings me to a directory listing. I wasn't sure if that was normal or not? I did a full render with in game commands thinking that I needed to render it before I was able to see anything. I was still unable to see anything though other then the Directory listing. Is there something that I may have missed?
This usually means that you didn't extract the whole ZIP file - our web (HTML, javascript, etc) comes from the files that wind up in the dynmap/web directory tree. Without them, we'll still make our tiles (that is, the tiles directory under the dynmap/web directory), but not have the actual HTML and code needed for the web site itself.
High res does exactly as you describe. I think a res of 4 works well enough (2 is almost well enough), and keeps the disk space somewhat reasonable.
Right - Forge defaults to the 'hires' templates: consider 'lowres' or 'vlowres'. Also, if there are any maps you don't want/need (cave is popular to drop), you can disable those.
Have you been reading the thread? many people are reporting this problem.
This is a clean install, the 1.4.5mc 1.3 works for player locations. The 1.4.6mc 1.3 has no player locations, no images are ever placed in the faces folder either.
These are all brand new files with a new server instance (although it also doesn't work with my existing server either)
Here is a quote from another person with this problem:
and another:
EDIT: I stumbled upon the fix by accident, you may want to mention this somewhere:
Then they MUST be using the Forge Server version of the LoginMessage and NOT the vanilla server version. This not only breaks Dynmap locations, but it also breaks the Twilight Forest portal.
Sorry for all the trouble mikeprimm. I still want vanilla walls though
Those refer to player faces not rendering, not lack of player position (you'll get an outline) - not clear to me that that is the same thing (unless that is what you're getting). I can point you to almost any of the 25,000 servers currently running Dynmap, and you'll see it working - trust me, its not a feature that I'd only get a couple of folks b*tching about if it wasn't working.
First question - is your server able to DNS resolve and access the faces URL? See skin-url setting (http://s3.amazonaws....ns/%player%.png is the pattern). Since the server fetches and processes the skins to make the faces, this needs to be usable by the server - both DNS and firewall-wise.
On the walls, be sure that you don't have some other mod's configuration set to try to use block ID 139 - even if the setting in the configuration file is obsolete, if its in one of the active mods, it can cause us to override the model and texture for the block with the one for the mod. We trust that the IDs are right, and intentionally override what we get from the mods over the vanilla stuff, as older supported versions (e.g. 1.2.5) have mods that use the IDs that have since been claimed by Mojang (for example, the RedPower plants block in Tekkit 3.1.3 uses 139).
sounds cool mike, glad to hear you're gonna try to help out forge users server tick rates soon, looking forward to that, almost had to decide whether or not to keep dynmap since we added it to the world when it was much younger this time than usual, oh could you possibly add an xycraft renderer sometime soon too? i love my red xychorium brick 9x9 but i can only see the windows of it for now.
Rollback Post to RevisionRollBack
24 hours gone again, wasted in futility, welcome to minecraft modding, that is (unfortunately) our community.
(an ode to minecraft modding)
i keep making the same mistake, i think "oh, i've given them a few months, surely it'll be fixed by now" THAT is why i seem to ALWAYS be angry to some of you, my advice is to get the lead out.
there were nice things here, until the mod author threw a tantrum.
sounds cool mike, glad to hear you're gonna try to help out forge users server tick rates soon, looking forward to that, almost had to decide whether or not to keep dynmap since we added it to the world when it was much younger this time than usual, oh could you possibly add an xycraft renderer sometime soon too? i love my red xychorium brick 9x9 but i can only see the windows of it for now.
XyCraft is on my feature request list - Thaumcraft has been a pain (lots of special rendering and custom models), and Twilight Forest was pretty huge (but so nice!), so I'm behind on some of the mods I'm trying to get supported. If you guys have a list of which blocks would be most important (building materials and landscape blocks tend to be the most important to do first), I can try to get a partial support done quickly (simple cubic blocks tend to be VERY quick to get done).
My two biggest dev priorities this week are 1) Forge performance (Bukkit has the benefit of 2 years of tuning, and the fact that I'm an active Bukkit contributor - Forge support needs more 'love'), and 2) update the Leaflet library (the mapping library we use for the web) to something current (support IE10 and current Chrome better). Both of these are the key items for 1.4, with other mod support being opportunistic.
cool, also noticed thaumcraft too but forgot to ask, i think one person used it but just for a roof so it's not very bad but if you can the warded stone ones from that, as for xycraft the bricks, plates and shields are the main ones i'd like to see rendered, at least that's my vote, not sure if other people want to use the storage block to build with or not.
i honestly decided i'd splurge for a building or two to play around with the xycraft bricks, i'm loving them, now i'm tempted to use shields as pavers
Rollback Post to RevisionRollBack
24 hours gone again, wasted in futility, welcome to minecraft modding, that is (unfortunately) our community.
(an ode to minecraft modding)
i keep making the same mistake, i think "oh, i've given them a few months, surely it'll be fixed by now" THAT is why i seem to ALWAYS be angry to some of you, my advice is to get the lead out.
there were nice things here, until the mod author threw a tantrum.
Those refer to player faces not rendering, not lack of player position (you'll get an outline) - not clear to me that that is the same thing (unless that is what you're getting). I can point you to almost any of the 25,000 servers currently running Dynmap, and you'll see it working - trust me, its not a feature that I'd only get a couple of folks b*tching about if it wasn't working.
First question - is your server able to DNS resolve and access the faces URL? See skin-url setting (http://s3.amazonaws....ns/%player%.png is the pattern). Since the server fetches and processes the skins to make the faces, this needs to be usable by the server - both DNS and firewall-wise.
I think you missed the part where I figured out what was causing the faces/location problem and it had nothing to do with dynmap.
On the walls, be sure that you don't have some other mod's configuration set to try to use block ID 139 - even if the setting in the configuration file is obsolete, if its in one of the active mods, it can cause us to override the model and texture for the block with the one for the mod. We trust that the IDs are right, and intentionally override what we get from the mods over the vanilla stuff, as older supported versions (e.g. 1.2.5) have mods that use the IDs that have since been claimed by Mojang (for example, the RedPower plants block in Tekkit 3.1.3 uses 139).
Can you confirm that the vanilla walls wind up being block 210 instead of 139? If so, we can come up with a fix/support for this pretty easily.
Confirmed, all recipes for walls produce the mod version of the walls and use the mod id, which in my specific case is 4095.
Config path:
config/vanillawithsprinkles/FancyFences.cfg
block {
I:"BlockID used by the modded wall block"=3911
}
If you didn't know, it's the config # + 256 = 4095
Confirmed, all recipes for walls produce the mod version of the walls and use the mod id, which in my specific case is 4095.
Config path:
config/vanillawithsprinkles/FancyFences.cfg
block {
I:"BlockID used by the modded wall block"=3911
}
If you didn't know, it's the config # + 256 = 4095
Thanks for the support mikeprimm, your the best
COOL - we can fix this easy I'll try to throw something together for 1.4-alpha-1 (which I hope to get out tonight)
COOL - we can fix this easy I'll try to throw something together for 1.4-alpha-1 (which I hope to get out tonight)
Sweet.
I don't know if it matters, but i realized after I posted that the +256 only applys to items and I double checked the config, the id is actually 4095, not 3911. That math didn't add up anyway
I have a little bit of an odd question, i can't seem to find a fix for.
So, i have this server used by one of my staff members, and given to me to use for my own server. I deleted the plugins, and ran the server up again to get all the files unloaded and it working properly. After putting my own map on the server, i began to put more plugins in. One of these plugins was Dynmap.
After attempting to use the /dynmap fullrender world command, and it not updating the dynmap, i was confused.
Dynmap still shows what i believe to be the previous map of the other server, even after putting the "fullrender" command in. The server did tell me it was working on, and was rendering the different chunks.
But it refuses to update on the Dynmap website. I'm wondering if somehow, Dynmap creates files once its actually run, outside of the plugin folder?
Any help you can provide would be greatly appreciated.
23:29:07 [INFO] [dynmap] Full render of map 'surface' of 'world' in progress - 33000 tiles rendered (141.94 msec/tile, 51.15 msec per render)
23:29:20 [SEVERE] [dynmap] Exception during render job: world=world, map=org.dynmap.hdmap.HDMap@40542fa7
23:29:20 [SEVERE] java.lang.ArrayIndexOutOfBoundsException: 7
23:29:20 [SEVERE] at org.dynmap.hdmap.TexturePack.readColor(TexturePack.java:1481)[/size]
[size=x-small]23:29:20 [SEVERE] at org.dynmap.hdmap.TexturePackHDShader$ShaderState.processBlock(TexturePackHDShader.java:143)
23:29:20 [SEVERE] at org.dynmap.hdmap.IsoHDPerspective$OurPerspectiveState.handlePatches(IsoHDPerspective.java:746)
23:29:20 [SEVERE] at org.dynmap.hdmap.IsoHDPerspective$OurPerspectiveState.visit_block(IsoHDPerspective.java:809)
23:29:20 [SEVERE] at org.dynmap.hdmap.IsoHDPerspective$OurPerspectiveState.raytrace(IsoHDPerspective.java:874)
23:29:20 [SEVERE] at org.dynmap.hdmap.IsoHDPerspective$OurPerspectiveState.access$400(IsoHDPerspective.java:86)
23:29:20 [SEVERE] at org.dynmap.hdmap.IsoHDPerspective.render(IsoHDPerspective.java:1428)
23:29:20 [SEVERE] at org.dynmap.hdmap.HDMapTile.render(HDMapTile.java:96)
23:29:20 [SEVERE] at org.dynmap.MapManager$FullWorldRenderState.processTile(MapManager.java:644)
23:29:20 [SEVERE] at org.dynmap.MapManager$FullWorldRenderState.run(MapManager.java:582)
23:29:20 [SEVERE] at org.dynmap.MapManager$DynmapScheduledThreadPoolExecutor$1.run(MapManager.java:180)
23:29:20 [SEVERE] at org.dynmap.MapManager$DynmapScheduledThreadPoolExecutor$2.run(MapManager.java:196)
23:29:20 [SEVERE] at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
23:29:20 [SEVERE] at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
23:29:20 [SEVERE] at java.util.concurrent.FutureTask.run(Unknown Source)
23:29:20 [SEVERE] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)
23:29:20 [SEVERE] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
23:29:20 [SEVERE] at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
23:29:20 [SEVERE] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
23:29:20 [SEVERE] at java.lang.Thread.run(Unknown Source)
I have a simeler problem as someone3x7
Package 1:java-1.6.0-openjdk-1.6.0.0-1.28.1.10.10.el5_8.x86_64 already installed and latest version
Craftbukkit dev build for minecraft 1.4.6 (version CraftBukkit 1.4.6-R0.3)
Problem with even rendering dynmap in world. Im usesing only dynmap version 1.4.6-R0.3 (2/1/2012) ServerIP: http://85.17.134.88:8123/ and http://85.17.134.88/dynmap
Error:
13:16:49 dynmap: Full render of 'world' finished.
13:18:19 Server: /dynmap fullrender
13:18:21 CONSOLE: [INFO] World name is required
13:18:30 Server: /dynmap fullrender world
13:18:31 CONSOLE: [INFO] Full render starting on world 'world'...
13:18:31 CONSOLE: [SEVERE] [dynmap] Exception during render job: world=world, map=org.dynmap.hdmap.HDMap@6577e8ce
13:18:31 CONSOLE: [SEVERE] java.lang.NullPointerException
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.TexturePackHDShader$ShaderState.<init>(TexturePackHDShader.java:94)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.TexturePackHDShader.getStateInstance(TexturePackHDShader.java:231)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.HDMapManager.getShaderStateForTile(HDMapManager.java:125)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.IsoHDPerspective.render(IsoHDPerspective.java:1413)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.HDMapTile.render(HDMapTile.java:96)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.MapManager$FullWorldRenderState.processTile(MapManager.java:661)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.MapManager$FullWorldRenderState.run(MapManager.java:595)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.MapManager$DynmapScheduledThreadPoolExecutor$1.run(MapManager.java:180)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.MapManager$DynmapScheduledThreadPoolExecutor$2.run(MapManager.java:196)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.FutureTask.run(FutureTask.java:166)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
13:18:31 CONSOLE: [SEVERE] at java.lang.Thread.run(Thread.java:679)
**** Version 1.4-alpha-1 (only released for v1.4.6 on Forge v6.5.0+) ***
[Forge v6.50+) Add limited support for render triggers (blockupdate, blockupdate-with-id (blockupdate with extra logging data to track which block IDs are source of updates), lightingupdate, chunkpopulate, chunkgenerate). blockupdate, chunkpopulate and chunkgenerate are on by default if empty render-trigger list.
Tune performance of chunk fetching on server thread - reduce lag
Add support for Fancy Fences wall rendering
Add workaround for IE10 zoom issue (force IE9 compatibility)
I have a simeler problem as someone3x7
Package 1:java-1.6.0-openjdk-1.6.0.0-1.28.1.10.10.el5_8.x86_64 already installed and latest version
Craftbukkit dev build for minecraft 1.4.6 (version CraftBukkit 1.4.6-R0.3)
Problem with even rendering dynmap in world. Im usesing only dynmap version 1.4.6-R0.3 (2/1/2012) ServerIP: http://85.17.134.88:8123/ and http://85.17.134.88/dynmap
Error:
13:16:49 dynmap: Full render of 'world' finished.
13:18:19 Server: /dynmap fullrender
13:18:21 CONSOLE: [INFO] World name is required
13:18:30 Server: /dynmap fullrender world
13:18:31 CONSOLE: [INFO] Full render starting on world 'world'...
13:18:31 CONSOLE: [SEVERE] [dynmap] Exception during render job: world=world, map=org.dynmap.hdmap.HDMap@6577e8ce
13:18:31 CONSOLE: [SEVERE] java.lang.NullPointerException
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.TexturePackHDShader$ShaderState.<init>(TexturePackHDShader.java:94)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.TexturePackHDShader.getStateInstance(TexturePackHDShader.java:231)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.HDMapManager.getShaderStateForTile(HDMapManager.java:125)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.IsoHDPerspective.render(IsoHDPerspective.java:1413)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.HDMapTile.render(HDMapTile.java:96)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.MapManager$FullWorldRenderState.processTile(MapManager.java:661)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.MapManager$FullWorldRenderState.run(MapManager.java:595)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.MapManager$DynmapScheduledThreadPoolExecutor$1.run(MapManager.java:180)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.MapManager$DynmapScheduledThreadPoolExecutor$2.run(MapManager.java:196)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.FutureTask.run(FutureTask.java:166)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
13:18:31 CONSOLE: [SEVERE] at java.lang.Thread.run(Thread.java:679)
This error happens when we've got an invalid perspective - you're configured to be using the standard ones, so the concern would be that one or more of the standard definition files is missing or bad. Can you give me a pastebin of all the server.log messages you see from dynmap during server startup?
well this is strange, that latest version of dynmap crashes the server once it's posted the [Enabled] status message, your lucky i was able to get the crashlog even.
the paste expires in a month, just to not clutter up pastebin's servers.
Rollback Post to RevisionRollBack
24 hours gone again, wasted in futility, welcome to minecraft modding, that is (unfortunately) our community.
(an ode to minecraft modding)
i keep making the same mistake, i think "oh, i've given them a few months, surely it'll be fixed by now" THAT is why i seem to ALWAYS be angry to some of you, my advice is to get the lead out.
there were nice things here, until the mod author threw a tantrum.
well this is strange, that latest version of dynmap crashes the server once it's posted the [Enabled] status message, your lucky i was able to get the crashlog even.
the paste expires in a month, just to not clutter up pastebin's servers.
Looks like some sort of obfuscation mismatch - which specific Forge are you using? Seeing a couple of other exceptions before ours, as well, that suggest some version mismatches (looks like an EE one versus RP, and a ChickenChunks one)
Edit: OK - see that you're on 489. I build with an earlier version, but that shouldn't result in a break - and its the same version I build DynmapForge 1.3 with.
Edit2: Just tried 489, and it works fine - the error reported in your log indicates an error trying to load a class, l.class, that is most certainly in the server jar. I think the earlier exception at line 2509, which is caused by a NPE in the ASM code at line 4548 MAY HAVE compromised the class loading/patching. In any case, I'd suggest doing whatever you need to do to make that first exception "go away".
i'm not entirely sure, i figured it was a compatible version though since the one we have is the 1.3 alpha 2 which says it needs the same version.
we're running the direwolf20 pack server v3 with added mods.
Rollback Post to RevisionRollBack
24 hours gone again, wasted in futility, welcome to minecraft modding, that is (unfortunately) our community.
(an ode to minecraft modding)
i keep making the same mistake, i think "oh, i've given them a few months, surely it'll be fixed by now" THAT is why i seem to ALWAYS be angry to some of you, my advice is to get the lead out.
there were nice things here, until the mod author threw a tantrum.
I tried one but it didn't render any blocks. Also the new RP2 blocks don't render.
SuperSlopes is a bit of a mess that way - its been moved around a bit, and incorporated elsewhere. Best place to start is to look at the corresponding renderdata/superslopes4-*.txt files (unless you're using 1.2.5, which would be the superslopes-*.txt files). The modname indicates the module name(s) we key off of: if those don't match, it isn't going to work. Secondly is the cfgfile lines - if these don't match the path and name of the config file containing the block IDs for the mod, we're not going to work.
Presently, the older Kaevator's SuperSlopes is supported via the superslopes-* files, and matches mod_Kaevator_Slopes, and uses config/KaevatorSuperSlopes.props for finding block IDs. The newer one was SuperSlopes 4.2, from here (http://www.minecraftforum.net/topic/1334173-132131-superslopes-wallpaper-frames/), which appears to have been discontinued and open-sourced (last version 1.3.2). Finally, we've got the version that is in BetterWorlds (which IS actually current and supported....).
Don't ask me to support another one - SuperSlopes is too much of a mess since being abandoned, and there are just too many versions floating around. At this point, I'd only consider the BetterWorld one "current", and if there is a properly maintained version of the existing ones, I'd update to make them work.
If you didn't know, you can request new hooks for forge on their site.
LOL - yep - as a Bukkit-Bleeding team member, I'm actually as likely to try to put together a PR with the changes - hate asking other folks to do work for me But, thanks for the pointer.
I'll be pushing 1.4-alpha-1 out tonight for Forge 1.4.6 - any requests for other Forge versions?
This usually means that you didn't extract the whole ZIP file - our web (HTML, javascript, etc) comes from the files that wind up in the dynmap/web directory tree. Without them, we'll still make our tiles (that is, the tiles directory under the dynmap/web directory), but not have the actual HTML and code needed for the web site itself.
Right - Forge defaults to the 'hires' templates: consider 'lowres' or 'vlowres'. Also, if there are any maps you don't want/need (cave is popular to drop), you can disable those.
Those refer to player faces not rendering, not lack of player position (you'll get an outline) - not clear to me that that is the same thing (unless that is what you're getting). I can point you to almost any of the 25,000 servers currently running Dynmap, and you'll see it working - trust me, its not a feature that I'd only get a couple of folks b*tching about if it wasn't working.
First question - is your server able to DNS resolve and access the faces URL? See skin-url setting (http://s3.amazonaws....ns/%player%.png is the pattern). Since the server fetches and processes the skins to make the faces, this needs to be usable by the server - both DNS and firewall-wise.
On the walls, be sure that you don't have some other mod's configuration set to try to use block ID 139 - even if the setting in the configuration file is obsolete, if its in one of the active mods, it can cause us to override the model and texture for the block with the one for the mod. We trust that the IDs are right, and intentionally override what we get from the mods over the vanilla stuff, as older supported versions (e.g. 1.2.5) have mods that use the IDs that have since been claimed by Mojang (for example, the RedPower plants block in Tekkit 3.1.3 uses 139).
24 hours gone again, wasted in futility, welcome to minecraft modding, that is (unfortunately) our community.
(an ode to minecraft modding)
i keep making the same mistake, i think "oh, i've given them a few months, surely it'll be fixed by now" THAT is why i seem to ALWAYS be angry to some of you, my advice is to get the lead out.
there were nice things here, until the mod author threw a tantrum.
XyCraft is on my feature request list - Thaumcraft has been a pain (lots of special rendering and custom models), and Twilight Forest was pretty huge (but so nice!), so I'm behind on some of the mods I'm trying to get supported. If you guys have a list of which blocks would be most important (building materials and landscape blocks tend to be the most important to do first), I can try to get a partial support done quickly (simple cubic blocks tend to be VERY quick to get done).
My two biggest dev priorities this week are 1) Forge performance (Bukkit has the benefit of 2 years of tuning, and the fact that I'm an active Bukkit contributor - Forge support needs more 'love'), and 2) update the Leaflet library (the mapping library we use for the web) to something current (support IE10 and current Chrome better). Both of these are the key items for 1.4, with other mod support being opportunistic.
i honestly decided i'd splurge for a building or two to play around with the xycraft bricks, i'm loving them, now i'm tempted to use shields as pavers
24 hours gone again, wasted in futility, welcome to minecraft modding, that is (unfortunately) our community.
(an ode to minecraft modding)
i keep making the same mistake, i think "oh, i've given them a few months, surely it'll be fixed by now" THAT is why i seem to ALWAYS be angry to some of you, my advice is to get the lead out.
there were nice things here, until the mod author threw a tantrum.
I think you missed the part where I figured out what was causing the faces/location problem and it had nothing to do with dynmap.
I use FancyFences, http://www.minecraftforum.net/topic/1298016- , could that be conflicting?
AHA - this seems likely!
Can you confirm that the vanilla walls wind up being block 210 instead of 139? If so, we can come up with a fix/support for this pretty easily.
Confirmed, all recipes for walls produce the mod version of the walls and use the mod id, which in my specific case is 4095.
Config path:
config/vanillawithsprinkles/FancyFences.cfg
If you didn't know, it's the config # + 256 = 4095
Thanks for the support mikeprimm, your the best
COOL - we can fix this easy I'll try to throw something together for 1.4-alpha-1 (which I hope to get out tonight)
Sweet.
I don't know if it matters, but i realized after I posted that the +256 only applys to items and I double checked the config, the id is actually 4095, not 3911. That math didn't add up anyway
So, i have this server used by one of my staff members, and given to me to use for my own server. I deleted the plugins, and ran the server up again to get all the files unloaded and it working properly. After putting my own map on the server, i began to put more plugins in. One of these plugins was Dynmap.
After attempting to use the /dynmap fullrender world command, and it not updating the dynmap, i was confused.
Dynmap still shows what i believe to be the previous map of the other server, even after putting the "fullrender" command in. The server did tell me it was working on, and was rendering the different chunks.
But it refuses to update on the Dynmap website. I'm wondering if somehow, Dynmap creates files once its actually run, outside of the plugin folder?
Any help you can provide would be greatly appreciated.
I keep getting the following error:
I have a simeler problem as someone3x7
Package 1:java-1.6.0-openjdk-1.6.0.0-1.28.1.10.10.el5_8.x86_64 already installed and latest version
Craftbukkit dev build for minecraft 1.4.6 (version CraftBukkit 1.4.6-R0.3)
Problem with even rendering dynmap in world. Im usesing only dynmap version 1.4.6-R0.3 (2/1/2012)
ServerIP: http://85.17.134.88:8123/ and http://85.17.134.88/dynmap
Error:
13:16:49 dynmap: Full render of 'world' finished.
13:18:19 Server: /dynmap fullrender
13:18:21 CONSOLE: [INFO] World name is required
13:18:30 Server: /dynmap fullrender world
13:18:31 CONSOLE: [INFO] Full render starting on world 'world'...
13:18:31 CONSOLE: [SEVERE] [dynmap] Exception during render job: world=world, map=org.dynmap.hdmap.HDMap@6577e8ce
13:18:31 CONSOLE: [SEVERE] java.lang.NullPointerException
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.TexturePackHDShader$ShaderState.<init>(TexturePackHDShader.java:94)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.TexturePackHDShader.getStateInstance(TexturePackHDShader.java:231)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.HDMapManager.getShaderStateForTile(HDMapManager.java:125)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.IsoHDPerspective.render(IsoHDPerspective.java:1413)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.hdmap.HDMapTile.render(HDMapTile.java:96)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.MapManager$FullWorldRenderState.processTile(MapManager.java:661)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.MapManager$FullWorldRenderState.run(MapManager.java:595)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.MapManager$DynmapScheduledThreadPoolExecutor$1.run(MapManager.java:180)
13:18:31 CONSOLE: [SEVERE] at org.dynmap.MapManager$DynmapScheduledThreadPoolExecutor$2.run(MapManager.java:196)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.FutureTask.run(FutureTask.java:166)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
13:18:31 CONSOLE: [SEVERE] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
13:18:31 CONSOLE: [SEVERE] at java.lang.Thread.run(Thread.java:679)
EDIT
http://85.17.134.88:8123/ for the problem
This error happens when we've got an invalid perspective - you're configured to be using the standard ones, so the concern would be that one or more of the standard definition files is missing or bad. Can you give me a pastebin of all the server.log messages you see from dynmap during server startup?
http://pastebin.com/6Ww1rAJH
the paste expires in a month, just to not clutter up pastebin's servers.
24 hours gone again, wasted in futility, welcome to minecraft modding, that is (unfortunately) our community.
(an ode to minecraft modding)
i keep making the same mistake, i think "oh, i've given them a few months, surely it'll be fixed by now" THAT is why i seem to ALWAYS be angry to some of you, my advice is to get the lead out.
there were nice things here, until the mod author threw a tantrum.
Looks like some sort of obfuscation mismatch - which specific Forge are you using? Seeing a couple of other exceptions before ours, as well, that suggest some version mismatches (looks like an EE one versus RP, and a ChickenChunks one)
Edit: OK - see that you're on 489. I build with an earlier version, but that shouldn't result in a break - and its the same version I build DynmapForge 1.3 with.
Edit2: Just tried 489, and it works fine - the error reported in your log indicates an error trying to load a class, l.class, that is most certainly in the server jar. I think the earlier exception at line 2509, which is caused by a NPE in the ASM code at line 4548 MAY HAVE compromised the class loading/patching. In any case, I'd suggest doing whatever you need to do to make that first exception "go away".
we're running the direwolf20 pack server v3 with added mods.
24 hours gone again, wasted in futility, welcome to minecraft modding, that is (unfortunately) our community.
(an ode to minecraft modding)
i keep making the same mistake, i think "oh, i've given them a few months, surely it'll be fixed by now" THAT is why i seem to ALWAYS be angry to some of you, my advice is to get the lead out.
there were nice things here, until the mod author threw a tantrum.
SuperSlopes is a bit of a mess that way - its been moved around a bit, and incorporated elsewhere. Best place to start is to look at the corresponding renderdata/superslopes4-*.txt files (unless you're using 1.2.5, which would be the superslopes-*.txt files). The modname indicates the module name(s) we key off of: if those don't match, it isn't going to work. Secondly is the cfgfile lines - if these don't match the path and name of the config file containing the block IDs for the mod, we're not going to work.
Presently, the older Kaevator's SuperSlopes is supported via the superslopes-* files, and matches mod_Kaevator_Slopes, and uses config/KaevatorSuperSlopes.props for finding block IDs. The newer one was SuperSlopes 4.2, from here (http://www.minecraftforum.net/topic/1334173-132131-superslopes-wallpaper-frames/), which appears to have been discontinued and open-sourced (last version 1.3.2). Finally, we've got the version that is in BetterWorlds (which IS actually current and supported....).
Don't ask me to support another one - SuperSlopes is too much of a mess since being abandoned, and there are just too many versions floating around. At this point, I'd only consider the BetterWorld one "current", and if there is a properly maintained version of the existing ones, I'd update to make them work.