Got it working but my map does not look the same as the one advertised?
Does the 1.7.10 version not have the updated map?
it does, but I'd advise downloading it from the official source as the world map is a recent addition (for 1.7.10) and some other site ripping it off might not have the most up to date. That said, there was obviously a problem with the hosting at Curse, but it seems to be resolved for the moment. If it proves unworkable I'll host it elsewhere and provide a link here
One thing I keep forgetting to mention is that sometimes in the world map, scrolling in and scrolling out doesn't work. If I go to another dimension on the same server, like the End, it will work there, but in the overworld, it won't.
if you didn't see the changelog, this should be fixed in 1.5.2. redid the mouse processing code to not lose input when the framerate dips a bit
Great mod! I really like the world map that's been added. I do have two questions/requests related to the world map though. Would it be possible, in future, to add support for servers with multiple separate worlds? I have one of my own so such a feature would be greatly appreciated. Secondly, it would be nice to be able to zoom out farther. I find that, for me at least, the farthest available zoom-out level is just not nearly enough.
zooming out farther would take more RAM. I might make it possible with some config option if you are fine with using 4 times the RAM to zoom out to 0.5 instead of just 1:1. It would be simpler if the world map was just stored PNGs, but each region shown is made up of the info needed to assemble the image on the fly to react to time of day and resource pack changes.
Basically, dumb problem. I am using 1.8, but the download button only gave the 1.7 version. There was no indication of a separate 1.8 files, So I assumed it was compatible with 1.8. Wasn't. Did a lot of digging, thought maybe some of my mods weren't compatible. Tested them all. Then I noticed the "files" tabs, where, low and behold, the 1.8 files was housed. So yeah, it was a pretty silly problem =p
haha I see why you just deleted it. Still thank you for posting it, if it happened to you it could happen to someone else, and it might help them see how you fixed it!
UPDATE: 1.5.3
fixes for compatibility with shaders mod (roundmap stenciling, blurred text on worldmap UI)
more consistent getting the name from multiverse servers with the requisite plugins
haha I see why you just deleted it. Still thank you for posting it, if it happened to you it could happen to someone else, and it might help them see how you fixed it!
UPDATE: 1.5.3
fixes for compatibility with shaders mod (roundmap stenciling, blurred text on worldmap UI)
more consistent getting the name from multiverse servers with the requisite plugins
Hello! I apologize if this is something you can't remedy, but I saw in your above post some fixes for the Shaders mod and figured I'd give this a shot.
The Colored Lights mod does some funky stuff to the rendering of waypoints:
A waypoint - no issues.
A waypoint with Colored Lights mod installed. Only the text is garbled - the beam itself is faint but there.
Also, when Dynamic Lighting is enabled in the Options menu all maps render with a red overlay:
Without Colored Lights, no issue.
With Colored Lights, Minimap fullscreen and procedural maps all have red tint (untinted chunks hadn't been refreshed as I loaded the world without CLC at first).
If it helps, the text issue has only been present since your 1.5.x backport to 1.7.10 - text was legible in Voxelmap 1.2.3. The waypoint beams were still very faint but CLC does that to just about every other minimap mod I've tested. I posted this in case there was something you could do on your end to make these two mods play nicer together - there are no other errors or crashes that I've found and I've been testing Colored Lights extensively. Thank you for your time!
*highly educated guess*: the first issue is colored lights not using the GlStateManager and glBind'ing a texture directly. The state manager then doesn't know about it, so the next time I go to bind the font texture the state manager thinks it's already bound and doesn't do anything, and the text renders with whatever texture Colored Lights bound. If that is the case, it is their issue to fix, as it means they are not playing nice with vanilla minecraft or any other mods that use the state manager (and are also missing out on some speed boosts the state manager provides)
*less educated guess*: second issue is colored lights almost certainly has to be using a different lighting method that doesn't use the 16x16 array vanilla does (0-15 for block lights, 0-15 for sky lights) which allows a 0-255 byte as an index into the array of ints for different light values. The fact that lighting works at all tells me they are probably now using 3 separate 16x16 arrays, one each for RGB. The first is red, and when I ask for the value from the light table I am getting the value from the red table.
That would be technically fixable, though I'd likely need to take a peek at their source, have a stub to compile against, and test for its presence and use a different code path if it's detected. TBH I am honestly not likely to do that much, especially since it would only fix the livemap. The persistent map would never show accurate colors without me changing the cached data format to allocate more bytes to lighting, which I am definitely not going to do
I'm having and issue with this mod. It was working fine for quite a while and I loved it, but suddenly both maps stopped working. All I get is black. Any ideas? Does optifine interfere with this mod?
*highly educated guess*: the first issue is colored lights not using the GlStateManager and glBind'ing a texture directly. The state manager then doesn't know about it, so the next time I go to bind the font texture the state manager thinks it's already bound and doesn't do anything, and the text renders with whatever texture Colored Lights bound. If that is the case, it is their issue to fix, as it means they are not playing nice with vanilla minecraft or any other mods that use the state manager (and are also missing out on some speed boosts the state manager provides)
*less educated guess*: second issue is colored lights almost certainly has to be using a different lighting method that doesn't use the 16x16 array vanilla does (0-15 for block lights, 0-15 for sky lights) which allows a 0-255 byte as an index into the array of ints for different light values. The fact that lighting works at all tells me they are probably now using 3 separate 16x16 arrays, one each for RGB. The first is red, and when I ask for the value from the light table I am getting the value from the red table.
That would be technically fixable, though I'd likely need to take a peek at their source, have a stub to compile against, and test for its presence and use a different code path if it's detected. TBH I am honestly not likely to do that much, especially since it would only fix the livemap. The persistent map would never show accurate colors without me changing the cached data format to allocate more bytes to lighting, which I am definitely not going to do
Quick response! I'll link your post to CptSpaceToaster (CLC dev) so he knows where to start to fix compatibility. He had mentioned he is going to look at his GL stuff after he works on his lighting engine a bit more, so hopefully a few other problems poking around will get remedied with the ones I posted above. Thank you for your insight!
*highly educated guess*: the first issue is colored lights not using the GlStateManager and glBind'ing a texture directly. The state manager then doesn't know about it, so the next time I go to bind the font texture the state manager thinks it's already bound and doesn't do anything, and the text renders with whatever texture Colored Lights bound. If that is the case, it is their issue to fix, as it means they are not playing nice with vanilla minecraft or any other mods that use the state manager (and are also missing out on some speed boosts the state manager provides)
*less educated guess*: second issue is colored lights almost certainly has to be using a different lighting method that doesn't use the 16x16 array vanilla does (0-15 for block lights, 0-15 for sky lights) which allows a 0-255 byte as an index into the array of ints for different light values. The fact that lighting works at all tells me they are probably now using 3 separate 16x16 arrays, one each for RGB. The first is red, and when I ask for the value from the light table I am getting the value from the red table.
That would be technically fixable, though I'd likely need to take a peek at their source, have a stub to compile against, and test for its presence and use a different code path if it's detected. TBH I am honestly not likely to do that much, especially since it would only fix the livemap. The persistent map would never show accurate colors without me changing the cached data format to allocate more bytes to lighting, which I am definitely not going to do
Excuse me for not understanding all the technical words, but what exactly should we ask CLC to change to help with this issue?
I really want those extra colors but at the same time I would never add something that could/would mess with my map.
Rollback Post to RevisionRollBack
VoxelMap, the best map mod! Link Removed
Colored Lights for Minecraft! Link Removed Ever wanted to be a blacksmith?
Excuse me for not understanding all the technical words, but what exactly should we ask CLC to change to help with this issue?
I really want those extra colors but at the same time I would never add something that could/would mess with my map.
the only thing I'd ask him to do is to use the state manager for all openGL calls. That would fix the font rendering issue, and is a good thing to do regardless.
making the map not red: well there's really nothing to be done. VoxelMap's dynamic lighting is tied very closely to Minecraft's default lighting, and that can't really be changed and still have the map's lighting work. You can use the map without dynamic lighting.
If he wanted to do something to retain compatibility with VoxelMap's lighting, there is maybe a possibility. As I said earlier I think he is reusing Minecraft's dynamic texture lightmap for the red portion of his lighting, and probably adding two more to handle blue and green. If instead he added three more, one each for red blue and green, and left the original alone things could work. He could then ignore that original and just use the red green and blue ones, while the map would read from the original. It wouldn't show the added colors of his lighting and would just display how blocks would be lit in vanilla Minecraft, but that would be better than not being able to show night/day at all. That would be a largish change and it's not something I am asking him to do, just brainstorming.
possibilities on my end: rather than getting the sky light level and block light level and using them to get a value from the dynamic lightmap texture, if ColoredLights had a function I could just ask for the light value directly. This would add additional complexity to the map code and like I said wouldn't work for drawing parts of the map that aren't actually loaded in world since only the block light level and sky light level are stored and used to get the lighting from the dynamic lightmap texture. Can't very well change that to query a hypothetical Colored Lights getLightValue() function on a chunk that isn't even loaded.
other possibility for me: instead of relying on values from Minecraft's lightmap texture (which CL is now using for red), I could maintain my own lightmap texture, like Rei's minimap used to do. That involves a lot of duplication of the Minecraft code used to create the lightmap and is sort of ugly.
tl;dr the font garbling is an easy fix that should be done. the lighting itself, eh not sure there's anything to be done
*highly educated guess*: the first issue is colored lights not using the GlStateManager and glBind'ing a texture directly. The state manager then doesn't know about it, so the next time I go to bind the font texture the state manager thinks it's already bound and doesn't do anything, and the text renders with whatever texture Colored Lights bound. If that is the case, it is their issue to fix, as it means they are not playing nice with vanilla minecraft or any other mods that use the state manager (and are also missing out on some speed boosts the state manager provides)
*less educated guess*: second issue is colored lights almost certainly has to be using a different lighting method that doesn't use the 16x16 array vanilla does (0-15 for block lights, 0-15 for sky lights) which allows a 0-255 byte as an index into the array of ints for different light values. The fact that lighting works at all tells me they are probably now using 3 separate 16x16 arrays, one each for RGB. The first is red, and when I ask for the value from the light table I am getting the value from the red table.
That would be technically fixable, though I'd likely need to take a peek at their source, have a stub to compile against, and test for its presence and use a different code path if it's detected. TBH I am honestly not likely to do that much, especially since it would only fix the livemap. The persistent map would never show accurate colors without me changing the cached data format to allocate more bytes to lighting, which I am definitely not going to do
Thank you... my knowledge of OpenGL is rather limited, so when I get some time, I'll take a look. To my understanding, Murray's work did not make use of the state-manager. Murray has since left the project (family things) So it looks like I'm alone on this endeavor.
Edit: Light/color overlay is done using a Vertex and Fragment shader..... but it looks like you're somehow asking that to turn things red... Not sure how yet.
Edit: Edit: You can ask world for the lightvalue directly, and it will give it to you. If you can't handle the extra bits packed into the lightValue, then you can mask them out, as I make sure the vanilla bits are left intact.
Depending on where you are, and what you ask for, you can recieve a variable with the following patterns: In most rendering:
Vanilla: 0000 0000 SSSS 0000 0000 0000 LLLL 0000
CLC: 0000 0000 SSSS RRRR GGGG BBBB LLLL 0000 In world and block:
Vanilla: 00000 00000 00000 0LLLL
CLC: 0RRRR 0GGGG 0BBBB 0LLLL
thanks for the post State Manager is a 1.8 only thing, so it's something else (realized you were on 1.7.10). State manager is nice to have since if it detects a call to bind a texture that is already bound it skips it, which can save some CPU. For instance, the font renderer binds the font texture every single character. Somewhat necessary since the unicode characters are on different textures, but a waste when consecutive letters are in fact on the same sheet.
For 1.7.10, I overrode the font renderer to keep track of its last bound texture and if the next letter wants to bind that, to skip it. It does bind no matter what at the beginning of each string. If I had to guess, it seems like somewhere subsequent to that Colored Lights is binding a texture and my extended Font Renderer is not realizing it and failing to bind the texture for the next letter. I'm not sure where you would be binding a texture during the middle of a string render though, that one has me a bit stumped.
For getting lighting values, I've been taking
int blockLight = chunk.getSavedLightValue(EnumSkyBlock.Block, x & 0xf,height, z & 0xf);
int skyLight = chunk.getSavedLightValue(EnumSkyBlock.Sky, x & 0xf, height, z & 0xf);
then getting the color from EntityRenderer.lightmapColors[skyLight << 4 | blockLight]
poked through your code, saw you had enlarged that array. Also saw that getSavedLightValue(EnumSkyBlock.Block, blah) will return a larger 20bit value in Colored Lights instead of the 0-15 value vanilla does (though the lowest bits are equivalent to said 0-15 for backwards/forwards compatibility purposes ie not breaking saves). Splitting out rgb values from that 20bit value like so
int r = blockLight >> 5 & 15;
int g = blockLight >> 10 & 15;
int b = blockLight >> 15 & 15;
(also if the returned value is less than 16, set r,g,b equal to it)
I can get the light value from your larger lightmapColors array like so
EntityRenderer.lightmapColors[g << 12 | skyLight << 8 | r << 4 | b]
and it functions.
To do so of course I would need to test for the presence of Colored Lights, which is doable but I have so many conditionals in that class already haha
Out of curiosity, why is the sky light value in between g and r like that?
Also posted to your thread before I realized you had posted here. Screenshot of preliminary in game results included
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumit does, but I'd advise downloading it from the official source as the world map is a recent addition (for 1.7.10) and some other site ripping it off might not have the most up to date. That said, there was obviously a problem with the hosting at Curse, but it seems to be resolved for the moment. If it proves unworkable I'll host it elsewhere and provide a link here
if you didn't see the changelog, this should be fixed in 1.5.2. redid the mouse processing code to not lose input when the framerate dips a bit
Forge 11.14.1.1333
LiteLoader 1.8.0
VoxelMap 1.5.1
Thanks!
why assume I haven't thought of this
zooming out farther would take more RAM. I might make it possible with some config option if you are fine with using 4 times the RAM to zoom out to 0.5 instead of just 1:1. It would be simpler if the world map was just stored PNGs, but each region shown is made up of the info needed to assemble the image on the fly to react to time of day and resource pack changes.
Basically, dumb problem. I am using 1.8, but the download button only gave the 1.7 version. There was no indication of a separate 1.8 files, So I assumed it was compatible with 1.8. Wasn't. Did a lot of digging, thought maybe some of my mods weren't compatible. Tested them all. Then I noticed the "files" tabs, where, low and behold, the 1.8 files was housed. So yeah, it was a pretty silly problem =p
UPDATE: 1.5.3
fixes for compatibility with shaders mod (roundmap stenciling, blurred text on worldmap UI)
more consistent getting the name from multiverse servers with the requisite plugins
Hello! I apologize if this is something you can't remedy, but I saw in your above post some fixes for the Shaders mod and figured I'd give this a shot.
The Colored Lights mod does some funky stuff to the rendering of waypoints:
A waypoint - no issues.
A waypoint with Colored Lights mod installed. Only the text is garbled - the beam itself is faint but there.
Without Colored Lights, no issue.
With Colored Lights, Minimap fullscreen and procedural maps all have red tint (untinted chunks hadn't been refreshed as I loaded the world without CLC at first).
*less educated guess*: second issue is colored lights almost certainly has to be using a different lighting method that doesn't use the 16x16 array vanilla does (0-15 for block lights, 0-15 for sky lights) which allows a 0-255 byte as an index into the array of ints for different light values. The fact that lighting works at all tells me they are probably now using 3 separate 16x16 arrays, one each for RGB. The first is red, and when I ask for the value from the light table I am getting the value from the red table.
That would be technically fixable, though I'd likely need to take a peek at their source, have a stub to compile against, and test for its presence and use a different code path if it's detected. TBH I am honestly not likely to do that much, especially since it would only fix the livemap. The persistent map would never show accurate colors without me changing the cached data format to allocate more bytes to lighting, which I am definitely not going to do
Quick response! I'll link your post to CptSpaceToaster (CLC dev) so he knows where to start to fix compatibility. He had mentioned he is going to look at his GL stuff after he works on his lighting engine a bit more, so hopefully a few other problems poking around will get remedied with the ones I posted above. Thank you for your insight!
Excuse me for not understanding all the technical words, but what exactly should we ask CLC to change to help with this issue?
I really want those extra colors but at the same time I would never add something that could/would mess with my map.
Colored Lights for Minecraft! Link Removed
the only thing I'd ask him to do is to use the state manager for all openGL calls. That would fix the font rendering issue, and is a good thing to do regardless.
making the map not red: well there's really nothing to be done. VoxelMap's dynamic lighting is tied very closely to Minecraft's default lighting, and that can't really be changed and still have the map's lighting work. You can use the map without dynamic lighting.
If he wanted to do something to retain compatibility with VoxelMap's lighting, there is maybe a possibility. As I said earlier I think he is reusing Minecraft's dynamic texture lightmap for the red portion of his lighting, and probably adding two more to handle blue and green. If instead he added three more, one each for red blue and green, and left the original alone things could work. He could then ignore that original and just use the red green and blue ones, while the map would read from the original. It wouldn't show the added colors of his lighting and would just display how blocks would be lit in vanilla Minecraft, but that would be better than not being able to show night/day at all. That would be a largish change and it's not something I am asking him to do, just brainstorming.
possibilities on my end: rather than getting the sky light level and block light level and using them to get a value from the dynamic lightmap texture, if ColoredLights had a function I could just ask for the light value directly. This would add additional complexity to the map code and like I said wouldn't work for drawing parts of the map that aren't actually loaded in world since only the block light level and sky light level are stored and used to get the lighting from the dynamic lightmap texture. Can't very well change that to query a hypothetical Colored Lights getLightValue() function on a chunk that isn't even loaded.
other possibility for me: instead of relying on values from Minecraft's lightmap texture (which CL is now using for red), I could maintain my own lightmap texture, like Rei's minimap used to do. That involves a lot of duplication of the Minecraft code used to create the lightmap and is sort of ugly.
tl;dr the font garbling is an easy fix that should be done. the lighting itself, eh not sure there's anything to be done
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThank you... my knowledge of OpenGL is rather limited, so when I get some time, I'll take a look. To my understanding, Murray's work did not make use of the state-manager. Murray has since left the project (family things) So it looks like I'm alone on this endeavor.
Here's some relevant source: https://github.com/CptSpaceToaster/CptsModdingLight/tree/1.7.10/src/main/java/coloredlightscore/src/helper
IRC: #ColoredLightCore
Edit: Light/color overlay is done using a Vertex and Fragment shader..... but it looks like you're somehow asking that to turn things red... Not sure how yet.
Edit: Edit: You can ask world for the lightvalue directly, and it will give it to you. If you can't handle the extra bits packed into the lightValue, then you can mask them out, as I make sure the vanilla bits are left intact.
Depending on where you are, and what you ask for, you can recieve a variable with the following patterns:
In most rendering:
Vanilla: 0000 0000 SSSS 0000 0000 0000 LLLL 0000
CLC: 0000 0000 SSSS RRRR GGGG BBBB LLLL 0000
In world and block:
Vanilla: 00000 00000 00000 0LLLL
CLC: 0RRRR 0GGGG 0BBBB 0LLLL
Edit: Edit: Edit: Git issue tracking progress? https://github.com/CptSpaceToaster/CptsModdingLight/issues/42
For 1.7.10, I overrode the font renderer to keep track of its last bound texture and if the next letter wants to bind that, to skip it. It does bind no matter what at the beginning of each string. If I had to guess, it seems like somewhere subsequent to that Colored Lights is binding a texture and my extended Font Renderer is not realizing it and failing to bind the texture for the next letter. I'm not sure where you would be binding a texture during the middle of a string render though, that one has me a bit stumped.
For getting lighting values, I've been taking
int blockLight = chunk.getSavedLightValue(EnumSkyBlock.Block, x & 0xf,height, z & 0xf);
int skyLight = chunk.getSavedLightValue(EnumSkyBlock.Sky, x & 0xf, height, z & 0xf);
then getting the color from EntityRenderer.lightmapColors[skyLight << 4 | blockLight]
poked through your code, saw you had enlarged that array. Also saw that getSavedLightValue(EnumSkyBlock.Block, blah) will return a larger 20bit value in Colored Lights instead of the 0-15 value vanilla does (though the lowest bits are equivalent to said 0-15 for backwards/forwards compatibility purposes ie not breaking saves). Splitting out rgb values from that 20bit value like so
int r = blockLight >> 5 & 15;
int g = blockLight >> 10 & 15;
int b = blockLight >> 15 & 15;
(also if the returned value is less than 16, set r,g,b equal to it)
I can get the light value from your larger lightmapColors array like so
EntityRenderer.lightmapColors[g << 12 | skyLight << 8 | r << 4 | b]
and it functions.
To do so of course I would need to test for the presence of Colored Lights, which is doable but I have so many conditionals in that class already haha
Out of curiosity, why is the sky light value in between g and r like that?
Also posted to your thread before I realized you had posted here. Screenshot of preliminary in game results included