I tried out the debugger and I must say it's rather well done! I'm impressed. It doesn't handle infinite loops though, like a main game loop. But for certain function calls it's good to step through them and see what they do.

The packager is neat too. This is feeling like a real editor now. This editor with minisphere + debug is far more robust of a tool than ever before.

If you step over a MapEngine call, it won't return to the debugger because MapEngine() runs its own loop.  If you use the analogue.js included with 1.7 you can set breakpoints inside map scripts though.

I don't know if you noticed, but in the variable viewer there's also an "eval" textbox... you can enter code there while execution is paused to inject stuff.  Whatever you enter will be evaluated within the current scope so that you can modify local variables, etc.

If you step over a MapEngine call, it won't return to the debugger because MapEngine() runs its own loop.  If you use the analogue.js included with 1.7 you can set breakpoints inside map scripts though.

Yeah, that makes sense. I'll definitely try out the eval, it was very helpful to have that in the .NET debugger and so to do that in minisphere - that's just wow, that's amazing!

BTW +1 for analogue shoutout, this is not something you could have done easily in the map editor.

Note that the analogue debugging is only possible because I modified analogue.js to use EvaluateScript() to pull in the mapscripts.  This is incompatible with Sphere 1.x because EvaluateScript() doesn't return anything in that engine for some reason.

Unfortunately this change was necessary because otherwise Duktape doesn't assign a filename to the script and therefore breakpoints won't work.  Overall I don't think it's a big deal though--I would say the vanilla engine is well and truly obsolete at this point.

Here's a screenshot for another neat debug feature I added at the last minute: With the debugger attached, Print() calls are intercepted and sent to the debugger.

This may have been covered already, but there are 32 pages. minisphere doesn't accept constant (const) variables?
Also, it doesn't really look like the engine doesn't really say much about what went wrong. It just says "Parse error"

Yeah, "parse error" is all Duktape will give.  Not much I can do about that.  And yes, const isn't ES5 compliant so it's not supported.  The Duktape developer is working on adding ES6 features though, so hopefully it'll make it in soon.  In any case, it's mentioned in the readme.

1.7.2 is posted, fixing a few bugs in Sphere Studio and making debugging local-only, avoiding the Windows Firewall prompt.  Oh, and there's a new stack viewer too.

So who thought minisphere would ever be this successful?  Least of all me.  In less than a year we now have a 99% compatible replacement for the vanilla engine, a bunch of new Sphere 2.0 stuff and even a stepping debugger, something I think Sphere has needed for a long time.  And all this from an experiment that I thought would never get off the ground...

At this point, at v1.7 I feel I can call minisphere fully mature.  Which means, I think it's time to get started on that JS map engine. . Now more than ever, with a full debugger, being able to step into map engine code will be very useful, I think.

Well, it turns out right-click New was completely broken in recent builds of Sphere Studio (those invalid filename errors someone mentioned recently)... I fixed it.

we now have a 99% compatible replacement for the vanilla engine

What's the missing 1%?

Two things mainly: stricter argument type checking (this is an issue in rare cases), and a few lesser-used APIs, such as Complex().

I'm tempted to ask you to fork minisphere once that's done so that one version has only the vanilla stuff for 1.5/1.6 (i.e. disable all the experimental/minisphere-specific API), we'd commit that to vanilla Sphere, then officially recognize minisphere as the vanilla successor and all the experimental/ms-specific stuff would be considered "proposed additions to Sphere 2.0" or "draft status" (using W3C terminology), then it's an arms race between the big three Sphere engines.

In this scenario, for lack of a better analogy minisphere becomes WebKit, TurboSphere becomes Gecko, SSFML becomes IE/Edge, YASE/sphereclone might be Opera/Presto unless casiotone decides to resume work on it or it gets folded into another engine project, the various web-sphere implementations are still web-based, and all other attempts at Sphere-compatible engines still exist but we haven't heard from them in a while.

I don't know, at this point I feel like that would just be needlessly extending the vanilla engine's life for no real gain.  If I were to add the missing primitives the engine would be 100% backward compatible as-is (save some audio formats), no need to make a build with removed functionality.  We WANT to get new users to use the new stuff, and having separate stable and unstable/experimental versions might scare them off of doing so.  In fact the additional bells and whistles are the biggest reason I recommend minisphere over vanilla--a build limited to just the 1.x APIs would Have no real advantage over the original engine, IMO.  Duktape is faster, yes, but not enough to make-or-break.

It's tempting to want to wait until Sphere 2.0 has stabilized to commit to anything, but part of the reason I took the initiative with minisphere in the first place was because that process was going nowhere--note the sorry state Pegasus ended up in.

I think our best bet is to embrace the extension system I already have implemented and, instead of standardizing "Sphere 2.0" wholesale, we work on standardizing the individual components.  So you would have a standard for Audialis, one for Galileo, etc., each with a unique extension string exposed through GetExtensions() and they would all be Sphere 2.0 components.  This is how the Ecmascript specs are built, and the process seems to work very well.

It's tempting to want to wait until Sphere 2.0 has stabilized to commit to anything, but part of the reason I took the initiative with minisphere in the first place was because that process was going nowhere--note the sorry state Pegasus ended up in.

Yeah, that's why I made Sphere Studio. There was a time when Vexo (man, what happened to these people ) said every year someone comes up with the idea of a new IDE and it always fails. I was thinking if I used a proper language and environment, say C# and WinForms I can make an IDE three times faster than anyone else (imagine doing it - alone - in C or C++!) and I'd have managed, clean code to work off of. .NET was built around the concept of being a desktop application developers language, or rather for Software Engineering projects in general.