It would, but the other families the sprites are in couldn't refer to them (and I agree shouldn't be able to, that would be weird.)--platforms is a family that responds to wetness by changing its surface type variables, plants would want wetness to know they've been watered. Each object type could individually respond to the variables, but I already have like *checks stats* 1700 events so I'm trying to keep my code from getting too complex... or uh, trying to keep my code relatively lean anyway. Like platforms would be alright, but I'm expecting to have 3 dozen kinds of plants, probably similar amounts of animals, fungi, enemies, etc.

I think what would best serve my purposes is like hierarchies of families, and then I could put every sprite that's like "in the world" under one family that would hold wetness, and then plants and talkables would be a subfamily of that, and carryables a subfamily of talkables (and groundPlants and treePlants subfamilies of plants, which would help with another similar problem, etc). I imagine that would be a significant rework of construct's code base, though? And I mean, if I'm the only one who would ever use it, I'm happy to do my workaround--it's not that annoying (though it's a bit confusing in some instances--like in the aforementioned thing with the cats, sometimes the carryable needs to inherit the type from the talkable's name, and sometimes the talkable needs to inherit the name from the carryable's type. i've already resolved this one, it's just an example)--I was just wondering.

No, you cannot make truly universal instance variables in object-oriented programming.

ok i got kinda heated at this one i won't lie, but seeing it could be ai generated cooled me off.

Thanks but I was not looking for help about the cats and NPCs. It needs to know the cat's and NPC's names for drawing the correct cat or NPC, and for talking to them. Cats are both carryable and talkable; they're in both families. Object type name does not work for my purpose at all.

They all use wetness for different things; animation, particles, figuring out the platform's surface type (for playing sound effects and affecting movement physics), behaviors related to freezing/burning, etc. I can give every family wetness but it gets annoying if something is in two families because they need different names. I'm only asking if there's a way to add instance variables to for instance every sprite, which the engine will know every sprite can have (similar to how every sprite has a sprite.X, sprite.Y, etc.) and so can be referred to under any family. I already have a workaround, but I'm just checking if I can avoid working around it.

I wouldn't recommend taking legal advice from a public web forum. There very well could be a problem with what you're describing. I assume what you're describing would be considered a derivative work, which provides very minimal protections if someone were to pursue a lawsuit for say AI art derived from their style. Enforcement situations are fluid and subject to more complex interpretations of the law, which include previous case work and court rulings. This will continue to be the case even if copyright law referring to AI art is updated in your country.

I would not recommend using AI art primarily (edit: from a legal perspective, for the reasons mentioned above. i don't recommend using it personally, either, but that part is up to you). If you're using it just to generate ideas and then drawing your own fireball sprites, that wouldn't be considered a derivative work under US copyright law--only if you use portions of other published works (for example, sampling a song, or downloading a png of say a film poster or screen, or art from someone's social media, and using a portion or the entirety of that art in your game, even with modifications.) The actual enforcement of derivative works depends largely on the decision of the person or persons whose work you are sampling. Again, I am not a lawyer and you should not seek legal advice on public forums.

sorry, my initial post was kind of irrelevant because i didn't understand your system.

so, the first thing i would recommend is to read up on containers in the manual.

i would make one object type to represent all of the equipment, and then give that object type a variable that holds what it is and one that holds where it can be equipped, as well as a variable that holds how big its inventory is.

then i would put that object into a container with an inventory array, and set the inventory array's size to the item's size in an event.

this will simplify your code base dramatically because you won't need to use families--all of the equipped inventory can be picked at once with your "on the player" variable

once that's done, it seems like you already have the basic setup done: gear has an associated array that can hold N items. now you have to draw the items, which you can do with a (fairly complex, tbh) nested set of for loops, one for each equipped item, and one for each entry in the equipped items array.

item is "on the player"

for each item

-----create itemIcon at x = loopindex*25, y = 300

-----itemIcon set animation item.Type

-----inventoryArray for each X element

----------create itemIcon at x = item.X+10, y=310+(loopIndex*10)

----------itemIcon set animation inventoryArray.At(inventoryArray.curX)

this would draw all the items vertically below the equipped item, if you set up the itemIcon to hold 1 animation for each item name.

i hope that helps you move forward!

edit: sorry i don't know how to render the tabs correctly

i did this by making a dictionary for gameKeys and gameActions, and then at the top of my main event sheet have a giant bundle of or block events that check if a keyboard or gamepad is pushing one of the relevant buttons:

when the game starts as part of my init function it loads all the default gameKeys from a dictionary project file, but you can change the key codes at runtime by using the LastKeyCode expression. i haven't actually implemented this yet because i'm not sure of the UI, so i don't have an example to share, sorry about that!

so all "on key press" actions are replaced with "if gameActions key 'down' is 1" and all "key is down" actions are replaced with "if gameActions key 'down' >= 1" and such.

(these r collapsed)

this also meant i could keep track of how many frames each key has been down, which i used to implement DAS or auto-repeat with this function:

i also frequently add 1 to the relevant gameActions if, for instance, you're in the menu and push "confirm" so that it doesn't automatically confirm when the next window opens as well

i'm actually pretty proud of this one (i love that i was able to implement auto-repeat like that tbh) but i do agree it was kind of a bummer it was so roundabout. i hope my code helps, lmk if you need clarification!