[wiki/guide request] details on changing localization keys

[ZhornLegacy]

Not a change request to the module, just a sample 'How to' on the subject in the documentation to understand intended use.

Wanting to make use of the newly implemented 'changing localization keys' so my CUB conditions can be labelled more accurately to 5e rules, mostly so I can reference things to my players and not have to translate what the module is doing differently.

Spot > Searching (ie taking the Search action PHB p193) and Dim > Lightly Obscured Dark > Heavily Obscured (PHB p183, both as to utilize the condition for scenarios not related to lighting)

I know I'm not doing it as you may have intended since swapping "stealthy.spot.label" to "stealthy.searching.label" is having the module just default to it's own default Spot.

[ZhornLegacy]

replacing "stealthy.spot.label" with "Searching" on its own works but the same cannot be said for either 'Lightly Obscured' or 'Heavily Obscured'. Will assume the 'space' is the issue

[Eligarf]

You are likely right about the space - sounds crazy but maybe quotes around the whole phrase might work?? The text is just sent as is into the localize function; spaces shouldn't affect anything in the Stealthy module itself. I'll play around with this later; I'm totally new to this localization stuff.

[LukasPrism]

I like these changes in terms to bring them in line with PHB as Zhorn is doing, but I’m not sure how to go about it. Would it be possible to have an option for 5E to use these terms?

[Eligarf]

Actually there is a bug in the experimental part where I reference 'this' in a static function, it should work as you expect when I put out 3.0.1 today. I don't have any objection to changing the names for 5E, I will look. BTW Lukas, any chance you could give the latest pr-BR.json file a lookover? I had to google translate some of the new stuff. And does your translation already use the proper term for 'Searching' if I change that over?

[LukasPrism]

Sorry you must be confusing me with someone else. I’d love to help if I could but only speak English!

[Eligarf]

Indeed 'twas another Lukas. My mistake! (understandable though I think).

[LukasPrism]

Absolutely... and I thought I was special sobs

BTW in case you missed it, I did reply to your message on Discord back on your first release... if you pop this in your CSS it will alleviate the HUD input overlapping other elements:

#ste_hid_inp_box { width: 50px; order: 1; }

The order part is optional... it will just push the input to the end of the list if the user has other modules adding icons to the HUD (like the TVA one in my screens):

Thanks again for such a brilliant and useful module!

[Eligarf]

Next update will have those boxes tightened. Thanks!

[ZhornLegacy]

I am also an idiot in forgetting TokenLightCondition is an entirely separate module and my prior monkeying with it to change its condition references... Just updated to it's latest version and broke all my edits for Lightly/Heavily Obscured Bad Zhorn, never open tickets at 4am... Since LukasPrism has also expressed interest in doing a similar thing, it may be worth asking on that module about an easy way to change the references from dim to lightly obscured and dark to heavily obscured. Last time me doing this manually way digging throw the module's files and doing a lot of word replacing... like a psychopath.

[Eligarf]

One thing to keep in mind when altering the Dim/Dark labels to Lightly Obscured/Heavily Obscured: the effective light level is changed based on the viewer's detection mode, so if you've assigned Lightly Obscured to a token, perhaps for being in mists or shrubs or something, Steathy's viewer detection code is going to treat that as a light level rather than obscuration. These are complications that need a broader scope of system responsibility than I'm willing to tackle with this module. Seems a pedantic difference but I think Dim/Dark better define how Stealthy interacts with the world.

[Eligarf]

I made a wiki page that hopefully addresses the specific issues about replacing stealthy.spot.label

[ZhornLegacy]

An understandable concern on the Lighting vs Obscurement terminology. It has crossed my mind a few times. In an ideal world it'd be splitting it up as 4 conditions, two for lighting (dim/dark) and two for everything else (generic lightly/heavily obscured) being the dozen spell effects and other natural/unnatural phenomena, but as this module along with TokenLightingCondition are still finding there feet (which I really hope takes off, that are an awesome pairing), pushing for scope creep like that at this early stage might not be a well received request.

[Eligarf]

I'll know that Stealthy has become a real boy once it gets some kind of setting inside midi-qol.