Oh I see 🤔 Hmm... yeah, messing with the reload commands can be a little fiddly, in my testing anything after a reload like that does not display. If I do eh...”\![reload,shell] shell has been reloaded” in script input, I can see “she” type out, and then the shell reloads and the rest is cut off. I think because these commands are probably expected to be used in a debug way?
You could consider having the alternates as completely separate shells instead, and locking it off so that the user can’t switch between them manually (though if you did that, you would need some additional code to prevent switches from the ghost explorer as well, if manual switches are undesirable). That way you could just give each shell its own menu in the first place, and not need the shell reload command.
The downside being, I think the blip would be more noticeable that way, and you would also need code to make the new shell loading in move to the same position that the other shell was when it was unloaded. I’ve done it before, it’s not impossible, but it is a bit of a pain 😅 If you did it that way, you could chain the balloon change command onto OnShellChanged.
That’s probably not ideal unless you’re really desperate though, I imagine it’d be difficult to switch over everything you have to deal with a multiple shell system depending on how far you are into it.
Another thought... you could set a variable in the OnSwitchMenu function like shellchange = 1 (and in that case, I would recommend changing it to an \![embed] tag rather than an embedded element, just in case the user cancels the script before it finishes executing. Or, you could use \t in the changing script to prevent the user from cancelling!), and then in one of the events that fires after the shell reloads, like OnNotifySelfInfo, check for that variable, and if it’s 1 set it to 2. Then in OnSecondChange, if it’s 2, change the balloon and reset the variable to 0. (Notify events can’t run scripts on their own, but if you don’t mind a 1 second wait you can shunt it off to OnSecondChange. It’s not my favorite method, but it’ll work in a pinch. You have to be careful with OnSecondChange though - under almost no circumstances do you want to end up outputting a script every second; it’ll interrupt your balloons and make the ghost unpleasant to use.)
That idea is definitely janky 😂 You could also try a timerraise (that’s timer raise, not time raise) command after the reload command instead, if you don’t mind waiting a second or two, and have the event that it raises change the balloon. That may come with its own kind of jank (can’t guarantee how long it’ll take the shell to switch in all environments), but it may be worth testing out to see if it’ll suit your needs.
But by far I think the most solid method, at least for changing the balloon, would actually be to combine your balloons into one. A lot of my ghosts have done this lately, where each balloon has multiple color options combined into a single balloon, and I use OnTranslate to change the balloon tags appropriately (but only if the ghost is currently on that balloon). SSP Angel is a good example of this! They go a bit overboard with the customization, in your case it should be a lot simpler. It should be as simple as an if check to make sure your custom balloon is being used, like if SHIORI3FW.BalloonName == “Aster Tooltip”, and then a check for which mode the ghost is in, and a set of replace commands if it’s in the mode with the alt coloration.
That method has a few benefits, primarily that it makes the script more straightforward so the balloon change always happens, and it cuts out any loading time for the balloon. And with OnTranslate handling the color changes, you can keep writing balloon tags as normal. (Side note, I do not recommend trying to use embedded elements for this instead. I used to do that with tags like %(b2) and %(b4), but then I found out that if I asked my ghosts to repeat the last dialogue just after I changed colors, they’d use the wrong one! So I let OnTranslate handle it now.)
I suppose eh... the problem is it’s difficult to have the reload shell command and a balloon change command in the same script and guarantee it’s not going to behave strangely. So I think the best solution, if you’re able to, is to eliminate one of those, and combining the balloons would do just that. But if that doesn’t suit your needs for whatever reason, maybe those other methods will work 🤔 just test them thoroughly, I suspect they would be plagued with issues of their own 😂
Ooh wait, I have one other idea. Have you considered using a change shell command, and simply switching to the same shell that you’re currently using? I think that would still have the effect of reloading it, but you get the benefit of the OnShellChanged event firing! That way you could set a variable, do the change, and then have OnShellChanged check if that variable is set and perform the rest of the change/dialogue on its end. \![change,shell,%(SHIORI3FW.ShellName)] should change you to the current shell, no matter what it is (uh, these SHIORI3FW variables I’m using assume you’re using YAYA and not AYA, since they come standard with YAYA specifically. I’m guessing you’re using YAYA if you’re using my guide, but I’ll make the note anyways.)
SORRY THAT’S A LOT but hopefully at least one of those things is helpful 😂
