I thought I was so smart and figured it out, but nope! I have all the weapons in a massive table. That same table is filtered by stores to make store fronts, and then copied and filtered again on the player character sheets then filtered by user so everyone only sees the weapons they buy.
But when I made a test account and tried to add weapons to it’s inventory the buy button toggled between the two accounts, instead of adding the second account to the row.
I made sure I had Allow Multiple Selections turned on but no dice. I’m using the user() on the button to filter. What am I doing wrong? Also, if there is a better way to tackle the inventory system please me know! I just started using coda this month lol, i’m running blind over here.
Welcome to coda! It seems like you’re already off to the races and have structured your doc well.
As you’ve written it, it’s saying that pressing that button should nuke the current cell and replace it with only User(). But you want to add user to what’s already there, right?
Try ListCombine( thisRow.Player, User() )
This takes whatever list of players is already present, and mashes User() into that list.
Notes:
I’m on my phone so may have messed the syntax
You could take this a step further, by preventing accidental duplicate entries in that Player list by adding .Unique() to the end of the formula.*
Consider changing the column name to Players if multiple people can buy the same item, for your future debugging sanity
Hey, I got another question. is there anyway to take this row and add it to a new table when this button is clicked? I’m trying to find a way to add player modifiers to the damage roll. Right now the player information table and the weapons table are two different tables. Can I add entire rows to tables and remove them with buttons?
Yep buttons can do AddRow() and DeleteRows() (for deleterows, you often take a whole table inside the brackets and then .filter() it down to the row or rows you want to delete).
However, you might want to think about a different structure. I’m not totally sure how the player modifier works in your game, but a common way to address the situation of “Table A’s rows are related to Table B’s rows in specific ways” is to make a 3rd table to hold the relationships.
So you would have a Modifiers table with a column for player, a column for weapon, and other columns that are specific to the relationship (damage multiplier or something?). Those first two columns would be Relation columns, referencing rows in the player and weapon tables.
So when you need to establish a relationship between a weapon and a player, create a row here (depending on how your game works, you might use this design pattern for all purchases even, rather than the method you were using before).
You can also, back in the weapons and players table, add a column that shows anything in Modifiers that references that weapon or player, so it’s bidirectional.
Basically when relating objects to one another, you have to think: do I only need to log THAT they are related, or so I need to log further information ABOUT their relationship? If the former, directly link them with a relation column. If the latter, make a table of relationship records.
