Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

[Script] HERO System scripts to automate the combat (where possible) and more...

Ok, a quite long post but... some explanation is due. I didn't want to “publish” such a crappy code – not before refactoring it –, but life got in the way and I won't be able to dedicate anymore those couple of hours a day that I could spare during the last weeks and that allowed me to write it all – at least until further notice. So here it is in the current, abominable form. It pretty much works, though, if all the requisites are met, that is. The alternative would have been not to put it out at all... Hopefully this is the lesser evil ;P Since it is for the HERO System, fortunately very few of you (if any), would use such scripts, hence if I'm lucky nobody will ever need to have a peek at the code or use it. But in the slim chance that someone out there other than me is playing HERO on Roll20, this series of scripts could (like they did with me) shorten up the combats by a hundred times (no kidding here). At the beginning it was only a turnorder fit to run HERO games, with phases and turns. Then I started to add code over code to implement more and morebetween sessions, without a proper planning. So please bear with me. There are too many details to put them all here, but I managed to write sort of an instructions document – see the link to my Google drive below. Basically the scripts automate most of the combat. Tokens (or players and npcs) have their weapons, spells and armors and combat is resolved like this: select your token (when it's your turn), click on the macro button corresponding to the weapon/spell you want to use, select the target. Everything else is computed (and shown) automatically. Of course I could emulate only weapons, offensive spells and some special effects. There is still a lot that cannot be done by the scripts, and some more that would be really hard to implement anyway. Before using this " autocombat " one of our fights typically lasted 3-4 hours. Now it takes 5-10 minutes. I chose to use the gmnotes to place the various strings that are used in the scripts. It is an easily accessible place where to read and write the strings, it is visible only to the GM, and every token has its own. We basically “tested” (and I coded half of) the scripts while playing our sessions, so it is probable that many bugs still crawl in the code. Frankly speaking, I would prefer to undergo a bowel surgery with a stick and a pair of rusty scissors rather than having to look for bugs in the code in its current state. Anyway, last warning: I used a lot of global variables without namespacing, so it is probable that if you're using other scripts some variable could write over each other – and nothing would work. There are 5 main scripts, and the parsing of the commands are scattered in 4 of them. The “ locations ” script is dedicated to the creation of the rollable table that is used in combat. It must be used (once) prior to use the other functions. But the images have to be put by hand inside the rollable table (and then in the code as well). The “locations” script does that. Use the ! tableinsert command to automatically create a rollable table called “ locs ” (it has to be named like that, so don't change the name in the code) with 10 locations and their corresponding weights to replicate the bell curve of a 3d6 toss of dice. Unfortunately the links are for my images on my account, by the current limitations of the API (only images in the Roll20 library can be used), you will have to insert your own 10 images by hand. Here you can find a rar with the images I used (together with the aforementioned more in-depth instructions), but you can use any image you like: Google Drive Once you have inserted them into the corresponding locations in the rollable table just created (0=head, 1=hands, 2=arms, 3=shoulders, 4=chest, 5=abdomen, 6=vitals, 7=thighs, 8=legs, 9=feet), you have to use the command !tableread . This command will dump into the API output console YOUR “ locs ” rollable table contents, including YOUR correct links to the images inserted, in a format ready to be copy-pasted in another of my scripts: autocombat . Copy these 10 lines and replace the ones around line 1090 in autocombat with them, removing the brackets before and after each line of course. That part is used for the aimed shots. Done with the coding part. Then you have another couple little preparations to do: First, you need to have a couple of tokens in any page in which the combat will take place, called XPin and combathelper , respectively. They are needed by the scripts. XPin is a classic pin image that I use to track the position of the tokens when they move (since I allow the players to see where they started their movement. It is needed because the script will tell a player when he/she is moving more than half their Run value (it works with the waypoints, too), so it is much easier if they can see their original position in order to adjust their movement). It will be hidden by the script once the combat starts or ends. The second token ( combathelper ) is needed as a helper for the GM. Its red bar is used to put an optional last-minute modifier in it, that will be applied to the OCV of the acting token (i.e. if you DON'T want that particular player to hit the monster boss, you put a neat -10 in it, or vice-versa ;). Its green bar is used to aim. When a player states that he/she wants to aim a specific part of the target, you just put the corresponding number in the green box of the combathelper token before the player attacks (see the locations corresponding to the images, above). Secondly, all the tokens involved in combat must have a character journal associated. These journals must have all the HERO attributes (in no specific order), PLUS these three: tempOCV, tempDCV, tempRange. They are used for the martial maneuver bonuses/maluses, if any. Moreover, all the attributes must have their max set to the same value than the current value. This is because AID, Drain, Heal and Regeneration effects need to know the max value. You should use the createjournal script to generate the character journals - the command is !newsheet nameofthejournal . To start playing, select all the tokens involved in combat and type !combatstart . To advance a phase, type !nextphase , to end the combat type !combatend . Another useful commands is !recovery - to let a selected token have a recovery. That should be it, good luck! Scripts: autocombat effects recovery locations heroturntracker2.0 createjournal
I wanted to say: Thank you very much. I just found out about Roll20 and changing from Maptools was a hard choice, but I decided to try to make the jump. This code you shared is going to save me a lot of time and give me a great starting point. I appreciate it greatly.
1388186909

Edited 1388186975
Fabio M.
KS Backer
Thanks, happy to help. Be sure to download the scripts from Gists though, as they are the must up-to-date. I could just squash a couple of bugs since I posted them, but nonetheless... If you need clarifications on how to use them, just ask.
actually i got it all set up your instructions were great. I made a character and gave them a weapon, armor etc. I was able to get the combat sequence to go, and the movement to work warning me when i pass a half move etc. However, how do I actually initiate an attack? I may be missing this
If you downloaded the doc with the instructions, there's a macro there that has to be used to attack. Just change the name of the weapon in the macro with the name of the weapon used in the string in gmnotes. I usually put these macros as an ability in character's journals, so after activating the "token action" option, they have the corresponding button(s) pop up once they click on their token. When you have the macro ready, it is just a matter of selecting the attacking token, hitting the macro button, selecting the target token. Everything else it's done by the scripts.
Thank you. It was foolish but I totally overlooked the document in your google drive. I followed the directions here and got pretty far, and I downloaded the gist. I am off to read that now, Thanks. If I need any more help I will post and I will let you know how things go for me
Ok that document is way more thorough. I did run in to another problem, though. Again it is something I am probably missing...When I try to launch an attack macro, after picking the target I get the following error: I looked through the code and could not quickly find the function this was trying to call. I went back and made sure I had all the scripts (can Roll20 call a function defined in another script?) and I have all 5. I am going to try to figure out what I am missing and in the process start to actually read through the code to see if I can see what you are doing. If you have any insight it would be appreciated. Maybe something I missed in the documentation that I will re-read. For reference, the error message generated was: ReferenceError: calcDistanceBetweenTokens is not defined at hitRoll (evalmachine.<anonymous>:800:32) at evalmachine.<anonymous>:1182:13 at eval (
1388254895
Stephen S.
Pro
Marketplace Creator
Sheet Author
API Scripter
Fabio this is good stuff.
@Jesse My bad, please re-download heroturntracker-2.0 script. I left that function out by mistake (I was doing some tests and I moved it into another script that wasn't part of the ones you have). Sorry for the headache! @Stephen Thanks
No worries at all, this looks like awesome stuff.
Another issue: I redownloaded the turntracker script, and went through a test and generated another error. At first I thought it was a typo or something I did, and it still could be. The message delivered to chat (doesn't break script) is: (From parseWeapon): no weapon sword'equipped' for Clarence (or malformed string)! I copy/pasted the information for the GMs notes section of the NPC this is attached to from the documentation. This is what is in there: {sword}2|efftype:p|damtype:k|currammo100|maxammo100|end3|norange|str13|wo1{/sword} Is this something I set up wrong? If you need to know what the macro is I used, it is: !heroHit sword;@{selected|token_name};@{target|token_name};?{other modifiers to hit|0} What did I do wrong, oh sensei?
Hmm, I cannot think of a reason why it shouldn't work... Unfortunately I'm not home so I cannot check it. Try another weapon string, mind that every token must have a unique name (at least the ones involved in combat). I used the scripts yesterday and all went smooth. When I get back home later tonight I'll check it out.
Yeah I tried a few. When you get a chance and get home look at it. I will let you know if it is something boneheaded I overlooked
Tested and it works for me, both on Dev and on Production servers. I don't know... I re-uploaded autocombat and effects (the two scripts involved), please try to download them again and see how it goes. Basically for weapons and attack spells you just need the macro (that is pretty universal, you just need to change the name of the spell/weapon at the beginning of it) and a weapon/spell string in the corresponding character token's gmnotes. The string you pasted here is correct. Once you use the macro the script looks for a string in the source token that matches the name you passed on with it. That error is also in case a string with that name is not found at all (I have just modified the error message to be more clear). As a last resort you can invite me in your testing campaign and I can have a look at it.
Another thing that could cause weird behaviour is using the combat script on a page while the "bookmark" is on another one. I didn't put checks on that and if it happens it can just behave... Oddly, without crashing. And sometimes it takes a while to realize it. Just keep it in mind.
User error. Being new to Roll20, when I read to "put the weapon string in the GM notes for John" I put the string in the GM Notes in the journal entry for the character, not the GM notes on the token itself. Reading your post while I was out I noticed you kept saying "Token" which made me think "Wait a minute, I put it in the journal. Is there a GM Notes on a token?" I got home and confirmed that there is, and got past that part. When I have more time to play with it I will let you know how it goes. First thing I noticed is either I have to do some setup for a hex grid because it probably calculates distance based on x/y and 70 pixels a unit, I am quite sure that is something I can adjust for my campaign. Thanks for the great work and putting up with my inexperience!
In the autocombat script, around line 293 you forgot .set it should be " oObj.set('bar1_value', (shooterStun-damageEndStun));" not oObj.('bar1_value', (shooterStun-damageEndStun)); I bet it was something in a cut/paste went bad or something. Things seem to be humming along though. Thanks for all the hard work!
Hmm, maybe I should post this somewhere else but I have reached the following error when an attack hits: For reference, the error message generated was: /home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:1 orts, require, module, __filename, __dirname) { function f(a){throw a;}var j=v ^ Error: Firebase.update failed: First argument contains NaN in property 'bar3_value' at Error (<anonymous>) at Aa (/home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:9:186) at Aa (/home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:10:196) at za (/home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:8:468) at Da (/home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:10:392) at G.W.update (/home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:128:318) at TrackedObj._doSave ( I made sure to have the bars match stun, end, body respectively. When I saw it is registering a NaN I thought I might have done it wrong and instead of having it match the stat on the corresponding journal manually punched in the numbers and set the stat to "none" which of course did not solve the problem. I am too new to roll20 to quickly figure out why this is happening but seems to be fairly straight forward and most likely something I did wrong. Any help is greatly appreciated
Jesse F. said: In the autocombat script, around line 293 you forgot .set it should be " oObj.set('bar1_value', (shooterStun-damageEndStun));" not oObj.('bar1_value', (shooterStun-damageEndStun)); I bet it was something in a cut/paste went bad or something. Things seem to be humming along though. Thanks for all the hard work! Thanks for the catch. Yes, that was probably a copy-paste error. And it is in a part of the code that is really seldom executed, that's why I didn't notice it. It is when somebody finishes his End and uses Stun instead.
Jesse F. said: User error. Being new to Roll20, when I read to "put the weapon string in the GM notes for John" I put the string in the GM Notes in the journal entry for the character, not the GM notes on the token itself. Reading your post while I was out I noticed you kept saying "Token" which made me think "Wait a minute, I put it in the journal. Is there a GM Notes on a token?" I got home and confirmed that there is, and got past that part. When I have more time to play with it I will let you know how it goes. First thing I noticed is either I have to do some setup for a hex grid because it probably calculates distance based on x/y and 70 pixels a unit, I am quite sure that is something I can adjust for my campaign. Thanks for the great work and putting up with my inexperience! I thought about using the journal's gmnotes instead of the tokens', but for the npcs, where you typically have one journal shared between many tokens, it wouldn't work. Especially for weapons with ammo, you need each single token with a different count of ammo, so the logical solution was to use the token's gmnotes. It is a pain when you have to change page and you have to copy the most up-to-date token(s) into it, but is quicker in combat when you can just click on a token instead of going to the journal tab, click on a journal and then click edit.
Jesse F. said: Hmm, maybe I should post this somewhere else but I have reached the following error when an attack hits: For reference, the error message generated was: /home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:1 orts, require, module, __filename, __dirname) { function f(a){throw a;}var j=v ^ Error: Firebase.update failed: First argument contains NaN in property 'bar3_value' at Error (<anonymous>) at Aa (/home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:9:186) at Aa (/home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:10:196) at za (/home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:8:468) at Da (/home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:10:392) at G.W.update (/home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:128:318) at TrackedObj._doSave ( I made sure to have the bars match stun, end, body respectively. When I saw it is registering a NaN I thought I might have done it wrong and instead of having it match the stat on the corresponding journal manually punched in the numbers and set the stat to "none" which of course did not solve the problem. I am too new to roll20 to quickly figure out why this is happening but seems to be fairly straight forward and most likely something I did wrong. Any help is greatly appreciated Unfortunately I never had this error... You did it right, normally you have to link the three bars to the corresponding values (green=stun, blue=end, red=body). But the script does its math on the bars, not the values of the journal (unless you are using an Effect, that is). This is because when you have NPCs you have a common journal and a single token with the three linked bars. But say you want a pack of 5 goblins, for example. You copy the single token 5 times and unlink the bars of the copies. In this way you have 5 distinct and independent monsters (end, stun and body-wise) that have all other stats identical (they are needed for movement, checks, Effects, etc.). Did you set a MAX value for the bars? It is not optional. It has to be equal to the CURRENT value (when you start, of course).
1388373647
esampson
Pro
Sheet Author
Success! It took me a little while to get this up and running. The instructions I was looking at didn't seem to mention that you have to connect the token bars to specific attributes so until the previous post I wasn't sure what was going wrong (I thought the errors I was seeing were related to the bars of the combathelper object). All in all it seems to be a great set of scripts. One thing that seems to be missing (or maybe I've missed it) are stun modifiers for killing attacks. Also it would be nice if an attack could be designated to be a general (non-location specific) attack and if an attack could be specified to not causing bleeding. This would be useful both for campaigns that aren't using the optional rules for hit locations or bleeding (such as super hero campaigns) as well as special attacks which might not use one or the other (such as an explosion which can be a general attack or a laser which may not cause bleeding).
You know, sometimes it is good just to go with a clean slate. So I deleted all my tokens, and recreated from scratch the way you suggested basically and did not get that error. Fantastic. I +1 Okami regarding these scripts being great. Maybe some time next weekend I can get some of my champions regulars and feed them a test dungeon crawl and see how it goes. Okami said: Success! It took me a little while to get this up and running. The instructions I was looking at didn't seem to mention that you have to connect the token bars to specific attributes so until the previous post I wasn't sure what was going wrong (I thought the errors I was seeing were related to the bars of the combathelper object). All in all it seems to be a great set of scripts. One thing that seems to be missing (or maybe I've missed it) are stun modifiers for killing attacks. Also it would be nice if an attack could be designated to be a general (non-location specific) attack and if an attack could be specified to not causing bleeding. This would be useful both for campaigns that aren't using the optional rules for hit locations or bleeding (such as super hero campaigns) as well as special attacks which might not use one or the other (such as an explosion which can be a general attack or a laser which may not cause bleeding). There is a modifier in there for defenders to not check for hit locations. However, from what it says (look in the top of autocombat) this is not what you are looking for, because it always gives bodyx1 and stunx3 and still checks armor for hit location and rolls hit location. There is a modifier for nobleed. However, this applies to a token and not to a specific attack. Once I get more familiar with Roll20 I believe I could easily add the things you are asking, though. I just need a little time. It is something I would want to do for champions games anyway.
Oh I do have a question related to this and Roll20. Is there a way to edit the GM notes on the default token for a character. Say I had an Orc character in the journal and a default token, From what you were saying (if I understand correctly) is you drag the token on to the table, edit the token to put in the body/stun/end and the strings for armor and weapons, then copy/paste that around. I am assuming you keep one of those tokens in the gm layer or somewhere so you can bring it out later easily by copy/pasting more. So, there is no way to get the default token to pop out pre-populated with details?
1388378503
esampson
Pro
Sheet Author
Right. The nohitlocs modifier that can be put on a person gives an automatic stun modifier of 3. This doesn't work because for a Champions campaign that is not using hit locations you would roll 1/2d6 for the stun multiplier. Additionally the setup doesn't work well if the campaign generally uses hit locations but a given power doesn't use hit locations for whatever reason. The same problem applies with nobleed. I have found one bug. It appears that the full parsing of killing damage occurs in a section of the code that deals with adding extra damage classes due to strength. If an attack doesn't increase damage due to either no strength minimum or the character's strength not being high enough the "." and "+" damage modifiers get ignored. I was able to fix it with the following change put in starting on line 369 for(var i=0;i<dmgClasses.length;i++){ if(dmgClasses[i] == numdice){ if(i+strDamMod > i*2) i = i*2; else if(strDamMod>0) i+=strDamMod; numdice = dmgClasses[i]; if(numdice.indexOf(".")>=0) halfdie = true; if(numdice.indexOf("+")>=0) pip = 1; numdice = numdice.replace("+",""); numdice = numdice.replace(".",""); nd = parseInt(numdice); break; } }
Jesse, you're right. The {nobleed} modifier can be used to avoid bleeding for a specific token. It is easy to add the "nobleed" effect to weapons or spells, though. I will have a shot at it today if I have 20 minutes spare. And yes, there is also {nohitlocs}, that is valid only for the token that has it in its gmnotes. It follows the HERO rules, meaning that the every attack against that token is treated as "non-location specific" and deals bodyx1 and stunx3. Locations are always taken into account for armour purposes, though. Also this one can be easily scripted to be an argument for the weapon strings. @Okami About the stun modifiers for killing attacks: They are there. I mean, a killing attack (or a normal one) deals different stun depending on the location. I use the standard HERO rules for body and stun multipliers depending on the location hit. Or did you mean the +STUNx advantage? This advantage is not in (yet). I put in the Armour Piercing and Penetrating advantages, though. Same as above, it should be fairly easy to add it into the script as another weapon argument. I basically kept adding stuff into the code depending on what was needed by my players/NPCs between (or during) our game sessions, and it happened that nobody needed +STUNx... Sorry about the instructions, I wrote them in a hurry when I decided to put the scripts online, so I probably forgot a lot of other stuff, too. Actually, you have to link the bars for your convenience, but as I said before to Jesse, for what concerns damage in combat the scripts use the values (current and max) in the bars, not the attributes (or they should, if they don't you found another bug ;) ). But you have to set the max values as well (for both bars and attributes). I'm sorry if it's complicated to set-up but I couldn't find an easier way to do it when I started writing the code (not that I planned much at all, to be honest), and I didn't worry about other people having to use it in the future, either.
Jesse F. said: Oh I do have a question related to this and Roll20. Is there a way to edit the GM notes on the default token for a character. Say I had an Orc character in the journal and a default token, From what you were saying (if I understand correctly) is you drag the token on to the table, edit the token to put in the body/stun/end and the strings for armor and weapons, then copy/paste that around. I am assuming you keep one of those tokens in the gm layer or somewhere so you can bring it out later easily by copy/pasting more. So, there is no way to get the default token to pop out pre-populated with details? What I do is prepare a default token, linked to a journal, possibly with a set of armour and weapons, and then set it as the default token in the journal. It creates a "snapshot" of that token (including its gmnotes). If in the future something drastically changes, you have to delete it from the journal and set again the changed token as the default. For characters, you never unlink the bars from the attributes. For NPCs, you drag a number of them on the page, and then unlink the bars.
Okami said: Right. The nohitlocs modifier that can be put on a person gives an automatic stun modifier of 3. This doesn't work because for a Champions campaign that is not using hit locations you would roll 1/2d6 for the stun multiplier. Additionally the setup doesn't work well if the campaign generally uses hit locations but a given power doesn't use hit locations for whatever reason. The same problem applies with nobleed. I have found one bug. It appears that the full parsing of killing damage occurs in a section of the code that deals with adding extra damage classes due to strength. If an attack doesn't increase damage due to either no strength minimum or the character's strength not being high enough the "." and "+" damage modifiers get ignored. I was able to fix it with the following change put in starting on line 369 for(var i=0;i<dmgClasses.length;i++){ if(dmgClasses[i] == numdice){ if(i+strDamMod > i*2) i = i*2; else if(strDamMod>0) i+=strDamMod; numdice = dmgClasses[i]; if(numdice.indexOf(".")>=0) halfdie = true; if(numdice.indexOf("+")>=0) pip = 1; numdice = numdice.replace("+",""); numdice = numdice.replace(".",""); nd = parseInt(numdice); break; } } Thanks for that. The damage class modifier due to str is one of the last things I put into autocombat, so I didn't test it much. You're right about the stun, I simply decided to use the rule of STUNx3 because we play heroic sci-fi or heroic fantasy games. It's easy to fix it with a randomInteger(3) instead of a plain 3.
It was really simple to add those modifiers, so I have done it. I have changed autocombat to include the fix from Okami. Moreover, now the "no-hit-locations" stun multiplier is a 1/2d6 instead of a fixed 3. The following new modifiers can be used in weapons/spells: nobleed nohitlocs stunx For the stunx modifier you have to specify a value, i.e. stunx1 - it means a +1 StunX multiplier will be added. I didn't test anything of course, but it should be pretty straightforward. Just re-download autocombat.
Cool thanks for all the hard work Fabio. Later on (As in later on in life, not later on today) I may write in a check to make sure the bars are set up, and if not to plug in the appropriate numbers (not link to stat but plug in the numbers). I was riding in to work this morning and I got to thinking about this, but is there a way to simulate the block maneuver with your scripts? It is something my players generally do a lot so I was curious.
I really didn't think at all about the block maneuver, since my players never use it. I'll have a look because they changed it in the 6th ed. rules. It is not a 5 minutes fix... Probably the best way would be to use a specific status icon. If during an attack that icon is present on the defender, the roll is made by the block rules (ocv of the defender plus miscellaneous bonuses + 11 minus attacker OCV and bonuses). And the !nextphase command would automatically put the "already acted" icon on the blocking token during its next active phase. This of course would still require the player to declare the block and the GM to activate the icon on the token. About the check: Any improvement of the code is welcome.
Very good. You already stated that you were putting the code out there because you didn't have time to really support it anymore, so don't worry about block. Once I get more acclimated to Roll20 and it's API and general interface I can tackle it if no one else has. Your plan seems sound to me with the status icon, and I think I would even put in a function to toggle that along with giving a optional manuever bonuses, then players could have a macro that would toggle the block status and update the temp ocv/dcv (which you would need since you get a -2 to block for every attack you block after the first) While I am at it, I may add a status icon for 'aborted action' to let the herotracker know that they already used their action when it becomes their turn again. This is a little ambitious since I really have only heard about roll20 less than a week ago, but as long as I can get free time I should be able to pick it up quickly.
Yep, it would be nice to have a macro for the players to use. You're right, I have now a couple of hours a week instead than a couple a day, so I can just fix something here and there or add simple functions. The block (and dodge, grab, etc.) are all maneuvers and I didn't plan to insert them (at least not until the code was refactored). But I reckon it would be nice to have them, the combat would be rather complete. Unfortunately, they are also more complicated to implement, since every one of them is different and causes a series of different effects/modifiers. The block is probably worth 2-3 hours coding. If I have time during the w.e. I will look into it, unless you already started, of course. You're more than welcome to tackle it ;)
No, I haven't started. I am in learn and get acclimated mode. I have written a couple small scripts in the API and I will probably write a couple other little ones and try to get used to the layout and tools. I probably won't do anything really worthwhile for a couple weeks to be honest. Really, we are in the same boat in that I only have a handfull of hours a week to dedicate to things, I just sometimes can squeeze out more.
Fabio M. said: What I do is prepare a default token, linked to a journal, possibly with a set of armour and weapons, and then set it as the default token in the journal. It creates a "snapshot" of that token (including its gmnotes). If in the future something drastically changes, you have to delete it from the journal and set again the changed token as the default. For characters, you never unlink the bars from the attributes. For NPCs, you drag a number of them on the page, and then unlink the bars. When I set GM Notes on a token, then set that as a default token in the journal, and I pull that token back out it has no GM Notes at all. Is there something I am doing wrong? I am pulling the token out by dragging the portrait from the journal to the table top. I tried pulling out the token by dragging the journal entry itself out, but then the token isn't even associated with the journal. Also when I have a token out, and copy/paste it to create several tokens from the same journal I have to rename the tokens so they each have a unique name. Otherwise all actions taken against any of the tokens only affects the "master" (or "original") token. So I have Orc 1, Orc 2, Orc 3 etc as an example. Is this because the targeting is based on name of the token and not the ID or some other unique identifier? Is this easily enough changed? Oh, and... Happy New Year everyone! I love having a day off in the middle of the work week
OK Scratch the part about the token not keeping GM notes. I found out I have to remove the old token, save changes, go back in and edit and then add the new token. Minor inconvenience, but I got it figured out.
In autocombat at line 387 currently you can paste the following three lines to support -1 pip of damage to die rolls (such as a dirk in fantasy hero 6e) if you like. Then for damage of the weapon just put a "-" after the number of damage dice to subtract 1 pip. if(numdice.indexOf("-")>=0) pip = -1; numdice = numdice.replace("-","");
Jesse F. said: Also when I have a token out, and copy/paste it to create several tokens from the same journal I have to rename the tokens so they each have a unique name. Otherwise all actions taken against any of the tokens only affects the "master" (or "original") token. So I have Orc 1, Orc 2, Orc 3 etc as an example. Is this because the targeting is based on name of the token and not the ID or some other unique identifier? Is this easily enough changed? Oh, and... Happy New Year everyone! I love having a day off in the middle of the work week You're right, it is based on tokens' names. When I wrote it I didn't even know you could get the token id from a macro (as pointed out recently elsewhere in the forum). It is an easy fix though (I can change it to allow to continue using the current macros or to use a new one that gets the IDs of the attacker/defender) . The problem is still there when you have an Effect that raises/lowers one or more attributes. Since the NPCs are sharing a single journal, all of them are affected by the change. A workaround I had thought was to automatically copy the journal in case of an Effect that modified it. Unfortunately this operation throws an error. Hopefully the devs are looking into it. Once it is working, it will be a matter of uncommenting a line in the effects script.
Jesse F. said: In autocombat at line 387 currently you can paste the following three lines to support -1 pip of damage to die rolls (such as a dirk in fantasy hero 6e) if you like. Then for damage of the weapon just put a "-" after the number of damage dice to subtract 1 pip. if(numdice.indexOf("-")>=0) pip = -1; numdice = numdice.replace("-",""); Thanks for this, it is nice to have the option.
1388629747

Edited 1388629800
Fabio M.
KS Backer
Happy New Year everyone! About the block: Since I had a couple of days off I could put the hands on the code. It is slightly more difficult than expected since it changes a number of default "behaviours" of the scripts. While I was fiddling with it, I found a couple of other parts of the code that needed to be fixed. To start with, I didn't put the option to use a shield. Now it is there (but I didn't upload the new code yet), simply add {shield}n{/shield} in the gmnotes (with n = DCV value of the shield) and it will be considered even for ranged attacks. Then I thought of an improvement: Every token should have in the gmnotes a "mainhand" and an "offhand" weapon. They are basically the equipped weapon for the character. They are simply a copy of your weapon of choice, but represent the weapon(s) actually in use for that token. Of course in order to use an offhand weapon the character should have the "offhand" skill. This is needed because when an attack is computed, the script will look for the equipped weapons of the defender in order to see if there are any DCV bonuses associated. Moreover, if the {offhand} weapon is present, it will add a +1 DCV (or a +1 OCV in case of a block) on top of its DCV bonus (if any). If I have time I will write a script to "equip" a weapon with a click, but for now the GM should just copy/paste the weapon string the player chose to use for that phase/combat and rename it "mainhand". The same goes for the optional offhand. From that moment on the players won't have to worry about a half dozen macros for their different weapons. Once they select the equipped one and the GM copies the string, they can simply use the same "mainhand" or "offhand" macro to attack. To avoid the players clicking and using a weapon not equipped, all the weapons (but the "mainhand" and "offhand" strings) can be kept in journal's gmnotes instead. About the standard maneuvers: Every character/NPC will have his maneuvers like block or dodge in his JOURNAL's gmnotes. This is because in HERO those are standard maneuvers that everyone has. If somebody has a different form of a standard maneuver (because of martial arts or other effects), the corresponding string has to be put in TOKEN's gmnotes (the standard ones will still be present in journal's gmnotes). The script will simply look first in token's gmnotes, and if the maneuver is not found there, will pick it up from the journal.
Fabio M. said: Jesse F. said: Also when I have a token out, and copy/paste it to create several tokens from the same journal I have to rename the tokens so they each have a unique name. Otherwise all actions taken against any of the tokens only affects the "master" (or "original") token. So I have Orc 1, Orc 2, Orc 3 etc as an example. Is this because the targeting is based on name of the token and not the ID or some other unique identifier? Is this easily enough changed? Oh, and... Happy New Year everyone! I love having a day off in the middle of the work week You're right, it is based on tokens' names. When I wrote it I didn't even know you could get the token id from a macro (as pointed out recently elsewhere in the forum). It is an easy fix though (I can change it to allow to continue using the current macros or to use a new one that gets the IDs of the attacker/defender) . The problem is still there when you have an Effect that raises/lowers one or more attributes. Since the NPCs are sharing a single journal, all of them are affected by the change. A workaround I had thought was to automatically copy the journal in case of an Effect that modified it. Unfortunately this operation throws an error. Hopefully the devs are looking into it. Once it is working, it will be a matter of uncommenting a line in the effects script. A bit more work would be to put a modifier in the GM Notes of the token. But that means every time you try to grab an attribute you have to run through that. Of course a simple function to check GM notes for modifiers and return the full modified value could be done, but that still means hunting down everywhere that accessed an attribute. I have no idea how many times that is in the script, you would have a much better idea. But it's a thought.
Fabio M. said: Happy New Year everyone! About the block: Since I had a couple of days off I could put the hands on the code. It is slightly more difficult than expected since it changes a number of default "behaviours" of the scripts. While I was fiddling with it, I found a couple of other parts of the code that needed to be fixed. To start with, I didn't put the option to use a shield. Now it is there (but I didn't upload the new code yet), simply add {shield}n{/shield} in the gmnotes (with n = DCV value of the shield) and it will be considered even for ranged attacks. Then I thought of an improvement: Every token should have in the gmnotes a "mainhand" and an "offhand" weapon. They are basically the equipped weapon for the character. They are simply a copy of your weapon of choice, but represent the weapon(s) actually in use for that token. Of course in order to use an offhand weapon the character should have the "offhand" skill. This is needed because when an attack is computed, the script will look for the equipped weapons of the defender in order to see if there are any DCV bonuses associated. Moreover, if the {offhand} weapon is present, it will add a +1 DCV (or a +1 OCV in case of a block) on top of its DCV bonus (if any). If I have time I will write a script to "equip" a weapon with a click, but for now the GM should just copy/paste the weapon string the player chose to use for that phase/combat and rename it "mainhand". The same goes for the optional offhand. From that moment on the players won't have to worry about a half dozen macros for their different weapons. Once they select the equipped one and the GM copies the string, they can simply use the same "mainhand" or "offhand" macro to attack. To avoid the players clicking and using a weapon not equipped, all the weapons (but the "mainhand" and "offhand" strings) can be kept in journal's gmnotes instead. About the standard maneuvers: Every character/NPC will have his maneuvers like block or dodge in his JOURNAL's gmnotes. This is because in HERO those are standard maneuvers that everyone has. If somebody has a different form of a standard maneuver (because of martial arts or other effects), the corresponding string has to be put in TOKEN's gmnotes (the standard ones will still be present in journal's gmnotes). The script will simply look first in token's gmnotes, and if the maneuver is not found there, will pick it up from the journal. This sounds fantastic
1388666785

Edited 1388799468
Fabio M.
KS Backer
Ok, it should work now. Unfortunately I had to change 3 scripts, so re-download them all: effects, autocombat, heroturntrucker2.0. It was trickier than expected, but I believe now it is faithful to the rules. Block can be activated using a string like this in token gmnotes: {block}-1|tdcv0|tocv2{/block} Likewise, dodge uses a string like this: {dodge}-1|tdcv3|self{/dodge} The macros to use in order to activate the maneuvers are, respectively: !heroHit block;@{selected|token_id};@{target|token_id};abort !heroHit dodge;@{selected|token_id};;abort Mind that maneuvers always have a damage of -1 in the "weapon" string. For some reason putting them in journal's gmnotes doesn't work, so for now always use token's gmnotes. The "abort" modifier at the end is of course important, it allows the characters to abort to a block or a dodge even when it's not their phase to act. The block can be used to block attacks directed at another token (within reach range). The bolt-shield marker is used to show that a block maneuver is activated (while the "ninja-mask" is for the dodge), and the number on the marker is the number of absolute phases is will last (just ignore it, I had to use this trick to emulate the rules about block). I also used the black-flag marker to automatically set the "already acted" status on the blocking/dodging character's next available phase. I didn't test the code much, so there could be some problem in particular circumstances.
Question that you may quickly be able to answer: Can a script detect the size of a token? I ask because if you have a 2x2 token try to attack with a melee weapon, it will think you are out of range with someone you are adjacent to. You can fix this by adding reach to the weapon, but when the normal size token attacks back it will think they are out of range as well.... I will look in to this when I get home if there is no response.
1388705232

Edited 1388706283
Fabio M.
KS Backer
It should be fixed now, thanks for noticing that! (Changed autocombat and heroturntracker2.0) Edit: To clarify, now the script "measures" attacker and defender tokens (they should be square but it takes the bigger of the two sides anyway) and adds any size greater than 70px to the reach (considering page scale). So it is not needed to add a special reach for your big bad ogre, if you make it double the standard size, it will have 1 unit more reach automatically. Of course in its weapon string you would probably put a bigger reach since it will be oversized ;) By the way, now the weapon/spell/maneuver macros can use token_id instead of token_name, but the old way still works.
You are the bomb. I probably can get some testing of blocks and dodge tomorrow. Thanks for all the hard work
Whoops? Just autocombat and heroturntracker2.0 changed, correct? For reference, the error message generated was: ReferenceError: currentPage is not defined at calcDistanceBetweenTokens (evalmachine.<anonymous>:1527:21) at hitRoll (evalmachine.<anonymous>:2945:32) at evalmachine.<anonymous>:3566:13 at eval (
My bad, left out a line in heroturntracker2.0. Just get it again, sorry (by the way, I noticed a missing declaration in autocombat as well, but strangely enough it didn't throw an error... updated that one too now).
When passing a token_id instead of name, it delivers messages using the ID as if it were a name. Also I copy/pasted the macro code for the block above but when I tried to activate block on one character it gave the message x, you have already acted this phase. (does the same for dodge with the abort in the macro of both) For troubleshooting purposes, this occured on phase 8. The attacker was spd 3 and it was their turn in the turn tracker. The defender attempting to block had speed 4 (so acted in 6, and again in 9). Also, was it a mistake to include the target for blocking? Should they be targeting themselves or the person they are blocking for?
Hmm... Thanks, I didn't notice it. I also forgot to mention that you cannot use token names that start with a "-". That is because to tell an ID from a name I used a cheap trick: I look for the first character and if it is a - (every ID starts with a -), it is considered an ID. Otherwise it is considered a name. Of course, if you for example call a token something like "-test-", it won't work. Regarding the block, it is because you cannot abort if you already acted that phase. But I reckon I changed the original code that puts the "acted" marker off at the end of every phase. Now it puts it off at the beginning of the tokens' acting phases. I will have to change it again to consider the scenario you described: If you have the "acted" marker on, but you didn't use any abort maneuver yet (i.e. no "block" or "dodge" marker), the "acted" marker has to go off the next absolute phase, or you won't be able to abort until you act again your next available phase... I hope it is clear :P As I told you I didn't test it extensively. The target for blocking is there because (as per HERO rules) you could block an attack that is targeting another character - within reach - at a -2 penalty. For a "normal" block you just need to target yourself. P.S. I made the above mentioned changes. Just download again heroturntracker2.0 and autocombat. As usual, I made the changes but I didn't test them (sorry, as you know testing takes more time than coding).
Yup, testing takes way more time. I have no problem helping anyway I can, and your explanation made perfect sense to me. So the target for the block is who you are blocking for. I will download and test today.