To illustrate:

Code: (javascript) [Select]

var gen = RNG.fromSeed(812);
console.log(Math.floor(gen.next() * 10));
console.log(Math.floor(gen.next() * 10));
var state = gen.state;
console.log("state saved:", state);
console.log(Math.floor(gen.next() * 10));
console.log(Math.floor(gen.next() * 10));
console.log(Math.floor(gen.next() * 10));
gen.state = state;
console.log("state loaded:", gen.state);
console.log(Math.floor(gen.next() * 10));
console.log(Math.floor(gen.next() * 10));
console.log(Math.floor(gen.next() * 10));
system.exit();

Output:

Code: [Select]

C:\src\spectacles-i>ssj -r dist
SSJ 4.0a1 Sphere JavaScript debugger (x64)
a powerful JavaScript debugger for minisphere
(c) 2015-2016 Fat Cerberus

starting C:/src/spectacles-i/dist/... OK.
connecting to 127.0.0.1:1208... OK.
verifying... OK.
querying target... OK.
    game: Spectacles: Bruce's Story
    author: Author Unknown

log: 0
log: 7
log: state saved: 19623bbbaffade049a164924bc152c80
log: 5
log: 1
log: 2
log: state loaded: 19623bbbaffade049a164924bc152c80
log: 5
log: 1
log: 2
debugger disconnected normally.
SSJ session terminated.

Here's the plan: minisphere 4.0 will be an experimental release, to test the waters for the Sphere v2 API.  There are a few areas that might be rough around the edges or in need of tweaks; I'm not ready to commit to the exact setup just yet.  minisphere 4.x will thus have the Sphere API level set to 0, specifically reserved to mean "unstable".  If that's successful and everyone is happy with what's available, minisphere 5.0 will have the API level bumped up to 1, finalizing the API.  From there on, features will only be added (and the API level bumped) in a backwards compatible manner.  Alternatively, features can be added first as extensions, and only later incorporated into the core API if they prove useful.

Doing it this way should also accelerate the 4.0 release, since I don't have to make sure the API is perfect before the release.  If breaking changes need to be made during the 4.x cycle, that can be done freely.

Beta 1 for minisphere 4.0 is available.  Install it and try out the new API.

minisphere 4.0 is out.  The 4.x.x series will be a rolling release to get the toolchain (SSJ, Cell, possible upcoming CLI tools) up the speed before finalizing the Sphere v2 API.  I could have delayed the 4.0 release further, but I figured it was better to get Sphere v2 out the door now so that the new API is available to everyone as soon as possible.

This has been a long time coming, now go crazy!

First update in the minisphere 4.0 rolling release cycle: minisphere 4.0.1 updates system.extensions to allow you to test for the presence of an extension using a simple if statement:

Code: (javascript) [Select]

// while building save game data:
if (system.extensions.sphere_stateful_rng) {
    saveData.rngState = monsterDropRNG.state;
}

Extension strings returned in this release are:

• sphere_gl_shader_support


• sphere_stateful_rng


• sphere_v1_compatible


• minisphere_ssj_api

downloaded. Will test it in the afternoons...

Ooh, fancy new API. When do you plan on removing Sphere 1.x API compatibility, or is that not going to happen?

Not for the foreseeable future.  I know there are existing large Sphere v1 codebases (Radnen's Blockman, e.g.) and I want to make migration as simple as possible.  For this reason it's perfectly acceptable to mix v1 and v2 function calls.

That said, the v1 API should be considered fully deprecated by this release and all new code should be written to the Sphere v2 API.  The legacy code is not likely to receive much maintenance going forward, except for bug fixes.

I figured that was the case, I just wanted to make sure that it wouldn't be completely removed.
Also, I haven't checked with the newest release, but I noticed minisphere as of 3.3 at least doesn't seem to take into consideration other possible game directories when GetGameList() is used. For example, I have minisphere installed in C:\Program Files\minisphere, but all of my games are in my dropbox folder with Sphere 1.5 and 1.6. Since I have Sphere Studio set to look in that directory, is it possible for minisphere to do the same somehow?

Technically all that's required for v1 compatibility for GetGameList() is to look in <engine_dir>/games, which minisphere does.  It also looks in <documents>/Sphere Studio/Projects, since that's where Studio puts new games by default.  Custom directories is a bit harder to support - the engine is self-contained and has no knowledge of the outside world, so to speak.

I'll see what I can do though, if anything.

So should I just use symlinks or something? I wish it was as easy to do in Windows as it is in Linux.

That should work, yeah.  The command you're looking for is

Code: [Select]

mklink /d "C:\Program Files\minisphere\games" <target_dir>

You need to do that in an elevated command prompt though, otherwise you won't be able to create a symlink inside Program Files.

I've used it once or twice before. And it requires elevated privileges regardless of location.

minisphere 4.1.0 is available now and introduces the new "assert" module.  This module has the same interface as the Node.js module by the same name:
https://nodejs.org/api/assert.html

Unlike ssj.assert() which only has an effect with an attached debugger and doesn't change program flow (beyond optionally triggering a breakpoint), the assert module methods will throw an AssertionError if a check fails.  This makes them suitable for argument validation and the like:

Code: (javascript) [Select]

const assert = require('assert');

function feedFace(what, howMuch)
{
    assert.equal(typeof what, 'string');
    assert.equal(typeof howMuch, 'number');

    /* ...carry on */
}

Did you just update twice tonight?