Feature request: Make cyphers, artifacts and oddities editable from the character sheet

[Onaka]

Numenera system version: 0.9.1

Current behavior: When putting an artifact, cypher, or oddity into a character's sheet, it becomes immutable, only the level and whether or not it's identified can be edited.

Desired behavior: After putting an artifact, cypher, or oddity onto the character sheet, the various fields should all be editable from the sheet.

[SolarBear]

The edition of numenera items was removed a while ago because the general sentiment (and by "general" I mean the only 2-3 people actively discussing the system with me back then) was that, unlike, say, abilities, GMs would be reluctant to let players edit their own cyphers and artifacts. As for the level and "identified" flag, they're only editable by the GM for pretty much the same reason.

Would you consider it to be an important feature? Is it simply a case of you simply trusting your players? In that case, I could, for instance, make them editable but only by, say, to players with the "trusted" level. I could also make that a system setting. What do you think?

[Onaka]

Yeah, the root of the problem is the fact it's not even editable by the GM once it's plonked down. I have 583 cyphers set up in an item folder, and I like to roll them. But they often have stuff that needs to be chosen afterwards, such as the form. IE. the difference between a wrist-mounted launcher and a pendant. And yes, these often have gameplay-changing effects.

Right now the workflow would be, duplicate cypher, edit the duplicate, then add it to sheet (because I don't want to lose the data for the original cypher). And you can imagine how cumbersome this can become when you start dropping half a dozen cyphers from a big discovery. There's also the fact that there is at least one focus that modifies the cyphers, such as "augments flesh with grafts" (IIRC the name) that grafts the cyphers, that's another edit that needs to be made on the fly, maybe a long time after the cypher is granted. Because of the cumbersome nature of this process, what I'm actually doing is using an external utility to generate cyphers and am pasting them in as journal entries, which isn't much better, but at least they can be edited this way.

TL;DR Only allowing trusted users and above edit rights is a good compromise.

[SolarBear]

Gotcha. I need to work on some layout stuff soon - the NPC sheet needs some love - so I'll add it to the list.

As for the form, you're right, it does matter. Someone recently came to me with a suggestion on managing forms more efficiently: allowing for a list of forms which would be selected randomly like levels and then overridden if the GM wants to. Would you think it's a good fit for your problem? If so, I'll check up on them to see if that's still in the works and if not, I'll add it to my TODO list.

[Onaka]

The random choosing of forms would be nice, but I worry that the data(-entry) format for it will be annoying or cumbersome. I had to do a lot of string parsing before I got those 583 cyphers into the item list. I don't think there's a proper way to differentiate the forms from eachother IIRC, at least in the cypher data that I have (which is scraped from the various book PDFs). What I mean is that there's no consistent way they separate out one form from the next. Can't split by comma, because that's sometimes used inside the description of the form, can't use anything else either that I can think of.

Making the form auto-randomizer somehow optional would, at least for my use-case, be the best option. Once the field is editable "in the wild", it won't matter too much anyway. If we could share a big database of cyphers legally, I'd love to crowd-source making it, but as it stands, if everyone who wants to get a list of cyphers from the books needs to do this, it seems like a bit of wasted effort making it super fancy.

I guess just allowing an array of forms, and if you want to have a single form in that entry be a string of all the forms, that would cater to my use case just fine, while allowing people who craft their own cyphers a nice QoL feature. As well as allowing the truly masochistic to manually enter every form for all ~600 cyphers that I'm aware of.

[gabrielgellner]

I am the one mentioned wanting a slightly more flexible form entry (likely coming from the similar experience of manually adding all the cypher's from my books). I wouldn't want the design to be based on text parsing as that feels brittle to me. My idea is starts from the assumption that basically all cypher fields (from at least discovery, the source book I am largely using) as being of the form:

<b>Usable</b> Description
<b>Wearable</b> Description
<b>Internal</b> Description

So as far as I see we have 3 kinds of keyword, top level form tags. The issue as you mention is frequently when something is mentioned it is a list of options so we would have Wearable: Belt, medallion, ring etc.

What I would like to do is have it so that this is all stored in a list, which would be prepped by having some kind of + control that would add a new record with two fields: <keyword see above>: <description> so if we wanted to entry the example I would have:

+ -> Usable -> Belt
+ -> Usable -> medallion
+ -> Usable -> ring

As nothing would be enforced or parsed, if this seemed like to much work you would just do:

+ -> Usable -> Belt, medallion, ring

Like it is in the dead tree text.

This seems flexible and general to me. It wouldn't add to much burden if you just want to ignore the random form feature (just have a single record), also for a migration I could imagine we could have

<b>Form</b> Usable: Belt, medallion, ring

So the default migration would be to have the keyword field be Form and then just copy all the current text into the description, that way having to tag the information would not be required if you didn't want anything to change.

Do people see any problems with this vision?

I am just a scientific programmer by day, so getting up to speed with all the html/css layout etc is taking me some time -- so I don't know the time frame for this, as adding the UI and the more complex data layout is taking some doing for me. I have only recently figured out how to setup a development environment without getting in the way of my install which I actually use to game!

[gabrielgellner]

To the first point about having cyphers etc being editable, I would much prefer this. I generally don't like when VTT systems are predicated on not trusting my players (i.e. thinking they will somehow cheat with the items etc). I just think it adds a lot of hassle to solve a non problem (or one that shouldn't be solved with technology).

With this in mind I would just want the "identified" behavior to not be easy for the players to accidentally click. So it would just be to make the experience of hidden items, not to try and stop my players from cheating.

Just my 2 cents to add the the 3-4 voices ;)

[Onaka]

I generally don't like when VTT systems are predicated on not trusting my players (i.e. thinking they will somehow cheat with the items etc).

I was going to say the same thing in one of my comments, but couldn't make it sound good. I agree with you entirely.

And yeah, I believe I wasn't clear, I am NOT expecting everyone to string parse their cypher lists, nor that the system itself should do any string parsing, just that I HAVE string-parsed the cyphers into a database and I agree: it's brittle. Though surprisingly little needed to change when copypasting from the sourcebook PDFs as other than the cypher forms, it's remarkably consistent.

[SolarBear]

Sorry for the late response.

I generally don't like when VTT systems are predicated on not trusting my players (i.e. thinking they will somehow cheat with the items etc).

I mostly agree with you. However, until now the feedback I've received - which, granted, is not that much - is that a lot of users end up playing with pick-up groups, and it's hard to trust people you've barely ever spoken to.

My aim in the long-term is to leave these decisions up to the GM - make the platform flexible enough so these decisions are up to them. As such, what I am going to do right now is make the user level a setting so it can be configured - that way your players will be able to edit their cyphers' information and PUG GMs will be able to keep control over their unreliable groups. I think everyone wins this way and, quite frankly, adding a setting is a simple thing to do.

[SolarBear]

Added in 0.14.0, tell me how that works for you!