Conditional (mis)behavior, maybe a song analysis bug?

[wboorman]

Ok, so I've seen this page, but my conditionals on some of my events in my current project still don't seem to be firing right.

I have three events, with the following intended behaviors: 1) First event should push on a specific date. You shouldn't be able to revisit it, nor should the player be able to activate it on their own, but it should happen again next year.

2) Second event should become available in a specific category (store.mas_songs.TYPE_SHORT) after the first event fires off once, and should remain available indefinitely.

3) Same as the second event, but in a different category (store.mas_songs.TYPE_ANALYSIS).

...But none of them are working right! Here is what they really do: 1) Event pushes regardless of date. Also, it appears as a topic in Unseen, and I would like to prevent this from happening if possible. At the very least, it shouldn't appear in Unseen until the chosen date. And no, the day I was testing wasn't the day I chose.

2) Event shows as visible in "Hey, Monika..." pool immediately, regardless of whether or not event 1 has occurred yet. I experimentally changed it to base off of a persistent instead, just in case the conditional method I was using wasn't doing what I thought it was doing, but the unintended behavior persists! EDIT: It also appears randomly, even though random isn't set and should default to false. Even if its condition were properly met (and it's not), it should be pooled, not random. What gives?

3) Event never shows up at all, neither before nor after event 1. Replacing the conditional with a persistent check instead of running an existing method had no impact, just like with event 2. EDIT: Unlike event 2, event 3 doesn't even appear to show up randomly. Monika will actively hit the "out of stuff to say" speech before triggering this event even once.

I based my project off of existing behavior in script_songs.rpy from the base MAS, but I noticed an odd lack of consistency in the whole three examples I had to work with. Two of the analysis events (specifically My Silver Lining and Wonderwall) seemed permanently locked off behind a "random=False, unlocked=False" that never seemed to be addressed, but the third analysis (Shelter) had no such limitations. All three appear on my game as they should, so apparently it doesn't matter? What makes Shelter not need their random and unlocked specifically declared false? Is Shelter wrong, or are My Silver Lining and Wonderwall doing something they don't have to? Is this a bug, or did I miss something?

[multimokia]

For one, the main song. I'm assuming there's bad data, for example the start_date/end_date properties were added later. In which case the new values are ignored and you'll want to delete the event to refresh it.

Conditionals and Actions are ignored for songs. If you want to introduce them via lore, use a TYPE_LONG (or TYPE_SHORT with random=False) as it's not selected randomly. You can also use a single label for the lyrics, where the intro topic calls them, along with the song topic.

The unlocked and random properties are persisted and locked properties, they're restored from event data on load. Additionally, the Event class defaults to unlocked=False and random=False. In other words it being there isn't necessary.

The song framework manages unlocking analysis topics on its own, but your label structure completely neglects the structure required by the song framework. See the top comments in script-songs.rpy for more details on that. With the above info, the analysis topics are all not randomed and not unlocked by default. The song framework manages unlocking it once the TYPE_SHORT version is sang.

[wboorman]

For one, the main song. I'm assuming there's bad data, for example the start_date/end_date properties were added later. In which case the new values are ignored and you'll want to delete the event to refresh it.

For testing purposes (in fact for this specific purpose) I have taken to testing all my events by erasing them immediately before adding them back at init 5. I use a combination of removeTopicID("labelname") and mas_eraseTopic("labelname") to accomplish this, and thus far it appeared to work. Didn't seem to matter as it wasn't having any effect anyway. Any other tables I need to clear out in order to simulate a clean install of the submod?

The particular thing I'm trying to reverse is the following: mas_getEVL_shown_count("label_name") == 0 I've been instructed to use something like this by numerous examples and even some documentation I was able to find, but I don't know how to reverse it. Thus, I seem to now be permanently locked out of testing my own code. At least it's stable now.

You'd think this would be fairly standard practice and more MAS devs would know this sort of thing off the top of their head. I've even asked for help with this same sort of issue before. Maybe this should be mentioned on the wiki, as resetting the field and clean installing is a routine element of QA in professional settings.

Conditionals and Actions are ignored for songs.

That explains it! I have no idea how I was supposed to know that songs were some kind of exception to standard rules...

[multimokia]

For testing purposes (in fact for this specific purpose) I have taken to testing all my events by erasing them immediately before adding them back at init 5. I use a combination of removeTopicID("labelname") and mas_eraseTopic("labelname") to accomplish this, and thus far it appeared to work. Didn't seem to matter as it wasn't having any effect anyway. Any other tables I need to clear out in order to simulate a clean install of the submod?

check mas_getEV("ev_label").start_date and mas_getEV("ev_label").end_date to check the dates on the event (replace ev_label with the label of the topic). See if they line up properly to what you want.

Looking at the code right now, you're setting the topic to be random if you simply load in between Today and April 2nd (NOTE: actions are NOT undone automatically, see undo action rules to look into action reversals)

The particular thing I'm trying to reverse is the following: mas_getEVL_shown_count("label_name") == 0 I've been instructed to use something like this by numerous examples and even some documentation I was able to find, but I don't know how to reverse it. Thus, I seem to now be permanently locked out of testing my own code. At least it's stable now.

I have no idea what you're asking here. That code is a boolean expression and will only return True or False. It changes absolutely nothing, and even if that was a single equals, the result of a function cannot be modified, so nothing changed.

[Booplicate]

There's a few bugs in your code, which may or may not affect the flow you get and hence led to unexpected results.

Those 2 functions you mention should be enough to completely reset your Events. They're dangerous and can wipe player's progression, they should be used with caution. I, for one, had never use them during testing. Notice that mas_eraseTopic takes an additional param: from which DB you want to remove your topic. Since you had your topics in the song DB and then transferred, you probably want to remove them from there.

Songs aren't an exception, all the databases behave differently. If you look at them, you'll find out which one utilise which Event properties. Songs never needed conditional/start_date/end_date, thus that was never implemented.

[wboorman]

I have no idea what you're asking here. That code is a boolean expression and will only return True or False. It changes absolutely nothing, and even if that was a single equals, the result of a function cannot be modified, so nothing changed.

The problem isn't that particular line, but what it implies. Basically, the more I've been reading, the more I'm noticing that the best practices in MAS seem to be to determine if certain events occurred based on whether or not certain labels have been seen. Fine, fair enough. We don't want a persistent polluted with several dozen different booleans. The problem is that seeing the label, even if testing, still counts as having seen that event once, and I've found no way to invert the process.

Right now, I'm in a position where my code will simply stop dead in its tracks because it thinks I've seen a certain label, even though I ran those two cleaning methods to simulate a fresh start. But I'm not getting to that fresh start point because something in the code remains under the impression that I've seen a certain label, and so a clean run isn't really clean. How do I get MAS to un-see that label again?

Those 2 functions you mention should be enough to completely reset your Events. They're dangerous and can wipe player's progression, they should be used with caution. I, for one, had never use them during testing.

So how do you test a clean install? I'm basically trying to see what it would look like for a user who installs the submod for the first time. No persistents. No lingering traces of anything. Just a fresh start. They may as well have just installed MAS fresh out of the zip file. In fact, if random elements are in play, I like to do these tests a few times and make sure that all the outcomes follow the rules that I want them to follow. What's a good way to clean up my environment if not with those two methods?

I'm getting the impression that there's a vastly easier way to do what it is that I'm trying to do...

[multimokia]

The problem isn't that particular line, but what it implies. Basically, the more I've been reading, the more I'm noticing that the best practices in MAS seem to be to determine if certain events occurred based on whether or not certain labels have been seen. Fine, fair enough. We don't want a persistent polluted with several dozen different booleans. The problem is that seeing the label, even if testing, still counts as having seen that event once, and I've found no way to invert the process.

If you're going by shown_count, mas_getEV("ev_label").shown_count = 0 If you're using the base renpy.seen_label("ev_label"), persistent._seen_ever.pop("ev_label"). The issue with seen_label is that as soon as the label is gotten to (literally the first line even), makes renpy.seen_label report it as having been seen (returns True). Which is why if you're checking the seen status of the label you're in, you have to use the shown_count.

If you want to test a clean install, delete the persistent. MAS starts from scratch again.

[wboorman]

If you're going by shown_count, mas_getEV("ev_label").shown_count = 0 If you're using the base renpy.seen_label("ev_label"), persistent._seen_ever.pop("ev_label"). The issue with seen_label is that as soon as the label is gotten to (literally the first line even), makes renpy.seen_label report it as having been seen (returns True). Which is why if you're checking the seen status of the label you're in, you have to use the shown_count.

Oh! I was thinking shown_count was some kind of readonly property, like how a List object's count works in .NET. Didn't know I could actually set it. I don't think I need persistent._seen_ever.pop() though. removeTopicID() literally does the same thing, while also double-checking that what you're popping exists in the list in the first place. Seems much safer to just use existing methods where possible than to pop things out of lists that I don't fully understand.

If you want to test a clean install, delete the persistent. MAS starts from scratch again.

I was wondering about that. Surely I could just move the current persistent to another folder, right? I imagine it's somewhat ill-advised to have been testing on my personal Monika this whole time...

[multimokia]

Yeah you should never test on your main install. You make a second install with a localized persistent so you don't cause damage when you inevitably need to revert changes to the persistent.

Considering it's just testing, not checking is basically fine since you just do it in the renpy console anyway, plus the persistent can be mended from console that way too.

[wboorman]

How do you localize a persistent? I was under the impression that the persistent is hard-coded to live in the app.data or some other obscure location on the hard drive? Also, what's a renpy console? Mind you, I'm using Visual Studio Code. I couldn't figure out how to get Atom to work, plus I've used VS Code before.

[multimokia]

Check our Contributing Guidelines for steps on how to do so.

[wboorman]

Thanks for all the help (and patience) again! I've finally got my submod where I want it.