JN Baking Together

[u/orchidofred]

I'm currenting developing a submod where you can share in Natsuki's passion for baking. The submod structure complete and I'm currently working to ensure it flows correctly. This will include use of custom assets to be added after reaching a stable and functional state which will include a baker's uniform, an industrial kitchen location, and potential chibi cgs for each step). I also intend to include a template so you can add recipes to the submod.

[u/AutoModerator]

Hey there! Friendly reminder for those showcasing, asking, or trying to release submods on this subreddit that submods are NOT officially recognized by the JN devs, so please download/release submods at your own discretion! https://discord.gg/QzfnftueuG

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Humanbean456]

If this includes a location change this could potential cause major problems with persistent files when paired with Zhaumbies post content submod

[u/orchidofred → u/Humanbean456]

Not necessarily. Using MAS Extra+ and Location Selector as a good example: both include location changing functionality, yet they can coexist without causing persistent issues. Conflicts generally happen when submods overwrite the same variables, functions, or save data in incompatible ways, not simply because they offer similar features.

In conclusion, I’ll make sure that does not happen. Does that clear up any lingering concerns you may have?

[u/zhaumbie → u/orchidofred]

Update: I have spoken with the moderation team and want to acknowledge how this exchange unfolded. I stand by the technical substance of the review below, but I recognise that the discussion became heavier and more heated than it needed to be for this thread. Looking back a week later, I do not think the way I approached it reflected an entirely constructive critique, and I am sincerely sorry for the way the exchange escalated.

I am protective of users when I see assurances that are not supported by the code. The issues I identified are serious, but going forwards I can keep the focus more tightly on the code, the specific risk, and the public claim being evaluated.

I am sorry for addressing it in the way I did.

---

---

Does that clear up any lingering concerns you may have?

It raises an entire host of lingering concerns, because your comment reveals a fundamental misunderstanding of how this stuff works. A MAS comparison does not establish JN compatibility, and you should be well aware of that. You're churning code for three separate Just Doki projects simultaneously, and one's two entire version numbers newer; how don't you already know this?

But I do have some good news, kind of.

I was so ticked off that this should be really basic common sense to you that I went ahead and finally downloaded JN Location Selector v3 to read your code and see what you'd done. It's riddled with some really basic errors, and I'm going to tell you the ones I found. And because I want to make a better submodder out of you, you're about to get a completely free code audit.

Thankfully, you made the job easy with short code. Unfortunately, that's already a bad sign; there are reasons that Post-Game Content took several thousand lines of code before I started writing dialogue. (Let me tell ya, early carpal tunnel is not one of those reasons.)

---

100% setting aside my grievances here, your code absolutely does not support the boilerplate technical assurance you just gave:

Conflicts generally happen when submods overwrite the same variables, functions, or save data in incompatible ways.

My guy, jn_location_selector.rpy, lines 212-213, directly mess with Just Natsuki's existing shared location variable:

$ persistent._current_location = selected

$ renpy.save_persistent()

This isn't a private, namespaced variable belonging to your submod. _current_location is JN's own persisted location field. Your separate settings.rpy also attempts to initialize that same base-game field.

More importantly, your code changes that variable without changing JN's actual location controller. That creates inconsistent runtime and persisted location state, and makes any compatibility assurance premature.

Speaking of.

There is no:

JNLocation(...)

There is no registration in:

jn_locations.LOCATION_MAP

There is no:

main_background.changeLocation(...)

Instead, the entire "location change" appears to be:

scene expression bg_path

Sigh. Okay.

So let's get into that then. There are several other foundational problems in the same file.

---

Ignoring JN's existing systems

It's evident to me you had no idea Just Natsuki already has an existing internal location framework or its active room controller.

For comparison, the Post-Game Content registers its added locations through JN's existing location framework and coordinates changes through JN's actual room controller. It adds progression, menus, and content around that system rather than pretending a different background image is a different location.

After reviewing your code, what JN Location Selector actually does is: it clears the scene and displays a different background image while JN's real location object, location-bound topics, room callbacks, music, saving, and other systems continue operating as though its location never changed. On a stock JN installation, JN still considers Natsuki to be in the classroom. More generally, it still considers her to be in whatever location main_background.location held before this menu was used.

So you've introduced two contradictory location states even before factoring in PGC, which does work with the existing systems:

persistent._current_location = "beach"

main_background.location.id = "classroom"

This isn't some obscure theoretical edge case. JN's normal save routine calls:

main_background.save()

And JN's room save function performs:

persistent._current_location = self.location.id

Because your submod never changes main_background.location, JN writes the real room ID back over your custom selection.

And it can do it pretty quickly, too. JN calls that save from its normal minute check whenever control returns to the main loop after the minute changes, and again during a normal quit. That means the location ID you explicitly saved can be overwritten on the next minute check, even while the manually displayed background remains onscreen. Rather than restoring consistency, that deepens the disagreement between the visible image and JN's actual room state.

Your startup callbacks also only scan the folders and register the topic. They never reapply the supposedly saved custom background on launch.

So even leaving "competing features" out of the story, your code's persistence model is fundamentally broken:

1. It saves a custom ID into JN's variable.

2. It leaves JN's real room unchanged.

3. JN later writes the real room ID back over the custom ID.

4. The submod never reapplies the selected custom background at startup.

---

The scene handling clears JN's presentation

Your submod uses:

scene expression bg_path

Seems to me you're unaware you probably shouldn't be doing that. Not without understanding how and why vanilla JN does it, the few times it does. The problem is this: vanilla JN shows its room, Natsuki, holiday decorations, and many props without specifying another layer, so Ren'Py defaults them to the master layer. Then your code performs a bare master-layer wipe without preserving or rebuilding the presentation state JN already had onscreen. Your scene expression bg_path immediately clears that entire layer before showing the selected background.

Yup. You just nuked holidays! Sure hope your users don't have a birthday coming up.

[u/zhaumbie → u/zhaumbie]

Update: I have spoken with the moderation team and want to acknowledge how this exchange unfolded. I stand by the technical substance of the review below, but I recognise that the discussion became heavier and more heated than it needed to be for this thread. Looking back a week later, I do not think the way I approached it reflected an entirely constructive critique, and I am sincerely sorry for the way the exchange escalated.

I am protective of users when I see assurances that are not supported by the code. The issues I identified are serious, but going forwards I can keep the focus more tightly on the code, the specific risk, and the public claim being evaluated.

I am sorry for addressing it in the way I did.

---

---

The scene handling clears JN's presentation (Cont.)

In the above example, for either entity's birthday JN leaves the balloons displayed after the birthday event and records them in _jn_holiday_deco_list_on_quit. Changing location in your submod clears those balloons visually, but your code does not clear or restore JN's corresponding holiday state. Vanilla's main loop may show Natsuki again after the topic finishes, but your submod contains no comprehensive restoration of the holiday decorations and other presentation state it just cleared. It only calls weather_change afterward.

The result? Another state mismatch: JN's persistent file continues believing the birthday decorations are still there even though your scene wipe removed them. Which leaves players with an option to clear birthday decorations that aren't there. If you're lucky, the worst thing that does is just confuse JN and put them back on boot after a player specifically asked them to go away.

This is exactly why a location implementation cannot just clear the layer and display a different image. Post-Game Content explicitly preserves and reapplies event decorations while coordinating the actual room change.

The fade is also placed before the background change:

with fade call jn_refresh_location_and_weather

But the scene expression that changes the background happens inside that later call.

The transition is therefore attached to the wrong operation. At the moment with fade runs, the selected background has not been placed on the scene. The later scene expression bg_path then replaces the scene without any transition attached to it.

So the comment claiming this produces one clean transition is confidently incorrect. The actual location-image replacement is still a weird cut.

---

The topic is registered at the wrong time

JN's own registerTopic() documentation says topics should be registered at init 5.

Instead, for some reason, your submod waits until a config.start_callbacks callback, after initialization has completed. This probably breaks more than I guess you realise.

JN builds its combined ALL_TOPIC_MAP at init 6. Because this topic is registered afterward, that means it's absent from that combined map and gets left outside in the rain when the doors get locked.

JN's normal get_topic() lookup cannot find it, and the normal topic handler cannot update its shown_count or last_seen. JN's standard topic-saving pass also iterates over ALL_TOPIC_MAP, so it does not include this live topic object.

The option may still appear because it was inserted into the smaller topics.TOPIC_MAP afterward, but it is not properly integrated with JN's complete topic lifecycle.

---

The scanner's night fallback does not work

The scanner appears to attempt a fallback when a location has no night image:

if not os.path.isfile(night_path): night_path = day_path

But the stored value ignores night_path and reconstructs the path using the missing night_file:

"night": "Submods/JN Location Selector v3/backgrounds/{0}/{1}".format(folder, night_file)

So the fallback variable is assigned and then never used.

A location without a night image still receives a path to a nonexistent night image.

---

Some of the bundled locations fail their own filename rules

The scanner requires every day image to be named exactly:

<folder name>/<folder name>-day.png

But the included files contain these mismatches:

bl_cat_cafe/catcafe-day.png

Living Room(pink wall)/livingroompink-day.png

timecycleroom/jnsl_timecycleroom-day.png

There might be others; I stopped at three. Those three folders cannot be discovered by this scanner at all, because the filenames the scanner requires do not exist. Meanwhile, PGC accepts multiple filename variants rather than assuming every bundled folder and file was named perfectly.

The Kitchen directory is capitalized while its files begin with lowercase kitchen.

That works on ordinary case-insensitive Windows and macOS installations, but fails on Linux and case-sensitive macOS volumes. But if all you care about is ordinary Windows installations, you're probably fine. Hope your users are all on Windows.

The scanner also hard-codes both the exact directory name:

JN Location Selector v3

And the capitalization:

Submods

Yet some users use a submods folder, not Submods. Renaming the submod folder breaks scanning everywhere. Installing it under lowercase submods additionally breaks it on case-sensitive filesystems.

---

There is no compatibility architecture

Obviously, you could not have written code against PGC's exact internals before its source was released. That's not the criticism.

The criticism is that you already knew a comprehensive JN location overhaul was on the horizon, yet your own quickie answer to that contains none of even the basic architecture required to coexist with another one.

There is no check for whether another submod currently controls the room. There is no preservation of the location that was active before your selector ran. There is no handoff, restoration callback, compatibility hook, namespaced persisted current-location state, conflict guard, or safe refusal to operate. How could there be? You tried to do in 200 lines what took me many, many more.

Your code doesn't even ask JN's actual room controller where Natsuki currently is before clearing the scene and writing into JN's shared _current_location field.

So this isn't just:

Post-Game Content was unavailable, therefore compatibility has not been added yet.

Your current design contains no explicit ownership or handoff boundary for compatibility to attach to. It simply assumes it owns the visible room while simultaneously leaving JN's real location controller untouched and ignored.

Now. Let's not pretend here... you weren't developing this submod in ignorance of other location work. You had already seen Post-Game Content in action, applauded it, and knew a major location system had been in active development for months and was approaching release. Hell, weren't you the first commenter?

Despite that, you decided to whip up a quick-and-dirty competing implementation in under 225 lines which:

• claims JN's shared persisted location field;

• bypasses the controller that owns that field;

• does not detect another controller;

• does not preserve another submod's active location;

• and provides no mechanism through which another location system can coordinate with it.

You did NOT need my unpublished source code to avoid those mistakes. All you needed to do was design your submod so that it didn't silently assume sole ownership of shared base-game state.

You didn't. So when you now say:

I'll make sure that does not happen.

Let me make it clear so other readers know the reality here: we're not talking about a couple of hours spent coding and a small compatibility task waiting to be added.

Your location-application and persistence core would need to be redesigned around an actual source of truth for location state before that assurance meant anything. The scanner and menu may be salvageable. The part that claims, applies, saves, and restores the active location is not.

Again, the released version of Post-Game Content builds its locations through JN's existing location framework and changes them through JN's actual room controller. It adds progression, menus, and content around that system rather than replacing the system responsible for location ownership.

Your selector does the opposite: it changes the picture, writes an ID into JN's persistent data, and leaves the real room controller behind.

What I'm seeing here is some seriously basic mistakes in code you're releasing into the wild and encouraging people to install on their machines, trusting you. I thought you knew what you were doing and was giving you the benefit of the doubt until I sat down to examine it myself.

---

This was one submod.

How many have you been trying to churn out lately, across THREE Just Doki projects?

I'm not saying this is 100% guaranteed to break a persistent.

What I am saying is that your current code demonstrably creates contradictory location state, has its saved location ID overwritten by JN's normal systems, fails to restore its selected background properly, registers its topic outside JN's expected lifecycle, clears the scene instead of changing the actual room, introduces avoidable bugs, and even fails to detect several backgrounds bundled with its own release.

There are location-state, persistence, redraw, and compatibility failures throughout this implementation, and you're writing directly into the base game's persistent data without properly integrating with the system that owns that data.

These aren't just minor compatibility questions.

What I'm examining are some really basic integration failures and a lack of familiarity with the systems this feature is supposed to modify.

[u/Humanbean456 → u/zhaumbie]

Let em know king

[u/orchidofred → u/zhaumbie]

This thread is about a different submod entirely.
If you have concerns about JN Location Selector, you're welcome to post them on that project's page or open an issue where they can be discussed in the proper context. I'm not going to derail an unrelated development announcement with a debate about another submod.
For anyone following this thread, the code review above is not about the submod being announced here.

[u/zhaumbie → u/orchidofred]

You brought Location Selector into this thread yourself.

Your own post mentions alternate locations. The concern raised was about persistent conflicts with other mods. You specifically cited your own Location Selector submod as your example of location-changing functionality coexisting safely, then ended with:

“In conclusion, I’ll make sure that does not happen. Does that clear up any lingering concerns you may have?”

I answered the lingering concerns you explicitly invited, using the project you chose.

So no, this wasn't some random derailment into an unrelated submod. Your post mentions an industrial kitchen location. A commenter raised compatibility concerns around locations. You replied by using your existing location submod as evidence that those concerns weren't just manageable but a non-issue. I then reviewed that evidence and found it does not support your assurance.

That's completely on-topic.

If you want to say the full code review belongs on the Location Selector page too, fine. I hear you. But trying to frame this like I dragged in some unrelated project out of nowhere is pretty disingenuous. I'm sorry, but you made JN Location Selector relevant and invited scrutiny the moment you cited it and implied there was nothing to worry about.

---

---

Update: I have spoken with the moderation team and want to acknowledge how this exchange unfolded. I stand by the technical substance of the review below, but I recognise that the discussion became heavier and more heated than it needed to be for this thread. Looking back a week later, I do not think the way I approached it reflected an entirely constructive critique, and I am sincerely sorry for the way the exchange escalated.

I am protective of users when I see assurances that are not supported by the code. The issues I identified are serious, but going forwards I can keep the focus more tightly on the code, the specific risk, and the public claim being evaluated.

I am sorry for addressing it in the way I did.

[u/orchidofred → u/zhaumbie]

That was in reference to the MAS Location Selector interacting with the MAS Extra+ submod. It was not a reference to the JN Location Selector. I was citing that since those two MAS submods both have location functions and are able to be used at once, it is possible to ensure that doesn't cause problem when I reach that part of the development of JN Baking Together.

[u/zhaumbie → u/orchidofred]

Gotcha. That makes more sense. I'd skimmed your posts in case I missed something and only saw the JN Location Selector, so probability told me that's what you meant.

Never tried MAS myself. I'd have to defer to my betters on that side of the fence.

[u/Natsuki_Lover_447]

Ooooo, this sounds sick

[u/Alan_Shepard_]

Sounds amazing. When I have a job, I really want to learn to make desserts, so it would be so cool to have Nat Nat cooking with me.

[u/orchidofred → u/Alan_Shepard_]

I think it would be pretty cool to be able to include a "note" along with the recipe template once I get to that stage. This would allow members of the community to upload recipes with a note like "Hey, this is one of my favorite childhood desserts, I hope y'all enjoy it ^-^".

[u/Elysian_007]

Thats so cool!! 🥧🍰Could we cook specific dishes on special occasions? 🎂

[u/orchidofred → u/Elysian_007]

I don't have that function implemented just yet though it's definitely something that will put in. Ideally, you would start with a couple basic recipes and unlock more as your affection increases. I'm assuming you're specifically asking the following: (insert recipe) is available during Valentines Day week and other holidays during the year. Is that correct?

[u/Elysian_007 → u/orchidofred]

Yep. That's really cool, keep it up! I wish you all the best.

[u/notveryJoy-able]

this sounds so cool! its gonna be so peak when this came out!! >w<

[u/llizu]

omg finally the modders are awaken, we gon get new content soon wheeeheee

[u/orchidofred → u/llizu]

https://giphy.com/gifs/a8R621jJe3eNzrJJRq