BUGS (Mote 1.16.12 Linux64)

[Arsil PS]

BUGS (Mote 1.16.12 Linux64)

macro.create
fontcolor parameter (property?) seems to be ignored and the default black color is used

map explorer
selected (hovered?) entry is unreadable (both background and foreground colors are yellow? or the BG overrides the FG?)

bars not updated (e.g health bars on PC tokens)

Update on state toggling via macro
Sometimes a state gets assigned and removed at the same time, you can tell because the state image appears and then suddenly disappears

Already reported: macro buttons properties edited via macro are not immediately displayed (UI not refreshed?)

(example: updating the "Selected Token" window when changing the BG color of one of its macro buttons)

[Idle Ideas Inc.]

We'll check the macro creation issue.

The default color for list element highlighting seems to be yellow, and no, it's not that fg and bg are the same, it's because the FG color in Linux seems to be white or too bright. These can be changed using the selectors on the macro editor, which we made to also universally set the list item colors, for the other lists in the UI.

Bars were part of the rewrite, side-effects were to be expected, sorry. We'll fix it soon.

State toggling and UI refresh: These work on our dev/test environments for Linux (Ubuntu 16.04+ LTS and 18.04+ LTS) where we do the actual coding and debugging, and are quite "vanilla". We wouldn't have made the release with a statement that this was fixed, if we didn't confirm that it worked. Other factors must be at play, so this will take some time to investigate.

[Arsil PS]

This campaign macro needs "Use selected tokens as context" checkbox ticked.

[h:initScore=1d20]
[h:addToInitiative(0, initScore)]
[h:initiative.sort()]

initiative.sort doesn't work if there are already tokens in initiative. Hard to explain. The macro adds the selected tokens to initiative and sort them.

It works fine the first time (when the initiative is empty), but then if you re-run the macro (with the same selected tokens or other ones), the initiative is not sorted.

The solution can't be to reset initiative first because sometimes you want to add new tokens to an ongoing combat.

This macro also has a weird effect when the "Show Initiative Gain Message" preferences->application option is enabled.

Instead of using the default (main) chat tab, sometimes it opens new chat tabs (labeled after PC tokens) to send the output "token-name has received initiative".

Note: I wasn't able to reproduce this bug, but it happened to me randomly.

EDIT: Ok, it doesn't happen regularly, but a way to help reproduce it involves not just clicking on the macro again and again, but alternating it to using also

"Next" (from the initiative window button or via macro) and then clicking on the macro again.

[Arsil PS]

Using "/table tableName" in a token macro, sends the output in a new chat tab (labeled after the selected token) instead of the default tab.

[Idle Ideas Inc.]

this by design, when token context (i.e. apply to selected tokens or impersonation), is used

[Idle Ideas Inc.]

no promises but we'll look into it. the initiative system is unique from other components in the app, both in Mote and MT, and is tricky because it has both synchronous and asynchronous elements to its workings. It's it never advisable to "mash" controls calling initiative-related functionality, as you might get what you basically described here. definitely not our favorite system to work on, especially since the original author wrote it in a way different from other contributors' contributions.

[Idle Ideas Inc.]

Update on state toggling via macro

Sometimes a state gets assigned and removed at the same time, you can tell because the state image appears and then suddenly disappears.

Already reported: macro buttons properties edited via macro are not immediately displayed (UI not refreshed?)
(example: updating the "Selected Token" window when changing the BG color of one of its macro buttons)

 

 

Please give steps to reproduce. The ones you've stated before work as expected already.

[Idle Ideas Inc.]

please provide a test with tokens and an initiative list that simulates the issue. thanks.

[Arsil PS]

Out of curiosity, is "/table" the only way to get a row from a table via macro or there are also other commands?

[Arsil PS]

Il giorno lunedì 12 novembre 2018 18:37:51 UTC+1, Idle Ideas Inc. ha scritto:

Please give steps to reproduce. The ones you've stated before work as expected already.

Here's a very stripped down framework with only a few campaign macros.

Issue with states (and macro buttons updating after changes)

Select the female cleric token

Try using the "faerie fire" and "darkness" token macros

NOTE 1. See also the issue related to the macro button BG color changed but (sometimes) not immediately updated.

NOTE 2. Most of the time the concentration state is assigned correctly, but once in a while it is not

In case the state was assigned, try using the "Conc" (in the Toggles group) campaign macro that is supposed to remove it

NOTE: this macro sometimes work and sometimes not

You can use the "Long" (in the Rest group) campaign macro to reset the buttons on the token and make them clickable again

Issue with initiative sorting

I suggest to have both the initiative and chat window open and visible

Make sure the preference option "Show Initiative Gain Message" is enabled

Make sure the initiative is empty and "round" is empty too

Select the 2 tokens in the map (the 2 on the left)

Use the "Roll" campaign macro

Now use "Next" on the initiative window

Now keep clicking on the "Roll" campaign macro until new chat tabs are opened (sometimes 1, sometimes 2), labeled after the token names

(if it doesn't work after a while, try resetting the initiative and start over)

A even better test for state toggling

Select the female cleric token

Click the "Charm" (in the Toggles group) campaign macro which is supposed to toggle the charmed state to the selected token

This always, without fail, assign the charmed state and then removes it (and if the token already had the state, it removes it and then adds it again)

Note how, on the other hand, the "Stand/Prone" campaign macro always works flawlessly.

I tried commenting the 2 rows about the input dialog, but what I get is that the command to remove the state is ignored

EDIT: the issue in this case seems to be related to the references to "CharmedBy" which is a Framework Property.

The "Charm v2" campaign macro seems to work fine, it uses getProperty and setProperty instead of using the property name as variable.

Using getProperty and setProperty is probably the best way to manipulate properties via macro, but it should work even the other way(it used to be in previous versions).

[Arsil PS]

I did some debugging and found something about the new chat tabs opened by the initiative gaining message.

Notes:

Always presume that you use the Roll campaign macro when at least one token is selected.

The Roll macro is only supposed to add the selected tokens to the initiative and sort them, not to give the initiative to someone.

It seems like new chat tabs are opened only when you click the "Roll" campaign macro when one of the tokens

listed in the initiative is already marked as the current one (it has that green tick icon).

And apparently using [h:initiative.dropAll()] via macro is not enough to really reset the initiative, it seems it is not

equivalent to using "Remove All" from the initiative window. I say this because - apparently - using the Roll macro

after resetting the initiative that way seems to never have the result of a token as the current initiative holder before

manually advancing (starting) the initiative using "Next" from the initiative window or via macro.

*** EDIT: forget it, using "Remove All" from the initiative windows to reset the initiative doesn't prevent the Roll macro

to end up with a token designed as the current one.

That said, does not using initiative.sort via macro call the same code used by "Sort" from the initiative window?

[Arsil PS]

Here's what happens with initiative.sort

The Roll macro iterates through the selected tokens doing 2 things:

add the token to the initiative

sort the inititiative

(i know I could call the sorting only one time at the end but that is just lazy scripting)

if you use the Roll macro when the initiative is empty, the sorting is correct

Now, if you use the roll macro again (using the same set of tokens already in the initiative),

what happens is that the tokens in the initiative keep the old sorting (as if their initiative

wasn't changed, despite in the list the new value is displayed)

Example: using Roll the first time gives this list:

• fight 22
• rogue 18
• wiz 18
• cleric 17

Using Roll macro again, the initiative value is updated but (despite calling again initiative.sort)

they are sorted again in the same order

• fightwe 12 (was 22)
  
• rogue 18 (got another 18)
  
• wiz 7 (was 18)
  
• cleric 17 (got another 17)

If you use Roll macro again, new values are assigned but the tokens in initiative are sorted using the previous values

• rogue (new value not considered, sorted as first based on the 18 that he got the previous time)
  
• cleric
• fighter
• wiz (new value not considered, sorted as first based on the 7 that he got the previous time)

EDIT: out of curiosity, I tried the dirty workaround of calling initiative.sort twice in the macro, but that doesn't

seem to work (which was probably expected, after all, since initiative.sort is called for every selected token anyway).

[Arsil PS]

Auras work as intended, but light sources don't follow the token. This is what I mean:

[Arsil PS]

Macro Editor, Properties:

If you edit the "Sorting Key" value and then click on "Apply Changes" it doesn't get updated,

you have to click "Enter" on that input field for change to be applied.

All other fields seems to work.

[Idle Ideas Inc.]

Thanks for all the point outs, we'll get to it once time is more free.

Though, with regard to the light source not moving with the token, I think it's not the light, but rather, Fog of War is not set to automatically clear upon movement.

[Idle Ideas Inc.]

there is the Table API. Look it up on the macro editor using the prefix "tables" 

[Arsil PS]

Il giorno venerdì 16 novembre 2018 09:51:26 UTC+1, Idle Ideas Inc. ha scritto:

Though, with regard to the light source not moving with the token, I think it's not the light, but rather, Fog of War is not set to automatically clear upon movement.

Do you mean "GM auto reveal vision field" in Server Settings?

Anyway, FOG was disabled. When FOG is enabled, it seems to work fine. If it is not enabled, it doesn't follow the token.

-----

In the Server Settings (the window you get when starting a server), there's a typo: "Visbility", missing an "i".

It's in the first column, fourth row of the Policies.

Macro Editor. The button to open the theme selector has no tooltip.

[Arsil PS]

Il giorno venerdì 16 novembre 2018 09:56:58 UTC+1, Idle Ideas Inc. ha scritto:

there is the Table API. Look it up on the macro editor using the prefix "tables"

I'm having some trouble with it.

I have this table called ConfusionEffect that rolls a d8

• does nothing
• move in random dir
• melee attack vs random target

It works with

/table ConfusionEffect

but if I use

[r:tables.result("ConfusionEffect")]

I get "Undefined variable: does" (or the first word of the row entry).

If I use (omitting "r")

[tables.result("ConfusionEffect")]

I get "Could not do table lookup: line 1:6: unexpected char: 0x1E"

Am I doing something wrong?

[Idle Ideas Inc.]

when the single-argument version of the function is used, it uses the default roll set for the table. if non was set, it returns nothing. the roll, if present, must be understandable to the parser. if it is, then its result should fit with what's on the table, and finally, the row's value should also be something which is understood by the parser.

please provide the table, for us to investigate. or is it already in your shared campaign?

[Idle Ideas Inc.]

any auto-reveal setting, actually. light always follows the token. have you tried setting its color to something non-transparent and see if moves with the token? can't test right now, sorry.

[Idle Ideas Inc.]

We tested your table using the campaign you shared and it worked ok. Have you checked your copy to see if there's any corruption?

[Idle Ideas Inc.]

we were only able to test states so far, and we still can't replicate using our installed version of 1.16.12. perhaps there is some artifact status carried over from somewhere (MT?) that needs a couple or several applications of the action to get it set straight. have you tried, for example, charming again after "failure"?

[Idle Ideas Inc.]

TL;WR It's fixed, though not quite for the reason reported here.

After dissecting the issue, here are our results:

• This isn't the best way to accomplish the goal. In fact, it's probably the worst way (sorry). 
  
  I'm sure you know that using selected tokens as context means that the entire macro command is executed each time for every token involved. Most people don't know that the Initiative system is tied tightly to the Initiative UI itself. Which means most won't know that doing addToInitiative and initiative.sort on the same block, generates more than the 2 results expected (1 per line). On average, this will generate at least 8 to 10 events, which was why things misbehaved, in the context of the Initiative system we've amended from MT. Our amendments made the system more asynchronous, but this left a window open for elements we've overlooked, to overwrite expected states, which is what happened here.
  
  The sorting was correct, but the values used were not the ones generated by the macro, because everything was done asynchronously.
  
  
• A "better" macro would be one that minimizes cascading events, ideally generating 1:1, with regard to cause and effect. Here's what we came up with on the fly (disable using selected tokens as context):
  
  
  [h, foreach(id, map.selected()), code:{

  [context.set(id)]

  [h:initScore=1d20+Dexterity]

  [h,if(Class=="Bard" && Level>=2):initScore=initScore+math.floor(Proficiency/2)]

  [h,if(Class=="Fighter" && SubClass=="Champion" && Level>=7):initScore=initScore+math.ceil(Proficiency/2)]

  [h,if(Class=="Fighter" && SubClass=="BattleMaster" && Level>=15):SuperiorityDice=math.max(1, SuperiorityDice)]

  [h,if(Class=="Barbarian" && Level>=7):initScore=math.max(initScore,1d20+Dexterity)]

  [h,if(Class=="Rogue" && SubClass=="Swashbuckler" && Level>=3):initScore=initScore+Charisma]

  [h,if(Class=="Monk" && SubClass=="OpenHand" && Level>=20 && SpellSlots1<=0),Code:

  {

  [h:SpellSlots1=4]

  [h, macro("UpdateSpellSlots@Lib:MacroHelper"): ""] 

  }]

  [addToInitiative(0, initScore)]

  }]

  
  

  [h: initiative.sort()]

  [h:state.HasInitiative=0]
  
  Though you'll have to wait for the next update, which addresses the sequence of events, while maintaining asynchronousity across clients, to get the correct ouput.

[Idle Ideas Inc.]

fixed.

[Arsil PS]

I tried it again and now it works. Go figure!

Il giorno sabato 17 novembre 2018 13:41:09 UTC+1, Idle Ideas Inc. ha scritto:

We tested your table using the campaign you shared and it worked ok. Have you checked your copy to see if there's any corruption?

On Saturday, November 17, 2018 at 3:51:29 PM UTC+8, Arsil PS wrote:

TROUBLE WITH THE TABLE API

[Arsil PS]

Having read that, I thought that maybe the problem could be that many of my saved tokens were made many versions of Mote back

(I save them one by one).

So I tried with a fresh new one, but I still get the same issues.

I don't know what to say if you can't replicate the problem.

I thought that the different outcome I get using "Charm" vs "Charm v2" could offer a hint on the problem,

but it seems for you it works fine with both versions.

[Arsil PS]

Updated to 1.17.0. Thanks for the hard work.

Now macro properties can't be changed via macro (e.g. BG color of a button).

Even macro.create arguments seems ignored, at least as far as color and fontcolor are concerned (haven't checked others).

initiative.sort marks the first token as the initiative holder. Shouldn't it simply sort the initiative without making it start

or resetting it (doesn't reset the round count, just the current initiative holder) in case you add tokens to a ongoing fight?

Code completion always active despite being disabled via button.

Still same issues with states. I even tried to delete a state and re-make it (from the framework properties)

to see if something changed, but nothing. I've confirmed that it seems to works fine on Mote 1.17.0 Win64

(I haven't tested it much, it's just at a quick glance).

EDIT: I didn't expect the new version to tackle this issue since you can't replicate it, I just wanted to point out

that the different behaviour of the linux and windows version seems to me like a clue that something is going

on the linux version (and, to be clear, I don't think you guys don't believe me).

By the way, I don't know if this is a problem specifically with win10, but by default updater, cleaner and un-installer

don't work because there are read-only files (in .mote or in the install directory, not sure which one).

[Idle Ideas Inc.]

are you certain you're using the proper property keys "colorKey" and "fontColorKey" for color and font color, respectively?

all sorts keep track of the current holder (if any) and re-applies it after the sort.

we understand that there are likely disparities between OS platforms. As mentioned priorly, we also debugged using Linux environments.

we'll check out the code completion issue, and as for the read-only issue, perhaps you can try another data folder location?

thank you :)