Hey all, following up to a thread that is technically a different issue.
Went to test my title on CogDemos and then also tested in VSCode.
I have my inventory files in separate files, and am using *gosub_scenes to access and try to create nested gosubs.
If the inventory is accessed via choicescript_stats, and then a *return of any kind is called, it just immediately goes back to the game and exits choicescript_stats.
If this is genuinely the case on how it operates… then I have to sever being able to view the inventory except for when it hubs or combat situations, as I’d need to sever its entire visibility from stats which would be completely inconvenient.
As such, a decentralized inventory system needs to honestly occur or having such a singular, massive file is going to be a huge pain to work with in the long-term. I’ll sever the inventory from the choicescript_stats page.
Yeah honestly that is fair. Once stuff big, cramming everything in one file just turns into a mess. splitting it up might be the only was even if it means cutting it from stats screen for now. sucks a bit, but makes sense long run.
I just tried it in CSIDE online and it works fine. I used a gosub_scene inside stats page and returned from that file, and it just built the stat page normally.
That’s simplified, to show that two gosub_scenes are executed and then a *return is used.
The moment any command is used that has *return - it exits the choicescript_stats loop entirely. Prior to it, even if I use the gosub_scenes, it’ll have the Return to your Game button where the stats button is up top. That remains even as I bounce through the scenes. But the moment that the *return hits, it exits the choicescript_stats loop ,button goes back to ‘Show Stats’, and I’m back in the game where I was when choicescript_stats was called via the button.
Plugged in testing of the *return function with *gosub_scene within my lore system accessed via choicescript_stats, and it returns just fine, even with multiple nesting…
As I typed the above response, I then began to think…
What does a *gosub of any kind do?
*return returns it to its original location in code.
Originally, all of these *gosub_scene calls were *goto_scene which do not need further instruction.
So when it returned with *return, it then ran off the script file because there was no instruction underneath the *gosub_scene telling it what to do/where to go. And instead of breaking and just ending the game, it killed the choicescript_stats execution to return to the original game to try and save it. .
This is why we don’t write code when exhausted, folks!
Simple case of when a *return was called and it bounced back to the prior file, there was no further instruction underneath the original *gosub_scene so it just kept going down the file until it hit the ‘end’.
Since I had only tested it in the choicescript_stats file system, it just returned to the prior game instead of acting like an *end or *finish. Likely would have just ended the game if it’d been done outside of it.
Fixed it by adding *goto’s after the *gosub_scene instructions.
Sorry if I am being nosy but I am intrigued over how your inventory administrator works. There are a lot of solutions for this dilemma here in the forum (Yet Another Inventory System, tygger_fluff’s, CS_lib). Do you use one of these or its a homebrew solution?
Do your inventories has a hard or soft limit? (Like, fixed or expansive slots). It occupy one slot for each item or does the itens stack? Only the MC has inventory or you have little merchant NPCs with their own inventory abroad?
I am sorry if I am asking you too much. If is that so please deconsider my questions.
My inventory system is decentralized and uses a variety of different files, one for each category of item (weapons, quest, junk, misc, armor, crafting materials ect), and one for item details for each of those categories to save on overall file bloat and to neatly organize it.
Items stack and use a count that is tracked for each item that way you can sell, but this is within the means of a carryweight system, where each item has an item weight (barring certain things such as ammunition, notes ect).
Every single vendor that is built throughout the universe will have their own inventories that’re loaded into a general shop system that is going to be built. This’ll be split into categories of vendor. Weapons vendors, armor/garment vendors, ship vendors, material vendors, ect. That way I can limit the bloat that is experienced in the individual files.
While overall, there’s a lot of files, this is done to create a cohesive decentralized structure to the project, where one file does not contain everything. This not only improves performance in my opinion, but it also makes it far, far easier for me to organize and maintain the project as it grows.
.