Monarch messages and screen state

Questions
#1

I faced strange behaviour with posting a message via monarch. I use factories to manage my screens.
Sometimes I don’t get the message that I send via monarch.post, it happens when I send 2 sequential messages e.g.

monarch.send("screen", "message_1", { some_data })
monarch.send("screen", "message_2", { some_data }}

I receive only the last message.

Also, when I tried to show a screen, post a message to it and show a popup, I don’t get this message. I found a workaround for it:

monarch.show(hash("screen"), {}, nil, function()
    monarch.show(hash("popup"), {}, nil, function()
        monarch.post("screen", "message", { data })
    end)
end)

Another strange thing is how the monarch keeps the state of the screen. At the game start, I show a gameplay screen that contains some metrics like current level and amount of gold via posting message from different parts of code. When the user completes the level, I show a new screen with a won message and buttons, and when he clicks on this button I show the gameplay screen and menu popup again, but monarch reinit my gameplay screen and I lost all metrics that I send to this screen previously. Why does monarch reinit my screen? I thought that it should exist in the stack and monarch will just show it to the user. It’s hard to keep everything in one place with a large codebase. Any suggestion on how to manage data for the persistent screen? The solution that I found is to create a module with shared state and load data directly from it on screen init.

1 Like
#2

Could you please create a ticket in the Monarch repo so that I can take a look?

Monarch will unload your screen when another screen is shown, which means that any state you have on scripts will be reset. I think the state will be kept if it is preloaded though.

1 Like
#3

Ok, I will create a ticket with repro steps

It’s marked as preloaded. After writing the topic, I rethink it and it looks like a shared state is a proper solution here, it allows more predictable behaviour and much fewer messages needs to be sent.

1 Like
#4

Yeah, putting this state in a Lua module makes a lot of sense.

1 Like