Help in creation of a macro for initiative in Symbaroum?

1507075288

Edited 1507076064
Nox
Pro
Hi all,  We are gonna start a campaign on a system called symbaroum.  Of course, it is a niche game and there are very few ready to use macros/content for this system.  I want to build a macro to speed up the initiative check for every player AND every enemy.  I'm gonna say I'm a noob with macros and I know very little on how to build them and what I can and can not do with them, but I want to learn (at this proposal if there is any in-depth guide on the forum I'd like if you could be so kind to link it down here). Since there is more experienced people out there i'm here to ask you some help for this. Down to business:  In symbaroum initiative is determined by a specific stat on the character sheet called "Quick" (similar to D&D dexterity). If two character has the same "quick", so you need to check another attribute "Vigilant". If the character has the same quick and the same vigilant, then the initiative is decided by rolling a d20 and who get higher value will go first.  I'd like to build a macro in which I can read every character quick attribute. After that, if someone has the same value I want to read vigilant attribute, and if this is the same aswell we roll a d20 to determine the initiative.  Of course everyone can decide to act later on in the turn, but once this order is set, they can not change it in any way. For the decision to delay the action we can do it by hand since I have no idea about how to implement this with a "?" function.  Of course I want to send the results to the tracker so everyone can see the turn order. I'm open to any adjustment to make this work, but i'd like to avoid the request for manually input values [?{Quick?}/?{Vigilant?}] if possible, or keep it the lowest possible. Hope someone can help :) thanks in advance Edit: It would be nice if the macro would be available only to the gm. 
I don't think there is any way to compare values without an API but you could this the way the 5e OGL sheet uses Dex tiebreakers but it's rather ugly. Something like: [[@{selected|quick}+@{selected|vigilant}/100 +1d20/10000 &{tracker} ]] should so the trick.
Also links: https://wiki.roll20.net/Macros https://wiki.roll20.net/Useful_Macros https://wiki.roll20.net/Turn_Tracker https://wiki.roll20.net/Dice_Reference https://wiki.roll20.net/Text_Chat https://wiki.roll20.net/Character_Sheets These may not be that useful to you but they're worth a look if you want to simplify some stuff on roll20.
1507078833

Edited 1507079645
Nox
Pro
Kyle said: I don't think there is any way to compare values without an API but you could this the way the 5e OGL sheet uses Dex tiebreakers but it's rather ugly. Something like: [[@{selected|quick}+@{selected|vigilant}/100 +1d20/10000 &{tracker} ]] should so the trick. Kyle said: Also links: https://wiki.roll20.net/Macros https://wiki.roll20.net/Useful_Macros https://wiki.roll20.net/Turn_Tracker https://wiki.roll20.net/Dice_Reference https://wiki.roll20.net/Text_Chat https://wiki.roll20.net/Character_Sheets These may not be that useful to you but they're worth a look if you want to simplify some stuff on roll20. Thank you very much, I'm checking those link right now. Yes, the macro looks ugly in the tracker, but it works, it's more than nothing :) thanks a lot! I'll try to improve it over time if i find some way. Is there any way to use that macro on multiple selected tokens at the same time? It would be nice. if I try to select more than one token it considers only the first one.
No problem, and reading through those and referencing is a very good way to learn, at least for me it was/is. Because the vigilant score was divided by 100 so if 2 people had a score of 14 that would add a .14 onto whatever their quick score was and so we need the d20 roll to be an even smaller number so it only comes into play when 2 people have the same vigilant score. So in the example I gave with .14 the 2 people roll the d20 and get 20 and 6 respectively you need the total to end up as .1420 and .1406. If you changed it to 1d20/1000 say those 2 rolls would lead to .16 and .146 respectively, which means the player with Vig 14 who rolled a 20 (to get a .16 modifier) will have a higher initiative than someone with a Vig 15 (who only has a .15 modifier). It's hard to explain in text but essentially the number on the bottom of the fraction needs to be bigger than 2000 and so I chose because it 10000 makes the calculations neater. As far as I know, no not without an API again but you can give a vote to this if you want  https://app.roll20.net/forum/post/1241922/allow-multiple-selected-tokens-to-execute-a-shared-macro
1507084044

Edited 1507084553
Nox
Pro
Kyle said: No problem, and reading through those and referencing is a very good way to learn, at least for me it was/is. Because the vigilant score was divided by 100 so if 2 people had a score of 14 that would add a .14 onto whatever their quick score was and so we need the d20 roll to be an even smaller number so it only comes into play when 2 people have the same vigilant score. So in the example I gave with .14 the 2 people roll the d20 and get 20 and 6 respectively you need the total to end up as .1420 and .1406. If you changed it to 1d20/1000 say those 2 rolls would lead to .16 and .146 respectively, which means the player with Vig 14 who rolled a 20 (to get a .16 modifier) will have a higher initiative than someone with a Vig 15 (who only has a .15 modifier). It's hard to explain in text but essentially the number on the bottom of the fraction needs to be bigger than 2000 and so I chose because it 10000 makes the calculations neater. As far as I know, no not without an API again but you can give a vote to this if you want  https://app.roll20.net/forum/post/1241922/allow-multiple-selected-tokens-to-execute-a-shared-macro Thank you again. I was wondering how could I round the result of those calculation to 4 decimals.  Fact is that even if I should get something like 12.1409 , in turn tracker i get 12.140899999999999999999999 and it looks awful. I dont get why I get this, it seems a bug. I tried to multiply and divide for 10000, but i still get the same values. I only have been able to do this: [[@{selected|quick}+round(@{selected|vigilant}/100+1d20/10000*10000)/10000 &{tracker}]] But i get values like 12.0012. The first two decimals are always 00 Edit: I finally did it! The macro looks like this : [[@{selected|quick}+round((@{selected|vigilant}/100+1d20/10000)*10000)/10000 &{tracker}]] And it works quite well.  If I'm missing some error let me know, but now it gives me 4 decimal (or 3 if the 4th is a 0) and seems to work just fine. I still do not get why in the turn tracker I got those strange decimals, but this fixed it. I was afraid that the Order of operation would not get those parenthesis but it seems it worked out well.
Yep I just tried it and I'm also getting the same errors, I have no clue why. I'm guessing roll20 doesn't like numbers that small because it works if you just scale up each part by 100, like this: [[@{selected|quick}*100+@{selected|vigilant} +1d20/100 &{tracker} ]] But then you get vaues like 1214.09 in the tracker which works exactly the same just looks a little odd.
1507087586

Edited 1507087976
It's a problem with JavaScript, as I understand it.
Rabulias said: It's a problem with JavaScript, as I understand it. That's a new one, I'm used to roll20 having the limitations haha. Just had a quick google and from what I can see this is happening because of Javascript's binary nature. It struggles to deal with small decimals that aren't fractions of powers of 2, this means your best option would be to change it to 1d20/2056, which gives horrible numbers so I'm probably just leave it with what you have if it's working.
1507124909
Nox
Pro
Kyle said: Yep I just tried it and I'm also getting the same errors, I have no clue why. I'm guessing roll20 doesn't like numbers that small because it works if you just scale up each part by 100, like this: [[@{selected|quick}*100+@{selected|vigilant} +1d20/100 &{tracker} ]] But then you get vaues like 1214.09 in the tracker which works exactly the same just looks a little odd. With this adjustment the macro works as intended, because by rounding the result it removes the decimals. [[@{selected|quick}+round((@{selected|vigilant}/100+1d20/10000)*10000)/10000 &{tracker}]] Just don't ask me why :D
Nicholas M. said: With this adjustment the macro works as intended, because by rounding the result it removes the decimals. [[@{selected|quick}+round((@{selected|vigilant}/100+1d20/10000)*10000)/10000 &{tracker}]] Just don't ask me why :D Don't you need the decimals for this to work? Otherwise you're just comparing quick scores, unless it still stores the decimals somewhere but just doesn't output them to the tracker.
1507127030

Edited 1507127163
Nox
Pro
Kyle said: Nicholas M. said: With this adjustment the macro works as intended, because by rounding the result it removes the decimals. [[@{selected|quick}+round((@{selected|vigilant}/100+1d20/10000)*10000)/10000 &{tracker}]] Just don't ask me why :D Don't you need the decimals for this to work? Otherwise you're just comparing quick scores, unless it still stores the decimals somewhere but just doesn't output them to the tracker. Yep, I do get the decimals! I am gonna type it by using math parentheses for clarity.  rounded {[(vigilant/100)+(1d20/10000)]*10000}/10000 In this way the vigilant+1d20 is multiplied for 10000, so the four decimals I need become whole numbers,  then rounded (this removes the excess of decimals caused by the error). Then it gets divided for 10000,and the result return a decimal. The we have (quick) + (result) and there you go. Edit: the final /10000 is executed after the rounding due to order of operation. I had to study it a little but it works well now and I am quite happy. Try it if you want, and let me know if I am missing something. 
I completely missed the rounding before, so that seems like it's fine to me. Still a little ugly with the decimals but until they improve the systems somehow I guess that's all we've got.
1507128466
Nox
Pro
Kyle said: I completely missed the rounding before, so that seems like it's fine to me. Still a little ugly with the decimals but until they improve the systems somehow I guess that's all we've got. Mmmh I don't find it that ugly. I actually like it.  I must thank you again since without your advice I wouldn't have been able to build the macro in the first place!