<game>.ssuser is correct.  It shouldn't be creating any .ssuser files, those are probably remnants from older Studio builds.

I guess you're doing that for consistency with <game>.ssproj, then. Okay.

Yes, and also for future-proofing: Once the build pipeline is implemented and everything is customizable, a user might choose to have more than one .ssproj file in the same directory.  So the best way to handle that is to use the same filename for the user settings.

You're right. I wasn't thinking there might be more than one .ssproj file, but I suppose it's not too much to have an active project switch. In that regard consistency is key.

Yay, the game path setting finally works!

Yeah, I'm not sure what happened with your game directory, apparently one of your game.sgm files made it angry.    I made the SGM parser more error-tolerant so apparently that fixed it.  Let me know if you hit any more crashes, I'll fix them as quickly as I can.

Not a major issue, but I just noticed that if you close all of the sub-windows and press the close button in the upper right, it throws a details/continue/quit error.

Open Discussion Question

I was using the editor http://brackets.io/ and I liked the fact it was so responsive and cross-platform for being programmed in JS and HTML5/CSS3. I was thinking if this, if you guys would prefer a future Sphere engine to be programmed like this? Cross-Platform styled, and responsive. Running perhaps on mobiles as well?

I'm thinking of starting up this idea, but maybe I'll wait for Sphere Studio 2.0 to come out, or maybe it's better to stop progress right now? But I hate for all the hard work to vanish!! Lord English (aka fatcerberus) is doing amazing things right now to Sphere Studio what with the debug support and all that and I've paved the way for a new project management system that kind of models the Visual Studio .csproj and Solution files.

But there are 2 complaints I hear usually:

1. Not on their platform.
2. Doesn't open because you may not have .NET 4.5
3. (personal opinion) WinForms is outdated. We can move on to WPF, but how long will that last?

I think how brackets was programmed - and how it's UI looks - is a prime example of the future of desktop apps. Plus imagine writing plugins for it in JS and using JSON, etc.

What do you guys think?

I did dabble with GTK forms for Linux/Win/OSX with some success, using Mono, but I mean, Brackets didn't require, well, it didn't require anything really. You just download it, no thrills. Worked right out of the gate. That's what I liked about cross-platform app development with JS. It seems so... perfect.

Edit:
But of course it also wouldn't be hard to write a series of "total conversion" plugins for Brackets. It does require really getting to know Brackets, but at the end of the day the plugins I think would be 90% of the code we'd write anyways for a new editor environment.

I would support a HTML/JS-based version, because it'd be cross-platform from the get-go (I've been wanting to use Sphere Studio!) and allow me (as well as others) to contribute improvements much more easily.

Neither Brackets (dependency issue on Ubuntu 15.04) nor Atom (NPM error about Node) want to install, though. Not exactly a shining example of providing functional software (or installers, I guess)...

I have a suggestion for Sphere Studio. With the exception of searching through multiple files, replace the "Find and Replace" box with something that appears in the bottom of the text editing area, like Sublime Text, that allows you to search for text as you type, and has fields and buttons for finding and/or replacing text.

I have fixed a few regressions/bugs with running the engine with invalid paths when you switch between profiles. The profiles changed recently and I think it's good that I had outdated profiles to load up. It helped me identify holes when you have paths that are invalid or files that suddenly don't exist.

Anyways, I'm running into a problem where I can't run Sphere 1.5/1.6 games but both the engine path and arguments are correct.

Test game button, doesn't work for 1.5/1.6

Code: (csharp) [Select]

                string gamePath = Global.CurrentGame.Build();
                string path = ((ToolStripItem)sender).Tag as string ?? EnginePath;
                string args = string.Format("-game \"{0}\"", gamePath);

                if (String.IsNullOrEmpty(path) || !File.Exists(path))
                {
                    // show a message if you switch to a project with an invalid path.
                    MessageBox.Show("Error: Could not find engine in path specified.");
                }
                else
                {
                    Process.Start(path, args);
                }

But if you right-click the game in the Start Page and choose play, it works every time:

Code: (csharp) [Select]

            if (!File.Exists(Global.Settings.EnginePath)) return;
            string args = string.Format("-game \"{0}\"", _proj.RootPath);
            Process.Start(Global.Settings.EnginePath, args);

In the forner section I get:

Sphere
Could not open game...
*path here*

It's so weird. The paths and args match completely.

Huh.  I'll look into it.  It's possible I broke something when I implemented the config manager.

Huh.  I'll look into it.  It's possible I broke something when I implemented the config manager.

No, I think it's the fact Sphere 1.5/1.6 doesn't accept paths with game.sgm tacked on to the end of it, but minisphere and SSFML are okay with that.

Edit:
Ok, I'm not sure if Build() should return the full path/to/game.sgm or if it should only return path/to. So far it's used when you test a project - which uses the Build() method to run the game. Trouble is, Sphere 1.5/1.6 does not like taking the game.sgm in the path (not too clever if you ask me). I guess Build() will return path/to/game.sgm and in the test game method I just strip out the end part of the path.

Luckily .NET makes that easy:

Code: (csharp) [Select]

string dirpath = Path.GetDirectoryName(filepath);

I love the .NET Path APIs, they're awesome.  The only thing it seems to be missing is a method for canonizing paths (stripping out /../ etc.) which has bit me a few times with the debugger, e.g. opening two copies of the same file because the relative path specified by the game was different.

minisphere should accept just the path, not sure about SSFML, you'd know that better than me.

Code: (csharp) [Select]

string dirpath = Path.GetDirectoryName(filepath);

Oh, I didn't do that. I used .replace(@"/game.sgm", "") I entirely forgot about the Path API completely. I've been programming in too many other languages and libraries (namely, JS).

I'll make a stylistic fix to fix that fix.

Edit: aand... done!

Yeah, I really miss the Path API whenever I use anything other than C#, it saves me from a bunch of tedious path parsing and regular expression hackery.  Allegro has its own path API too (more object-oriented than .NET's though), which was very much appreciated for implementing minisphere.

By the way I didn't want to pollute the Sphere Studio repo with minisphere-specific stuff, but it was just easier to work on the debugger with it as part of the project, especially since I had to change around a lot of other internals to accommodate it.  The Plugin API still hasn't fully stabilized, yet, unfortunately.

By the way I didn't want to pollute the Sphere Studio repo with minisphere-specific stuff, but it was just easier to work on the debugger with it as part of the project, especially since I had to change around a lot of other internals to accommodate it.  The Plugin API still hasn't fully stabilized, yet, unfortunately.

Right, technically the minisphere debugger is a third party plugin. But yes, I think the debugger should stay in the repo for now since it is still experimental and is being used to flesh out other parts of the system. Someday it can be stripped out, but it's better not to right now.

I'm right now working on an entity list like what Sphere had. I've been working on a game recently and I'm seeing a few things that I'm wanting to fix and this entity feature would be nice. It's good for bulk edits and managing or searching for hidden entities. I even may want to add a search bar to the map editor which will scroll into view the entity you search for.

By the way I just pushed a commit to revamp the dock panel system.  The DockDescription system seemed a bit clunky, so it's much simpler to use now:

Code: (csharp) [Select]

IDockPane pane = PluginManager.IDE.Docking.AddPane(ctrl, "My Panel", icon, DockHint.Right);

pane.Show();
pane.Hide();
// etc.

PluginManager.IDE.Docking.RemovePane(pane);