Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- so, in this system, there would be two states in total: eating and just eaten. there would be a holy heckton of common events, one for each item, called by the corresponding item.
- each unique item common event would set the food property variables to be stored, and then would then call another common event, which surveys which actors are eating (actors with the state "eating") and stores those actor indexes away, checking for each party member slot. this allows for shared meals to also be possible. at this point, everyone that's been surveyed has "just eaten" applied and "eating" removed. at this point, either another common event or the same one (might just break them up for ease of reading and have one call the other) will cross reference actors that were tallied, test that against the current food data stored, and then apply the appropriate effects to each actor in the table, and this is done for the amount of times that there are party member slots.
- each time the effects are applied, the state is removed so they don't get extra effects every time. at the end of the checking, the variables are all reset to avoid exploits.
- this system basically lives and does by the fact that it's still the same turn and only one particular food item can be applied in that moment.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement