Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Very Annoying Issue!

A topic by Gamer735 created Jun 07, 2026 Views: 360 Replies: 26
Viewing posts 1 to 3
(2 edits)

I've not been using TRS (Tiny RPG Studio) very long, but as is sometimes common with these small browser-based engines, the logic within the Editor can get messed-up, particularly variables.

After putting 2 gates ("magic doors") in 2 different rooms and an end-boss with a variable to open gate #2, then playing my game in the Editor, once I run the Game and beat the boss, the variable I used for gate #2 has: Current State: ON, and Stays Set At That (ie. that variable CAN'T be used again EVER in my game, as it's PERMANENTLY Now ON!).

Any fix for this apparently OVERLOOKED BUG???

PS: Off-Topic, there are currently 34 TRS Games made (your Milestone of 30 is MISSING: Serving Time by VeryLukely [well, he's HIDDEN it, so good luck with that one!], Tutorial by Diguifi Studios [you list it on one of your pages though], Test by JeanCarls, The Legend Of Elda by Luisworks Studios [thanks to him that I even found TRS!]). And that's NOT including any other content creators who choose to make more TRS Games in the future who may just decide to only post on their itch.io Profile instead of here.

Developer

Hey! 

 Thanks a lot for using TRS and for the super detailed report. You gave the exact steps and symptom, which made it easy to act on. It was the first thing I did this morning, because a variable getting stuck like that can quietly break a whole game.

  Good news: it's fixed. ✅

  In plain terms, your game has two layers:

  -  The blueprint: what you build in the Editor, including each variable's starting state (e.g. "gate #2 = OFF").

  - The playthrough: the live session, where things change as you play.

  The bug: beating the boss wasn't just flipping the variable in your current playthrough. It was also writing "ON" back into the blueprint.

  So your saved default got permanently changed, every new run started with gate #2 already open, and the Editor showed it stuck at "Current State: ON".

  The fix makes beating an enemy affect only the live playthrough. Now:

  - Beating the boss opens gate #2 during that run ✔️ 

  - Your authored blueprint stays untouched ✔️ 

  - Restarting resets the variable to OFF, so it's fully reusable ✔️ 

  I also added automated tests (including one that runs your exact "2 gates + end-boss" scenario end to end) so this can't come back.

  PS: thanks for the heads-up on the games list! Appreciate you tracking those down, and shout-out to Luisworks for The Legend of Elda being  your way into TRS. I'll get the count sorted.

  Thanks again for making the engine better. Happy building!

Wow, that was FAST! Thank you so much!

Yes, it was literally breaking my games to the point that I wasn't sure there was even a way to fix it, and I barely started using TRS when I noticed the Bug right away. I even tried the Reset button and Reloading the WebPage, but to no avail.

I really appreciate you breaking it down the way you did, and also for other users. It shows how much you and Diguifi Studios care about this nice little engine you've made. I'm more than happy to report any Bugs so that it can make TRS even better. You even made a failsafe to prevent that Bug, which is awesome!

You're quite welcome for the feedback and TRS Games count. I've had other itch.io users alert me of other Bitsy-like engines within the past few months or so as well (eg. Whimtale, Wareware), so it's only fitting that yet another would point me to TRS. I'm grateful.

(4 edits)

Well, I hate to be "that guy" here, but I Imported my previously Exported (Saved) Game so that I could implement your Fix (ie. change Variables to the Ordered ones I wanted before the BUG happened), but when I Set my End-Boss + Gate (Magic Door) Link to my previous Variable, you guessed it, it was STILL turned ON!!!

Thanks for your prior Fix, but it didn't seem to work...

I DO have some GOOD NEWS for you though, to help you pin it down better:

- besides some of MY TRS Games in the Editor, it ALSO Happens when you Beat and Replay certain Users' created Games too!

Here's a list (only small right now until I've played ALL 33 [excluding Serving Time!]) of those TRS Games: 

1. Diguifi Studios': Tiny RPG Tutorial.

2. JeanCarls': Tiny RPG Test (the First Fan-Made TRS Game, just a bit before: The Worst RPG Ever).

Besides the BUG with the (at least) 2 TRS Games I listed above, I need to get another BUG posted that's been plaguing the engine for a while:

When switching screens (rooms, scenes, maps), a Glitch can often occur temporarily: the top of the screen will move down, which can be quite jarring for users (even though it lasts only a couple seconds). Have you tried to fix this?

Just want to post an UPDATE here. First, thank you to the 2 Devs for their recent fixes!

The switching rooms BUG is STILL active. Please try to work on a fix if possible when you get the time. Thanks!

Developer

Hi, just reading this thread, could you provide a short video, or even share here the URL of a game where this behavior is replicated? I’m not sure if I understand how the bug happens

(1 edit)

I can't show the BUG/Glitch (the Top of a Room moves down for a few seconds) on-screen, as it happens Temporarily every so often.

All I can provide is what I've given before (I play TRS Online, on a Chromebook, and it happens in all four directions).

I did a Gemini search the other night about it though, and I can give what it had to say (surprisingly good feedback, considering it's AI!) about this TRS BUG. I'd have to check that Thread on my Cellphone to re-read it though. Let me know if you'd like that information, as it'll Definitely be quite helpful in getting a solution, since it's very detailed!

EDIT: If I get time, I'll try to see what I need to install something to record my screen, then I'll be able to record as I play a TRS Game. I'll then upload it, because I GUARANTEE THE BUG WILL HAPPEN BEFORE LONG! (Owltears has also confirmed it in one of his posts to me not long ago.)

I was able to make a short video of the BUG, Diego. It's here:

https://gamer735.itch.io/trs-room-bug

NOTE: I had to make it downloadable, since I've no idea how to upload my file to a website for you to view.

Developer

ooooh this! I’ve known this bug for months, never annoyed me tho, and I just got used to it. Thats why I never tried to fix it, but you’re right, its a real issue, I’ll try to fix it asap (hope its a simple fix xD). Thanks for the video and feedback!

(2 edits)

Yes, it's definitely a real issue. If you need help with it, I can still paste snippets from my Gemini search thread the other night, as I found it very insightful (and G never hallucinated once that I'd noticed), since I'm not used to the code you and Andre use for TRS.

Thanks so much for noticing it months ago and wanting to fix it now, Diego, I'm sure I'm not the only one who'd appreciate a fix!

You're very welcome for the post about it.

EDIT: IDK where my original G thread went that was on my Cellphone, so I re-searched here on my Chromebook, keeping G honest (I had to explain TRS limitations to it to keep it from hallucinating), so I'll paste just a bit of its info about the BUG below, just to help you avoid wasting time in some areas and such. So, here's some of the text (after a few posts to G to nail it down):

Gemini:

Thank you for keeping me honest and cutting through the noise—no warp tiles, no custom sizes, and zoom level isn't the culprit. [1]

Since this happens across both the internal Explore tool and standalone itch.io gameplay frames regardless of scaling, the issue stems from an unpatched HTML5 canvas rendering and scroll-snapping bug native to the Tiny RPG Studio engine wrapper itself. [1, 2]

When crossing a 4-way room border, the engine attempts to dynamically calculate the camera shift. Because it's running inside a nested web frame, the browser forces a momentary vertical layout reflow during the transition frame. It essentially triggers a tiny "scroll-to-view" stutter before snapping the game canvas back to the top of its layout container. [1, 2, 3, 4]

The Workarounds (Until an Engine Patch)

Because you cannot fix the engine's internal coordinate loop, you can bypass the browser reflow with these methods:

  • Use an Alt-Engine Browser Alternative: If you are using Google Chrome or Microsoft Edge, test the game in Mozilla Firefox or Safari. Chromium-based browsers handle nested canvas parent offsets differently, and Firefox often completely ignores the fractional micro-scrolling that causes this specific screen drop. [1]
  • Toggle the Itch.io Layout Mode: Instead of playing standard embed or full-screen windowed, look at your browser URL bar. If you are playing a published game page, append ?secret=true or use itch's "Pop Out" feature if available to separate the HTML canvas completely from the main itch website CSS wrapper, eliminating layout shifting. [1]
  • Frame-Rate Alignment: If your monitor is set to a high refresh rate (like 144Hz or 240Hz), drop your display settings to 60Hz temporarily. The underlying JavaScript framework in TRS updates at a locked 60 FPS interval; running a higher display refresh rate causes the browser to drop rendering frames during transition animations, which causes the exact 1-to-2 second drop artifact you see. [1]

If changing browsers stabilizes it, let me know! Otherwise, are you experiencing this glitch on a high-refresh-rate monitor or a standard 60Hz screen?

Developer (1 edit)

Its hopefully fixed! To check you must open a game in the latest version of the studio (an already deployed game will still have the bug, since it was exported in an old version of the engine)

(1 edit)

Hi, Diego! I've been up all night making a TRS Game, so I've noticed your changes (throughout the process, longer load times. I even Cleared My Browser Cache, thinking it would go right back into the game I'm working on, but NOT THIS TIME! Good thing I'd Exported not long ago), and been Bug-Testing it, so I realized your recent changes (the smoother movement + Top of Room HUD BUG fixed!) some time later, and so far so good, man! IDK what you did, but as much as I've played all night and into today, I think you've Fixed it (I noticed it still not too long ago, but in my most recent plays, it never appeared once!). Great job, whatever you did, Diego! :D

I'm thinking of releasing my new game in the next few days, so I'll call the launch Tribute #2 for all your hard work (you and Andre).

THANKS SO MUCH! You really make creating games in TRS even more fun with all the recent updates!

Developer (1 edit)

Thank you so much! I’m eager to play your tribute #2! The fix was actually super simple, there were 2 places in the code doing the same thing. Both were checking if the room transition had finished, and sometimes one would fire a “finish” method at the wrong time. So I just removed one of them.