Skip to main content ↑ ↓
Topic: neoSphere 5.10.1 (Read 8505861 times) previous topic - next topic
0 Members and 14 Guests are viewing this topic.

Re: minisphere 4.4.2

Reply #1485 –
4.4.2 fixes a Cell bug which caused it to SyntaxError on some Sphere 1.x code.  Basically transpile.v1() was running in permanent strict mode due to a missing option when invoking Babel.

edit: Nice, the minisphere thread made it to 100 pages!

Re: minisphere 4.4.2

Reply #1486 –
Quick question. I just downloaded v4.4.2(previously had 4.2) After tinkering with my cellscript, I got everything to build correctly, however, now I get a reference error thrown in the main script after declaring variables for character objects, like it's not reading my other scripts.
Is RequireScript() deprecated now? That is what I was using at the top of my main.js. Thx

Re: minisphere 4.4.2

Reply #1487 –
RequireScript() is deprecated along with the rest of the Sphere v1 API.  However it should still work as designed.  In your Cellscript, are you using transpile.v1()?  If you just use transpile() then it will compile all your scripts as modules which might explain your issue.

edit: Now that I think of it some more, it could just be that your describe() doesn't include a version field.  Version defaults to 2; in a v2 game, the main script is loaded as a module.  In that case any globally declared variables are confined to the script that declared them.  You have to explicitly make them global then: global.whatever = "foo";  So your solution is to either do that, or add "version: 1" to describe().

Re: minisphere 4.4.2

Reply #1488 –
Okay, makes sense. I've been been using v2.
I've got my globals marked with global., so guess I'll have to study up on using modules.
Basically, I've got my scripts organized by the objects they are i.e. character.js has a character object and functions that go along with it(stat updates,etc), items.js has item objects, creates items, uses, etc., menu.js the menu and all of its functions, blah, blah

Since I know they're loaded as modules I can start trying to figure out how to properly structure everything.
I want to continue with the v2 to take advantage of all the capabilities, even though it's over my head right now.
Thanks for the quick reply.

Re: minisphere 4.4.2

Reply #1489 –
Good to see someone diving in to take advantage of all Sphere v2 has to offer :)

If you have a transpile() step in your Cellscript then you're all set to use the latest JS syntax, so you should read up on classes:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes

Re: minisphere 4.4.2

Reply #1490 –
Just added support for ES6 syntax to Cell today.  I didn't originally consider it to be a big issue for ES6 not to be supported in Cellscripts, but it might be confusing when, say, destructuring assignment is supported in game scripts but not in the build script.  After all, I deliberately used JS for Cell so that it would be familiar for someone already writing Sphere code.

Re: minisphere 4.4.2

Reply #1491 –
Found out something interesting: While Babel does compile ES6 modules to CommonJS, and therefore you can import them using require(), the exports are all named.  Which means if you have a module with:

Code: (javascript) [Select]

// pig.js
export default
function getEaten() {
    console.log("You got eaten by the pig.  Good job.");
}


To load that module using require, you'd need to:
Code: (javascript) [Select]

const getEaten = require('./pig').default;


Apparently the same will be true in Node once they implement ES6 modules:
https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md
 

Re: minisphere 4.4.3

Reply #1492 –
So I was thinking about my plans for minisphere 5.0 before, and I decided I want to do a rebranding for the next version - to "miniSphere" (with a capital S).  camelCase evokes JavaScript, plus it makes the name seem more... I don't know, substantial?  "Tiny size" is no longer one of the engine's main attractions (it's probably a bit bigger than Sphere 1.x, even)--in fact I actually stopped compiling it with size optimizations a while ago--so trying to convey that with the name doesn't make sense anymore.

miniSphere also seems like a better indication of the engine being a successor to the original Sphere.  I feel like having the name be all lowercase might have made it seem like a second-class citizen next to the original engine (which is thoroughly deprecated now, what with all the strides made since minisphere 4.x).  In other words people think it's an "alternative engine" rather than "the new Sphere on the block".  Clearly we would prefer them to think the latter rather than the former... ;)

Re: miniSphere 4.4.3

Reply #1494 –
Also, I just got an idea for QSI integration. Can you replace the CommonJS term module with something that would allow you to have the engine output and take input from the terminal? That way a developer could handle that without having to leave the IDE.

Re: miniSphere 4.4.3

Reply #1495 –
Quote from: Eggbert – on

Also, I just got an idea for QSI integration. Can you replace the CommonJS term module with something that would allow you to have the engine output and take input from the terminal? That way a developer could handle that without having to leave the IDE.


Not sure what you're getting at here.  You can print stuff to the (real) terminal using console.log() or one of its variants; there's no way to read from stdin though, that seems like something that's out of Sphere's jurisdiction?

edit: As for neoSphere, I considered it, but I don't think the name flows as well and besides I didn't really want to make a complete name change, so I settled for just tweaking the branding a bit.

Re: miniSphere 4.4.3

Reply #1496 –
Quote from: Fat Cerberus – on

Not sure what you're getting at here.  You can print stuff to the (real) terminal using console.log() or one of its variants; there's no way to read from stdin though, that seems like something that's out of Sphere's jurisdiction?


Why can't it use stdin? And my idea was that in the same way that you can do I/O from the term module, you could do the same, but with the system console or with QSI's console. I was planning on having QSI's console get console output from miniSphere anyway.

Re: miniSphere 4.4.3

Reply #1497 –
Quote from: Eggbert – on

Why can't it use stdin?


No reason really (it's no less portable than, say, printf), but it just seems a bit too technical in nature to be part of the official high-level API (console.log() is only present because it's sometimes useful in the absence of a proper debugger).

The "term" module serves a different purpose anyway: It's there to make it easier for games to include an in-game cheat console, like a lot of FPS engines have.  It's not directly for the aid of the developer (it sometimes does help in that regard, admittedly).  I agree it would be useful if there were some SSJ integration with the term module though... just not sure what the best way to implement it is yet.

Re: miniSphere 4.4.3

Reply #1498 –
@Eggbert: You should update the AUR package, I've fixed several showstopper bugs in Cell since 4.4.0, including a nasty crash when files() doesn't find anything.  The current version also has support for ES6 syntax in Cellscripts, which wasn't in the initial release.

Re: miniSphere 4.4.4

Reply #1499 –
Posted miniSphere 4.4.4 to finalize the recent rebranding.  I also made a few minor tweaks, see the release notes on GitHub for the full changelog.