<!--QuoteBegin--Icecream+Aug 3 2003, 07:26 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Icecream @ Aug 3 2003, 07:26 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> How to add the littel icons for to Minimap??? will they automaticel createt if i build the the minimap??? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> yse!
Does that build minimap command also build the minimap for the players or just the comm's map? It seemed to me that that was an overview map, not a sprite.
Quick thought on the new (very much improved!) minimaps... I'd really like to see underwater areas on the map -- they are currently treated like the void, cutting off some areas from the final overhead schematic of the level. Bast's link from Feedwater Control Hive to Water Treatment, for instance, is absent in the minimap (and important!).
IMO, it's desirable for the minimap to have the following display properties for water areas: <ul><li>they show up on the map so that underwater paths aren't missing<li>They are clearly marked as different from dry land so that the players can tell at a glance they are submerged<li>they fit the current visual theme of the minimap sprite (blues, darker == lower)<li>they don't make it difficult to see the new overlay sprites for players, buildings, weldables, etc.</ul>My proposed solution: use a 50% dither between the color that would have been used if the item were a dry floor and the alphatest color, and draw the walls around the water as if they were dry areas--this would result in a translucent area.
The solution above would mean that water can't be mistaken for normal map areas but would still be visible to players. It keeps the current color scheme so it doesn't interfere with the map overlays, and relays the height of the water surface using the same system as dry land. Alternately, the height of the surface under the water layer could be used (the bottom of the pool).
The thumbnails below are linked to before and after screenshots of a hand-edited minimap sprite in game to demonstrate what I mean (cropped but otherwise unretouched screenshots converted to gif to make them web viewable--didn't use jpeg since the compression would blur the effect of the dither and make it look more like true translucency than it is):
<i>Disclaimer: Level is a work in progress, please disregard poor quality/unfinished layout/textures/lighting/etc.--this couldn't even be called an alpha, but illustrates what I'd like to see in the minimap <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--></i>
Also an option is to simply hand-edit the minimap of your own level when you compiled the final version. It took me about 2 hours for each of the 2 maps I made so-far, including sector names. It should take even less time if you're doing it for your own map, since you know the layout better. Examples for ns_lost and ns_mineshaft, as well as some information on how to edit the sprites, can be found <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=1&t=40179' target='_blank'>here</a>.
Unfortunetely editing the minimaps for the other maps (apart from bast) should take more time, since their mappers used the NULL texture on info_locations, making it invisible in QuArK's BSP viewer <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
<!--QuoteBegin--XP-Cagey+Aug 4 2003, 12:53 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Aug 4 2003, 12:53 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> The thumbnails below are linked to before and after screenshots of a hand-edited minimap sprite in game to demonstrate what I mean (cropped but otherwise unretouched screenshots converted to gif to make them web viewable--didn't use jpeg since the compression would blur the effect of the dither and make it look more like true translucency than it is):
<i>Disclaimer: Level is a work in progress, please disregard poor quality/unfinished layout/textures/lighting/etc.--this couldn't even be called an alpha, but illustrates what I'd like to see in the minimap <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--></i>
Implementation should be pretty simple... <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> OMG, it has a 'Marathon' (if you know what Marathon is) touch to it, I love it!
<!--QuoteBegin--Wolv+Aug 4 2003, 01:28 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Wolv @ Aug 4 2003, 01:28 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Also an option is to simply hand-edit the minimap of your own level when you compiled the final version. It took me about 2 hours for each of the 2 maps I made so-far, including sector names. It should take even less time if you're doing it for your own map, since you know the layout better.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I know what you're saying, and I did hand-edit the sprite for those screenshot pics, but there are a few reasons why I'd rather see the buildminimap algorithm updated instead of using hand-edits for each map:
<ul><li>Completeness... it's simply not possible to hand-edit each map as it's released (even at an hour apiece it would be a huge commitment), and adding water information requires placing routes on the map; it's tedious to hand-measure and place walls in the sprite even with the bsp loaded in Quark. I think it's too much to ask of map authors to add this step as a common practice, and if it's not universally adapted the problem of invisible paths will persist. Updating the minimap builder won't cover previously created maps, but it will allow individuals to create consistant updated minimaps for them without an external editor or a major time commitment. <li>Adaptability... as the NS 2.0 release demonstrated, the minimap generator could have future style changes (I'm asking for one <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->)--any hand-edited sprites would need to be adapted to match new standards as they are introduced. It would be much less painful to auto-generate new sprites than to have to edit them by hand again. Anybody who worked on customizations for a 1.0x sprite, for instance, has to go back to the drawing board now. <li>Uniformity... I'd like to see the developer's vision carried out uniformly across all of the custom maps to the fullest extent possible (I'm guessing we're not in agreement about this last point since you're adding text to the sprites, Wolv, but I'm guessing you can see the reasoning behind and agree with the first two points).</ul>
I also believe (given my present knowledge and a few guesses) that it would be less effort to make the change to the code than to hand edit even a few sprites... I don't have access to the code, but I don't forsee any major obsticles in implementing the system I've described--if the depth test returns the information in the right format, the total time for the change should be under an hour--just add something to the effect of
<!--c1--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->if(itemHitByDepthTest is liquid) { *consider the pixel as part of the map* pixelcolor[x][y] = ((x + y) % 2) ? colorForDepth : alphatestcolor; }<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->instead of<!--c1--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->if(itemHitByDepthTest is liquid) { *don't consider the pixel as part of the map* }<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
replacing the pseudocode with the appropriate items that I can't see in the black box <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I agree that automatic generation is the best solution, theoretically, but I think there will always be things left to clean up. If you look at the attached comparison of an original and fixed frame of ns_mineshaft (without the sector names) you'll notice large errors in the original frame, that the automatic generation seems to have made for no apparent reason. So the water isn't the only problem. And even if the code could be optimized to generate correct frames, there'll always be cases where it will fail, such as with the window between Gamma Deck Access and Equilibrium Regulation on NS_Lost.
I think hand-editing of the minimap should be left to the mapper, to be used when he wants to add just that little polished touch to his map. About the issues you brought up:
<i>Completeness...</i> I agree that completeness would be a nice goal, I'm just saying I doubt it's possible. Note that I still think the autogenerator is a good tool, just that it's output needs to be improved here and there. This is much less work then actually generating the entire minimap from scratch.
<i>Adaptability...</i> To update the sprites once per serious client update doesn't seem like all that much work for a mapper. He'll probably have to change his map anyway, to accommodate for changed balance.
<i>Uniformity...</i> I agree that for the finished product a uniform style is necessary, and believe that the developers can enforce that by setting certain guidelines for the finished product, like how to handle water, vents and vents overlapping the level. If the automated generator would handle that, that's only better of course, but there will always remain places to fix. Sector naming probably won't make it in a uniform style, since that would be a significantly larger amount of work then just touching up the errors and would be harder to do consistently.
Comments
yse!
And, Yes.
Max
IMO, it's desirable for the minimap to have the following display properties for water areas:
<ul><li>they show up on the map so that underwater paths aren't missing<li>They are clearly marked as different from dry land so that the players can tell at a glance they are submerged<li>they fit the current visual theme of the minimap sprite (blues, darker == lower)<li>they don't make it difficult to see the new overlay sprites for players, buildings, weldables, etc.</ul>My proposed solution: use a 50% dither between the color that would have been used if the item were a dry floor and the alphatest color, and draw the walls around the water as if they were dry areas--this would result in a translucent area.
The solution above would mean that water can't be mistaken for normal map areas but would still be visible to players. It keeps the current color scheme so it doesn't interfere with the map overlays, and relays the height of the water surface using the same system as dry land. Alternately, the height of the surface under the water layer could be used (the bottom of the pool).
The thumbnails below are linked to before and after screenshots of a hand-edited minimap sprite in game to demonstrate what I mean (cropped but otherwise unretouched screenshots converted to gif to make them web viewable--didn't use jpeg since the compression would blur the effect of the dither and make it look more like true translucency than it is):
<a href='http://xp-cagey.com/images/minimap_before.gif' target='_blank'><img src='http://xp-cagey.com/images/minimap_before_thumb.jpg' border='0' alt='user posted image'></a> <a href='http://xp-cagey.com/images/minimap_after.gif' target='_blank'><img src='http://xp-cagey.com/images/minimap_after_thumb.jpg' border='0' alt='user posted image'></a>
<i>Disclaimer: Level is a work in progress, please disregard poor quality/unfinished layout/textures/lighting/etc.--this couldn't even be called an alpha, but illustrates what I'd like to see in the minimap <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--></i>
Implementation should be pretty simple...
Examples for ns_lost and ns_mineshaft, as well as some information on how to edit the sprites, can be found <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=1&t=40179' target='_blank'>here</a>.
Unfortunetely editing the minimaps for the other maps (apart from bast) should take more time, since their mappers used the NULL texture on info_locations, making it invisible in QuArK's BSP viewer <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
<a href='http://xp-cagey.com/images/minimap_before.gif' target='_blank'><img src='http://xp-cagey.com/images/minimap_before_thumb.jpg' border='0' alt='user posted image'></a> <a href='http://xp-cagey.com/images/minimap_after.gif' target='_blank'><img src='http://xp-cagey.com/images/minimap_after_thumb.jpg' border='0' alt='user posted image'></a>
<i>Disclaimer: Level is a work in progress, please disregard poor quality/unfinished layout/textures/lighting/etc.--this couldn't even be called an alpha, but illustrates what I'd like to see in the minimap <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--></i>
Implementation should be pretty simple... <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
OMG, it has a 'Marathon' (if you know what Marathon is) touch to it, I love it!
I know what you're saying, and I did hand-edit the sprite for those screenshot pics, but there are a few reasons why I'd rather see the buildminimap algorithm updated instead of using hand-edits for each map:
<ul><li>Completeness... it's simply not possible to hand-edit each map as it's released (even at an hour apiece it would be a huge commitment), and adding water information requires placing routes on the map; it's tedious to hand-measure and place walls in the sprite even with the bsp loaded in Quark. I think it's too much to ask of map authors to add this step as a common practice, and if it's not universally adapted the problem of invisible paths will persist. Updating the minimap builder won't cover previously created maps, but it will allow individuals to create consistant updated minimaps for them without an external editor or a major time commitment. <li>Adaptability... as the NS 2.0 release demonstrated, the minimap generator could have future style changes (I'm asking for one <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->)--any hand-edited sprites would need to be adapted to match new standards as they are introduced. It would be much less painful to auto-generate new sprites than to have to edit them by hand again. Anybody who worked on customizations for a 1.0x sprite, for instance, has to go back to the drawing board now. <li>Uniformity... I'd like to see the developer's vision carried out uniformly across all of the custom maps to the fullest extent possible (I'm guessing we're not in agreement about this last point since you're adding text to the sprites, Wolv, but I'm guessing you can see the reasoning behind and agree with the first two points).</ul>
I also believe (given my present knowledge and a few guesses) that it would be less effort to make the change to the code than to hand edit even a few sprites... I don't have access to the code, but I don't forsee any major obsticles in implementing the system I've described--if the depth test returns the information in the right format, the total time for the change should be under an hour--just add something to the effect of
<!--c1--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->if(itemHitByDepthTest is liquid)
{
*consider the pixel as part of the map*
pixelcolor[x][y] = ((x + y) % 2) ? colorForDepth : alphatestcolor;
}<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->instead of<!--c1--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->if(itemHitByDepthTest is liquid)
{
*don't consider the pixel as part of the map*
}<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
replacing the pseudocode with the appropriate items that I can't see in the black box <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
And even if the code could be optimized to generate correct frames, there'll always be cases where it will fail, such as with the window between Gamma Deck Access and Equilibrium Regulation on NS_Lost.
I think hand-editing of the minimap should be left to the mapper, to be used when he wants to add just that little polished touch to his map. About the issues you brought up:
<i>Completeness...</i>
I agree that completeness would be a nice goal, I'm just saying I doubt it's possible. Note that I still think the autogenerator is a good tool, just that it's output needs to be improved here and there. This is much less work then actually generating the entire minimap from scratch.
<i>Adaptability...</i>
To update the sprites once per serious client update doesn't seem like all that much work for a mapper. He'll probably have to change his map anyway, to accommodate for changed balance.
<i>Uniformity...</i>
I agree that for the finished product a uniform style is necessary, and believe that the developers can enforce that by setting certain guidelines for the finished product, like how to handle water, vents and vents overlapping the level. If the automated generator would handle that, that's only better of course, but there will always remain places to fix. Sector naming probably won't make it in a uniform style, since that would be a significantly larger amount of work then just touching up the errors and would be harder to do consistently.