Quote from: Lord English on August 15, 2015, 01:45:47 am<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.
<game>.ssuser is correct. It shouldn't be creating any .ssuser files, those are probably remnants from older Studio builds.
Open Discussion QuestionI 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.53. (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.
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); }
if (!File.Exists(Global.Settings.EnginePath)) return; string args = string.Format("-game \"{0}\"", _proj.RootPath); Process.Start(Global.Settings.EnginePath, args);
SphereCould not open game...*path here*
Huh. I'll look into it. It's possible I broke something when I implemented the config manager.
string dirpath = Path.GetDirectoryName(filepath);
Code: (csharp) [Select]string dirpath = Path.GetDirectoryName(filepath);
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.
IDockPane pane = PluginManager.IDE.Docking.AddPane(ctrl, "My Panel", icon, DockHint.Right);pane.Show();pane.Hide();// etc.PluginManager.IDE.Docking.RemovePane(pane);