__ess__
patreon
New inventory script released! Inventory with context menu.
🕑 Added 2023-02-27 14:33:37 +0000 UTCI have finally finished the new inventory script which uses a context menu for interactions with items! 😁
Watch the video above to learn how to use it, and download the example project containing the inventory.rpy file at the bottom of this post.
The example project and the tutorial video contains a lot of useful information on how to setup a game using this inventory. In addition to the video tutorial, I also have a few extra things I didn't manage to mention that I'll explain below in this post. They might not make sense unless you've watched the video.
⭐⭐⭐ Enjoy! ⭐⭐⭐
Important note!!! The code have been updated to fix a few issues. You can read what these are in the "script updates" section below.
Filenames
The filenames in the Environment Items, Inventory Items and UI folders should use dashes (-) between words for the inventory script to work properly. If you use anything else, you're going to get errors.
show_item_actions() function
When using the "show_item_actions" function with the item imagebuttons in a scene, you want to pass in the name of the item with underscores to the item parameter instead of dashes. Like this:
Function("show_item_actions", item_from = "environment", item = "scene_1_door_key")
Even though the names of the item in the images folder should use dashes (scene-1-door-key).
Label and screen names
I'm not sure how clear I was in the video about label and screen names. You can call you own labels and screens whatever you want! The only labels that needs to be named the same as in the example project are: items_combined, item_dialogue, item_pick and door_interact. They are referenced by the inventory script so they can't be left out. I put these in the main script file as the labels they call inside will be your own labels that do whatever actions you want.
Your scene screens can of course also be named whatever you want.
I might add more stuff here as I come to think of them. 😊
Scene intros
Dialogue intros to scene screens need to be launched with the on "show" OR on "replace" statements, depending on if the screen is one to replace another or if it's the starting scene. So essentially, any scene that isn't the starting scene in the game, and uses intro dialogue, should use on "replace" to make sure the label jumped to for the intro dialogue actually runs. See code in the script.rpy file for example.
SCRIPT UPDATES
v.1.0.1 (may 9, 2023)
Added another condition to the sensitive property of the example scenes (scene_1 /scene_2) in the script.rpy file. This condition helps make sure the scenes cannot be interacted with underneath the combine_items screen if it's showing.
v.1.0.2 (august 10, 2023)
A bug was reported where the items from the first scene could still be clicked on in the second scene, even though they couldn't be seen. This was due to that the first screen was still showing in the background as it was never hidden. To fix this with the least amount of code changed, I have added the same screen tags for all scene screens, so when switching to a new scene, it will automatically replace the old scene screen. Scene intros launched with the 'on "show"' statement now needs to be 'on "replace"' instead to work.
v.1.0.3 (October 20, 2024)
It was reported the 'align' property was used with the 'anchor' property, which in newer version of Ren'Py throws errors (align sets both anchor and pos, which is why the error appears). It has been changed to use 'pos' instead.
v.1.0.4 (March 3, 2025)
When the player tries to combine two items that can't be combined, this will first call the label "items_combined" which then checks if this is a valid combination. If not a valid combination, it calls the "claire_invalid_combination" label. This label didn't use the return statement (but instead used "call" to get back to the combination screen) and thus kept adding the call to the call stack unnecessarily if the player kept making invalid combinations. This label does not need to use the call statement at the end to work, so I swapped it for a return statement.
There's now also two pop_call() function calls inside the label to prevent adding the "cant combine" dialogue several times to the stack as well. You can do the same to your own label(s) that are used for telling the player the combination doesn't work. Add the function call once before the dialogue lines and once after like in the example script.
Comments
Sara
Hey BladeGrip! Yeah if the call stack is bothersome, you can add two "pop_call" function calls inside the "invalid_combination" label and also use a return statement instead of the call statement as it's actually not needed there. I tested the code below and it will avoid repeatedly adding the call statement and the dialogue inside the label to the stack. I'll update the script with it as well I think. Here's what I did: label claire_invalid_combination(item): show screen expression current_scene show screen combine_items(item) $renpy.pop_call() c "Hmm, that doesn't seem to work." $renpy.pop_call() call screen expression current_scene return # Return instead of calling. To see what happens in the call stack when you're testing this, you can print to the console: $print(renpy.get_return_stack()). I put it as the first line in the label when i tested this. So like this: label claire_invalid_combination(item): $print(renpy.get_return_stack()) ...
BladeGrip
First of all, I apologize in advance if it turns out I have missed something or brought this upon myself by modifying the codes in my project and forgetting about it. I just recently noticed that in "items_combined(item_1, item_2)" label, the invalid combination part uses 'call' command. ("call invalid_combination(item_1)"). I understand that this is necessary to make it able to carry the item_1 variable, but it doesn't seem to have a corresponding 'return', therefore if a player makes multiple invalid combinations while experimenting or such, I worry that it may end up creating a deep call stack, which in turn may bring up performance issues or problems with other 'return' commands in the project.
Sara
Hello! Yes, this is something I have missed to update. I will do this sometime next week, but for now you can change the 'align' properties to 'pos' instead and leave the values as they are. Thanks for reporting the issue!
Chloe N
There are errors from this code with the current version of Ren'Py. From a google search it seems this was in the changelog: "Ren'Py will now produce errors when a screen sets two conflicting properties, like align, and xalign. Previously, the behavior of this was undefined." File "game/inventory.rpy", line 170: keyword argument 'align' is incompatible with 'anchor'. align(0.4, 0.9) ^ File "game/inventory.rpy", line 190: keyword argument 'anchor' is incompatible with 'align'. anchor(0.0, 0.0) ^ File "game/inventory.rpy", line 197: keyword argument 'anchor' is incompatible with 'align'. anchor(0.0, 0.0) ^ Ren'Py Version: Ren'Py 8.3.2.24090902
