Understood.
I do pretty similar things in my mod to avoid overlap with certain dreams and dreamtalk.
As such, I understand your contribution rather as a "convenience blueprint" one can adopt for the own mod instead of re-inventing the wheel, not really as a *mod*. (Copy and paste the code and adjust to your triggers.)
I got it! Came to me in the morning of course. The problem is priority. Every mod can't wait for every other mod's rest scenes to happen or two scenes will both wait for the other and never happen. One mod has to have priority.
One question: Why not make this one mod that adds the script blocks to the listed mods once in an install and give modders the possibility to just...
I'm trying to avoid doing anything that involves me making a mod that patches existing mods. Both because I'm generally against messing with other people's mods, and because that would require this to be a mod to be installed last (which then has to be reinstalled if you install another mod). I don't want this to be a mod that people have to install. I'd rather just give code that people can put inside their own mods if they wish and modify as they see fit (much like a modding tutorial, except I already wrote it all for them). It's a voluntary action by modders rather than me going in and messing. So instead of everyone who plays your mod having to install this other mod to make your rest scenes yield, you would just have the coding inside your mod and it would function as an entirely self-contained system that wouldn't require anything from anyone else.
Anyway, back to my solution for the RestCheckForModScenes coding.
As it is now restcheck is code that anyone can pop into their mod to prevent their rest scenes (that they include the trigger in) from triggering with any of the normal BG2:EE dreams or rest scenes. That's a good start.
However this can be added to provided you don't have two mods yielding to each other. The coding and idea I had before works, but it can't be free to download by anyone and use or you'll have that issue. What we'd need is a priority list (or really a reverse priority list). Here's how it would work.
My mods have the full restcheckformodscenes coding, yielding to every other mod (I have a lot of rest scenes but no hurry in them triggering so I'm happy to yield). That coding (unlike the ingame scenes) has to have my prefix.
The next mod that wants restcheck coding can ask and I'll give them a folder of files and coding for their tp2 files (with their prefix) that they can use to have their rest scenes yield to the rest scenes of every other mod except my mods.
The 3rd mod that wants the coding can ask and I'll give them the same thing but for every other mod except those of the first two.
So as each modder adds themselves to the list I will send them the coding they need with their prefix already attached, but I don't include coding for yielding to the mods on the list above theirs. So the farther down the list you go the fewer mods you yield to. The highest modder on the list (me) yields to everything. That way there's an order and you never have two mods trying to yield to each other forever.
Of course if I have a particular scene which I don't want to yield that's easy too, I just don't add the restcheckformodscenes trigger as a requirement for that rest.
And that way no one's coding will interfere with anyone else's mod. My coding is a self-contained system which makes my scenes yield. Your coding is self-contained system which makes your scenes yield, and nothing you do will affect me and vice-versa (since we all have different prefixes).
I think that fixes everything. As I add more mods to restcheck I can just pm each modder with their updated version of restcheckformodscenes, but even if they don't update their mod it won't break anything. Everything would still function just the same (they just wouldn't yield to the new mods I added to restcheckformodscenes).
Thoughts?
