Greetings.

It's been years since the last commit on the GitHub repository for Squiffy.
I was wondering if there was still a maintainer? I can understand not actively developing it, but was wondering if pull requests had any chance of being reveiwed and merged.

There seems to be a few improvements that could be made by volunteers that would either be low-effort or seem to be brought up fairly often on the forums, but if there's nobody that can accept pull requests there isn't much point.

mrangel has made some really neat additions to the squiffy source, including an easy and versatile attribute randomizer, automatic text input/textarea/contenteditable processing, and nestable attributes. You can search for these in the forum and paste his code into the source code.

When Alex quit, Squiffy was taken over by Manowar, however he is now quitting too, and I am in the process of taking over (and have been for over a year). Ultimately, I would like to get mrangel's updates incorporated (I do not know Squiffy at all myself), but as yet I do not have the permissions or knowhow to do that.

I never managed to get my head around git properly :S

Git can be very annoying, I agree 😁

@The Pixie, I hope that you do manage to get the permissions for the repo (and for updating the npm module); even if it is just so people can send you pull requests to review.

I've looked at some of mrangel's stuff, and having some things like having better support for random numbers, or having it so you can add a sidebar without having to include a heap of Javascript in your first section would be great (I think something like how @title or @start works to specify what section is your sidebar, as well as which side it's on, etc. would be great), and surely it shouldn't be too hard to have some better array support or to add in extra links to the header/title bar thing.
I'm sure there's other things I was thinking of before that I've forgotten now, but certainly some of them I'd be willing to push up a pull request for.

I'm not sure the sidebar is common enough to be a standard thing. But I was wondering about having some special-named sections like _initialise, _onload, _onset_[attribute name], _beforepage and _afterpage which could be added to add hooks, making it a lot easier to get access to the system internals for tweaking things. Then the sidebar would be relatively easy to implement, but so would other things that people might like to use. I'd also suggest a revamp of the text processor, similar to the equivalent system I proposed in Quest, making it easier to add new functions. (Perhaps squiffy.ui.textprocessorfunctions could be an object that the user can add onto in _initialise if they want to add their own functions).

"Easy" custom squiffy function support would be nice, especially when using @import to include a library. (though that can be done with say importing a javascript file, a lot of Squiffy seems annoying to simply add to during run-time)

Concerning things like sidebars, or adding stuff to the header where the Restart link is, I think partly why you don't see those much is that it isn't built-in. (also Squiffy isn't used that much compared to other alternatives)
It should of course be optional; and looking at the compiler and index.template.html it wouldn't be hard to have it so it embeds sidebar stuff into the HTML (for example) only if there is a @sidebar definition.

If we do get things where updates can be made again, I guess discussion on what should be added or updates to Squiffy or it's editor could properly happen.
I'd like to see some things like @color or @font or other things to make styling a little easier for people who don't want to touch Javascript.
Though other things... like as much as I'd like array, etc. support doing it with Javascript should be easy enough for the people who would actually use such things.

Though a built-in Javascript function to make a section or passage link seems disturbingly absent from the Squiffy engine.

"Easy" custom squiffy function support would be nice, especially when using @import to include a library. (though that can be done with say importing a javascript file, a lot of Squiffy seems annoying to simply add to during run-time)

That does seem useful. I assume it would be done when compiling, so the libraries are merged into a single story.js.

Allowing the import of javascript (pseudo-JSON) files would be interesting; if you merge them in with $.extend(true, jquery, included_object), it would be relatively simple for a library to override most of the core functions, making it a lot easier for people to use more advanced code without needing to copy out all the workarounds and wrappers.

Squiffy command line (the one I actually used...) already has @import support.
Importing more squiffy files gets embedded into story.js, but other Javascript files don't, just getting referred to as another <script> block in index.html.
This of course makes them less useful for extending Squiffy itself, as you'll need to pass in the squiffy object somehow (not impossible, but not very good if you are wanting to extend Squiffy with a javascript library)
Probably better would be to include them in story.js, maybe done in similar way to requirejs modules. It would need some thought to figure out the best way, I think.

You might be able to get around that by importing a squiffy file instead, like all the javascript in an [[include]]: section and using {include} at the start of your game to run the code.

I'd also love the ability to have "common" libraries in the web editor that you can @import, though I haven't actually looked at the IDE code so I don't know how feasible that would be.

And, speaking of @import... being able to import *.css files would be nice. It could be done in exactly the same way as the compiler imports *.js currently. Just a few extra lines of code.

I don't want to change the compiler or templates myself at the moment though, since I feel like it's not worth it if I can't put up a pull request for the changes.

other Javascript files don't, just getting referred to as another <script> block in index.html.
This of course makes them less useful for extending Squiffy itself, as you'll need to pass in the squiffy object somehow (not impossible, but not very good if you are wanting to extend Squiffy with a javascript library)

That seems inelegant. Ideally, you'd want to test if they return a plain object; or if they define variables squiffy, story, ui etc. As almost all of Squiffy's code except the startup stuff is inside that object, merging replacement functions into it seems like it would be intuitive to work with.

I think importing *.js files should get embedded at the end of story.js, so they are in the same context as you would expect them to be would be good enough. Then you would have access to all the squiffy stuff you can get in normal squiffy code.
Though perhaps something to be able to put them in that inner function that defines the "private" variables/functions if required might be good.

Maybe there's more things to consider too, but I can't really think of them at the moment.

I think importing *.js files should get embedded at the end of story.js, so they are in the same context as you would expect them to be would be good enough.

Really, you want the user's own code to override library code. So the loading order should be

1. Squiffy core
2. Imported libraries
3. User code

with each having the power to overwrite functions provided by the layer before.

I suspect that the most sensible way to do this (although a bit of a structural bodge) would be to change:

squiffy = {
  // huge mass of generated code, including the stuff from squiffy.template.js and stuff generated from the squiffy file
}

into

squiffy = $.extend(true, {
  // all the default stuff from squiffy.template.js
},
{
  // contents of included_library.js
},
{
  // contents of included_library_2.js
},
{
  story: {
    sections: [
      // dynamically-generated stuff created from game.squiffy
    ]
  }
});

Either as a restructure like that; or splitting it up into separate files (so the code that lives outside of the squiffy object would loop over a bunch of other JS files including them, starting with a static squiffycore.js and ending with the generated story.js)

I think that having it put inside an object definition would be a bit too annoying; as it would behave differently than normal Javascript.
if it was put in the story.js file in a similar way as the generated squiffy code is placed in, you could still have in included javascript just stuff like squiffy.ui.sidebar = function() { /*stuff here*/ };or whatever to do as much changing of squiffy as you currently can.

Though neither your suggestion or mine would give access to the private functions.

Of course, we can override public functions to do something then fallback to a backup of the original, but I think some things should probably be altered to allow for being a bit more "mod friendly"; such as being able to add new text commands easily - I'm sure something like a private array of condition and action function pairs with a method to append a new command to it would be easy enough to support in the squiffy engine.