vÍnce said: Hi Nicole, Just curious, please excuse my ignorance, but is there a downside to exposing all the attributes in the sheet to API Mod access? It depends on what you mean by "all the attributes" here. Like, are you referring to "I want to edit my AC", or are you referring to "I want whatever the database holds and I'll figure out what it means myself"? Because those are two different things with different answers. If the former, there's no downside really, it's just work for each individual one, so it has to be prioritized against other work. Unlike older sheets, where the attributes you might want to access are all just in the database as-is and the work is just "go find the exact attribute you asked for", most of what you want to access isn't like that on the 5.5 sheet. For each attribute a user might want, Beacon asks the sheet "how should we respond to this request?" For XP, it's just an oversight because it is actually just a value we have to pull out and update. It is still work and not something we get automatically, but relative to other attributes that one is pretty light. We do have to individually plan each one, though, so oversights do happen and they have varying levels of difficulty to implement. Most of what you see is actually a combination of a bunch of individual pieces of data run through specific logic to figure out how to display them, so that specific logic has to be rerun if you want something like "what's my maximum HP" or "what's the damage of my flail attack". Inline editing has unlocked a lot of editing attributes though, since we now have a system in place for what it looks like when someone just manually edits their value without care for any of that complexity, which we just recently started dipping into with maximum HP editing. If the latter, there are pros and cons that have been heavily discussed internally. Our data is still in heavy flux, with the way data is structured changed and updated frequently, and as soon as we give access to that structure to the public, anything anyone does will be built on shaky ground and if it breaks due to our changes, it will be frustrating for everyone involved and we'll begin to fall into a trap of messy backwards compatibility. For example, we're now in the process of deleting a certain property from ~75% of our data as part of our work to improve performance. If we had previously allowed APIs to edit this property, then a lot of APIs could have immediately broken, annoying the users of the API, the devs of the API, and us. There's a whole layer of architecture that would be required to make all the data available, which would have to be prioritized against our other features because it would require dev work and upkeep/maintenance. It would be largely useless without heavy documentation, that we would then have to add "keep that documentation up to date with our weekly changes" to the list of work. Personally, someday I would like to go that route because it's exciting to think of what users might be able to create with that level of freedom, but that's just my personal opinion and we're definitely not in a place today where that would make sense. I tried to write documentation for our data a few months ago and it's over a dozen pages already, with the most intricate pieces of data still unstarted, and it's out of date now lol.
