Comm function to post a chat command...

[HoloGnome]

Moon Wizard / Trenloe -

There appears to be a bug in Interface.setLighting when invoked directly (via an extension).

The API says that the supplied string for setLighting should be RRGGBB, but, in fact, the routine is reversing the byte order and treating it as BBGGRR -- for every set of values other than the basic 4 lighting behaviors (odd).

However, when using the chat window /lighting "RGB" command, the byte ordering is as expected for other values.

It was a little confusing at first - i thought I had a bug somewhere because day & forest -- are approximately symmetrical and appeared to work, but not really (night and fire are different). Also, I noticed that the markup contains 32-bit rather than 24-bit values - is that an attempt to compensate for lua's 1-based array indexing?

Anyway - Interface.setLighting() doesn't seem to work as documented, and somehow, the chat version of the command is being byte-swapped (because I pass the same values and it does the right thing). You may also want to check the markup values in the lighting mini-panel to make sure they are as you intend.

OK - wait a minute - hmm...now I am suddenly wondering if this is a Little-Endian byte swapping problem at runtime with lua. Shouldn't be...I am passing the values as strings...

So, if you could check the execution path for Interface.setLighting() on your side and/or let me know, I would appreciate it. Thx!

Edit - I just did some more testing, and it seems like there must be something in the code on the FG side. The 4 default values are not being swapped through the Interface.setLighting() call, but everything else is. If not a bug or other hard-coded behavior, then it's somewhat perplexing. For now, I have left the original 4 unswapped and swapped my other table values. I look forward to the explanation!

[Moon Wizard]

The parameter expected is an ARGB hex string value, where A is the alpha or transparency. If only 6 characters are passed in, then an alpha value of FF is assumed.

Regards,
JPG

[HoloGnome]

OK - thx - makes sense. I figured it was something like that, since I also tried sending 32-bit values to replicate what the buttons were doing and saw no change with the 4 base types, but still saw the byte swapping issue. (very cool, btw)

Any thoughts on the byte-swapping problem/bug with the Interface.setLighting() call?

[Moon Wizard]

OK, I got a chance to investigate this today. The Interface.setLighting function is the only function in the API that expects the color hex string in the AABBGGRR format. Every other function expects it in the AARRGGBB format. It has apparently been this way, since before I started working on the code. The /lighting slash command uses AARRGGBB format, as expected.

Unfortunately, I can't change it to match the other API functions without breaking all existing rulesets, since all the lighting values for forest, fire and night are copied across multiple rulesets. I can potentially address in a future version with a larger version number change, where I can change the behavior based on the ruleset compatibility version.

For now, I have added a note to the ruleset reference page for the Interface package:
https://www.fantasygrounds.com/refdo...cp#setLighting

Cheers,
JPG

[HoloGnome]

Aha! Now I know why I thought the default lighting types were being passed through "unchanged". I never actually looked at them in a color picker - they were already reversed, of course, to match the API. I had based my assumption on our earlier discussion of RGB ordering and the api doc. Haha! Yeah - sounds like a synchronization issue for the next major update.

While you're at it, there are 5 other things that you may want to address with this functionality, as follows:

1. The /lighting chat command does not accept alpha channel input - it will only modify RGB and ignores the alpha byte. Would be nice if it worked.
2. The alpha channel setting should be slewed with the rest of the lighting change, rather than just applied at the end (which tends to wreck the transition effect)
3. There should be a symmetrical Interface.getLighting() call to retrieve the current state of the lighting. There may be transient (extension) effects that want to change and restore lighting from where it currently is, rather than daylight or some other setting. This might also apply to themes that modify the lighting so that extensions can restore the original - or maintain a theme's alpha channel setting with any lighting change (which would be the likely user expectation). Alternately, there could also be an Interface.defaultLighting() call that invokes a default value provided with themes, but that would require a global theme update. Much easier to just have a getLighting() call to return ABGR. (edit - The API should return the last value that was set or the default value if nothing set so that themes don't need to be updated)
4. It should be possible to specify a time domain for the transition in seconds...or Interface.setLighting(ABGR,secs), where secs is optional (is secs optional? ). If there is no secs, then [the population will die and turn into zombies] FG2 would just use the default light slewing time it currently uses.
5. It would also be nice to be able to supply a callback vector so that some action could execute when the slewed lighting change completes.

Thanks for looking into this issue and taking the time to respond! It all makes sense now.

(hmmm...no bbcode for strike-through text? Need to add it: https://www.vbulletin.org/forum/showthread.php?t=77721]) Yes, even the forum bbcode is not HoloGnome-safe. LOL!

To save time:
1. In your AdminCP, go to Custom BB Codes and click Add New BB Code
2. Enter the following info in the appropriate fields:
Title: Strikethrough
Tag: strike
Replacement: <strike><span style="text-decoration: line-through;">{param}</span></strike>

[HoloGnome]

I just looked at the updated note - it would be nice to add documentation for the alpha channel byte.

[HoloGnome]

Added 1 more thing to the list above - callbacks on setLighting.

[HoloGnome]

3.0.4 Regression: Interface.setLighting() and alpha channel Fixed/Verified. You can now set the alpha channel with the /lighting chat command call by passing 4 bytes (except for 00ffffff). However, /lighting with no parameter following it will turn the screen black - in that case, it should probably do nothing or show the help. Also, the alpha change is still applied all at once at the end of the animation rather than slewed with the RGB change.