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

Token to use their own localised instance of character sheet that no other token of that type uses.

Score + 2
1732045311

Edited 1732075314
Xeg
Pro
*Edit* I don't think I am quite clear in what I am asking. So I made a video in Foundry and this is what I want Roll20 to do. <a href="https://youtu.be/IBWRk1SBxks" rel="nofollow">https://youtu.be/IBWRk1SBxks</a> *End Edit* Hello, I think it would be useful for tokens to have their own version of a character sheet when you place them on the map. Say you want some grunts/goons and you make that enemy type. Thug you call it. It would be good I think to drag it onto the map several times and each of those times the tokens have their own sheet copy, so when you open the sheet from them and change it, it changes ONLY for that one particular token. All other tokens and the character in the journal are left untouched. I ask this because while using tokens for health and armour and all that are great for some games.....they aren't for others. With the way health and armour work in say Cyberpunk 2020, it becomes quite unusable and just not any fun to use tokens in that way. It's better to use the sheet I think as changing the health and other values on that affects any stat changes and whatnot. But of course, this means if you change a tokens health through the sheet it uses, it changes the health for all tokens using the sheet, which isn't great. The only other solution is to have loads of copies in the journal clogging it up. Or go and change a sheet, transfer the info to the token and put the sheet back so the next token is normal and keep faffing about like that. Doing this shouldn't effect how people play already, but only those that would need/want to use it.
When you set up a token for an NPC, don't link the hp to the character sheet, just use static values. This way, when you copy multiple instances of that token, they will each have individual hp pools, and subtracting hit points from one copy will not affect the others.
The character sheet has to go somewhere, so it would be no different then making copies or a new "version" appears when you drop a token, either way it will be in your journal tab as it needs to store it somewhere accessible.&nbsp; If you do not want to see them in your journal tab, you can always archive them so you don't see them, and shift clicking the token will still bring up the character sheet. If you only need to change the armor and hp values, simply do not link them to the character sheet, so you can alter every token to have different ac and hp values, one won't effect the other.&nbsp; Hope that made sense.
1732057000
Andrew R.
Pro
Sheet Author
Have you read the Help Center article on Linking Tokens to Journals? Because it explains how to set up adversary tokens properly so they share a Character Sheet without having to share HP, etc.,&nbsp; <a href="https://help.roll20.net/hc/en-us/articles/360039715593-Linking-Tokens-to-Journals" rel="nofollow">https://help.roll20.net/hc/en-us/articles/360039715593-Linking-Tokens-to-Journals</a>
1732069459

Edited 1732069703
Xeg
Pro
It doesn't work so well with Cyberpunk. Foundry has a system where a token can be taken onto the board and a check box will state if it edits the main sheet or has it's own little copy of it so all the tokens are independent of each other and the main sheet. (But the Cyberpunk rule set is totally broken there so I don't use it.) I know how to link sheets to tokens, that's not my problem, it's tokens that use the sheet, all end up changing it too. I'm fine with them in the journal, I just don't want to have to copy a character 10 or more times in said journal to use multiples that can be edited separately. The way Cyberpunk works is, you have 10 states of injury. Each with 4 points. Cyberpunk doesn't do the whole number HP thing like others. Characters have separate body parts, that can each be targeted independently of each other.&nbsp; Different parts of armour also cover different parts of the body so you have multiple armour values. As your health goes down, your stats change. &nbsp;&nbsp; Works fine on a character sheet but is absolute Hell to work with on a token. So I would rather be able to call up a sheet from that token like normal, but the sheet being one that doesn't affect any other sheet being used by the other tokens. I don't want to operate from the token and use the bars as the information doesn't translate well. It sounds like a Cyberpunk specific thing, but Foundry does it with all rule sets. I'm just not good at explaining it I guess. I'll make a diagram of what I mean and hopefully you'll see why using token bars isn't that great always. And I also don't want to simplify mechanics down so it is more like other games, kinda defeats the purpose of playing this one. Not against house rules, but the spirit of the game would be lost.
1732069750

Edited 1732069777
Gauss
Forum Champion
Xeg said: I know how to link sheets to tokens, that's not my problem, it's tokens that use the sheet, all end up changing it too. &nbsp; It is this line that is the problem. If you change one token and any other tokens change then you did not set up the token properly.&nbsp; In the image below step #2 should say "None". If it does not say "None" then it is set up incorrectly. (For non-unique characters such as in your example.) Note: Please ignore that this screenshot is for a different game system. The principle is the same. Do not connect a bar to the character sheet if that token is not unique.&nbsp;
1732070768

Edited 1732071568
Xeg
Pro
Gauss said: is this line that is the problem. If you change one token and any other tokens change then you did not set up the token properly.&nbsp; The token doesn't change. The character sheet in the journal changes, which I don't want that to. I want the token to use a character sheet. If I have 5 gang members, I want them all to use the same sheet. But in doing so they all edit the same sheet even if I open the sheet through the one token. I would like a system where each token using that sheet, uses it's own localised version of that sheet. Which is a function in Foundry, for any game system, not just Cyberpunk. Editing health and armour on tokens is just not viable for Cyberpunk at all. Doing it in the sheet is the better way to go about it, and so far the only way to have those 5 gang members using a different version of the sheet, is to copy them in the journal. I only want the one version in there so it doesn't get cluttered. Archiving them would only just move that clutter but I'd still need to go to them to get the multiple members. If I use the tokens for mindless grunts, then that's now two different combat systems. And how would I get a token to use all the cyberware and skills if it has none as the represents character? It wouldn't feel very cyberpunky.
1732080715

Edited 1732080784
Gauss
Forum Champion
Alright, I watched the video and while I saw you setting up the individual characters I still don't understand where the problem doing that here is.&nbsp; I've never played Cyberpunk, have no idea how it works. What about it is not possible to represent on a token?&nbsp; Nothing you did in the video seemed to relate to what I would normally see as "hitpoints" in other game systems.&nbsp;
1732082655

Edited 1732082831
Xeg
Pro
The difference is, Cyberpunk doesn't use standard hit points. You have 10 health stages with 4 points in them. And say if you take 10 damage, you end up in the 3rd stage, Critical Stage 2. And when you select that health stage or any other, it affects your stats and how well you do things. Then you have targeting an enemy, shooting or hitting them can hit a part of their body. This is used for armour as armour has 6 categories for the head, torso, arms and legs. Some armours cover more than one body part. Then you have SDP for things like cyber limbs if they get hit, you don't lose health but the cyber limb does, the SDP. All this is fine when playing with the character sheet. So unique characters aren't a problem. It's just grunts that are. Translating all of that to a token is quite the task. And doing so means it only changes numbers on a token (And manually too as &nbsp;s electing the attributes for the bars, does nothing. The numbers don't change on getting hit ), the stats won't be changed so the damage won't affect them now. The tokens are good for having grunts that are edited apart from one another, but character sheets aren't and it would be nice if I could avoid having to create many copies of a character sheet just to put some gangsters on the street. Foundary does this, and it's not even a Cyberpunk specific thing, it does it with all rule sets. It's just how it does it with tokens and character sheets. If I had those checkmarks selected, it would function like Roll20 does, and editing the sheet through the token would edit the journal sheet and any other tokens using that sheet, it would be edited through them too. But that one little checkmark makes it able to have tokens use their own version of the sheet.
1732084528

Edited 1732084615
Gauss
Forum Champion
Ahhh I see the problem now.&nbsp; Yeah, Roll20 needs some way to support that, but the method you are advocating probably won't work well. More character sheets winds up causing a huge load on your system. So much so that it used to cause major slowdowns until Roll20 implemented the lazy loading update.&nbsp; Having so many character sheets open would be a huge resource drain.&nbsp; With all that said, you might find a solution via a Mod (API Script). I'd run it past the folks in the API forum.&nbsp;
1732617721

Edited 1732617842
Raf
Pro
Gauss said: Ahhh I see the problem now.&nbsp; Yeah, Roll20 needs some way to support that, but the method you are advocating probably won't work well. More character sheets winds up causing a huge load on your system. So much so that it used to cause major slowdowns until Roll20 implemented the lazy loading update.&nbsp; Having so many character sheets open would be a huge resource drain.&nbsp; With all that said, you might find a solution via a Mod (API Script). I'd run it past the folks in the API forum.&nbsp; What if... You can set up a Character Sheet, tag it in the settings as an "Archetype" character sheet, and when you drag it onto the map, it creates a Token as usual, but also creates an instance of the Character Sheet, i.e. a "Virtual Sheet", which can be opened through&nbsp;the Token (i.e. by ALT+Double-Clicking, or Right Click -&gt; Character Sheet, or Double-Click -&gt; Open Character Sheet). When you first open a Virtual Sheet, it just pulls all of its Attribute data from the Archetype Sheet it is linked to. When you make changes, it doesn't save them to the Archetype Sheet, but to the Virtual Sheet. On subsequent loads, it first loads all the Attributes from the Archetype Sheet, then replaces Attributes as necessary based on what was stored on the Virtual Sheet. Only differences in values would need to be saved to the Virtual Sheet. &nbsp;This way, if the Character Sheets for your game have, for example, 100 different Attributes, but you were only changing a few Attributes e.g. HP, Armor, Total Ammo, Ammo in Magazine, then the Virtual Sheet would only need to save those few Attributes, rather than requiring you to create a whole new Character Sheet with its own version of the 100 different Attributes.
1732642770
Gauss
Forum Champion
Raf said: Gauss said: Ahhh I see the problem now.&nbsp; Yeah, Roll20 needs some way to support that, but the method you are advocating probably won't work well. More character sheets winds up causing a huge load on your system. So much so that it used to cause major slowdowns until Roll20 implemented the lazy loading update.&nbsp; Having so many character sheets open would be a huge resource drain.&nbsp; With all that said, you might find a solution via a Mod (API Script). I'd run it past the folks in the API forum.&nbsp; What if... You can set up a Character Sheet, tag it in the settings as an "Archetype" character sheet, and when you drag it onto the map, it creates a Token as usual, but also creates an instance of the Character Sheet, i.e. a "Virtual Sheet", which can be opened through&nbsp;the Token (i.e. by ALT+Double-Clicking, or Right Click -&gt; Character Sheet, or Double-Click -&gt; Open Character Sheet). When you first open a Virtual Sheet, it just pulls all of its Attribute data from the Archetype Sheet it is linked to. When you make changes, it doesn't save them to the Archetype Sheet, but to the Virtual Sheet. On subsequent loads, it first loads all the Attributes from the Archetype Sheet, then replaces Attributes as necessary based on what was stored on the Virtual Sheet. Only differences in values would need to be saved to the Virtual Sheet. &nbsp;This way, if the Character Sheets for your game have, for example, 100 different Attributes, but you were only changing a few Attributes e.g. HP, Armor, Total Ammo, Ammo in Magazine, then the Virtual Sheet would only need to save those few Attributes, rather than requiring you to create a whole new Character Sheet with its own version of the 100 different Attributes. That will still cause a huge load on the GMs system.&nbsp; Every character sheet the GM loads takes resources.&nbsp; In the old days of Roll20 when the user entered the game Roll20 would load ALL the character sheets automatically. "In case they were needed".&nbsp; This was bad as it caused user's Roll20 experience to slow down under the weight of all that data being active on people's systems. Then a few years ago Roll20 did an update which changed that. Now only the sheets you open are loaded onto your system.&nbsp; The idea you are proposing would cause 1 sheet to become 5, 10, 15, or even 20 on someone's system, magnifying the workload tremendously.&nbsp; Of course, perhaps the Devs can find a way around that but that would probably be a much bigger revamp of things.&nbsp;