Hey I'm wondering if you might consider a <<fadeallaudio>> macro to compliment the <<stopallaudio>> macro?
I currently use <<stopallaudio>> in passageready for when I change locations in my game, so if a player changes passages while a file is still playing, it cuts off the sound so new ones can be heard without overlap. But fading instead of stopping instantly would actually be much better and more pleasant.
This is because changing passages is meant to represent a change of location, so it would sound more natural having the location sound trail off instead of just stopping.
Sounds reasonable, so consider it on my TODO list. I'll probably call it <<fadeoutallaudio>> or, closer to the truth, <<fadeoutplayingaudio>>.
That said, I ended active development of SugarCube v1 months ago. From its website:
Notice for all users
SugarCube v1 has been superseded by SugarCube v2. It will receive maintenance releases only (e.g. critical bug fixes) and is no longer actively developed. Unless you're updating your install for existing SugarCube v1 projects, you should probably look into SugarCube v2 instead.
I point this out only because I believe that you're still using v1.
I'm happy to upgrade to v2 if it won't be painful. This feature would be great incentive to do so.
I have the sidebar display hidden, so I suppose should be an easy changeover since I don't use the main css changes? Oh and the custom playlist macro you gave me would need to be updated.
I'm happy to upgrade to v2 if it won't be painful.
I wouldn't think it should be, though I cannot say with certainty—there are a lot of changes between v1.0.35, or whatever version you're on, and v2.7.2.
You should check the upgrade instructions before making the jump to see what you're getting into. The instructions do not mention it, however, there are quite a few legacy shims in place to ease the transition, so not everything needs to be updated all at once.
As a suggestion, back up your current codebase, if that's not already part of your normal routine, and try it out. I'm, obviously, willing to answer any questions required to help with the transition.
Supplemental data (title, date, and metadata) is now added to save objects before invoking the Config.saves.onSave callback, rather than after.
Added an optional metadata parameter to Save.export().
Minor updates to the State API.
Significant updates to the audio subsystem, not the least of which is separate settings for various properties—e.g. volume—on a per-track, per-playlist, and master level.
Updates to the standard macro library:
Fixed an order-of-operations issue with <<replace>> which prevented using content within its target(s) as part of the replacement.
Renamed <<click>> to <<link>>. <<click>> has been readded as an alias of <<link>>, so it will continue to function as expected.
Changed <<playlist>> so that when used with playlists created by <<createplaylist>> it requires a playlist ID in addtion to the action list. Also, added a skip action.
Added special group IDs to <<audio>> which allow it to affect multiple tracks at once—e.g. :all, :looped, :muted, :paused, and :playing. Also, added the ability to manually specify the audio format for rare cases where it cannot be automatically determined.
Great, sounds good! It looks now that the SugarCube audio API is now really flexible, but also means I have to upgrade to SugarCube 2.
Let me know how it goes. Also, if I recall correctly what your custom playlist macros do/did, I don't think you'll need them anymore, but let me know if you run into any snags with the new <<createplaylist>>+<<playlist>> combo.
I seem to have an issue — I find/replaced all click macros with link and when I launch my game it sits at the initialising screen indefinitely. Find/replacing everything from link back to click restores functionality, but obviously I would rather replace depreciated macros with the current ones.
ETA: Nevermind; I forgot to also mass replace all instances of the tag closing as well, no wonder it got confused!
Oh, cool. I started with Harlowe, but found it severely lacking for my programming brain. Had wanted to switch to SugarCube, but found it to be too different, making me hard to switch.
This release changes everything, specifically the <<click>> to <<link>>, as well as <<linkappend>>, <<linkprepend>>, and <<linkreplace>>. VERY nice.
Updated the custom complex object revival subsystem to allow for deeply nested revivals. To accommodate this, while also not breaking existing user code, the JSON.reviveWrapper() extension method now takes an optional second parameter—it is strongly recommended that users of the method should review its documentation.
Updated the Saves dialog button bar CSS so that it works a bit better at very small horizontal dimensions (e.g. 480px).
Updated the documentation earlier today. Notably, I've finally documented several existing system functions and object methods which are occasionally useful to developers—e.g. clone().
I've also tried to add, very, basic version information for every major feature that was added after v2.0.0—see <<playlist>> and <String>.toUpperFirst() for two examples.
Localization refactor, which should make it a little easier for translators:
Added the l10nStrings object, which is similar to the old strings object if its sub-objects were flattened into properties; deprecated the strings object.
TME, thank you for the improvement to the link macro. The relatively small change makes it enormously more useful in my hands.
I'm sure I speak for many when I say how much I appreciate all the hard work and, no doubt, innumerable hours you have put into creating SugarCube, and answering questions on at least two forums ranging from the sublime to the complicated. SugarCube has allowed me to create curricular materials that have been extremely useful in the training of students in a professional educational program.
I forgot to mention in its release announcement that v2.10.0 also added specific warnings about capability degradation. Meaning that, when possible, players will now be told specifically what's wrong, rather than receiving a generic warning—e.g. like the Web Storage API being missing/disabled.
Added the Story.lookupWith() static method, which returns an array of Passage objects which pass the test implemented by the given predicate function.
Updated the Macro.add() static method to throw an error upon invalid macro names.
Updated the Config.ui.stowBarInitially setting to accept integers (number of viewport pixels), in addition to booleans, and changed its default value to 800 (pixels).
Updated the experimental Config.cleanupWikifierOutput setting so that it is applied globally.
Updated the <<button>>, <<link>>, <<linkappend>>, <<linkprepend>>, <<linkreplace>>, and (deprecated) <<click>> macros to use a restricted subset of formatters for their wiki link text.
Updated the <<checkbox>>, <<radiobutton>>, <<textarea>>, and <<textbox>> macros to support temporary variables.
I'm going to be making adjustments to SugarCube's (v2) loading screen—all of the init screens, actually. The modifications actually address a few deficiencies I hadn't noticed before in addition to reworking the loading screen into something a little more generic.
The loading screen is pretty nice. the 10, 30 sec implies that we might have control over how long it loads? if it's just your examples that's alright, but I was curious.
Fixed an issue where the source component of image markup was not being properly processed when the markup was used as an argument to macros.
Fixed an issue with audio macros where fading on looped tracks whose remaining time was less than the fade duration was broken.
Fixed several minor issues with the init screens in general, rewrote all associated messages to make them less verbose, and refactored the loading screen to make it more generic.
Dropped the apologetic tone of the l10nStrings._warningIntroLacking message template to match the rewritten init screen messages.
Added the UI.stow() and UI.unstow() static methods, which stow and unstow the UI bar.
Sound like some great patches here - thanks very much.
Can I just ask, in that I do a fair bit of customising with the UI (this is the sidebar, yes?) would I need to change anything in my CSS template to accommodate the new UI.stow?
Also, in the Formats list, what is the star to the right of the format for? If I click it it get kind of highlighted with a shadowed box, but I don't see what if anything this does?
I assume your talking about the loading screen itself, if so I already explained why you cannot style that seamlessly, as you may with everything else, and how to resolve that if you must.
If you're talking about something else—e.g. some initial part of your project not being styled properly at first—then you're going to need to be more specific because I'm lost here.
I edited and now I can't add attachments (is that a bug)?
Anyway, in the next post, the first screenshot is what I see for about one second when I launch my game. Then my css takes over and it changes to the second. This is what I'm talking about when I say I get a delay where I can see the default design of SG2.
Comments
I currently use <<stopallaudio>> in passageready for when I change locations in my game, so if a player changes passages while a file is still playing, it cuts off the sound so new ones can be heard without overlap. But fading instead of stopping instantly would actually be much better and more pleasant.
This is because changing passages is meant to represent a change of location, so it would sound more natural having the location sound trail off instead of just stopping.
It'd only need to be a couple of seconds fade.
That said, I ended active development of SugarCube v1 months ago. From its website: I point this out only because I believe that you're still using v1.
I have the sidebar display hidden, so I suppose should be an easy changeover since I don't use the main css changes? Oh and the custom playlist macro you gave me would need to be updated.
You should check the upgrade instructions before making the jump to see what you're getting into. The instructions do not mention it, however, there are quite a few legacy shims in place to ease the transition, so not everything needs to be updated all at once.
As a suggestion, back up your current codebase, if that's not already part of your normal routine, and try it out. I'm, obviously, willing to answer any questions required to help with the transition.
That would be easy enough to do.
Downloads & documentation for all Twine versions: http://www.motoslave.net/sugarcube/2/
Changelog highlights:
And an update to the following: I ended up not adding either of these in favor of making <<audio>> able to do this. The new group IDs allow you do do the following:
Let me know how it goes. Also, if I recall correctly what your custom playlist macros do/did, I don't think you'll need them anymore, but let me know if you run into any snags with the new <<createplaylist>>+<<playlist>> combo.
ETA: Nevermind; I forgot to also mass replace all instances of the tag closing as well, no wonder it got confused!
This release changes everything, specifically the <<click>> to <<link>>, as well as <<linkappend>>, <<linkprepend>>, and <<linkreplace>>. VERY nice.
Downloads & documentation for all Twine versions: http://www.motoslave.net/sugarcube/2/
Changelog highlights:
I've also tried to add, very, basic version information for every major feature that was added after v2.0.0—see <<playlist>> and <String>.toUpperFirst() for two examples.
Downloads & documentation for all Twine versions: http://www.motoslave.net/sugarcube/2/
Changelog highlights:
I'm sure I speak for many when I say how much I appreciate all the hard work and, no doubt, innumerable hours you have put into creating SugarCube, and answering questions on at least two forums ranging from the sublime to the complicated. SugarCube has allowed me to create curricular materials that have been extremely useful in the training of students in a professional educational program.
I forgot to mention in its release announcement that v2.10.0 also added specific warnings about capability degradation. Meaning that, when possible, players will now be told specifically what's wrong, rather than receiving a generic warning—e.g. like the Web Storage API being missing/disabled.
Downloads & documentation for all Twine versions: http://www.motoslave.net/sugarcube/2/
Changelog highlights:
Please check out the new loading screen demo and comment if you like.
That said, you may already delay the dismissal of the loading screen in two ways:
Ahhh ok cool.
Downloads & documentation for all Twine versions: http://www.motoslave.net/sugarcube/2/
Changelog highlights:
Can I just ask, in that I do a fair bit of customising with the UI (this is the sidebar, yes?) would I need to change anything in my CSS template to accommodate the new UI.stow?
Also, in the Formats list, what is the star to the right of the format for? If I click it it get kind of highlighted with a shadowed box, but I don't see what if anything this does?
I did a test run with the 2.12 and noticed the throbber, but I still get the default design loading in before my CSS.
I appreciate this wasn't what your patch was supposed to fix, but I was just curious to see if it had made any difference in that respect.
If you're talking about something else—e.g. some initial part of your project not being styled properly at first—then you're going to need to be more specific because I'm lost here.
At least I think this is what I'm talking about.
I'll try and get a screenshot, but I'll have to be quick with my Print Screen key.
Anyway, in the next post, the first screenshot is what I see for about one second when I launch my game. Then my css takes over and it changes to the second. This is what I'm talking about when I say I get a delay where I can see the default design of SG2.