Re DUMB - are you using kode54's updated fork of DUMB as the base?

Having recently purchased an Xbox One controller for my new gaming PC (custom built!), I found a longstanding bug in the map engine - it doesn't recognize joystick input for movement.  It responds to pressing the Talk button, but not the analog stick.  I'll fix it in the next update.

Re DUMB - are you using kode54's updated fork of DUMB as the base?

I'm not, just what's in the Arch Linux repo.

Having recently purchased an Xbox One controller for my new gaming PC (custom built!), I found a longstanding bug in the map engine - it doesn't recognize joystick input for movement.  It responds to pressing the Talk button, but not the analog stick.  I'll fix it in the next update.

Is the left analog stick going to be treated the same way as the dpad, or is it going to be its own thing (so you can walk fast or slow)?

The d-pad is treated as a POV-hat by the DirectInput drivers, so it's a separate thing from the analogs.  That said, the Sphere 1.x map engine just uses a single movement speed, analog input is converted to digital with a dead zone of ~50%.

It will be possible to support true analog input with varying speed in the new map engine that I eventually want to get around to making.

I figured that would be the case, and while I doubt the analog speed will be used much, if the outcome is worth the effort, I'm sure someone might have a use for it.

Edit: There's an issue with your xml parser, and possibly some other modules as well. When I run the following code

Code: (javascript) [Select]

const xml = require("xml");

function game() {
    ml = xml.load("sample.xml");
}

Just clicking "Test" gives me the error "ReferenceError: 'FileStream' undefined" in #/modules/xml.js:17.
If I use the debugger, I see the exception "ReferenceError: module not found `stream`" in #/modules/lib/sax.js:163

That last ReferenceError you mentioned is harmless.  sax.js is trying to load the built-in Node.js "stream" module, which of course fails.  The error is caught and sax uses a fallback.  SSJ always reports thrown errors, even if they are caught.  If you're using Sphere Studio, caught errors will have a green checkmark next to them.

The FileStream error I do have to fix, though.  Originally, with Sphere v2, you opened files like this:

Code: (javascript) [Select]

var file = new FileStream(fileName, 'r');

However, since I wrote the xml module that has changed to:

Code: (javascript) [Select]

var file = fs.open(fileName, 'r');

It seems that I never updated the xml module to reflect that, oops!

So until it's officially updated, can I just replace it myself?

Yeah, that should work.

The new joystick API coming in minisphere 4.2 will allow you to easily query connected input devices using Link, like this:

Code: (javascript) [Select]

const link = require('link');

// historically, Sphere requires a gamepad with at least 2 axes (X/Y) and
// 5 buttons (A, B, X, Y, Start) for full operation.
var devices = link(Joystick.getDevices())
	.where(function(it) { return it.numAxes >= 2; })
	.where(function(it) { return it.numButtons >= 5; })
	.toArray();

This allows minisphere to support any number of gamepads while at the same time allowing games to ignore any devices without enough inputs.  While that latter thing was technically possible in Sphere 1.x, the engine itself would only tell you about 4 devices max.

Not that I can see too many people hooking up 10 gamepads to their computer, but the API flexibility is there to allow it if they do.

minisphere 4.2 is out, bringing with it the brand-new joystick API, a new "joy" module, and basic support for TextEncoder and TextDecoder (utf-8 only for now).  There are also a few bug fixes: the XML module works again (thanks Eggbert for finding this), and a long-standing bug in the map engine which prevented the input person from being moved with the joystick is now fixed.  Refer to sphere2-api.txt and miniRT-api.txt for documentation on the new objects and functions.

No more new features are planned for minisphere 4.x.  The remainder of the 4.x cycle will instead be spent polishing up the Sphere v2 API and getting it ready to be finalized in minisphere 5.0.  At that point system.apiLevel will be set to 1 and no more incompatible changes to the API will be allowed.

I swear one of these days I'm going to actually make use of my One Game A Month account, and get all familiar with the New And Improved Sphere... Things are starting to look really sweet.

One thing I keep thinking about nowadays is cross-platform compatibility. By which I mean phones or HTML5. Do you think this could ever feasibly happen with how minisphere has changed things? (Just curious. I'd love to use it that way. "mobile" support could partially be an extra module to add in the support for eg. a controller overlay.)

I really want to do at least mobile support.  The web is a totally different beast since everything is async, but a Sphere app certainly seems feasible.  I can technically compile Android apps using Visual Studio, but I've been too lazy to learn how everything works.  I'm pretty sure my next phone is going be Android-based though (was going to be an iPhone 7, but I hate the changes in the iOS 10), so maybe that'll light a fire under me to make Mobile Sphere work.

That's good to hear. Nice work on all the progress, by the way. I swear I'll eventually get around to making something with it...

I updated the AUR package

I updated the AUR package

Good to hear, thanks.

Edit: The AUR page claims to still be using the tarball for 4.1.1?