Ink Scripted Importer #205
Conversation
|
Oh wow thanks for looking into this! I'll take a look this week if I find time. At a glance it looks lovely (so much less code!!) |
|
Totally! I see your message in #ink-unity-integration-dev. I'll keep watch for questions/comments there too. Thanks! |
…ince ink files aren't constucted at runtime anymore
|
@tomkail Okay I'm moving this out of draft as I've cleaned up the known things I needed to do, but I suspect there may be things I've missed since this was such a huge change. Feel free to tag me on any changes you want after doing a review. I'll loop back when I have the time 🤘 |
|
Amazing! Annoyingly nobody has checked this out. How about we stick it on a
beta branch and publish it there? Maybe that’ll encourage people.
…On Mon, Oct 7, 2024 at 00:49 Alex Larioza ***@***.***> wrote:
@tomkail <https://github.com/tomkail> Okay I'm moving this out of draft
as I've cleaned up the known things I needed to do, but I suspect there may
be things I've missed since this was such a huge change. Feel free to tag
me on any changes you want after doing a review. I'll loop back when I have
the time 🤘
—
Reply to this email directly, view it on GitHub
<#205 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJR3UED36NFMMKTA7MLXJDZ2HD67AVCNFSM6AAAAABNPMJ5EWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJVGY2TKOJTGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Sounds good to me! I'd rather give more people more time to test it out before its merged into main 😅 I don't appear to have the option to change the base branch to a new (non-existing) branch tho. If you make a beta branch I can update the PR! |
|
I forgot to update the docs, so I snuck another commit in 👍 |
| DefaultAsset asset = AssetDatabase.LoadAssetAtPath<DefaultAsset>(path); | ||
| DrawInkFile(InkLibrary.GetInkFileWithFile(asset), rect); | ||
| InkFile asset = AssetDatabase.LoadAssetAtPath<InkFile>(path); | ||
| DrawInkFile(asset, rect); |
There was a problem hiding this comment.
InkFile is now a Scriptable Object.
No OnDrawProjectWindowItem would be needed if we assign a custom icon to InkFile.cs from the inspector
Hey, thank you for the review! I just wanted to drop a note here that I probably won't have time to review and make changes until around Feb 2025.
While I'm in favor of cleaning up the code, I'm not a maintainer and this would probably be a better conversation to have with @tomkail. But I'll certainly circle back for a re-review once I've had a chance to process your feedback. Cheers! |
|
Hey! I’m totally in favour of cleaning up the codebase and modernisation.
I’m happy to help too - catch is that I don’t have a huge amount of time
either, and that any big breaking changes should be tested on large scale
projects before merging to the main branch (which is really the only reason
this hasn’t been merged in, it’s fantastic stuff)
…On Mon, Nov 25, 2024 at 15:13 Alex Larioza ***@***.***> wrote:
@ErnSur <https://github.com/ErnSur>
I left some general comments, moving to scripted importers is a natural
step forward for the library but it looks like it will require breaking
changes.
Hey, thank you for the review! I just wanted to drop a note here that I
probably won't have time to review and make changes until around Feb 2025.
This could be a chance for some cleanups and other breaking changes around
the codebase. Let me know if you want more feedback, I'm interested in
closer collaboration.
While I'm in favor of cleaning up the code, I'm not a maintainer and this
would probably be a better conversation to have with @tomkail
<https://github.com/tomkail>. But I'll certainly circle back for a
re-review once I've had a chance to process your feedback.
Cheers!
—
Reply to this email directly, view it on GitHub
<#205 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJR3UHJEN62TCUSCI4WDND2CM47ZAVCNFSM6AAAAABNPMJ5EWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJYGI4TANZTHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@tomkail I've been advocating for using Ink in our projects at work, so when the next one spins up, I'll use my fork with these changes to get them tested. |
…lder to address build time errors
|
@tomkail @ErnSur I think I've stumbled on to one of reasons why the import process prior to this PR had been so complex - the Ink language's INCLUDE feature. The Ink language supports including other Ink files, which allows them to be broken up into smaller chunks. I had overlooked this initially, so to support this I added a bit of code in 0b5980d (which ErnSur had also reccomended in this comment) so that master ink files were aware of their includes. This solved the problem of Ink files used as includes not triggering reimports of their master files. However the problem I now have is that some Ink files used as includes cannot be compiled on their own outside of the context of the master file that includes them. For example, when a master file defines global variables, any include files that use the global variables fail to independently compile. This is problem for the changes introduced in this PR because the custom importer will flag such files as failed to compile, when they really should just be ignored. And this is where I'm stuck. I'm not quite sure if Unity has a way to express this kind of dependency with the ScriptedImporter API. While its possible to know if a master file has includes (we can parse it to look for I think I'd like to avoid a system similar to the old InkLibrary but I feel like we may not be able to get around generating some sort of intermediary file to allow for a two-pass import? |
|
Ok here's are two proposals, both centered around not trying to auto identify if files are used as includes:
|
Some API context:
So my idea for a solution to this issue would be to import ink variables as additional scriptable object (sub-asset). Then
I don't know how feasible is the second point, but I'd try this approach. I think it should be possible to load another
As I mentioned before, you don't really have to introduce any custom editors to add serializable state to the importer. Just add a serializable filed to importer the same way you would add it to a scriptable object and it'll work. |
|
Thanks for your input!
Oops! I hadn't realized I could just defined them in the importer, thanks for calling this out 👍
Ohh interesting. I'm not sure how the separate ink variables will solve the core problem? As your second bullet is where the issue is, specifically determining a file is an include before the file that actually includes it is imported. |
|
Seems I didn't explain the idea that well...
importer wouldn't have to successfully import ink file if its missing variable declarations. Let's say we have a project with following files:
Let's say we import the project and assets are imported in unfavorable order for us where File B is being being imported before file A:
Importer design issueEven if the above solution fixes the issue I would actually change the way importer works. We're trying to import File B but its missing variable X? No problem, it should report importer warning but still succeed at file import. The result will have "{variable name}" in places where the variable should be. As a source of inspiration I recommend looking at Unity UXML and USS files, how they're imported and how they deal with references between each other. |
|
Ahh thanks for the explanation! I'm still not sure what the additional InkVariable objects get us, but I think the second half of your last post hits on what I've been trying to describe:
If I'm understanding correctly, I think we're on the same page here. Specifically, if an Ink file fails to compile (and by compile I mean compile via the Ink compiler) it should still be successfully imported into Unity. However, what I'm still unsure about is the developer experience for this. Going with your example, if File B is imported first and logs a warning regarding the compilation failure to the Unity console, how should we follow up once File A is imported? Additionally, importing File A still doesn't fix the compilation of File B because File B is not intended to be compiled as a main file. I'm starting to feel more strongly for proposal #2 from my earlier comment as I think this is likely the same issue the original developers faced and why the master file toggle was added. @tomkail Do you have any historical context you could share? |
…s that aren't intended to be compiled standalone
|
Hey all! What is the status of this PR? Reading through the thread, it seems like this was slowed down by the |
|
I’ve not been working on any big ink projects lately and I’m worried about
merging this without a lot of testing. Please do give it a spin and see how
it goes for you!
…On Wed, Aug 27, 2025 at 17:44 ARPP3 ***@***.***> wrote:
*ARPP3* left a comment (inkle/ink-unity-integration#205)
<#205 (comment)>
Hey all! What is the status of this PR?
Reading through the thread, it seems like this was slowed down by the
INCLUDE statements. Testing it out locally, it seems super promising. I
also was running into frustrations with the sidekick files and seeing the
single asset feels really like a great step for this package. I actually
only came across this fork after trying to do the same myself 😅 Would be a
shame for this to become outdated,
@SHiLLySiT <https://github.com/SHiLLySiT> @tomkail
<https://github.com/tomkail> @ErnSur <https://github.com/ErnSur>
—
Reply to this email directly, view it on GitHub
<#205 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJR3UGREKJGO64PCAZNUGT3PXN5TAVCNFSM6AAAAABNPMJ5EWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMRYHE3DANJRHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
We've been using my fork at work for two projects, with one of them being quite sizeable. I had been waiting to confirm until it shipped in a few months, but at this point the team has been using it for over a year so I'd say it's pretty stable. I think the main impact is people with existing projects that want to upgrade. It's going to probably require a lot of manual changes for them to migrate to this new version. |
|
Amazing!
Can we ship this but make it disabled by default? That’d be the best place
to start; we can then have a button that enables it and updates the users
project.
We have an editor window that I can force to pop up when ink updates, so we
can use that to inform people.
Can you list the changes somebody upgrading would need to know about?
…On Wed, Aug 27, 2025 at 20:11 Alex Larioza ***@***.***> wrote:
*SHiLLySiT* left a comment (inkle/ink-unity-integration#205)
<#205 (comment)>
We've been using my fork at work for two projects, with one of them being
quite sizeable. I had been waiting to confirm until it shipped in a few
months, but at this point the team has been using it for over a year so I'd
say it's pretty stable.
I think the main impact is people with existing projects that want to
upgrade. It's going to probably require a lot of manual changes to work
with this new version.
—
Reply to this email directly, view it on GitHub
<#205 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJR3UGQDLGYQ5L5NOHSDPL3PX7G7AVCNFSM6AAAAABNPMJ5EWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMRZGQ2DCNBZHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@tomkail I wouldn't recommend putting this behind a feature toggle. We'd need to restore all the now deleted code and refactor the refactoring I did to support both systems 😅 I'm also not quite sure what Unity would do with all the imported Ink scripts when the custom importer is disabled. I'd recommend a major version bump and include a migration guide. I can write the guide - would you prefer it as a Markdown file in the repo, a comment in this PR, or somewhere else? |
# Conflicts: # Packages/Ink/Editor/Core/Ink Library/InkLibrary.cs # Packages/Ink/Editor/Tools/Player Window/InkPlayerWindow.cs
|
Just catching up on this now. It looks really promising! I have some thoughts on the outstanding question about the best workflow for Unless I'm misunderstanding something, I don't think that exposing global variables as sub-assets would solve all of the problems of missing To my mind, thoroughly capturing, parsing, and resolving all these dependencies is outside the scope of the original intended change - and very welcome improvement! - here. I'd suggest that the pragmatic option is for the user to continue to explicitly identify which files are master files. As well as being a familiar concept and workflow for existing users, this would greatly reduce the scope of work required to land this update, and therefore its potential for bugs. If, in the future, there's a desire to build on this further and add some kind of automatic dependency resolution, that can be treated as a separate PR. |
|
@reallyfancy Hey thanks for jumping in here!
Yup! This is also where I landed, so we're in agreement there.
Ahh that is a great argument for keeping the old terminology. Its been awhile now so I don't quite remember my reasoning for the name change 🤔 I just updated the PR to rename the new toggle! |
|
@tomkail I also added some migration notes to the changelog to communicate changes to users. |
|
Thanks for getting back to me! With regard to the naming, there's generally a move away from calling things "master" in favour of maintaining/root/whatever makes contextual sense, and I'm definitely not opposed to that - but the exact name that feels like a decision for maintainers! The important consideration from my perspective is limiting change for users - in this case, letting them keep thinking in terms of opting in to standalone compilation, rather than opting out. Anyway, this is looking good! I'm happy to take a look at this, likely in a week or so, and experimentally port a medium-sized Ink project to it to see what happens. @tomkail I see that you expressed concerns about this change not being behind a feature flag, but @SHiLLySiT doesn't think that's the right fit for this code. It would be good to figure out what would give you the confidence to merge this. It's a big change but there are a lot of ways to derisk things like this - additional safety, additional testing, major version bump, migration tooling, and so on. I'm happy to pitch in to help this land, if we can come up with a plan! |
5 participants
This aims to implement #53, which IMO, has some huge benefits:
InkFilereferences instead of genericTextAssetreferences in game code.This PR is currently in a proof of concept stage: it hasn't been fully tested, but loading and running ink files at runtime and in the Editor is working.
The original implementation was written before Unity supported custom scripted importers, so many of the systems are now obsolete. Since this is a pretty big change, I wanted to open a PR to get an initial review to get some initial thoughts from the maintainers.
Interested in all feedback, but the question at the top of my mind: Do we need to expose includes and master files in the editor? While Ink at a language level still has these concepts, I'm not sure how important it is to expose these in Unity if its no longer important for compilation?