A good portable full featured HTML Glk implementation would be great to have, and could be used for online terps and offline too.
What we really need is more new people getting involved in maintaining the existing terps.
Is there anything non-programmers can do to help?
Learn to program? 
I’ve said before that I find the approach of Dreamwidth.org inspirational. (denise.dreamwidth.org/23600.html) In an ideal world, we would actively solicit coding help from everybody, including newcomers, including newcomers who have never written a line of code.
In this world, we’re apathetic and surly to newcomers, just like most open-source communities.
Is there any public todo-list of things that interpreters need? It might be a good starting point to have such a page, maybe with the competences needed? (this requires to know how a terp works, this is more a design/UI thing, this is just scripting, etc.) I remember those kinds of lists when I was looking into the Google Summer of Code, and they were pretty motivating.
Also, maybe non-coders can help with the testing side of things? “Write a game that uses colors heavily that will be used for tests during the development of new features”? Although I don’t know if that’s a good idea for regression testing or if you should be testing individual functions instead.
Just brainstorming… and thanks to anyone who contributed to interpreters, in the past or in the present; it’s a lot of work and it benefits everyone.
Yes, I second that todo-list. The easier it can be made for people to contribute, the more likely I think it’ll be that they do.
Such a list is something non-coders certainly can help with too. “These are the problems with this term on Mac” - kind of things.
I’m not promising that I’d do anything if contributing was made easier to do, but maybe. I’m not prepared to commit to years of work or anything. (I’ve tried open source development, and burned out on it. Towards the end, it was no fun at all.)
So, in an attempt to contribute something to the conversation, I started a TODO list, over at the IFWiki so that anyone can edit it or talk about it on the discussion page. Some stuff I remember from posts here, some stuff comes from zarf’s todo list on the January Gameshelf blog post (thank you, bg, for thinking of this).
Disclaimer: I don’t know much about interpreters and how they work. I’d like to learn, for sure, but right now I’m not at a place where I can commit to helping, unfortunately 
I just did that to help and get people motivated to contribute. And some of the issues on there are, well, not very clearly described either ^^’
If you know of any problems or bugs, if you think I forgot something (your favorite interpreter, a technical comment, a general request, a remark about accessibility), please, don’t hesitate to say something! On this thread, on the IFWiki page, or send me an email, a PM - but let me/us know! Thank you 
Better support for TADS in gargoyle: https://intfiction.org/t/upgrading-gargoyle-to-use-recent-tads-sources/9141/1
Multiplatform C/C++ and jam required. Bonus if TADS and gargoyle codebases familiarity.
Hey hey, awesome stuff! Thanks a bunch for getting the ball rolling!
Awesome! So you need someone to take a look at the code, make it multi-platform and put it in Gargoyle? Any links to your repo by chance?
Thanks a bunch 
Yes, that’s the plan, roughly speaking. Not necessarily “make it”, but I’ll need mentoring at least.
Not yet because we were clearing up some license issues, but I’ll post links and questions about new Gargoyle code in the other thread.
I just went through mulehollandaise’s TODO list (ifwiki.org/index.php/User:Muleho … eters_TODO), reorganizing and adding notes from my own (long-standing) TODO lists.
I threw in dev tools (Inform compiler and library), too. And I added links to project pages and bug trackers.
Time to promote this to a top-level “IF Task List” wiki page?
Awesome, thanks so much!
I also added Vorple stuff from Juhana’s website (‘known limitations’).
Should we split that up in three pages? (dev tools, interpreters and website-related?)
Don’t think it’s that big yet. It’s nice to have an overview that someone can read through.
Ok, looking over the to-do list:
Inform 7:
What, specifically, is needed? Replacements for all the existing hyperlink extensions, to make them compatible with UGI? Is anyone in particular planning to take care of this, or can anyone jump in?
IFDB:
Is checking to make sure you’ve got the correct opening screen, and tweaking this, something a non-programmer could do, or at least help with? Is checking the screenshots something that could be set up for anyone to contribute to, piecemeal, as they have time (e.g. there’s a queue, and you just click a check box to approve the screenshot, or not?)
Web sites:
As long as we’ve got web sites on the list, what about add something along the lines of cvaneseltine’s suggestion of a tool that would allow adding games to IFWiki without duplicating the effort of adding them to IFDB?
The easy task is to port the existing hyperlink and menu extensions over to UGI.
The hard task is to design a state model for choice-based games which is as powerful and easy to use as possible. How hard this is depends on how ambitious you are. This might be as flexible (and hard to finish) as Threaded Conversation.
Ideally, all of these are things that a non-programmer could do. However, setting up a system where people can contribute to this is a chunk of programming work in itself. None of it exists yet – I just have a demo that runs off a cruddy config file.
Add away.
I’ll have a think if there are other open tasks that could be added to the list.
Zarf, quick question, how much work would it take to add the option of multiple timers to Glk? By that I mean both speccing it and the relative difficulty of changing the common Glk implementations.
Um. It’s not intrinsically hard to design, but the API would be messier than the current one. You’d need the timer call to return a value which could be used to cancel that particular timer. Implementation wouldn’t be fun.
I know you said you wanted this for “debouncing” window size changes. However, it’s going to be easier to update an interpreter to support that directly than to stuff the functionality into GEP. Having every game run a rapid timer loop behind the author’s back is just not the right way to do things.
The current timer call assumes the input code is self-contained, which doesn’t fit well with GEP. But all of Glk’s input API assumes that. I’m not very motivated to update just one piece this way.
Well most of the terps are badly maintained. We really needed debouncing for Kerkerkruip because of the number of windows it had, and so I’ve already added debouncing to GEP, but its code would be simpler if multiple timers were available. It wouldn’t run constant timer loops, but set up a single timer after the first resize event for 100ms or so. Any resize events that came in before the timer event would check if the timer is running and be ignored.
Multiple timers would have other uses too. Animations of course, but also the stuff Erik wrote his Glulx Real Time extension for. But I think it would really be most useful for just allowing extensions which use timers to operate independently.
Do you mean that glk_request_timer_events() would return an id? I was instead thinking that you would call glk_request_timer_events(millisecs, rock). (Or an alternative function so that the arity wouldn’t be changed.) You would call glk_request_timer_events(0, rock) to turn it off. The rock value would be returned as the event val1. Subsequent calls with the same rock would update the period of that timer, rather than making new timers, and the existing calls could be interpreted as calling with a rock of 0. I don’t think this would be too messy?
Anyways, it’s not essential by any means. We’ve been making do without. But if it’s not too complex then it could be worth adding to the next Glk update, whenever that comes along.
I’m trying to picture the logic for a client-server relationship where timers are concerned.
If we assume the story file manages what timers are “on” and knows their information (expire date-time and a command are the only important data to emit to the client), then if the client knows the list of timers and expiration date-times, it can do what needs to be done.
I’m not really concerned about standard interpreters these days, but for web implementations this seems relatively easy. We just need to emit something to the browser that gets “scraped” out of normal output and tells a JS file to manage the list of emitted timers. When one expires, its command is fired.
For FyreVM this would be trivial. Have a dedicated channel for timer data. The client then manages its timers based on that channel, which could be a JSON payload with all of the pertinent information.
(I’m really just thinking out loud about an extension I’d add to my list of things to do…a fyrevm web timers I7 extension)
This quote struck me because I just started a new thread about clout (or lack thereof) in the IF community, and your term ‘foundation’ in reference to herding cats is pretty on point.
I’d like to see a bunch of the heavy hitters around here form some type of concensus about what needs to be done to bring interpreters into ‘spec’ on all platforms, for all story files, etc. and what the best candidate for doing so would be.
An up-to-date, well-maintained, universal interpreter seems to be a likely unifying goal around here, given that it will benefit everyone and not just users of certain platforms / target audiences / authoring systems.
If anyone has any solid ideas for organizing such a foundation, I’d be willing in investing some time & $$$ in helping to herd those cats.