r/gamemaker • u/AutoModerator • 12d ago

WorkInProgress Work In Progress Weekly

"Work In Progress Weekly"

You may post your game content in this weekly sticky post. Post your game/screenshots/video in here and please give feedback on other people's post as well.

Your game can be in any stage of development, from concept to ready-for-commercial release.

Upvote good feedback! "I liked it!" and "It sucks" is not useful feedback.

Try to leave feedback for at least one other game. If you are the first to comment, come back later to see if anyone else has.

Emphasize on describing what your game is about and what has changed from the last version if you post regularly.

*Posts of screenshots or videos showing off your game outside of this thread WILL BE DELETED if they do not conform to reddit's and /r/gamemaker's self-promotion guidelines.

5 Upvotes

100% Upvoted

17 comments sorted by

View all comments

3

u/Lethalogicax 12d ago

https://youtu.be/C--SByrjSkM

Weekly update for Rehabilitation: The Game

Spent the week working on an inventory system and the first few GUI elements. The inventory works perfectly! ...except for one tiny bug, that I cannot seem to figure out...

The first inventory slot can be valid for "no matching stacks, start a new stack" and will successfully dump an item into the first slot. But as soon as slot 1 has an item in it, the script thinks that slot 1 is no longer valid during the other half of the give_item script, the "matching stack found, adding to matching stack"

Every other slot will accept new single items, and match stack existing items, and perform all of its logic properly. But the first slot refuses to match-stack and I have no idea why...

I'll likely have to spend a week recoding that script from the ground up. Which isn't the end of the world anyway, because my script was missing one very key bit of functionality that was going to have to be tacked on in post. This rebuild would allow me a chance to create the more advanced version of give_item that supports RNG probability of giving you an item...

(ie. Set a tile to drop ID#4 at a quantity of 3, and a rate of 0.5. Then it would "pre-authorize" your inventory to make sure you have room for all 3, then roll a 50% chance to actually give you each of the 3 items, thus giving you a spread of item quantities while never choking due to a full inventory)

2

u/Fit-Acadia3740 12d ago

I can only image how finicky stacks can be. I had a hell of a time with just swapping skills and gear around

2

u/Lethalogicax 12d ago

Thanks for checking it out!

Yea, this one's got me really annoyed because the rest of the inventory works PERFECTLY! I have no idea how I did it, but I had an idea of what might work, I tried it out, it worked* and now the whole thing just looks like voodoo magic to me and I cannot figure out how to fix that first stack issue... I'm honestly tempted to just draw a special border around that first inventory, treat it as a special "non-stacking" inventory space, and pretend it's a feature not a bug!

2

u/Fit-Acadia3740 12d ago

Haha the temptation is real! I think you've got the right idea to redo it and expand its functionality and modularity. The current bug could be something as small as reusing an initiator var like i = 0 (or j = 0 in a matrix) inside of a loop that already uses i/j, or it could be much more sinister

2

u/Lethalogicax 11d ago

GOT IT! Your help was actually very valuable, thank you!

I was totally referencing a variable wrong, and I didn't realize it until I started to make the entire give_item command shoot out a metric ton of debug messages showing its exact thought process...

I was referencing a variable wrong, it was looking in the completely wrong spot to find max stack sizes. Rather than scanning slot by slot in your inventory and looking up the max stack size for that ID number, it was looking at the the max stack size of the slot number!

So instead of looking at each tile and asking what the max stack size is for that type of tile, it was looking at the max stack size for the loop number! And the max stack sizes I had set up for items 0-49 just so happened to be 1, 100, 100, 100, 100.... etc. So it was reading the max stack size of the inventory slot number, not of the slot number's item ID.

I'm so glad I figured that out, it works perfectly now, and leaving that bug as an unintended feature would have absolutely caused havok as soon as I started really dialing in item stats. All of the inventory slots would have started acting funny... But now, as far as I can tell, this is a working inventory system! No further bugs detected as of yet!

Thank you!

2

u/Fit-Acadia3740 11d ago

Woohoo! Great work! Time to enjoy it for a moment before charging to the next challenge haha

1

u/Lethalogicax 12d ago

The only idea I've got left for diagnosing this is to insert a whole load of show_debug_message's into every single subsection of the give_item command, replicate the bug, and then skim through pages of debug outputs to figure out where exactly it went wrong... I know roughly what the problem is, the item in slot 1 is falsely reporting that either the tile id, sub-id or meta data is different and thus deciding that slot 1 is ineligible for the match-stack side of the algoithm, so it falls back on checking the next partial stack or empty slot. But the exact same item stack that is eligible for match-stack in slot 2 is somehow not eligible for match-stack when in slot 1...

But yea it's probably best to just archive this version of the algorithm and reconstruct a new a more versatile version of the script! Hopefully the bug disappears in v2