@LordEnglish: sweet! I know the dock description was clunky but it got the job done (offloaded all dependencies to dock forms). I like it when these refactorization iterations are made though, it makes the code cleaner than it was before and easier to read.

Yeah, I did this kind of thing constantly throughout minisphere's development.  Whenever something annoyed me or wasn't adequate for my needed use case, rather than try to work around the limitations I'd just rewrite the whole component.  As a result the codebase ended up being very clean.  Very little of the original code remains.

For Sphere Studio I'm mainly trying to get Sphere.Plugins in a state where it doesn't need breaking changes every time a new system is added.  So far it's been pretty infeasible to write third-party plugins because the API keeps changing.  Anything to minimize that is a win in my book.

Regarding the weifen luo dock: Its API is terrible and I have no clue how it became as popular as it is.  Doing pretty much anything with it is an exercise in guesswork.  For example I wanted to make the debug sidebar split so that variables are on top with the callstack below, but I still haven't figured out how to do it.  Same goes for saving the layout.  It's worse than Scintilla's API, and that's saying something!

Ok, I added the map entity control. You'll see a list of entities on the map, including the layers and type. Double-click the entity and you'll see the correct entity  dialog for that entity (person or trigger). I was going to put this as a new form, but I added it as a component in the map editor. This feature will be available in either one of Lord English's latest minisphere builds or when I make an official standalone, which I may do soon after more testing, and when Lord English thinks it's okay to release with the changes he's made thus far.

I even fixed more bugs and regressions. The Spriteset editor crashed the engine without warning (I couldn't even get the debugger to tell me where the error occurred!) It was with ImageEditView.Content getting deallocated in the undo chain. So in the spriteset editor I just make to sure to copy whatever it gets back from the ImageEditor component.

Then in the map editor the layers property dialog crashed also without the ability for VS to search for the area where the crash occurred, but it was with invalid layer parallax values this time. Multiplying 1.457E10 or whatever by 10. It must have just been junk. I could only fix it by wrapping the logic area in a try..catch block and then setting the parallax value to more sensible values like 0 instead.

I even made that layer property dialog pop up when you double-click to the right of the layer visibility eye. I always turn layers on and off, and it was a tad annoying when casually clicking the eye meant that the layer property box popped up. It just a subtle UX change that makes a big difference when editing maps.

That parallax bug is weird... I have no clue why it was crashing, it's never happened to me.  Maybe a map with corrupt parallax values?

I'm definitely going to have to check out that entity control, that sounds nice.

As for a standalone release, I just want to give the plugin manager another quick review first and then you can make a release if you want.  What would it be, v1.2.0?

What would it be, v1.2.0?

Yes, we'll say 1.2.0.

Which means that Sphere Studio 2.0 is on the roadmap, but it's a ways off which requires the build and process pipeline to be finished and anything else that makes Sphere Studio closer to Visual Studio in a way. It may even include redoing some of these controls for editing spritesets since we still get people who are confused with it.

That parallax bug is weird... I have no clue why it was crashing, it's never happened to me.  Maybe a map with corrupt parallax values?

Right, it's just a sanity check I added. I doubt most maps are affected, but if you opened Blockman maps with it you might get the crash.

Okay, everything should be in good shape, no release blockers on my end.  I will keep looking out for glitches and crashes, of course.

I just posted minisphere 1.7.6 whose copy of Sphere Studio includes the new Entity view mentioned earlier in the thread.

@Radnen: I'm experimenting right now with integrating Jurassic into Sphere Studio.  Not sure if I'm up for working on the whole build pipeline yet, just want to get the basic framework set up.

@Radnen: I'm experimenting right now with integrating Jurassic into Sphere Studio.  Not sure if I'm up for working on the whole build pipeline yet, just want to get the basic framework set up.

Ok cool, I'm not sure if you've used it before, but I found Jurassic pretty straight forward and fairly flexible. There's so much it can do between JS and .NET it's crazy!

Though I have a custom build for SSFML which adds pre-compiled functions and const support.

Yeah, I found the learning curve to be fairly shallow, which was nice.  I figured everything out from Intellisense alone (this is my talent to be able to do this!) without opening Firefox once. . You can see the results of my experiments in the "jurassic" branch.  It went surprisingly well.

I'd be lying if I said I didn't miss Duktape's stack-based API, though.  It can get tedious at times to work with, but it gives you surprisingly low-level control over the JS engine, so much so that the divide between script and host almost disappears.  If you look at minisphere for instance, the engine is almost an extension of the JS environment rather than the other way around.  It's kind of neat.

So I decided that this will work best if not just the build, but the entire project system would be JS-based.  For example, here is the current project script for Sphere projects:

Code: (javascript) [Select]

RequireScript('link.js');

// ES6 polyfills
String.prototype.startsWith = function(searchString, position)
{
	position = position || 0;
	return this.indexOf(searchString, position) === position;
};

function prep(source)
{
    source.mkdir('scripts');
    source.mkdir('maps');
    source.mkdir('images');
    source.mkdir('sounds');
    source.mkdir('spritesets');
    source.mkdir('windowstyles');
}

function build(source, target)
{
	// Sphere filename filters
	var filters = [
		"*.rmp", "*.rss", "*.rts", "*.rws", "*.rfn",
		"*.js", "*.coffee", "*.glsl",
		"*.mp3", "*.ogg", "*.mid", "*.wav", "*.flac", "*.it", "*.s3m", "*.mod",
		"*.png", "*.jpg", "*.bmp", "*.pcx",
	];

	// copy relevant files into the distribution
	Print("Copying files to distribution");
	Link(filters).each(function (filter) {
		Link(source.ls(filter))
			.where(function(filename) { return !filename.startsWith('dist/'); })
			.where(function(filename) { return filename != 'build.js'; })
			.each(function(filename)
		{
			source.cp(filename, target.path + filename);
		});
	});

	// write game.sgm
	Print("Generating game.sgm");
	var sgmFile = new FileWriter(target.path + 'game.sgm');
	sgmFile.write("name=" + source.name + "\n");
	sgmFile.write("author=" + source.author + "\n");
	sgmFile.write("description=" + source.description + "\n");
	sgmFile.write("screen_width=" + source.screenWidth + "\n");
	sgmFile.write("screen_height=" + source.screenHeight + "\n");
	sgmFile.write("script=" + source.mainScript + "\n");
	sgmFile.close();

	Print("Getting everything eaten by PigGeta");
}

function clean(target)
{
    target.rm('game.sgm');
}

This will make Sphere Studio truly engine-agnostic.

The one thing I am trying to figure out is how plugin integration will work.  Plugins should be able to register to either run as part of the build process, or else provide additional functions which can be used in a build script.  For example a plugin for minifying scripts might add a minify() method to the source object.  The trick is to do this without introducing any external dependency on Jurassic...

I started working on integrating Sphere Studio with Cell on a separate branch.  This seems like the best option now, it's stupid to do double work on two build systems, especially since both use JS.  And Cell's setup is superior, as it's more automated--what I came up with for SS originally was basically just a JS wrapper around standard file system operations.

I branched the Cell integration off of master because it will require some work to do it properly--a lot of the project code was already rewritten to use the earlier build system and will need to be updated again; I don't want to leave master in a broken state.  Honestly I think this is probably the best overall branch policy: it ensures master is always stable for production use if only complete features and bug fixes go in.  This is the setup Duktape uses, and it works very well.

@Radnen If you want to release 1.2.0 with master as it is, that's fine--the current build system works very well for both Sphere 1.5 and minisphere, and I haven't found any bugs in the past couple of weeks, so I'm comfortable with it in its current state.

I have time this weekend. I'll look at cleaning up anything in the 1.2.0 branch and go release an official version for once. Then I need to go ahead with reworking other areas of it and make it easier to use.

Followup to the Cell integration mentioned above: It will be implemented through the plugin system.  Since the eventual goal is to be engine-agnostic, this is another step in the right direction I think, having the user able to select the compiler backend to use.

In case no compiler plugin is available, there will be a barebones "copy if newer and generate SGM" compiler built into the core (it is also tolerant of the project and build paths being the same; in which case the copy step is skipped).  Since the IDE is useless without a build plugin, it made sense to have a fallback in place.

I think this might be a good idea in general to have fallbacks built in for important components.  The script editor would be a good candidate for this treatment I think.  It's important to ensure that the fallback components have no additional dependencies though, so implementing it editor-wide will need some thought.  It should also be set up so that despite being built in, fallback stuff is still registered through the plugin manager to avoid a bunch of special cases throughout the code.  To the rest of the editor, the default component would just be another plugin like any other.