DramaFork Shows "Needs Update" but the Old Assets Are Still There—How Should Creators Judge Whether They Can Still Be Used?
"Needs update" only means that this change touched a dependency of some completed step. It does not mean the old assets have already been replaced, nor does it mean they are necessarily wrong. What you need to do is manually verify: is what was changed the fact that the old assets are expressing? If the fact expressed by the old assets still holds, they can continue to be used; if the fact they express has already been changed, they need to be redone or at least changed to be consistent.
Introduction
"Needs update" only means that this change touched a dependency of some completed step. It does not mean the old assets have already been replaced, nor does it mean they are necessarily wrong. What you need to do is manually verify: is what was changed the fact that the old assets are expressing? If the fact expressed by the old assets still holds, they can continue to be used; if the fact they express has already been changed, they need to be redone or at least changed to be consistent.
The two fictional teaching examples below illustrate this. The project names, character names, and dialogue in the examples are made up, used to demonstrate the judgment process, and are not actual test records.
First Distinguish Two Things: Status Markers and Data Retention
This article is organized by DramaFork and explains according to the current project implementation: upstream modifications will, according to step dependencies, mark the relevant completed downstream steps as "needs update" while retaining the old data. This marker indicates the scope of review; it does not judge which specific sentence or action in the old assets has become invalid. Creators still need to check the actual expression, and then decide which assets to modify or retain.
Real dependencies are defined by step: changing the plan affects the script and subsequent generation steps; changing the script affects storyboards, style, characters, nodes, video, preview, and export; changing storyboards affects nodes, video, preview, and export; changing style affects characters, video, preview, and export; changing characters affects video, preview, and export; changing nodes or video affects preview and export. When the relevant steps are not completed, they will not be directly marked as "needs update" by this rule.
When judging, first ask three questions: What fact appears in the old assets? What was changed this time? Do the two conflict?
Case One: Changing a Person's Name, When the Old Assets Do Not Contain That Name
In the fictional project Letters from Fog Harbor, the character was originally named "Lin Wan." The completed character art and three storyboards had no name text, but the dialogue in one video said her name. Later, the author changed the character name in the script to "Lin Zhao."
This is a script change, and the relevant completed storyboards, style, characters, nodes, video, preview, and export all enter the "needs update" scope. Then check the actual content item by item:
- Character art: There is no name in the image, the appearance has not changed, and the old image still expresses the correct fact, so it can continue to be used.
- Storyboard: The image description says "she pushes the door open," with no name written, so it can continue to be used.
- Video: The dialogue subtitle contains "Lin Wan, you're here." The fact expressed by this line has already been changed, so the subtitle needs to be redone or the line re-recorded.
- Preview and export: Because they include the video, they are affected along with it.
The key here is not the three words "needs update," but whether the fact "Lin Wan" appears in the old assets. If it does not appear, it can still be used; if it does appear, it must be changed.
Case Two: Changing an Action, When the Old Assets Locked the Action In
In the same project, the script originally said "she puts the letter into the drawer," and the completed storyboard and video were both drawn according to this action. Later, you changed the script to "she burns the letter."
This time the action fact was changed. The old storyboard and old video express "puts it into the drawer," which conflicts with the new script and needs to be modified. The system still marks the relevant completed steps according to the script's full dependencies, including style and character assets; manual inspection can confirm whether the appearance and style are still applicable, and it is not necessary to automatically redo every file just because it entered the review scope.
But note: if the old storyboard only showed "she stands by the window holding the letter" and did not show putting it into the drawer, then it may still be usable, and you only need to check the subsequent continuity. The basis for judgment is always the content actually expressed by the old assets, not the marker itself.
A Reusable Review Record Template
You can check item by item according to the table below. In the table, "the fact expressed by the old assets" must be written specifically, not just as "no problem."
| Step | Fact appearing in the old assets | This change | Conflict? | Handling |
|---|---|---|---|---|
| Character art | Appearance, no name | Name change | No | Continue using |
| Storyboard 3 | "She pushes the door open," no name | Name change | No | Continue using |
| Video subtitle | "Lin Wan, you're here" | Name change | Yes | Redo subtitle |
| Storyboard 5 | "She puts the letter into the drawer" | Changed to burning the letter | Yes | Redraw |
| Node text | Describes "putting the letter" | Changed to burning the letter | Yes | Change text |
After filling out this table, you will know which can stay and which need to be changed. The marker only helps you find the scope; conflict judgment depends on you reading the old assets.
When a Character Makes Up an Excuse, Do Not Treat It as a New Fact
During review, you may let a character chat to help you recall the plot. The character may say, "I really did burn the letter that day," but if the script originally did not have the event of burning the letter, this is only a statement made up by the character in dialogue, not a new world fact. It cannot in turn prove that the old assets are wrong, nor can it be used as a basis for modification. You need to go back to the script and the completed assets themselves to verify.
Completion Check
After doing the above steps, use this checklist to confirm:
- For every step marked "needs update," you have written down the fact actually expressed by the old assets.
- Every conflict corresponds to specific assets, rather than only writing "needs update."
- For old assets with no conflict, you have clearly written "continue using."
- For old assets with conflicts, you have redone them or changed them to be consistent with the current script.
- Preview and export are regenerated and checked after the relevant assets are changed.
If item 5 has not been done yet, do not export for delivery first. Export has two types: the local asset package localAssets and the remote link package remoteUrls; the former must be run according to the instructions and checked offline, while the latter depends on the network and services and is not a permanent resource guarantee. A successful ZIP does not equal playability verification. On someone else's computer, localhost points to their own local machine and cannot be used as a universally accessible domain name.
Finally, do one small thing: open the step currently marked "needs update," find in the assets the fact it actually expresses, and write it into the first row of the table above. Once you finish writing this row, you will already be able to judge whether it can continue to be used.
