How to keep the message window from disappearing when the show choices command is used

[Gargoyle77]

Hello, everyone. Can you help me with this? I'm trying to make a message appear and then run a common event that shows some choices, but the message is automatically hidden when the choices appear. I know that this is because there are things between the message and the show choices command, but I need it to be this way so the interaction can be looped. Is there a way to fix this without resorting to making multiple common events with different messages?

To sum up, I want some way to keep the last shown message to appear (or not to disappear) when the show choices command is used (no matter what).

Thanks for reading!

 

[ATT_Turan]

If you share screenshots of your event, perhaps we can help you structure the loop/jumps so that the necessary commands aren't in between.

 

[Gargoyle77]

If you share screenshots of your event, perhaps we can help you structure the loop/jumps so that the necessary commands aren't in between.

Yes, sorry. The image shows examples of the loops I want to make in many systems of my project. As I see it, the loops are a must if I want to make these kind of systems that constantly loops back to themselves. The only problem is, as I said before, the dialogues are not shown at the same time as the choices if both are in different common events, even if one is immediately next to the other. Is there a way to fix this without changing much? Thanks for the answer!

 

[ATT_Turan]

This is very weirdly structured. You don't actually have any loops in there - loop is a term with a specific meaning (see the Loop event command on the first tab).

But it looks strange to me that you have all this split across three common events. And it looks extra weird that you're calling the same event from inside itself - what you're referring to as a loop is you calling COMMON from inside COMMON.

So we're going to use actual loops, instead.

Now to get the exact view you want, with the choices always attached to text windows, we need two switches (to see if we're inside one of the loops) and a variable (to control what the text is) and a script call.



The script call for the Control Variable is:

$gameSwitches.value(1) ? "Is there anything else you want?" : "Greetings"

Replace the 1 with whichever switch you're using. You can see for the first loop I'm using switch 1 and the second loop is switch 2, and you can see where I'm turning them on and off.

This part is optional, if you want to have different messages there. Most of the time you see systems like this in older games, it's just the same text every time, so that would eliminate the variable and switches.

 

[Andar]

loops

what you have is not a loop, but a recursive call.

and besides the wrong terminology in describing it, recursive calls are very bad for the computer.
because each recursion adds to both stack and memory requirements, so there is an increasing risk of a stack overflow or a memory leak.

 

[ATT_Turan]

what you have is not a loop, but a recursive call.

Dilbert's recursive acronym is one of my favorite strips.

 

[Gargoyle77]

This is very weirdly structured. You don't actually have any loops in there - loop is a term with a specific meaning (see the Loop event command on the first tab).

But it looks strange to me that you have all this split across three common events. And it looks extra weird that you're calling the same event from inside itself - what you're referring to as a loop is you calling COMMON from inside COMMON.

So we're going to use actual loops, instead.

Now to get the exact view you want, with the choices always attached to text windows, we need two switches (to see if we're inside one of the loops) and a variable (to control what the text is) and a script call.

View attachment 251609View attachment 251610

The script call for the Control Variable is:

$gameSwitches.value(1) ? "Is there anything else you want?" : "Greetings"

Replace the 1 with whichever switch you're using. You can see for the first loop I'm using switch 1 and the second loop is switch 2, and you can see where I'm turning them on and off.

This part is optional, if you want to have different messages there. Most of the time you see systems like this in older games, it's just the same text every time, so that would eliminate the variable and switches.

It seems I still got much to learn. Thanks a lot for taking the time to do this and explain it to me. I'll change my events to now implement proper loops as you taught me. I have 1 last question. How can I change the text inside "$gameSwitches.value(1) ? "Is there anything else you want?" : "Greetings"" with another common event? I mean, imagine I want the npc to at one point of the game say another thing that's not "Greetings" or whatever I put there. Could I put a variable instead of the text and then change that variable whenever I want? If so, how can I do that? Thanks again for all the help.

what you have is not a loop, but a recursive call.

and besides the wrong terminology in describing it, recursive calls are very bad for the computer.
because each recursion adds to both stack and memory requirements, so there is an increasing risk of a stack overflow or a memory leak.

Oh, I didn't know that. Thanks for the heads up. Glad to know that before I proceeded with that kind of systems. One question: When is it safe to call a common event inside a common event? I usually put common events inside the events and then change whatever I want from the common event itself so I don't have to track every individual event to change something. Can I keep doing that or is there a risk? Also what about calling common events from inside other common events? Again, thanks a lot.

 

[Andar]

When is it safe to call a common event inside a common event?

in all cases except the ones where you create a recursion by calling itself or a common event further up the line.

Think of it as the oxygen line to an old diver - everything is save as long as the line goes free, but grap back to it and create a knot and problems will appear.

 

[Mac15001900]

Could I put a variable instead of the text and then change that variable whenever I want? If so, how can I do that? Thanks again for all the help.

Yeah, you definitely can. You can set a variable to a string by choosing "Script" in "Control Variables" and putting the text in quotation marks. Then access it using $gameVariables, similar to that switch. For example:
$gameSwitches.value(1) ? "Is there anything else you want?" : $gameVariables.value(1) will replace "Greetings" with whatever value the first variable has (and ofc you can replace the 1 with the number of the variable you'd like to use).

 

[ATT_Turan]

When is it safe to call a common event inside a common event? I usually put common events inside the events and then change whatever I want from the common event itself so I don't have to track every individual event to change something.

Andar already answered you about the recursion part (an event not calling itself, nor an event that will end up calling it again).

But you're kind of ignoring the point of common events. The idea is that you put code inside of common events that will be called from more than one place in your game - it's "common," shared.

Anything that's specific to one map or event should, logically, go on that map. You do have a finite number of common events, and unless you add lots of descriptive comments, your method can actually backfire because you'll see an event in your list but not know where it's being used.

 

[MemoriesLP]

When is it safe to call a common event inside a common event? I usually put common events inside the events and then change whatever I want from the common event itself so I don't have to track every individual event to change something.

It's fine to make a common event call another one. The main issue here is you making the recursion with them.

For my bestiary I use 3 common events.
First one sees which Enemy Troup is in combat. Second sets a bunch of variables. Third sends the message with the info about the enemy. So one common event calls the other.
It could be one single massive gigantic common event, but thats a nightmare to take care of, so I separated it in to 3.

 

[Gargoyle77]

Thanks a lot for the help. I'm learning about loops and how to use them properly, but for now I think I'll sticj with common events, but will avoid making recursions. Thanks a lot again!