Ok... I think I put too much time into this feature, but there was a lot of good merit to figuring this out.

I find it an extremely useful feature actually. Thanks for putting that extra time into it.

You can now MultiSelect tiles in the map editor. I had this feature once before, but not in the new map editor after I recoded it. Now bushes and such things would be easier to paint.

Woo!

My next step is to turn this into a completely plugin based system and switch it over entirely to Mono. Wish me luck on these two! I've already shown though, that I can make a plugin based editor since I had attempted one with Mono under Linux. But this time I want to see if I can convert my already mature project over. I think it can be done with a bit of know-how.

A full plugin system would be so amazing. Plugin-based TurboSphere + plugin-based editor opens up all sorts of AWESOME possibilities.

New Feature
Plugins! Plugins! Plugins!

I'm going to start the slow process of converting _everything_ into plugins, starting with a task list. My first test, loading a plugin, was a success and so was adding it to the editor so it can be effectively used. My next step is to add more communication between the host program and plugin so that with some coordination you can make certain types of plugins: new editors, like map or image editors; persistent widgets, like task lists; and menu options. Currently the interface between host and plugin is very, very limited. But that may change with time. I also *need* to make sure it's user friendly to create plugins.

A plugin needs only 3 dependencies:
1. Sphere.Plugins
2. WeifenLuo's DocPanelSuite
3. Sphere.Core

Sphere.Plugins provides the plugin/host interface
Sphere.Core provides useful objects that can open Sphere datatypes and other such things.
The DockPanelSuite is needed so you can attach your custom control into the editor environment.

Any other dependencies can be added. So, if you wanted to add gzip support as a plugin that adds a menu option, then you will need to put the gzip dependency (.DLL) in the editor's root directory and the plugin (.DLL) in the editor's /Plugins directory. The editor already loads all dll's at root anyways and so that is how that is done.

What kind of architecture are you using for your plugins? And what kind of linkage do the plugin DLLs need to have?

This is so awesome. Nice job Radnen!

Will the map editor be extensible? That way the entity editor, which I guess is a sub-plugin of the map editor, could be extended.

If you're curious how Wine handles the editor right now...

Code: [Select]

Unhandled Exception:
System.ArgumentException: An empty file name is not valid.
  at System.IO.FileSystemInfo.CheckPath (System.String path) [0x00000] in <filename unknown>:0 
  at System.IO.DirectoryInfo..ctor (System.String path, Boolean simpleOriginalPath) [0x00000] in <filename unknown>:0 
  at System.IO.DirectoryInfo..ctor (System.String path) [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) System.IO.DirectoryInfo:.ctor (string)
  at Sphere_Editor.SubEditors.StartPage.PopulateGameList () [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) Sphere_Editor.SubEditors.StartPage:PopulateGameList ()
  at Sphere_Editor.EditorForm..ctor () [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) Sphere_Editor.EditorForm:.ctor ()
  at Sphere_Editor.Program.Main () [0x00000] in <filename unknown>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentException: An empty file name is not valid.
  at System.IO.FileSystemInfo.CheckPath (System.String path) [0x00000] in <filename unknown>:0 
  at System.IO.DirectoryInfo..ctor (System.String path, Boolean simpleOriginalPath) [0x00000] in <filename unknown>:0 
  at System.IO.DirectoryInfo..ctor (System.String path) [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) System.IO.DirectoryInfo:.ctor (string)
  at Sphere_Editor.SubEditors.StartPage.PopulateGameList () [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) Sphere_Editor.SubEditors.StartPage:PopulateGameList ()
  at Sphere_Editor.EditorForm..ctor () [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) Sphere_Editor.EditorForm:.ctor ()
  at Sphere_Editor.Program.Main () [0x00000] in <filename unknown>:0 
Shutting down finalizer thread timed out.

What kind of architecture are you using for your plugins? And what kind of linkage do the plugin DLLs need to have?

I don't know yet, but here is what the test task plugin currently looks like (totally subject to change): here.

I'm in the process of trying to create an API that is both easy to use and offers a lot of flexibility. Basically the Plugin talks to the main program through the IPluginHost interface, which has method to add or remove widgets, menu items, and other such things. A plugin *has* to implement IPlugin or else it won't even be loaded from the .DLL file! Other than that, the rest is an open sandbox.

Hmm...

I wonder how hard it would be to create a 'soft-fat-binary' sort of thing. Like a plugin for a map engine, that your editor calls to have a map editor and TurboSphere calls to have a map engine. A plugin that supplies in one package both the runtime logic and support for anything it adds to the engine in the editor.

That would be pretty nifty. But probably very difficult to do.

Jest, that error you got was not just Wine, in Windows too. A result of an empty path list in the editor.ini, due to me adding the multiple paths feature. I have fixed the bug, and will release the newer version. Internally I have also changed it to use Sphere.Core library (which it had been using, but internally). Now, Sphere.Core is a separate class library with a full (and tedious) XML function reference. It will be used to help make plugins and so an extremely useful library for the developer.

I'll put the update up shortly. Edit: It is up.

I am not certain how sub-plugins will work. If you make a map editor plugin that requires itself a plugin to extend it. I guess in that case, I'll have to add a kind of interface? No, due to the freedom, I think if a plugin needs sub-plugins, you'll have to implement it's own plugin manager apart from the editor, with it's own IPluginHost that interfaces with just that plugin only. (eg, IMapPluginHost with IMapPlugins).

I think (from what I've been doing with plugins) that most of the time, sub-plugin sort of functionality can just as easily be a shared library that a plugin links with.

I was considering a sort of multi-way sub-plugin system, where a plugin would either put up functions to the engine, or ask for such functions from the engine. A sub plugin would just tell the engine it needs some function to be put up by another plugin. The engine would then give the asking plugin access to requested function from the supplying plugin. Although dependency checking could become quite complicated, the overall architecture of such a thing seems quite nice and clean.

Well then: a modular Sphere editor has finally arrived? Do the plugins have to be C# or can I use C++ instead?

I have a JSON-based "database" editor idea I've been kicking around for a week as an experiment on whether I can write a cross-platform app in C++ (likely using nall+phoenix) that dynamically creates a GUI for editable fields or not (similar to what WIP was making for ika).

The main purpose of this test app would be to see if I can replicate to any significant degree the info entry system in RPGMaker, but using JSON to not only store the info but to also determine how the info is presented/stored. I'll put up the theory behind my idea later in the week, as I do believe it's viable and would be one step closer to bridging that RPGMaker-Sphere gap AND helps me accomplish an old goal of mine to create such a bridge.

Well then: a modular Sphere editor has finally arrived? Do the plugins have to be C# or can I use C++ instead?

I don't know about C++... It might be possible? I mean .NET is .NET... right?

I have a JSON-based "database" editor idea I've been kicking around for a week as an experiment on whether I can write a cross-platform app in C++ (likely using nall+phoenix) that dynamically creates a GUI for editable fields or not (similar to what WIP was making for ika).

The main purpose of this test app would be to see if I can replicate to any significant degree the info entry system in RPGMaker, but using JSON to not only store the info but to also determine how the info is presented/stored. I'll put up the theory behind my idea later in the week, as I do believe it's viable and would be one step closer to bridging that RPGMaker-Sphere gap AND helps me accomplish an old goal of mine to create such a bridge.

So, you were planning that this might be a plugin?

Feature suggestion: Ability to change the font for the script editor.  Right now it appears to be hard-coded to use 10-point Courier New, which is murder on the eyes on a 1920x1080 17" laptop display.  I tend to prefer 11- or 12-point Consolas on this screen, but unlike the official editor, Sphere Studio doesn't appear to allow changing it.  I'd also like the ability to change the tab size.  The default tab stop of 2 is far too small.

@NEO: I was planning something like that (using Common Lisp instead of C++), basically to make a monster/item/party/whatever else editor for my RPG framework. It would be way easier to have it integrated with a map editor though, which is why I really want sub-plugins for the map editor (for monsters and stuff; items would have a top-level plugin).

Feature suggestion: Ability to change the font for the script editor.  Right now it appears to be hard-coded to use 10-point Courier New, which is murder on the eyes on a 1920x1080 17" laptop display.  I tend to prefer 11- or 12-point Consolas on this screen, but unlike the official editor, Sphere Studio doesn't appear to allow changing it.  I'd also like the ability to change the tab size.  The default tab stop of 2 is far too small.

Feature suggestion: Ability to embed Emacs for the script editor.
The one true text editor! (Although admittedly the defaults are horrible, once you customize it and make it more modern, the thing rocks.)

(Don't worry Radnen, I'm mostly just kidding. Although that would be amazingly cool....)

I was actually thinking of trying to move away from the scintilla script editor to something a bit different, a bit better such as the code editor used in mono develop. I have used it once before and I liked it (it highlights the changes you have made in your code, and looks a bit more modern).

But in the mean time, I'll have to try and look into adding a script font changer.

Well then: a modular Sphere editor has finally arrived? Do the plugins have to be C# or can I use C++ instead?

I don't know about C++... It might be possible? I mean .NET is .NET... right?

I'm trying to avoid vendor lock-in with my thing; there's already some by my using GCC 4.7 to get some C++11 niceties built into byuu's code but at least it's cross-platform.

[ ...snip... ]

So, you were planning that this might be a plugin?

I was actually planning on writing a standalone app for general JSON editing (and calling it NdbJSON until I had a better name), but if it can be integrated into a Sphere IDE that'd be pretty sweet. I think I was trying out libjson or json-cpp to see which works more cleanly, but if I can convince byuu to add JSON parsing to nall (or somehow write a nall-based parser myself) that'd be even easier for me.