z929669

To each his own, I guess, but there are lots of things that could bother you about things that look 3-dimensional that are revealed to be only flat polygons upon closer inspection ... normal maps are only a trick and are really a lie when you look closely

Valid input, but I go back to my original premise. Landscape textures and models are our approximation of natural constructs like dirt, stones, rock, and grass. These natural objects have random variation that no artist can ever capture exactly. Thus the detail and randomness that TB adds is an overall improvement, IMO, and it makes the landscape a bit more detailed and interesting at no cost. Blending with the surrounding objects is generally better. Rocks and mountains are significantly improved due to the added bumpiness. With regard to ordered, organized objects, I 100% agree that normals should be created from the same source as the diffuse in order to sync light reflection with the texture shading, but more random and whimsical things like terrain and unordered objects benefit nicely from the added detail. TB is a nice touch for STEP and almost always has been. We can hide a few of the bad ones (there will be very few though), but I think we should keep the mod in STEP. Also, I don't think pop-in is increased by TB but rather reduced, since the LOD usually hint at more detail than the actual models put out.

Any work back from the author? I PM'ed him on the Nexus back in August, and still no response. It occurs to me now that, since the mod is and has been down for some time now, it is not possible to check the permissions regarding re-distribution or use of the mod. It may be OK if we re-upload with credit to the author. Can anyone see if the readMe has any distro info? What about info for cases like this in the Nexus TOS?

My guesses: 1. A = TB2. A = TB3. B = TB4. A = TB5. B = TB6. B = TB7. B = TB8. A = TB9. B = TB10. B = TB11. A = TB (the vanilla normal is better in this one case IMO)12. B = TB13. A = TB ... so, bumpier is better, no? This is a good lesson in 'creative effects' used to add flare and that sticking to "best practice" is not always best when it comes to art. @Tech ... thanks for posting the screens!

I agree with Aiyen: the bumpier maps win in almost every case. Ideally the normal 'bumps' map directly to the texture shading, but this is terrain, and an overall more bumpiness, regardless of perfect match, creates better blending with the environment, particularly the LOD pop-in as Aiyen also pointed out. The only stark contrast is the second image in the first set. B is just plain bad. The last shot in the first set: B looks better, but I realize that the normal does not match the base texture, and there is some warping, but the overall effect is better. This is background stuff, not focal stuff, so noisier is almost always better, IMO. That is why we have always recommended TB for STEP ... it adds noise to an otherwise relatively smooth terrain. To be fair, I pretty much know which is TB in most of these shots, and it is not better in every case, but it is better in most.

First set: AAB---B Second set: ABBBBA

I have addressed this 'problem' on the mod thread. Basically, we need some screens showing the issues in game. I have never noticed any, and it has been known from the start that Terrain Bump used HRDLC as its source. IMO, it works well with Serious and SRO, regardless of some inconsistencies ... the outcome is favorable in all my experience with the mod ... so in-game screens are important here.

It has been known from the start that the normals were not created from the base textures of most of what we use in STEP; however, I have yet to see any real 'oddities' and have found Terrain Bump to still be an improvement. Can you post a couple screens of some of these issues?

Actually, Semantic popups could be used to get the result you want, if not in the exact format you want. As s4n noted previously, we will not implement any dependencies for sandbox solutions. I do see the usefullness of drill-down guides, and using popups with links to other pages inside with still other popups to 'Drill' into is something that SMW can do (but there may be some browser compat issues). This is why I am posing the idea here, since creating a custom solution for all guides that is not wiki based (e.g., using Drupal), is a major undertaking in order to get even close to what we have here now. The wiki may not be ideal for fancy navigation, I just don't see STEP without a wiki where users can easily help out and contribute

What I am hearing is the desire for functionality akin to drill-down reporting (diving into a data structure at multiple, analogous levels), but users will "drill down" into information that pertains to a set of ordered, inter-dependent choices. Another way to do it is to "pop up" rather than drill down. This may come with more options. SMW probably can do this sort of thing, I think, but it would be a chore. Regardless of what is used, the first step is to construct a reference table mapping the patch-relevant inter-dependencies and whether they are explicit or implicit. (This is "Pack" level info and could be Sematically attached to Pack pages). Then parser functions could be used to guide the logic (e.g., #ifeq), and popup Semantic Forms could be used (we used them briefly in the Pack Forms). We would need to store relationships in a meaningful way, so that all relationships are as directly implicit as possible (that sounds oxymoronic, I know) I think that there is value in this sort of functionality, such that we could apply to the STEP Guides, too. Also, check this out ... I did not delve deeply, but it seems like this could share a lineage with SMW popup forms.

True, but it is useful to have this info within our Dbase, since it allows us to use this info as a filter in mod selection among other things. Many mod attributes are recorded off site, but we collect them anyway for our use here, so it is not redundant to do the same with tags (glad you guys are providing info to LOOT team though, and I encourage we do the same for Skyrim).

Your prerogative. If you think that STEP personnel contributions warrant it, then you could always say: By tony971 & the STEP Team.

Yes, but for those that do not, we can help ;) Also, it would be nice to track the info on our mod pages anyway, so I will see about adding a dropdown list combobox to allow selection of this attribute when adding/editing mod pages. A brief write up of instructions on end user adding tags manually would be useful within our WB Guide for linking elsewhere.

I think it would be helpful if we included instructions on tagging for STEP:Core/Extended mods within the mod notes. It would also be good to introduce the instructions on tagging in the WB Guide and supply links to that from all applicable mod notes and STEP Guide. Actually, adding this info to the mod notes template could be a good idea, but then that assumes that all of our users are sticking strictly to the STEP mod lists. Perhaps adding tagging info to the guide itself is better, but I'd have to think about that. I do think that tags are generally applicable to most mods, regardless of the mod build ... it would be wise of us to begin adding recommended tag attributes to mods though in any case ... waiting for LOOT team to do so may not be most prudent (again, I am not sure how fast they do this). At the end of the day, tagging is fundamentally important to BP functionality, so it would seem that we should be adding this info.

Nice!

Uploading updated version (1.5.6) with fixes now

Thanks for all the good info alt3rn1ty

__NOTOC__ may not be needed, but I found that some of out templates had a TOC, so need to trace what causes that .. also, thanks for beginning the updates!

OK, cool

I had changed the Video template actually, adding a <br />. I have since reverted that and updated the useage examples of the RelatedVideos template ... sorry about that!

Breaks would need to go into the Video template master as far as I can tell in order to avoid use of bullets. I updated the template page useage examples (not the template though) to show more possibilities. I guess i would want the ability to show as a horizontal 'list' as well, but that would require a margin adjustment ideally. Even better, the #ifeq parser function could be used to detect use of bullets and optionally adjust the margins accordingly. I will let DY decide.

Thanks ... I also found that if TOC right/left is present in any way, TOC limit has no effect (even if correctly parameterized), so that was my problem.

Click in upper right of wiki: TOOLBOX > Special Pages > Templates ;)

Hmmm, I still don't get it ... If you understand it, could you update the Template page as I describe here? I am trying to implement on Neo's old guide, but no luck. I left another comment on the talk page.

New Topic Biolerplate <p> <span style="font-size:14px; font-weight:bold;">Discussion topic:</span><br> <span style="font-size:24px; font-weight:bold;"><a data-ipb="nomediaparse" href="https://stepmodifications.org/wiki/Template:TemplateName" rel="">Template:TemplateName</a></span> </p> <hr> <p> &nbsp; </p> When creating templates on the wiki, please use the following format, which strictly implements the 'noinclude'/'includeonly' tags and relevant HTML and adds other useful info. Cut/paste EXACTLY and edit in place (please don't add additional line breaks or markup unless absolutely necessary). Template code MUST be placed between the 'noinclude'/'includeonly' tags without spaces or line breaks. Spaces and line breaks can lead to unexpected results in certain situations. Any linked templates under "Related Templates" should take the form of {{:TEMPLATE NAME}} (note the colon at front). Available Template Categories New template Biolerplate <includeonly>__NOTOC__<includeonly><INSERT TEMPLATE CODE HERE WITHOUT ANY SPACES OR LINE BREAKS></includeonly><noinclude>__NOTOC__[[Category:Template Category Name]][https://stepmodifications.org/forum/topic/15978-pagetitle/ '''Forum Topic'''] == Purpose & Usage == Describe what this template is intended to do and how it works. === Required Parameters === <span class="salmontx">'''parameterName'''</span> - parameterDescription : '''Values''' :: Default: [ n/a; <code>parameterName=parameterDefaultValue</code> | <code>parameterName=parameterDefaultValue</code> ] :* ''parameterDefaultValue'' ... :* parameterValue2 :* parameterValue3 :* parameterValueN ... === Optional Parameters === : '''Values''' :: Default: [ n/a; <code>parameterName=parameterDefaultValue</code> | <code>parameterName=parameterDefaultValue</code> ] :* ''parameterDefaultValue'' ... :* parameterValue2 :* parameterValue3 :* parameterValueN ... == Examples == : '''Code:''' <code><nowiki>{{TEMPLATE NAME AND PARAMETERS}}</nowiki></code> : '''Result:''' :: {{TEMPLATE NAME AND PARAMETERS}} == Related Templates == [[:RELATED TEMPLATE NAME AND ARGUMENTS]] </noinclude>