Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - DrLilo

#1
Hi guys. I'm using the default Inventory window from Tumbleweed, but I find that if I make gMain.Visible false and then true later, the inventory automatically returns to the first row. This gets quite annoying for the player, when gMain is hidden during every bit of dialogue (including using LookAt on an item deep into the inventory).

What I'd like to know is if there's a way to check which row is currently displayed at the top of visible GUI so that I can store that before gMain becomes invisible and then use invMain.ScrollDown() to advance back to whereever the user left off?

I've experimented with manually incrementing a variable every time the use clicks btnInvScrollDown but that solution falls over when items are Added or Lost elsewhere in code, unpredictably causing the visible row to shift organically.
#2
Thanks everyone, based on the feedback above I ended up disabling the global setting to hide interface and instead handled it manually using a 1 cycle delay as suggested. It feels a bit hacky, but the whole game now feels considerably more seamless without those 1 frame GUI flickers.
#3
Thanks all, I've been experimenting based on the feedback, but I'm not having a ton of luck. I've removed the default AGS behaviour to hide the GUI and created my own code to handle it, but it's gonna take a crap lot of QA to ensure it's working as elegantly as the default soluion.

I wonder if anyone has an answer to my initial thought, is there a way to remotely trigger a cycle of the current Room's repeatedly_execute function, besides just offsetting some manual code to occur after x number of cycles I mean...
#4
Quote from: Crimson Wizard on Fri 08/11/2024 18:55:23Hm, could you clarify how do you make GUIs invisible during blocking actions

I'm doing nothing special, it's the default behaviour of Tumbleweed to hide gMain whenever there's dialogue or anything with eBlock, such as player.Walk. I'm not sure whatever they're doing to hide gMain is exposed, I can't find any isntances of EnableInterface in VerbGUI.asc for example...

#5
Hi guys.

I'm wondering if there's a way to force a single cycle of the player's current Room's repeatedly_execute function to be run each time the player is about to exit a blocking routine (but before the GUI becomes visible again).

The idea is to prevent the GUI from appearing for a single frame and then disappearing again, if a variable was set during a blocking routine that is going to trigger another blocked routine from within the repeatedly_execute function. (ie, if(solvedPuzzle==true){ something immediately happens }).

I'm already a good way into this project and have been structuring (perhaps naively) most of the events in this way, where the repeatedly_execute function is looking for a variable and then animates a cutscene when it sees the change, but the annoying result is seeing a frame of flicker where the GUI becomes visible and then gone again, in between the player's previous action and the resulting cutscene.

What I (think) I need is for there to be a single cycle of the Room's repeatedly_execute function every time the player is about to regain control (and the GUI reappear), that way we go smoothly into each cutscene or very quickly back to normal gameplay if no variable has been set.

If anyone knows if that's possible please let me know, if not, I'm open to suggestions for other ways to prevent that one frame of GUI flicker. (However if you're about to say "don't handle cutscenes that way" it's a little late, tbh...)
SMF spam blocked by CleanTalk